Why copying competitor features doesn’t work, and what to do instead

I think most of us know by now that merely copying competitors’ features or business models is a bad idea. Jesse Weaver’s Emulation Is Not a Product Strategy does a very good job of explaining why this approach almost never works, and what to focus on instead. One example:

In focusing their efforts on emulation, product managers stop considering options that could enhance what is unique about the company and its customer base. They miss chances to deliver something powerful and unexpected. Instead, product managers should focus on unique strengths — those things their customers came for in the first place. In doubling down on those, product managers can exponentially increase a product’s value, deepening customers’ connection to the specific magic that makes a product special.

Podcast recommendations: interviews with Teresa Torres and Tim Herbig

Product Management podcasts are a bit hit and miss, but this week there were two discussions that I found really interesting and useful.

First, on the Product Science Podcast, an interview with Teresa Torres on continuous product discovery:

Teresa Torres is a product discovery coach and the author of the Product Talk Blog. She spends most of her time coaching cross-functional product teams on how to adopt continuous discovery practices. On this episode of the Product Science Podcast, we get into how you can refine your product discovery practices.

And on the Product Experience Podcast, Tim Herbig discusses how to be an effective product leader when you don’t have “official” power:

Tim Herbig has made many mistakes (who hasn’t?). Fortunately for us, Tim not only owns up to his mistakes, he’s written a book to help the rest of us avoid making the same ones. We’ve all had issues with how to work best – not only within our individual teams, but with the rest of the organisation as well. In our conversation, he shares some simple and practical methods to diagnose when you have a problem and how to solve it.

Tim references Teresa’s work in his conversation, so the two episodes are really complementary as well, which is a nice bonus. Tim’s agile peer canvas to foster empathy within a team is also really interesting and worth looking into.

Startups die at the mercy of go-to-market, not at the hands of product.

This interview with former Google and Flipkart product leader Punit Soni covers a lot of ground and is interesting all the way through. His thoughts on the importance of a go-to-market strategy is so important, and a trap many product managers fall into:

When an idea is finally in sight, it may be tempting to jump feet first into product building. According to Soni, founders need to resist the impulse to obsess over product to the exclusion of everything else at the very beginning. “It’s tempting to slip into a ‘build it and they will come’ mentality, especially if you’re convinced of your own product prowess. Now I’m a product manager through and through, but I’ll be the first to tell you that product usually isn’t the issue,” he says.

Instead, tackle go-to-market, working through who’s going to buy, why and what they would pay. “Product is more binary in that, either the tech will allow you to do it or it’s not possible. Making sure that you can build a sustainable business model around that product is a far tougher task,” Soni says. “Figure all of that out before you start a company, not as you go along. Once you check that box, then you can become a product-focused company.”

The best approaches to onboarding new product managers

I really like Vrushali Paunikar’s approach to onboarding new product managers in an organization. In particular, the focus on three different time horizons with distinct goals is very important:

The first 30 days are about breadth. Put together a 30-day checklist broken up by people, product, and process to help your PM gain context and develop peace-time relationships.

The first 3 months are about perfecting execution. Give your PM projects she can actually launch within the 3-month window to help her establish early wins as well as learn your product development process.

At the end of the first 6 months, your PM should have a point of view on the direction of her product. Set this expectation early and empower her to own product strategy and vision.

One crucial point that is implied but not explicitly stated in Vrushali’s post is that PMs should avoid coming in with guns blazing in the first month and try to change/introduce a bunch of stuff. The first month is about really, truly, honestly listening and understanding. You’ll have plenty of time to have an opinion. Make sure you understand the context of the company and the product before you start having and communicating them.

For further reading on this, a while back I also wrote about What a Product Manager should focus on in the first 90 days.

The product manager’s goal is not to win, but to get the best outcome

In Egoless Innovation Sari Harrison reminds us that ideas are not personal. As product managers our goal should always be to get the best outcome, not to win or be right or for everyone to “just get along”:

When the idea you are advocating for gets challenged, an egoless innovation mindset means choosing to see the challenge as a gift to the innovative outcome which the idea hopes to someday become. It means looking objectively at the input, responding to it authentically, saying “wow, good point, I’m going to take that back to the team” if it was a point you hadn’t considered and saying “yes, we thought of that and…” if you have. It means you don’t get flustered by questions or negative comments because you are focused on achieving the best outcomes, not your own status. If you can embody this, you will be helping move the culture towards more and more innovation occurring with less and less friction. And you will be more successful.

When it’s appropriate to rewrite your software

Herb Caudill’s Lessons from 6 software rewrite stories is an extensive analysis of the rewrite projects of companies like Basecamp and Trello, why they succeeded or failed, and what we can learn from them:

Once you’ve learned enough that there’s a certain distance between the current version of your product and the best version of that product you can imagine, then the right approach is not to replace your software with a new version, but to build something new next to it — without throwing away what you have.

Eventually all product managers face a decision like this, so I found these case studies invaluable.

“Why Not?” is a bad reason to ship a feature

I agree with Chris LoSacco that “Why Not?” is a dangerous questions to ask for any product team:

Often stakeholders assume that if their ideas aren’t bad, they should be on the roadmap. “This isn’t hard; let’s get it in front of the engineers.” But the burden of proof is the other way around — ideas should get turned down unless they clear a high hurdle.

Just because a feature is easy or obvious doesn’t mean you should build it. This is why I prefer the question “Why Now?”:

What is the danger of not doing this project right now? If we don’t solve this problem or add this feature right now, what do we lose? Are sign-ups going to drop? Are we going to lose customers? Are we going to miss a major shift in the market? If so, then, yes, now is a good time to work on it. But if the room suddenly falls silent and everyone comes up short on the downside of skipping over the idea, that’s a pretty good indication that it can wait for later.

Accountability, tripwires, and other product management lessons learned on a failed project

This is an incredibly brave and insightful post by Erin Chan that I think every product manager should read. In The Hard Thing About Complex Products & How I’ve Grown as a PM she describes a long, failed project at Shopify in detail, and what she learned. The section on creating “tripwires” for complex projects is something I’m going to start using immediately:

A tripwire is a mechanism or an indicator that you define, and when it gets triggered, flags are raised.

For example, you should set the tripwire of ‘time’ when a milestone isn’t completed after a defined period (for me, this should have been two months). When that happens, my recommendation is to have a serious discussion with the team and make your Leadership and stakeholders aware of what is happening. Communicate the changes that you will make to the team or process to get the project back on track. Next, outline what happens if the milestone isn’t completed in three months, then four. These are your tripwires as determined by time, but you can define tripwires in whatever form you see fit for your initiative.

What I look for in product management software

I’ve had this vague sense for a while that I need to dig into the product management software space a lot more. So on Friday I just did it — I signed up for a bunch of accounts and started playing around. As I went through each product I realized two things:

  1. I didn’t know what I was looking for.
  2. Most of the products I was looking at didn’t know why they wanted me to use it either. The landing pages are all great, but once I was in the product, it was like a different (and very confusing) world. Which is kind of ironic for a product that’s aimed at product managers.

So I took a step back and asked myself why I’m actually doing this. What are the issues I’m hoping to address with software? What am I looking for?

In short, I am looking for a better way to plan. JIRA is a great execution tool — I don’t want to change that part. But JIRA is a terrible planning tool. And our current process of using Basecamp and Dropbox Paper for planning works just ok for me. The combination lacks a bunch of things to make it as effective as it can be.

I then identified what I would need to feel like our planning and scheduling process is effective and efficient:

  • A visual, lightweight, flexible representation of our product ideas and overall strategy, to help us with prioritization.
  • Prioritization scoring (customer / business impact, effort, etc.). I’d like to try a version of RICE at some point, but it should be flexible enough to use whatever system we want.
  • Incorporating, summarizing, and linking customer feedback from a variety of sources. We currently do this in JIRA, and it’s not a great workflow.
  • A way to go from general idea to product specifics in an orderly and predictable fashion. Right now we use JIRA, Confluence, Dropbox Paper, and Basecamp, and that can get a little confusing.

This gave me the framework I needed to evaluate the different products I was looking at. I’m not done evaluating, but right now productboard is the one that seems to fit our particular culture and goals the best.

productboard overview

Here are the list of things productboard has going for it:

  • The one thing that makes it stand out from all the others is that it’s a flexible system rather than a process (see the overview diagram above). Instead of forcing a particular software development process, it has no opinion on the specific methodology you use to prioritize and get work done. It’s focused on letting you use your own way to gather customer insights, define business goals, and prioritize work.
  • It will let us gather all user insights together, and prioritize features based on our goals and objectives (or “drivers” in the productboard language).
  • It will let us easily share, communicate, and change the plan without getting too formal about it.
  • If we wanted to, we could have a public-facing portal to get feedback on ideas, like this.

Oh, and their Why productboard? page is pretty solid, especially this phrase:

a way that provides transparency, fosters collaboration, and encourages alignment with the broader product team.

I’m not done evaluating yet, and who knows where we’ll end up. But I thought I’d share my initial thoughts and explorations of this interesting meta-industry.

Software should be designed for teachability rather than learnability

Related to the podcast discussion I shared the other day, Andy J. Ko wrote a really good essay called The problem with “learnability” in human-computer interaction. He argues that most software is learned socially, not independently:

We just have to think about our own personal experiences to see that nearly everyone learns how to use all but the simplest software socially, not in isolation. Our friends and family introduce us to new software and teach us how to use it. Our parents call us and ask for help troubleshooting software behavior they don’t understand. Our children teach us about new apps.

He then goes on to ask what it would look like if we designed software for this kind of social learning:

What would it mean to design for teachability rather than learnability? It might mean supporting the creation of not just one tutorial, but a myriad of tutorials, each supporting learners with different prior knowledge and interests. It might mean software companies having their app’s splash screens start with the question, “How do you want to learn this app?” rather than dropping users to a home screen and giving them a few tooltips. It might mean designing software to have teacher modes, where someone could go through and annotate key parts of the interface for someone they are teaching how to use an application (e.g., “Dad, remember to always click this box this before you submit!”).

These are good questions to think about as we work on product onboarding strategies.


  1. 1
  2. ...
  3. 9
  4. 10
  5. 11
  6. 12
  7. 13
  8. ...
  9. 134