Forget features, understand pain points and needs, says Crowdfire's Abhishek Madhavan.
In Summary: Most tech companies have great engineers that are itching to build whatever they are asked to build. That's the easy part. What to build is the million dollar question.
Good PMs keep shipping but great PMs go back to the user every time they ship something.
PMs that take the time to do this understand what their customers want and eventually develop an understanding of why customers want what they’re asking for.
Companies who succeed over the long-term are those who define themselves by their customers’ needs and desires, not by the longevity of their products.
Platform Product Management requires different skills and a different career path, says Optimizely's Wyatt Jenkins
In Summary: The job of a platform Product Manager is to evolve a component or set of components that are used by multiple consumer products and potentially end users as well.
Platform PM’s have to understand their customers and their customer’s customers in order to be successful. Platform product roadmaps require a long term view because of the need to set expectations with a wide variety of stakeholders.
Platform Product Managers often need to be technical because the problems they are solving are the traditional computer science problems of scale, maintainability and architectural design.
Understanding how platform Product Management changes your product organisation can be the difference between a company that is built to last and a one-trick pony.
A framework for analysis from Hubspot's Chris O'Donell.
In Summary: Chris believes there are four levels to showing impact and value creation during the product development cycle.
Level 1 is anecdotes, Level 2 is usage and engagement, Level 3 is enterprise value and Level 4 is customer value. The journey through these levels takes the PM from pure instinct to showing that their product generates business value and actually changes the customer’s life.
PMs at Level 1 should focus entirely on getting those first few people to love and depend on their product. It’s not yet the time to obsess over metrics or to over-analyse. Level 2 is about instrumenting tracking and developing basic discipline around measuring engagement.
Level 3 focuses on tying usage and engagement data to business outcomes. Level 4 shifts the focus from the value your company is getting out of your product, to the value your end users are getting.
Product Managers should know their measurement level and that it's a choice on a spectrum that changes over time as their product matures.
Intercom's Des Traynor shares everything he's learnt about product over the years. Lengthy, but well worth the effort.
In Summary: Without a product vision, you will flip-flop frequently as you don’t really know what you’re trying to do. You need to consider what the future of your product's domain looks like and the tech trends that make it possible.
Gall’s Law states that a complex system built from scratch will fail. It can’t ever be made to work. That's why it's important to start small.
Thinking you’re just one more feature away from mass adoption is a fallacy. If you can’t distill the problem you’re trying to solve down to an initial release that people actually want, forget about expanding it. Good beta users will give you data that lets you know when you cross the 'good enough to use' line.
You have to understand your real competitors as well as your users' switching behaviour. Most companies think their product is 3x better than it actually is. You need to maximise your product's attraction and minimise people's anxiety to change.
Most new features, even built well, still flop. When you’re improving features, you have to understand the tradeoffs between quality, importance, satisfaction and frequency.
As you get more aware of your domain over time you may change your opinion and you should act on that change.
Michael Marfise summarises the mistakes he and his team have made in respect to MVPs and Lean Startup theory.
In Summary: Like many, Michael feels that he never conducted real experiments. He would show product previews to customers but not conduct actual A/B tests. He also allowed 'MVP' to mean something different to everyone. Most assumed it meant the first version of a product that is built and launched.
His team also thought of 'minimum' the wrong way, tending to focus on 'how to build x' rather than how to get from Point A to Point B. One of the most common mistakes made by lean Product Managers is asking users ‘Do you want this?’ But this tells you very little. Anyone will take anything for free.
Product Managers should use the term MVP cautiously and ensure they are focusing on value and validation. The goal of an MVP is not to launch the first version of a product. It’s simply to start gathering feedback and observe users interacting. This distinction is critical.