Inspired: How to Create Tech Products Customers Love

Recommended by Alfonso Graziano on Gitbar for those in Product Management. Mega bestseller. Also suggested by my PM Lotte. Good summary: https://t-ziegelbecker.medium.com/a-summary-of-inspired-by-marty-cagan-9d94e1eeb4bd

Excellent book. I really liked it; it opened my eyes to the role of the Product Manager and how hard it is to build a good product and understand what people want. It drags on a bit at the end and tries to reinforce the vibe with stories of Product Managers (like the one who split Word for Mac from Word for Windows).

Notes

• No more roadmaps. That waterfall setup where the requirement comes from the customer or sales, you discuss, you make a roadmap, is outdated. The push should come from devs and managers, let ideas move fast, and test.
• The old style: you build features no one cares about and then polish them. The team is not involved, design does not work in sync, and more.
• The issue is that about half of our ideas will not work. Requirements change, people want something else. So we need to fail fast.
• Also it takes multiple iterations to make things work before delivering value, but often the business is afraid and in a rush. The team gets involved too late to evaluate the idea.
• Risks must be addressed up front, not at the end.
• A good team is key to a strong product. They should be aware of the risks (value, usability, feasibility, business viability). They should collaborate across the parts and, above all, solve a business problem.
• Questions to ask during discovery:
  • Will the user pay for it? (value)
  • Can the user figure out how to use it? (usability)
  • Can we build it? (feasibility)
  • Can our stakeholders support it? (business viability)
• Fall in love with the problem, not the solution.
• Promise yourself not to waste time on useless features until you are sure the customer needs them.
• Two pizza rule. A team should be at most what two pizzas can feed (8 to 12 people).
• The PM role is tough. Understand the customer and the product. Sit next to every member of the team: Design, Engineering, Marketing. Also the customer, the tester, anyone who touches the problem.
• Having strong players, in sync and aligned, is key. Share challenges and problems with them; do not shield or hide them. Everything should be in sync.
• Use analysts and marketing to get more insights on how to sell well.
• So the roadmap should be bottom up, with lots of prototypes, fail fast, and iterate. Identify high value items first and avoid committing too hard in one direction. Stay flexible.
• More nebulous chapters on the various stakeholders (head of sales, head of engineering, etc).
• Also nebulous chapters on vision, strategy, and OKRs. OKRs are discouraged and complicated. In a startup it is simple: bring in cash.
• The main job of a product manager is discovery. Ask questions like
  • Will the customer buy it? (prove value)
  • Will users figure out how to use it? (check usability)
  • Will we be able to build it? (ask about feasibility)
  • Will our business benefit from it, and will we cover the costs? (verify viability)
• Do not try to please everyone. Pick a market segment and test there.
• Never tell people how to do something. Tell them what to do and they will surprise you.
• Having a solid demo and prototype matters. Present it well so stakeholders can get a feel for what you are building.
• Be excited about the product. Otherwise you will not inspire others.
• Without a strong product, marketing cannot sell, which leads to requests for more features, which wastes more time, which means you still do not have a strong product.
• The customer often does not know what they want, so we need to discover and test their needs and share what we have done.
• Techniques for doing this:
  • Framing (align on goals, do an assessment with an enlightened customer on what is needed)
  • Planning: story mapping, activities and stories to identify the system, or leverage a Reference Customer, your nurtured customer who promotes you to others for free
  • Ideation: customer interviews and tests, hack days, prototyping
  • Official tests like usability testing, viability, value testing, etc. For that you need a working prototype
• How? It suggests design sprints, weeks where devs can invent and build what inspires them.
• Culture: a good team tests a lot, validates ideas with the end customer, knows they will often fail, and celebrates outcomes, not features. They focus on the problem.