“Inspired - How to create tech products customers love” By Marty Cagan is a highly recommended read for all product managers.
This is the second part of a 3-part series; the series being a summary of the key points from the book that resonated with me. You can find Part1 here and Part3 here.
“We need a team of missionaries, not team of mercenaries.” Mercenaries build whatever they’re told to build. Missionaries are true believers in the vision and are committed to solving problems for their customers.
The PM is responsible for reevaluating opportunities and determining what gets built and delivered to customers. The PM should have a deep knowledge of the customer/product, data, business and the market and industry.
We need design, not just as a service to make our product beautiful but to discover the right product. In strong teams today, the design informs the functionality at least as much as the functionality drives the design. This is a hugely important concept. For this to happen, we need to make design a first-class member of the product team, sitting side by side with the product manager, and not a supporting service.
There’s probably no more important relationship for a successful product manager than the one with your engineers. The morale of the engineers is very much a function of you as the product manager. It is your job to make them feel like missionaries and not mercenaries. You do this by involving them deeply in the customer pain you are trying to solve and in the business problems you face.
One of the key themes of this book is focusing on outcome and not output.
Typical roadmaps are the root cause of most waste and failed efforts in product organization. The issue is that anytime you put a list of ideas on a document entitled “roadmap”, no matter how many disclaimers you put on it, people across the company will interpret the items as a commitment. And that’s the crux of the problem, because now you’re committed to building and delivering this thing, even when it doesn’t solve the underlying problem.
The key takeaway is that we need to solve the underlying problem, not just deliver a feature.
For the product teams to be able to figure out the best ways to solve the particular business problems assigned to them, the product teams need to have the necessary business context. They need to have a solid understanding of where the company is heading (the product vision and strategy), and they need to know how their particular team is supposed to contribute to the larger purpose (business objectives).
Outcome-based roadmaps is where each item is stated as a business problem to solve rather than the feature of project that may or may not solve it.
When there is a need to commit to a date or a specific deliverable, the team can resort to a high-integrity commitment.
For this, we would need to ask the stakeholders to give us a little time in product discovery to investigate the necessary solution. We need the time to validate that solution with customers to ensure it has the necessary value and usability, with engineers to ensure its feasibility, and with our stakeholders to ensure it is viable for our business.
Once we have come up with a solution that works for our business, we now can make an informed and high-integrity commitment about when we can deliver and what business results we can expect.
The concept is straightforward and based on 2 fundamental principles:
“Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity”. This is fundamentally about how to empower and motivate people to get them to get their best work.
“When performance is measured by results”. The idea is that you can release all the features you want, but if it doesn’t solve the underlying business problem, you haven’t really solved anything. This is about how to meaningfully measure progress.
Hope you found these notes helpful. Do checkout Part1 and Part3 of this series too.