Inspired — How To Create Tech Products Customers Love

from the book authored by Marty Cagan

Photo by Dhaval Parmar on Unsplash

PART 1: LESSONS FROM TOP TECH COMPANIES

The job of a product manager is to lead the product team to combine technology and design to solve real customer problems in a way that meets the needs of the business.

You need to know two things about each idea:

• 1/ How much money or value will it make?
• 2/ How much money or time will it cost?

Two inconvenient truths about product

• 1/ At least half of our ideas are just not going to work
• 2/ Even with the ideas that do prove to have potential, it typically takes several iterations to get the implementation of this idea to the point where it delivers the necessary business value

There is simply no escaping these inconvenient truths no matter how smart you might be. The real difference is how you deal with theses truths.

Best practices

Risk management

In modern teams, risks are tackled up front, rather than at the end and prior to deciding to build anything. These risks include:

• Value risk = whether customers will buy it
• Usability risk = whether users can figure out how to use it
• Feasibility risk = whether our engineers can build what we need with the time, skills and technology we have
• Business viability risk = whether this solution also works for the various aspects of our business — sales, marketing, finance, legal, etc.

Co-creation

Products should be defined and designed collaboratively, rather than sequentially.

Solving problems

Finally, it’s all about solving problems, not implementing features.

Continuous discovery and delivery

We are always working in parallel to both discover the necessary products to be built — which is primarily what the product manager and designer work on every day — while the engineers work to deliver production-quality product. The engineers are also helping daily on discovery (and many of the best innovations come from that participation, so this is not a minor point), and the product manager and designer are also helping daily on delivery (mainly to clarify intended behavior).

In discovery, we are tackling the various risks before we write even one line of production software. The purpose of product discovery is to quickly separate the good ideas from the bad. The output of product discovery is a validated product backlog. Strong teams normally test many product ideas each week — on the order of 10 to 20 or more per week.

While the P in MVP stands for product, an MVP should never be an actual product (where product is defined as something that your developers can release with confidence, that your customers can run their business on, and that you can sell and support). The MVP should be a prototype, not a product.

PART 2: THE RIGHT PEOPLE

Team Scope

It’s more common today that the product is the full customer experience, and each team is responsible for some smaller but meaningful piece of that experience. Sometimes we have each team focus on:

• a different type of user or customer
• a different type of device
• specific workflow or customer journey
• specific parts of the architecture (this is pretty common because the architecture drives the technology stack, which often requires different types of engineering expertise)

There is never a perfect way to carve up the pie. Realize that when you optimize for one thing, it comes at the expense of something else. So, decide what’s most important to you and go with that.

The Product Managers

4 critical contributions that you need to bring to your team — a deep knowledge of:

• 1/ your customer
• 2/ the data
• 3/ your business and its stakeholders
• 4/ your market and industry

The successful product manager must be the very best versions of:

• smart: intellectually curious, quickly learning and applying new technologies to solve problems for customers, to reach new audiences, or to enable new business models
• creative: thinking outside the normal product box of features to solve business problems
• persistent: pushing companies way beyond their comfort zone with compelling evidence, constant communication and building bridges across functions in the face of stubborn resistance.

The Designers

Good product designers think about the customer’s journey over time as they interact with the product and with the company as a whole. Depending on the product, the list of touch points could be very long, considering questions as:

How will customers first learn about the product? How will we onboard a first-time user and (perhaps gradually) reveal new functionality? How might users interact at different times during their day? What other things are competing for the user’s attention? How might things be different for a one-month-old customer versus a one-year-old customer? How will we motivate a user to a higher level of commitment to the product? How will we create moments of gratification? How will a user share his experience with others? How will customers receive an offline service? What is the perceived responsiveness of the product?

We need design — not just as a service to make our product beautiful — but to discover the right product. 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.

The Engineers

There are typically two types of discussion going on each day.

• 1/ you’re soliciting their ideas and input for the items you’re working on discovery
• 2/ they’re asking you clarifying questions on the items they’re working on delivering to production

The morale of the engineers is very much a function of you as the product manager. It is your job to make sure they 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. Don’t try to shelter them from this — instead, share these problems and challenges very openly with them.

Not every engineer or even senior engineer wants to participate in discovery activities, and this is fine. What’s not okay is to have a team of engineers in which none of them wants to engage in discovery activities.

Product Marketing

Modern product marketing managers represent the market to the product team — the positioning, the messaging and a winning go-to market plan. They are deeply engaged with the sales channel and know their capabilities, limitations and current competitive issues.

User Research

Especially with the qualitative learning, research is either

• generative = understanding the problems we need to solve
• evaluative = assessing how well our solutions solve the problem

Head of Product

This role is often called a player-coach role because of this dynamic of leading your own team, in addition to being responsible for coaching and developing one to three other PMs. 4 key competencies:

• 1/ Team development
• 2/ Product vision
• 3/ Execution
• 4/ Product culture

PART 3: THE RIGHT PRODUCT

The alternative to roadmap

Roadmaps have existed for so long because they serve two purposes and these needs don’t go away.

• 1/ The management of the company wants to make sure that teams are working on the highest-business-value items first.
• 2/ Since they are trying to run a business, there are cases where they need to make date-based commitments and the roadmap is where they see and track those commitments

Product vision and strategy

The difference between vision and strategy is analogous to the difference between good leadership and good management. Leadership inspires and sets the direction, and management helps get us there.

The vision is mainly a persuasive piece that might be in the form of a storyboard, a narrative such as a white paper, or a special type of prototype referred to as a vision type. Its primary purpose is to communicate this vision and inspire the teams (and stakeholders, investors, partners — and in many cases prospective customers) to want to help make this vision a reality.

The product strategy is our sequence of products or releases we plan to deliver on the path to realizing the product vision. For most types of businesses, I encourage teams to construct product strategy around a series of product/market fits.

For business-focused companies, you might have each product/market fit focus on a different vertical market (e.g., financial services, manufacturing, automotive.) For consumer-focused companies, we often structure each product/market fit around a different customer or user persona.

Outcome-based roadmaps

They are essentially equivalent to using a business objective-based system such as the OKR system. The compromise is straightforward: the product teams asks for a little time to do product discovery before commitments are made, and then after discovery, we are willing to commit to dates and deliverables so our colleagues can effectively do their jobs as well.

Product evangelism

• 1/ Use a prototype
• 2/ Share the pain (of customers with the team)
• 3/ Share the vision: show how your work contributes to this vision and is true to the principles
• 4/ Share learnings generously (including problems)
• 5/ Share credit generously
• 6/ Learn how to give a great demo
• 7/ Do your homework: be the undisputed expert on your market, users.
• 8/ Be genuinely excited
• 9/ Learn to show some enthusiasm
• 10/ Spend time with your team

PART 4: THE RIGHT PROCESS

We need to learn fast, yet also release with confidence. It’s understandable that many people might naturally view these two difficult goals as at odds with each other.

The purpose of product discovery is to make sure we have some evidence that when we ask the engineers to build a production — quality product, it won’t be wasted effort. And, this is why we have so many different techniques in product discovery.

Set of core principles

• 1/ We know we can’t count on our customers (or our executives or stakeholders) to tell us what to build

It is our job to make sure the solution we deliver solves the underlying problem. This is probably the most fundamental principle in all of modern product: historically, in the vast majority of innovations in our industry, the customers had no idea that what they now love was even a possibility.

• 2/ The most important thing is to establish compelling value

Without the core value, we really have nothing (will customers buy or use it?). As a result, this is generally where we’ll spend most of our discovery time.

• 3/ As hard and important as the engineering is, coming up with a good user experience is usually even harder, and more critical to success
• 4/ Functionality, design and technology are inherently intertwined

This is the reason we push so hard for the product manager, product designer and tech lead to sit physically adjacent to each other

• 5/ We expect that many of our ideas won’t work out and the ones that do will require several iterations
• 6/ We must validate our ideas on real users and customers

We need to do this before we spend the time and expense to build an actual product, and not after.

• 7/ Our goal in discovery is to validate our ideas the fastest, cheapest way possible
• 8/ We need to validate the feasibility of our ideas during discovery, not after
• 9/ We need to validate the business viability of our ideas during discovery, not after
• 10/ It’s about shared learning

Teams competent in modern discovery techniques can generally test on the order of 10–20 iterations per week. As a rule of thumb, an iteration in discovery should be at least an order of magnitude less time and effort than an iteration in delivery.

Discovery Techniques Overview

They include: Framing, Planning, Ideation, Prototyping, Testing (feasibility, usability, value, business viability), Transformation

Framing: Understanding Underlying Issues

2 Goals:

• 1/ Ensure the team is all on the same page in terms of clarity of purpose and alignment
• 2/ Big risks to be tackled during the discovery work (value risk)

3 techniques:

a/ Opportunity assessment technique

• 1/ What business objective is this work intended to address? Objective — Does this work address at least one of our assigned problems?
• 2/ How will you know if you’ve succeeded? Key results — Does it map to at least one of the key results assigned to our product team?
• 3/ What problem will this solve for our customers? Customer problem — We can occasionally do something to help internal users, so if that’s the case we can call that out here. But even then, we try to tie it back to the benefits to our end customers.
• 4/ What type of customer are we focused on? Target market — It might be described as a user or customer persona, a specific target market or a specific job to be done.

b/ Customer letter — for larger projects that often have multiple goals and a more complicated desired outcome

Technique from Amazon, the “working backward”: start the effort with a pretend press release. How does it improve the life of our customers? What are the real benefits to them? Include a customer quote as well.

One variation of this technique: rather than communicate the benefits in a press release format, you describe them in the format of a customer letter written from the hypothetical perspective of one of your product’s well-defined user or customer personas. The letter — sent to the CEO from a very happy and impressed customer — explains why he or she is so happy and grateful for the new product or redesign. The customer describes how it has changed/improved her life. The letter also includes an imagined congratulatory response from the CEO to the product team explaining how this has helped the business.

c/ A startup canvas — entirely new product line or new business

In this situation, you have a much broader set of risks, including: validating your value proposition, figuring out how you intend to make money, how you plan to get this product out to your customers and sell to them, how much it will cost to produce and sell this product, what you will measure to track your progress, determining whether the market is large enough to sustain a business…

NB: unique value proposition, pricing, channels and costs are all real risks which are part of assessing business viability. But the biggest reason that startups and new products fail is the value risk. If you can discover a solution that your customers love, then you can tackle the risks of monetization and scale. However, without that solution, the rest of your work is very likely going to be wasted.The point is that you don’t need to spend your time doing pricing optimization testing, sales tools, marketing programs and cutting costs until and unless you have discovered a truly valuable product.

Conclusion on framing techniques

The most important lesson in our industry is to fall in love with the problem, not the solution. It’s our job in the product organization to tease out the underlying problem and ensure that whatever solution we deliver solves that underlying problem.

A small amount of time up front framing the problem to be solved — and communicating this framing — can make a dramatic difference in the results.

Planning: Identifying The Bigger Challenges & Planning How You’ll Attack This Work

2 techniques:

a/ Story Map Technique, introduced by Jeff Patton

The origin of story maps came from frustration with the typical flat backlog of user stories. There’s no context, just a prioritized list of stories. How can the team know how one story fits in with the big picture? What does it mean to even prioritize at that granularity with so little context? And what set of stories constitutes a meaningful milestone or a release?

If you lay out your system this way, you can, at a glance, get the holistic view and consider where to draw the line in terms of different releases and their associated objectives.

To go further, read: User Story Mapping: Discover the Whole Story, Build the Right Product, by Jeff Patton

b/ Customer Discovery Programme Technique — for larger efforts

• The power of reference customers

We are discovering and developing a set of reference customers in parallel with discovering and developing the actual product. Remember that this technique is not designed to discover the necessary product — that comes next. Rather it is designed to give you direct access to the target customers where you’ll find the product ideas necessary to generate reference customers.

A reference customer is: a real customer, who is running your product in production, who has paid real money for the product, and most important, who is willing to tell others how much they love your product.

• The relationship

Benefit to the prospective customer: get real input to the solution, and most important get a solution that truly works for them.

Benefit to the product team: get ready access to a set of users and customers that you can go deep with, have agreed to test early versions, and most important they have agreed to buy the product and sere as a public reference if the resulting product works for them.

If you find you are having real trouble recruiting even four or five prospective customers for this effort, this is one of the very first reality checks (aka demand validation) to make sure you’re spending your time on something worthwhile.

Defining product/market fit

One of the most common technique (mostly relevant for consumer products and services) is the Sean Ellis test: if more than 40 percent of the users would be “very disappointed” if they could no longer use the product, then there is a good chance you’re at product/market fit.

For products for businesses, the discovery program will give you a very practical and effective definition of product/market fit.

Ideation: To Provide The Product Team With a Wealth of Promising Solutions Aimed at the Problems We’re Focused On Now

a/ Customer interviews

Here’s what we are trying to understand:

• Are your customers who you think they are?
• Do they really have the problems you think they have?
• How does the customer solve this problem today?
• What would be required for them to switch?

Frequency: a bare minimum would be 2 to 3 hours of customer interviews, per week

Attendees: ideally the product manager, the product designer and one of the engineers

b/ Concierge Test Technique

This test requires going out to the actual users and customers and asking them to show you how they work so that you can learn how to do their job, and so that you can work on providing them a much better solution.

This is similar, but not the same, as spending some time with your customer service or customer success staff. That is also valuable and often a good source of product ideas as well, but that is helping customers once they call with a problem.

c/ The Power of Customer Misbehavior

If you find your customers using your product in ways you didn’t predict, this is potentially very valuable information. Dig in a little and learn what problem they are trying to solve and why they believe your product might provide the right foundation. Do this enough and you’ll soon see patterns and potentially some very big product opportunities.

d/ Hack Days

The goal is for the self-organizing groups to explore their ideas and create some form of prototype that can be evaluated, and if appropriate, tested on actual users.

• Directed: there’s a customer problem or business objective we’ve been assigned
• Undirected: people can explore whatever product ideas they like, so long as it’s at least loosely related to the mission of the company

Prototyping: Our Go-to Tool For Product Discovery

“ Plan to throw one away; you will, anyhow. “

Principles

• The overarching purpose of any form of prototype is to learn something at a much lower cost in terms of time & effort than building out a product
• The very act of creating a prototype exposes major issues otherwise left uncovered until much later
• It is a powerful tool for team collaboration and shared understanding
• We create the right level of fidelity for its intended purpose — we only do higher fidelity when we need to
• Prototype as spec benefit — or supplemented with use cases, business rules and acceptance criteria

a/ Feasibility prototype technique (for the engineers)

The idea is to write just enough code to mitigate the feasibility risk. This typically represents just a small percentage of the work for the eventual shippable product (usually just a day or two of time).

b/ User prototype technique, from low-fidelity (wireframes) to high-fidelity

NB: The big limitation of a user prototype is that it’s not good for proving anything — like whether or not your product will sell ie validating value.

c/ Live-data prototype technique, to collect actual data so we can prove something

The key is to is to be able to send some limited amount of traffic, and to collect analytics on how this live-data prototype is being used. Actual users will use the live-data prototype for real work, and this will generate real data (analytics) that we can compare to our current product or to our expectations to see if this new approach performs better. Examples: game dynamics, search result relevance, social features, product funnel work.

Two big limitations to keep in mind:

• This is code so engineers must create the prototype, not your designers
• Not a commercially shippable product, you can’t run a business on it.

d/ Hybrid prototype technique

Great examples of the “build things that don’t scale” philosophy of product discovery. Admittedly, it’s mainly qualitative learning, but that’s often where our biggest insights come from anyway.

One example is a Wizard of Oz prototype: it combines the front-end user experience of a high-fidelity user prototype but with an actual person behind the scenes performing manually what would ultimately be handled by automation. It is absolutely not scalable but the benefit from our perspective is that we can create this very quickly and easily and from the user’s perspective it looks and behaves like a real product.

Testing: Trying to Separate Quickly the Good Ideas from the Bad

We usually assess usability and value with the same users at the same time.

a/ Testing Usability: Designed for the Designers to Address Areas Where They Identify Concerns

We likely will need to address usability before the user of customer can even recognize the value.

b/ Testing Value: To Ensure The Customers Will Choose To Use Or Buy Our Product

This is often the toughest — and most important — question to answer and if the value is not there, not much else matters.

Testing Demand

Fake door demand test: we put the button or menu item into the user experience exactly where we believe it should be. But when the user clicks that button, it takes her to a special page that explains that you are studying the possibility of adding this new feature and you are seeking customers to talk to about this. The page also provides a way for the user to volunteer (email or phone number).

Landing page demand test: if the user clicks the call to action, rather than signing up, the user sees a page that explains that you are studying the possibility of adding this new offering and you’d like to talk with them.

Testing Value Qualitatively

Qualitative testing is about understanding the why — fast learning and big insights. It is probably the single most important discovery activity for product teams. Do it at least two or three times every single week.

• Interview first (Customer Interview Technique)
• Usability Test (before testing value)
• Specific Value Tests: Using money (willing to buy), reputation (wiling to recommend), time (willing to schedule some time) or access (willing to provide credentials) to demonstrate value
• Iterating the prototype

Testing Value Quantitatively

Quantitative testing is about collecting evidence, with live-data prototypes.

• Discovery A/B testing: 99%:1% (vs optimization A/B testing 50:50)
• Invite-only testing
• Customer Discovery Program

5 main uses of analytics in strong product teams

• 1/ Understand User and Customer Behavior: if you’re going to put a feature in, you need to put in at least the basic usage analytics
• 2/ Measure Product Progress: focus on outcome and not output
• 3/ Prove Whether Product Ideas Work: at least with high risks or high deployment costs things
• 4/ Inform Product Decisions: data beats opinions
• 5/ Inspire Product Work

Flying Blind

Remarkably, too many product teams either aren’t instrumenting their product to collect analytics or they do it as such a minor level that they don’t know if and how their product is being used

c/ Testing Feasibility: Designed for the Engineers to Address Areas Where They Identify Concerns

Holding a weekly planning meeting where you throw a bunch of ideas at the engineers — and demand they give you some sort of estimate — is almost certain to go badly.

If however then engineers have been following along as the team has tried out these ideas with customers (using prototypes) and seen what the issues are and how people feel about these ideas, the engineers have probably already been considering the issues for some time. You need to give the engineers time to investigate and consider it.

The question isn’t “Can you do this?”. Rather you are asking them to look into it and answer the question “What’s the best way to do this and how long would it take?”

d/ Testing Business Viability: Costs, Finance, Business Development, Marketing, Legal, Sales, Ethics

We’ll often address these business risks last because we don’t want to stir up the organization unless we’re confident it’s worthwhile.

The last thing you want to have happen is that your team moves forward and takes the time to commercialize the solution and deliver a shippable product, only to find out that you can’t ship because you are violating one of these constraints.

User Test vs Product Demo vs Walkthrough

• User test: with users and customers, to test the usability and value of the prototype or product
• Product demo: with prospective users or across your company, to show off the value of the prototype or product
• Walkthrough: with a stakeholder, to give her every opportunity to spot a problem

Transformation: Improving The Way We Work As a Team

a/ Discovery/Design Sprint Technique

A discovery sprint (or design sprint) is a one-week time box of product discovery work, designed to tackle a substantial problem or risk your product team is facing, cf the book Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days, by Jake Knapp, John Zeratsky, Braden Kowitz.

It starts with framing the problem by mapping the problem space, picking the problem to be solved and the target customer, and then progresses into pursuing several different approaches to the solution. The team next narrows down and fleshes out the different potential solutions, then creates a high-fidelity user prototype — finally putting it in front of actual target users.

b/ Pilot Team Technique

The technology adoption curve also applied to our own organization. Some people love change, some want to see someone else use it successfully first, some need more time to digest changes, and a few hate change and will only change if they’re forced to do it.

Pilot teams allow the roll out of change to a limited part of the organization before implementing it more broadly. You’re looking to compare the team’s effectiveness in delivering business outcomes.

c/ Weaning an Organization Off Roadmaps

The goal is that over time, the organization moves its focus from specific features launching on specific dates to business results.

Teams work on the prioritized business objectives determined by the leaders; we share our key results transparently; and we commit to high-integrity commitments when critical delivery dates are needed.

Managing Stakeholders

The product manager has the responsibility to understand the considerations and constraints of the various stakeholders, and to bring this knowledge into the product team.

Success in terms of stakeholder management means that your stakeholders respect you and your contribution. They trust that you understand their concerns and will ensure solutions work well for them too. They trust that you will keep them informed of important decisions or changes. And, most of all, they give you the room to come up with the best solutions possible, even when those solutions end up being quite different from what they might have originally envisioned.

Key technique: one-on-ones (weekly lunch or coffee) ; commit to previewing your solutions during discovery with the key stakeholders before you put this work on the product backlog

Communicating Product Learnings

A good technique is for the head of product at a company all-hands or similar meeting every week or two, to take 15 to 30 min to highlight what has been learned in product discovery across the various product teams.

One cultural benefit of the product organization being transparent and generous in what they learn and how they work is to help the broader organization understand that the product organization is not there to “serve the business” but rather to solve problems for our customers in ways that work for our business.

PART 5: THE RIGHT CULTURE

It’s much more about culture than it is about process — or anything else.

A strong product culture means that the team understands the importance of continuous and rapid testing and learning. They understand that they need to make mistakes in order to learn, but they need to make them quickly and mitigate the risks. They understand the need for continuous innovation. They know that great products are the result of true collaboration. They respect and value their designers and engineers. They understand the power of a motivated product team.

In an IT-mindset organization, the product teams exist to serve the needs of the business. In contrast, in a product-mindset organization, the product teams exist to serve the company’s customers in ways that meet the needs of the business. The resulting differences between these mindsets are many and profound.

Top Reasons For Loss of Innovation

• 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

Top Reasons For Loss of Velocity

• 1/ Technical debt
• 2/ Lack of strong product managers
• 3/ Lack of delivery management
• 4/ Infrequent release cycles
• 5/ Lack of product vision and strategy
• 6/ Lack of co-located, durable product teams
• 7/ Not including engineers early enough during product discovery
• 8/ Not utilizing product design in discovery and instead having them try to do their work at the same time the engineers are trying to build
• 9/ Changing priorities
• 10/ A consensus culture

Establishing a Strong Product Culture

We can think of product culture along two dimensions:

• 1/ Whether the company can consistently innovate to come up with valuable solutions for their customers. This is what product discovery is all about.
• 2/ Execution. It doesn’t matter how great the ideas are if you can’t get a productized, shippable version delivered to your customers. This is what product delivery is all about.

Only a few companies are strong at both innovation and execution.