Review: Inspired by Marty Cagan

A worthwhile read on how to build tech products, with some good insights.

It does take a bit of work to figure out those insights. The book is broken down into 60+ tiny chapters (many chapters are just 2 pages long), with lots of closely related content confusingly split up across multiple chapters (almost as if the book authoring software didn’t support headings/subheadings), and lots of content repeated in multiple chapters, all of which makes it hard to build a clear mental model of the author’s advice. The book also spends a bit too much time worshipping product managers, as if they are some kind of heroes, above and beyond everyone else in a company. I suppose this is par the course for this sort of book: most design books worship designers, most entrepreneurship books worships founders, and so on.

Despite a few flaws, I found a lot of useful content here. Here’s a summary of my learnings:

The two inconvenient truths about product

Truth #1: at least half of your product ideas won’t work.
Truth #2: even for product ideas that have potential to work, it’ll take multiple iterations to get the implementation to the point where it delivers business value. This is called “time to money.”

No matter how smart or talented you are, there is no escaping these two truths. Instead, you need to build a product process that embraces these truths, and succeeds despite them.

Three overarching principles of effective product development

1. Tackle risks up front, rather than at the end. Before building the product, you should gather concrete evidence to address the key product risks:

   • Value risk: will customers choose it and buy it?
   • Usability risks: will customers be able to figure out how to use it?
   • Feasibility risk: can our team build it?
   • Business risk: does this work for our business in terms of sales, marketing, finance, legal, ethics, etc?

   It’s essential to address all these risks, but it’s worth noting that, in many cases, value risk is the trickiest one. In order for a customer to change how they work and pick your solution, your solution can’t be just a little better: it must be demonstrably and subtantially better. Think 10x, rather than 1.1x. That’s a high bar.

2. Define products collaboratively, rather than sequentially. Although many teams talk about agile, in practice, their process is still sequential and waterfall-like, starting with a PM gathering requirements, a designer coming up with a design, engineering implementing the design, and so on, moving down the line, where each team is entirely dependent on the work of the team before them. The better solution is for all these teams to work side by side and concurrently/iteratively.

3. Focus on solving problems, not implementing features. Or, said another way: fall in love with the problem, and not the solution; after all, as per the “two inconvenient truths about products,” your first few solutions are not likely to work! This has an interesting implication: the traditional product roadmap is an anti-pattern. After all, most product roadmaps are prioritized lists of proposed solutions, and most of those solutions likely won’t work (as per “two inconvenient truths about products”); not to mention that spending lots of time up front on roadmaps is yet another sign of a waterfall process. Therefore, instead of roadmaps that focus on solutions, you should create roadmaps that lay out the key problems to solve; and instead of having teams focus on outputs (build feature X from our roadmap), you should create teams that focus on outcomes (solve problem X from our roadmap and achieve a specific business result).

Dedicated, empowered product teams

One of the key insights in this book is to move away from traditional team structures to dedicated, empowered product teams. Here are the key differences:

1. Dedicated product teams are cross-functional teams that have just about all the skillsets they need on the team: a product manager, a designer, some engineers, etc. This allows the team to (mostly) independently deliver products.

2. Instead of jumping from project to project all the time, dedicated product teams own on a single product over a long time period, and do many, many iterations on that product. This helps address the “two inconvenient truths” in point (1).

3. Instead of some exec handing the team features to build (“feature factory”), the team is given problems to solve and business results to achieve, and it’s up to the team to figure out how to get that done. The idea is to have teams of missionaries who are excited about solving the problems handed to them, rather than mercenaries who are just paid to execute someone else’s orders.

4. The team is judged on outcomes rather than outputs. The focus isn’t on shipping a feature, but on achieving specific objectives. So the team isn’t off the hook just because something launched; they aren’t off the hook until they have achieved the results the business is looking for.

Mission, vision, and strategy

Mission: this is the why. Your mission should explain why your company exists. It should be a big, long-term goal, that is inspiring, is clearly associated with your company, and remains fairly constant, even if the products you build to achieve that mission change.

Vision: this is the what. Your vision should paint a clear picture of what your company is trying to create for your customers. Two key points on vision. First, it should be unified: that is, you should have one product vision for the whole company, and not one vision per team. You want a single north star that everyone is working towards: a shared, common understanding of what you’re all trying to achieve and the role each team plays. Second, the vision should be inspiring: it must motivate the team, so everyone feels the work is meaningful and exciting, and does extraordinary (remember, you want missionaries, not mercenaries); it should be a powerful recruiting tool to hire new team members; it should be an effective evangelism tool that persuades your company, investors, and customers of the value of what you’re doing.

Strategy: this is the how. The strategy specifies how your team will accomplish its product vision.

Product discovery

The goal of product discovery is to address the key product risks mentioned earlier (value risk, usability risk, feasibility risk, etc). You address these risks not by building the product, which can be very expensive, but by running lightweight experiments. Strong product teams run dozens of experiments per week. Some of the discovery techniques mentioned the book include:

• Work backwards: write a fake press release to announce your product before building the product. Alternatively, write a fake “customer letter,” pretending to be a happy customer emailing your CEO to explain how the new product has improved their life; you may even want to include an imaginary follow-up email from the CEO to your team explaining how the product has helped improve the business. This helps both in addressing value risk (if your team isn’t excited by the press release or letter, perhaps there isn’t enough value in the proposed product) and helps you really focus on the most important problems to solve (after all, press releases and letters are typically short, so you have to pare them down to the things that really matter).

• User story mapping: create a two dimensional map to represent the entire user journey. At the top, from left to right, you lay out major user activities as cards, roughly in the order you expect users to do those activities. Then, from top to bottom, you add additional cards that go into more detail on each of those major user activities, breaking down all the subtasks (“user stories”) of what the user does to accomplish their goals. This way, at a glance, you can have a map of the entire product experience, which helps to flush out whether the solution really solves the problem, the work involved, and so on. You can also sort the detailed tasks in the vertical columns to put the highest priority ones near the top, and draw horizontal lines to define releases or milestones.

• Prototypes: instead of building the full product, build tiny prototypes of specific parts of the solution, and test those prototypes. The prototype could be a wireframe, a high fidelity design, a partially working implementation (e.g., static HTML/CSS/JS with mock data), a landing page, etc; the testing will initially be with your own team (merely creating a prototype will reveal a ton of valuable insights) and then as soon as possible, with real customers. The idea is to address the key risks, head on, at a tiny fraction of the cost of building the full product.

• Reference customers: first, pick a target vertical: e.g., customers in the financial sector. Next, find 6 customers in that vertical who are keenly feeling the pain of whatever problem you’re trying to solve and willing to use an early version of your product (note: to end up with 6 customers, you may have to recruit 8-10, as some may drop out; if you’re having trouble recruiting, that may be a sign that there’s not enough market demand for what you want to build). The key idea is that you will let them use your product initially completely for free and you’ll work with them very closely to iterate on that product until it fits their needs (note: this is NOT consulting; your goal is to build one general-purpose product that solves this problem, not 6 custom solutions; however, input from 6 real customers helps you build a much better general solution). If, and only if, the customer is successful with your product, then they agree to (a) start paying for the product and (b) to be a reference customer, in that you can use that company’s name + logo in your public product launch, marketing materials, sales process, etc. By using this process, you not only end up with a far better product, but you also end up with 6 happy customers in a vertical that your sales and marketing teams will be able to use to sell to all the other companies in that same vertical (“look how well our product works for these other important companies in the financial industry…”). You can then repeat the process with other verticals.

• Hack days: assign your team a specific problem to focus on, provide 24h, and let everyone come up with prototypes and proposals for solutions. Some of the best ideas and insights often come from the people doing the implementation work (e.g., engineers) and not the product team.

• Value tests: when testing ideas with a customer, it can sometimes be hard to tell if they are saying something just to be nice to you or because they really mean it. Some ideas for working around this: (a) Money test: ask the customer if they’d pay a specific amount for the product. Even if you aren’t intending to actually charge them, seeing if they are willing to pull out their credit card right there is important. For expensive products, you can even ask if they’d sign a “non-binding agreement” to pay for the product when it’s ready. (b) Reputation test: ask the customer if they’d recommend the product to friends or coworkers. You can even ask them for the contact details of specific people they’d recommend it to, even if you aren’t going to use those emails. (c) Time test: ask the customer if they would be willing to commit to spending a significant amount of time workign with you on the product. (d) Access test: ask the customer if they would provide credentials to the products they are currently using as part of switching to your product. You wouldn’t actually save these credentials; it’s just to see how serious the customer is about switching.

Rating: 4 stars