Inspired – How to Create Tech Products Customers Love – Marty Cagan

Author: Marty Cagan Type: #book

• Behind every great product is a product manager. PM is the person who leads product teams to build something that's valuable for customers and makes sense for the business.
• Typical product team consists of a PM, product designer and several engineers.
• Companies of different scales are facing different challenges:
  • Startups need to find product-market fit
  • Growth companies strugle with teams not knowing how their work fits/contributes into larger goals and not being empowered/autonomous enough
  • Enterprise companies struggle with innovating. Their teams don't have enough empowerment to bring real innovation. They lack vision (because the founding vision was perhaps achieved)

Why waterfall doesn't work (aka Root Causes of Failed Product Efforts)

• Sales- or stakeholder-driven ideas are usually not the best for products
• Deciding based on "business cases" (how much will X make vs. how much will it cost), because you cannot know early in the process.
• Many product ideas won't work -> it's not a good idea to build out big product roadmaps based on them. And even if they do, it takes time to develop them: Time to money – it typically takes several iterations to develop a product idea enough to deliver the necessary business value.
• PM's job shouldn't be just gathering requirements and documenting them for engineers. Product manager's job is to decide what to build next. To do their job well, Product managers have to have deep knowledge of customers.
• Engineering should be involved early in the product development process. They are one of the best sources of innovation.
• Customer validation happens at the end of the process. The risk is at the end, way too late.
• There's opportunity loss. Working on something nobody needs loses you time and money that you can't get back.

Three principles of working agile

1. The Four product risks are addressed early in the process, instead of at the end.
2. Products are defined in collaboration instead of in sequence. The product teams work together to define and design the product.
3. Product teams try to solve problems instead of merely implementing features. Outcomes over outputs.

- There are two key phases of product development process, running in parallel: discovery and delivery. Discover the product to be built and deliver it to the market. - Discovery is about minimizing the 4 product risks. - The goal is to achieve product/market fit: build the smallest possible product to meet the needs of a specific market.

Product teams

• Strong Product teams have to solve problems, not just deliver features They're given objectives and it's up to them to reach them. The team is responsible for the outcome. This is what the term "empowered teams" means.
• Product teams need context in order to best solve problems for the business autonomously. Context means customer needs and business objectives.
• Three key roles of product teams are: product managers, product designers and engineers. "The holy trio".

Product manager

• Product manager's job is to decide what to build next and make sure the team delivers it to customers.
• Product managers have to have deep knowledge of customers, but also data, business and market/industry.

Product designer

• Product designer is measured on the success of the product. Not on the output of their work. Pixels in Figma don't matter, business results do.
• Prototyping is one of the most important skills to communicate ideas to others and also to use in experiments to validate ideas.
• In strong product teams, design informs the functionality as much as the functionality drives the design.
• Product managers and product designers are partners and should work together.

Engineers

• Engineers should participate in discovery acitivities like interviews or user testing. They need to build the empathy for customers and their problems so that they can be missionaries (passionate about solving their problems) and not just mercenaries (only executing solutions passed onto them)

Two inconvenient truth about products:

• About half of product ideas won't work (e.g. don't bring enough value to customers)
• Time to money – it typically takes several iterations to develop a product idea enough to deliver the necessary business value

• The problem with roadmaps is that people tend to view them as commitment. Weak product teams carry on building with little consideration if it actually solves the problem. Strong product teams are able to quickly tackle the 4 risks by doing product discovery. Product teams have to solve problems, not just deliver features.

Roadmaps cater to two needs:

• Management wants to make sure that teams will be working on high-value ideas first.
• The company has to make date-based plans and roadmaps offer a view of commitments.

Cagan states that roadmaps don't work and proposes a different model:

Product teams need context in order to best solve problems for the business autonomously They get it from:

• The product vision and strategy
• Business objectives: tell the team what we need to accomplish and how it will be measured and let them solve it (This is where OKRs come in)

Every product team must know how their work contributes to the larger business objectives and overall vision.

In this model, management prioritizes business results over product ideas.

When a team really has to commit to delivering on a date, it's a high-integrity commitment. (Possible parallel to Shape Up's "appetite"?)

Some teams modify roadmaps to include objectives instead of product ideas: outcome-based roadmaps. These are a different way of communicating the objectives, similar to OKRs.

• Teams need to learn fast and discover the right solution (discovery) but also deliver with confidence (delivery). That means robust, scalable and secure software. How to make the two work?

• Making reliable and robust software is hard. That's why it's important that we have the confidence that what we're building will bring value to customers. Discovery allows us to build that confidence and provide evidence for that.

• To discover great products, get in front of customers and test ideas.

• To deliver great products, use best practices for engineering and don't override engineers' concerns.

Product discovery

• The purpose of discovery is to address the 4 risks (value, usability, feasibility, business viability)
  • Another risk that teams should consider is ethics. "Should we build it?"
• Product discovery is about finding the cheapest, fastest ways of coming up and testing product ideas.

Core principles of discovery:

• It's our job as product teams to find solutions to customer/user needs. They cannot tell us what to build, only what problems to solve. They don't know what's possible.
• Establishing value is more important than eliminating every usability issue or having the best performance.
• Technology (engineering), design and functionality (prod.mgmt) are intertwined. They drive and enable each other.
• About half of product ideas won't work. We can't know in advance what will work for customers. That's how we approach the discovery. And that's why we have to Validate ideas with real users and customers
• Validate feasibility during discovery. Developers must see your ideas before planning a sprint (-> grooming?). Engineering perspective also often improves the solutions and it's important to get it early. PM and designer share the responsibility on this.
  • Same goes for business viability. This is mostly the PM's responsibility to make sure it's addressed.
• Product teams should learn together. They should watch how ideas work (or don't) in front of customers. They should share the customer's pain or delight in using the product they've made. And learn from it together.

Discovery techniques

There are several activities or areas we do during discovery and each has some techniques:

1. Framing
   1. Goal: Clearly identify the problem(s) to solve and what to focus on
2. Planning
   1. Goal: TBD
3. Ideating
   1. Goal: Gather ideas for solutions to the selected problem
4. Prototyping
   1. Goal: Prototype the most promising ideas so that we can test them
5. Testing
   1. Goal: Address each of the 4 risks through various forms of testing
   2. Caveat: Not all ideas have risks in all the 4 main areas. Only validate what you need to.

Not every effort will require framing and planning. Sometimes, the solution to a problem is straightforward and team goes right into delivery.

Often, though, there are some risks that have to be addressed. Some teams focus too much on usability or feasibility risk. Value risk is still the most important to address – it's usually the biggest risk.

If the team doesn't feel any significant risk, it's better to proceed to delivery than to be too conservative and test every assumption first. It's important to learn quickly.

Three discovery framing techniques

The goal is to articulate what we want to achieve with the discovery work.

• Opportunity assessment
  • Answer and document 4 key questions:
    • What will this help us to achieve? (Business objective)
    • How will we know we succeeded? (Key results)
    • What problem does this solve for customers/users?
    • Who are we doing it for? What is our target market/segment/persona?
• Customer letter
  • Describe the future you want to create from the perspective of the customer and how it will benefit them.
  • The goal is to help the team focus on Outcomes over outputs
• Startup canvas
  • Similar to lean canvas or business model canvas. Best used when working on a whole new product or establishing a business.

Discovery planning techniques

• Story mapping
  • For seeing individual user stories in context. Helps with defining what to prototype.
• Customer discovery program
  • One of the best techniques to make sure you have strong product but takes a lot of effort.
  • The goal is to gain access to target customers that you can source product ideas from. Then to build a set of reference customers (ideally 6). This basically builds social proof.
  • Reference customer: real customer, actually using the product, paying money for it and willing to tell others about how much they love the product. Very powerful to have them.
  • Ideal for large efforts (e.g. creating a new product or a redesign), not for smaller features or projects.

Discovery ideation techniques

• Customer Interviews
  • Basic but also very powerful technique.
  • Designer, PM and one engineer should attend these.
• Concierge Test
  • Have the trio perform a task or a job of the target audience.
• Power of Customer Misbehavior
  • See if people use your product for unintended use cases. Find the need behind that usage to discover some great product opportunities.
• Hack days
  • People work on any idea under the company's mission or a specific objective. Great for building the "missionary not mercenary" mindset. Also good for involving engineers in ideation.

Discovery prototyping techniques

• User prototype
• Live-data prototype
• Hybrid prototype
• Feasibility prototype
  • For devs to assess feasibility risk. It's often about performance, but could be a new tech or an algorithm.

Principles of prototyping

• Prototyping is about learning at a fraction of the cost of building a real product.
• Prototyping forces you to really think through the solution and uncover things that need to be addressed.
• Prototype can be a great collaboration tool. Allows the team and partners to experience the potential solution.
• It's important to choose the appropriate fidelity of the prototype for its intended purpose. Different levels of fidelity require a different level of effort to build.
• Prototype can also serve as a spec to developers so they know what to build.
• Prototype will usually be thrown away after learning or building the actual product. So don't invest more time in it than necessary.

Value testing

Demand testing:

• Fake door demand test
• Landing page demand test

When the demand is there but we're unsure if people will choose to use/buy it, we have to test for value. Qualititative testing of product ideas with real users and customers is one of the most important discovery activities. Testing for value during user interviews is typically preceded by a usability test so that the user knows what the product/feature is all about. Few ways of testing for value:

• using money
• using time
• using reputation
• using access

Qualitative testing is about learning and insights. Quantitative testing is about collecting evidence.

It's crucial to enable teams to collect data on how what they ship is being used. Otherwise, they're left in the dark. PM's should watch not only user analytics but also things like sentiment, performance or business analytics (conversions, active users etc.).

Testing feasibility

There are many factors that engineers must consider when evaluating a feasibility of something:

• How to build it? - the most fundamental thing
• But then also: Scale, infrastracture, dependencies, cost, performance, available components, required architectural changes, time and necessary skills

Don't throw product ideas at engineers. It's best if they have the time to investigate and consider them in advance, before planning any work (and giving estimates). This is why the whole team should learn together and engineers should watch how ideas are tested. Often, when engineers have time to investigate, they can come up with great ways of solving something technologically.

Testing business viability

It's about making sure that the proposed product idea works within constraints of different areas of the business – from marketing, through legal, CS to management. Impacted stakeholders should have a chance to review the idea and have their concerns addressed.

It's the PM's job to ensure the team's work will sit well with all key stakeholders. Stakeholders should be kept in the loop and be able to look at the prototypes in discovery that the team intends to build. They should have space to express concerns and ask questions. PM has to build collaborative and respectful relationships with them, ideally through some regular 1-1 time.

The right culture

Ten principles for creating great products and innovating:

1. Customer-centric culture
2. Compelling product vision
3. Focused product strategy
4. Strong product managers
5. Stable product teams
6. Engineers in discovery
7. Corporate courage
8. Empowered product teams
9. Product mindset
10. Time to innovate

These principles are important for consistent innovation (regularly adding value to the business).

Strong product culture = strong innovation culture (discovery) + strong execution culture (delivery)

Other notes

• Best solutions come from collaboration in strong product teams
• Data beats opinions