My friend and colleague Garrett Dimon wrote about his experiences building and selling a product in his post Hindsight. He gives some advice based on what he learned. You might not agree with everything, but I think his perspective is really interesting and worth checking out. For example, on the balance between building product and doing marketing:

I don’t want to build an operational system to grow a business and then spend no time on the product. I want to design a company to build the product and serve customers. That’s not to say that there shouldn’t be some type of marketing that will need to be done, but I’d rather find ways where marketing is a by-product of the software rather than a separate activity. Checking analytics and numbers eventually becomes relevant for a business, but it’s a spectrum. I want to check the numbers to make sure the business is healthy, but I don’t want to be in a situation where I’m spending days analyzing or optimizing.

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.

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.”

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.

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.

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.

In the article From Four Wheels to Two RJ Marsan talks about the Lyft engineering team’s principles for quickly and safely adding major features to a mobile codebase. It’s full of interesting learnings as they went through the process of adding scooter rentals to the app. Here’s a good point about trying to avoid doing everything in the first release of a new feature:

Every new feature is a chance to start with a clean slate, and it’s often tempting to immediately build for scale. We all want our products to launch to massive fanfare and usage, but more often than not, the path to success for new features is slow and steady. With steady growth in mind, we designed our first architecture to support exactly what’s needed for our first product iteration, and nothing more. For Lyft Scooters, we cut out many features one might expect from a classic ride such as sharing ETA or setting a destination.

Prioritize Opportunities, Not Solutions is a really good post by Teresa Torres about using the Opportunity Solution Tree methodology to make sure we place lots of product bets early on in a lifecycle, and only implement the ideas that matter. I also like her distinction between one-way door decisions (“once you’ve walked through the door, you can’t turn around and come back through”) and two-way door decisions:

Your opportunity assessment and prioritization decisions are two-way door decisions. Once you choose a target opportunity, you’ll test whether or not you made the right decisions by prototyping and experimenting with solutions that address those opportunities. If you learn through experimentation that you didn’t choose the best opportunity, you can always walk back up the tree and choose another opportunity.