Notes from Inspired book by Marty Cagan

It doesn’t matter how good your engineering team is, if they are not given something worthwhile to build.

Product Manager - someone who leads the product team to combine technology and design to solve real customer problems in a way that meets the needs of the business.

Strong tech-product companies know they need to ensure consistent product innovation. Many product ideas just end up making absolutely nothing.

Knowing what we can’t know (at a certain stage).

Engineers are typically the best single source of innovation.

The biggest form of waste is to design, build, test, and deploy a feature or product only to find out it is not what was needed.

Strong teams test on the order of 10 to 20 product ideas each week (using mainly prototypes).

The MVP approach causes confusion. One builds too long and could get the same amount of learnings much more lightweight. And MVP products shipped are often not usable enough to have it shipped to the customer. The MVP should be a prototype.

Qualitative learning: Understand why our users and customers behave the way they do. Quantitative learning: Understand what users are doing with the product.

In each of the examples for great Products built by great product managers, the winning solution didn’t come from users, customers or sales. The user had no idea the solution they fell in love with was possible.

Fall in love with the problem, not the solution (Often our initial solutions don’t solve the problem)

Risks

Value Risk

Will customers buy it (or choose to use it)?

Usability Risk

Can customers figure out how to use it?

Feasibility Risk

Can engineers build it regarding their skills, technologies, time and budget?

Business Viability Risk

Does the solution work for all other aspects of the business (marketing, legal, sales, …). Can our stakeholders support this?

Financial risk: Can we afford this solution?

• Business development risk: Does this solution work for our partners?
• Marketing risk: Is this solution consistent with our brand?
• Sales risk: Can sales sell it?
• Legal risk:
• Ethical risk: Is this solution something we should do?

Overarching principles

• Risks are tackled up front, rather than at the end. (prior to building anything)
• Products are defined and designed collaboratively, rather than sequentially - Product, Design and Engineering works side-by-side
• It’s all about solving problems, not implementing features - Ensure that the solution solves the underlying problem. It’s about business results.

Two important truths

At least half of our ideas are just not going to work. (really good teams assume that at least ¾ of the ideas won’t perform like they hope).

It takes several iterations to get the implementation of an idea to the point where it delivers the necessary business value (time to money).

It’s about how we deal with these truths!

Product Discovery

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.

It’s about providing answers to the Risks.

Product discovery involves running a series of very quick experiments, and to do these experiments quickly and inexpensively, we use prototypes rather than products.

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.

The key to effective product discovery is getting access to our customers without trying to push our quick experiments into production.

Core principles

• We know we can’t count on our customers (or our executives or stakeholders) to tell us what to build. (It’s our job to ensure that what we build solves the underlying user problem).
• The most important thing is to establish compelling value. So that customers ultimately choose to buy or use our product. This is where we need to spend most of our discovery time.
• As hard and important as the engineering is, coming up with a good user experience is usually even harder, and more critical to success.
• Functionality, design and technology are inherently intertwined (so the disciplines need to work together).
• We expect that many of our ideas won’t work out, and the ones that do will require several iterations.
• We must validate our ideas on real users and customers. (and before we spend the time and expense to build an actual product)
• Goal is to validate our ideas the fastest, cheapest way possible
• Discovery is about the need for speed. This lets us try out many ideas and for the promising ideas, try out multiple approaches.
• We need to validate the feasibility of our ideas during discovery
• We need to validate the business viability of our ideas during discovery It’s about shared learning

Approach

Use discovery iterations. One iteration is about trying out at least one idea or approach. It’s about testing 10-20 iterations per week. An iteration in discovery should be at least an order of magnitude less time and effort than an iteration in delivery.

Discovery techniques

With: Build things that don’t scale philosophy during discovery.

Framing Techniques

To identify the underlying issues that must be tackled.

• Clarify underlying problem to be solved
• Tease out risks and determine where to focus times one

Especially important for initiatives (projects spanning multiple teams).

1st Goal is to ensure alignment in terms of clarity and purpose.

• Define business objectives we’re focusing on.
• The specific problem we are intending to solve for our customers
• Which customer you’re solving that for
• How will you know if you’ve succeeded.

2nd Goal is to identify the big risks that will need to be tackled during the discovery work.

If pm, tech and designer do not feel there’s a significant risk in any of these areas, then normally we would just proceed to delivery.

Use discovery time for those situations where we know there’s a significant risk, or where team members disagree.

Tools

• Opportunity assessment
  • What business objectives is this work intended to address (Objective)?
  • How will you know if you’ve succeeded (Key Results)
  • What problem will this solve for our customers (Customer Problem)
  • What type of customer are we focussed on? (target market; the intended primary beneficiary .. user, persona, target market or job-to-be-done)
• A customer letter (for larger projects with multiple goals)
  • Like a press release .. but this time a fictive letter from a very happy and impressed customer to our CEO about a positive product usage)
    • How did it improve life of the customer? Benefits?
  • It create empathy for the customer’s current pain too
• A startup canvas (for an entirely new product)
  • A replacement for too much investment in business plans
  • Creates a holistic understanding of the product and highlights key areas of the affected business.
  • Highlights key assumptions and major risks (and major focus on exposing the value risk)

Discovery planning techniques

Identify the bigger challenges and planning how you’ll attack this work.

Tools

• Story Maps
  • Useful for ideation
  • Great for communicating with team and key stakeholders
  • Planning work
  • Use first to frame the prototype
• Customer Discovery Program (for bigger topics like new products, a new market)
  • Build a pool of reference customers (especially relevant for B2B)
  • Discover and develop a set of reference customers in parallel with discovering and developing the actual product
  • Key number B2B is about 6 reference customers and 10-50 for B2C

Many teams consider a high-fidelity prototype and a story map as their go-to techniques.

Product Market Fit

Asking: How would they feel if they could no longer use this product? (very disappointed, somewhat disappointed, don’t care, no longer relevant). If 40%+ would be very disappointed that should a good product market fit.

Discovery ideation techniques

To provide the product team with a wealth of promising solutions aimed at the problems we’re focused on now.

Tools

• Customer Interviews
  • 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?
  • 2-3h of customer interviews per week/every week
  • Try to understand and learn quickly (not to prove something)
• Concierge Test Technique
  • We do the customers job for them - manually and personally
• The Power of customer misbehavior
  • Allow and encourage users to use our products to solve problems other than what we planned for and officially support (e.g. EBay - everything else category)
  • E.g. building a public API
• Hack Days (directed with business goal or undirected but in line with mission of the company)
  • Team building and mindset of missionaries
  • Engineers diving deeper into the business context

Discovery prototyping techniques

Tools

• Feasibility prototypes
  • Algorithm, performance, scalability, fault tolerance, new technologies, third party component, legacy system, dependency on changes from other teams
  • Write just enough code to mitigate the risk
  • Throwaway code
  • Done in 1-2 days
• User prototypes
  • Low fidelity prototype
    • E.g. to just think through a problem using wireframes
    • High fidelity prototype
    • A simulation - smoke and mirrors.
    • NOT for proving something (people say all kinds of things and then go and do something different). You need to use other techniques for validating the value!
• Live Data Prototypes (A/B tests)
  • Without a lot of the productization that is normally required like automated tests, analytics, performance, … (about 5-10% of real product work)
• Hybrid prototypes (combination of the above mentioned)
  • Wizard of Oz prototype (real working UI but with fake/manual backend)

Principles

• Learn something at much lower cost in terms of time and effort than building out a product (with at least an order of magnitude less time and effort as the eventual product)
• Force you to think through a problem at a substantially deeper level .. alone creating it exposes major issues
• Powerful tool for team collaboration
• There are many different levels of fidelity for a prototype (and lower fidelity being cheaper and faster to build)
• Purpose – tackle one or more product risks during the discovery phase and to communicate what needs to be built.

Discovery testing techniques

About quickly trying out an idea. A good idea defined as one that solves the underlying problem in a way that customers will buy, they can figure out how to use, we have the time and skills and technology on the team to build and that works for the various aspects of our business.

Order .. Value and Usability - Feasibility - Business Viability

Testing feasibility

Techniques to address areas where engineering identifies concerns.

• Do we know how to build this?
• Do we have the skills on the team to build this?
• Do we have enough time to build this?
• Do we need any architectural changes to build this?
• Do we have on hand all components?
• Do we understand the dependencies involved?
• Will the performance be acceptable?
• Will it scale to the levels we need?
• Do we have the infrastructure?
• Can we afford the cost to provision this?

Testing usability

Testing value

Testing demand

• Fake door demand test (painted wall test?)
• Landing page demand test

Testing Value Qualitatively

Focussed on response or reaction. Do customers love this? Will they pay for it? Will they use it? If not, why not?

It is not about proving. It tells what is happening (or not), but not why.

This is probably the single most important discovery activity for you and your product team. (2-3 per week)

1) Interview 2) Usability test (using high fidelity prototypes) 3) Have conversations with the user about the value

Testing Value Quantitatively

How well does this solution solve the underlying problem? It’s about proving, about collecting evidence.

• A/B test based on prototype. (It’s a difference to optimization A/B testing where you e.g. change color, button,… and can use a much higher traffic share). Only 1% of users … with close monitoring.
• Invite only testing

Testing business viability

Assessment of costs to produce, market and sell the product.

Transformation techniques

Discovery sprint (design sprint)

• Frame problem by mapping problem space
• Pick the problem to be solved and the target customer
• Pursue several different approaches to the solution
• Create high fidelity prototype
• Observe interaction from target users
• When the team has something big and critically important and/or difficult to tackle

Analytics

… (269)

• User behavior analytics (click paths, engagement)
• Business analytics (active users, conversion rate, lifetime value, retention)
• Financial (ASp, billings, time to close)
• Performance
• Operational costs
• Go-to-market costs
• Sentiments (NPS, customer satisfaction, surveys)

Product Vision

The longer term objective of the product. 2-10 years perspective. It’s how the product organization intends to deliver on the company’s mission. Might be in the form of a storyboard, a white paper or a visiontype.

It’s on an organization level but not on product team level. The product vision should be inspiring and the strategy should be focused.

Principles

• Start with why (Simon Sinek) . Use the vision to articulate your purpose.
• Fall in love with the problem, not with the solution
• Don’t be afraid to think big with vision
• Don’t be afraid to disrupt yourselves (otherwise someone else will)
• The product vision needs to inspire (center it around how you genuinely help your users and customers)
• Determine and embrace relevant and meaningful trends
• Skate to where the puck is heading, not to where it was (identify the things that are changing)
• Be stubborn on vision but flexible on the details (don’t give up on your vision too soon)
• Realize that any product vision is a leap of faith
• Evangelize continuously and relentlessly

Product Strategy

The sequence of products or releases we plan to deliver on the path to realizing the product vision. Should be constructed around a series of product/market fits e.g. around a different customer or persona.

Principles

• Focus on one target market or persona at a time
• Product strategy needs to be aligned with the business strategy
• Product strategy needs to be aligned with the sales and go-to-market strategy
• Obsess over customers, not over competitors (focus on customers and not chasing the competitors). Customers leave us because we stop taking care of them.
• Communicate the strategy across the organization

Product principles

The product principles speak to the nature of the products you want to create. E.g. “In case where the needs of buyers and the sellers conflict, we will prioritize the needs of the byer, because that’s actually the most important thing we can do for sellers”

Prioritization

Use OKRs. The first principle is fundamentally about how to empower and motivate people to get them to do their best work, and the second is about how to meaningfully measure progress.

KRs should be a measure of business results (not output or tasks). Don’t let personal objectives or functional team objectives dilute or confuse the focus.

Annually for organization wide objectives and quarterly for team’s objectives. Every product team tracks their active progress against their objectives (typically weekly).

Be transparent on what objectives each team is working on and their current progress.

Senior management is responsible for the organization’s objectives and key results. Head of product and technology are responsible for the product team objectives. The individual product teams are responsible for the key results.

Focus the OKRs at the product team level.

Regarding markets

Inputs to consider:

• Market sizing - Total addressable market (TAM)
• Distribution - Go to market (regarding required sales channels and go-to-market strategies) (GTM)
• Estimation for how long it will take - Time To Market (TTM

Product Delivery

Deliver to the customer and consider scale, performance, reliability, fault tolerance, security, privacy, internationalization and localization. Something you can sell and run a business on.

Role of delivery managers to help the team to get stuff live faster by removing obstacles that get in the way (can be taken by the engineering manager).

Product Roadmaps

If they contain features it leads to wrong assumptions and expectations. It needs Business Goals to reach and that should be on the roadmap.

Often product roadmaps are all about output, but what matters is outcome. People interpret items on a roadmap as a commitment.

Underlying needs:

• Management wants to make sure that teams are working on the highest-business-value items first
• For date-based commitments they can see and track it

Alternative approach

Provide product vision and strategy. And provide the business objectives. Tell the team what you need them to accomplish and how the results will be measured, and let the team figure out the best way to solve the problems. It is management’s responsibility to provide each product team with the specific business objectives they need to tackle.

Put business objectives into the roadmap and convert to an outcome-based-roadmap. And only add deadline dates to high-integrity commitments that require a certain date to be finished.

It needs time to validate a solution with customers to ensure it has the necessary value and usability, with engineers to ensure feasibility, and with stakeholders to ensure it is viable for the business. Only then one can make date based commitments.

A similar approach is using an OKR system.

Product Leadership

VP product/Head of product/Directors of product/CPO

• Responsible for building the skills of the product managers
• (Sometimes also manages the product designers and data analysts)
• Needs strong competencies in
  • Team development … to build a strong team of product managers and designers
  • Product vision
  • Execution … knows how to get things done
  • Product culture
    • Team understands the importance of continuous and rapid testing and learning
    • Need to make mistakes - do them quickly and mitigate the risks
    • Understand need for continuous innovation

Principal product manager

• Review work of various PMs and teams to identify and help to resolve conflicts
• Main focus on the product itself

(Group product manager)

Leaders of product design

Ensure a consistent and effective user experience systemwide

CTO, managers and architects are responsible for the holistic view of the system implementation. They have a clear strategy for managing technical debt

The Head of product, head of design and head of Technology should sit very close to one another.

Team structuring

Use an empowered, dedicated/durable, cross-functional, collaborative product team model. Increased level of motivation and true sense of ownership.

Principles:

• Alignment with investment strategy (so consider lifespan of products)
• Minimize dependencies
• Ensure ownership and autonomy
• Maximize leverage (by using shared services where appropriate)
• To best support to deliver to the product vision and strategy
• Team Size (total product team not more than 10-12
• Alignment with Architecture
• Alignment with User or Customer
• Alignment with Business

Invest in building a high-leverage foundation.

Team skill levels:

• Experienced and can be entrusted to make good choices
• Having the right intentions but may not have the level of experience to make good decisions in many cases and need some assistance
• Junior team that may not even know what they don’t know yet

Provide the full business context:

• The overall product vision
• The specific business objectives assigned to each team
• Provide clarity on what the team can decide and what not

Business Cases

For ideas that need a larger investment. How much money will you make? How much will it cost? Often done too early in the Discovery funnel, where we don’t know much about that.

Product Manager

Needs to be among the strongest talents in the company.

• Technology sophistication - understand technology trends
• Business savvy - deep knowledge of the business (and the role that the product plays in your business)
• Knowing your stakeholders and the constraints they operate under
• Credibility with key executives
• Deep customer knowledge (issues, pains, desires, their thinking) (B2B: how they work, how they decide to buy)
• Passion for the product
• Respect of their product teams
• Deep knowledge of data and analytics
• Deep knowledge of market and industry - the competitive landscape
• Smart, creative and persistent

Add product marketing in the team. They need to represent the market to the team. The positioning, the messaging and the winning go-to-market plan. And they close the loop with the sales channel.

Work closely with User Research

Support with Qualitative learning:

• Generative:They help to understand the problem we need to solve.
• Evaluative: How well our solutions solve the problem. They can help to find the right type of users, craft the right types of tests and learn the most from each user or customer interaction.

Work closely with Data Analysts

• Manage data privacy constraints
• Analyze the data
• Plan live-data tests
• Understand and interpret the results

Key Responsibilities

• Evaluate opportunities and determine what gets built and delivered to customers.
• Ensure that what goes to the product backlog is worth building.
• Responsible and accountable for the success of the product.

Keys for successful relationship with your designer

• Have the designer sit next to you
• Include designer from the very inception of every idea
• Include designer in as many customer and user interactions as possible. Learn about them together
• Give much room to solve the design challenges themselves
• Encourage to iterate early and often and to explore alternative solutions to the problem. Avoid getting nitpicky on early iterations.

Keys for successful relationship with the engineers

• Share openly what you know about your customers, especially their pain, data and business constraints
• Encourage to voice opinions on developing the product further
• Daily: Solicit ideas/input for items in discovery and answer clarifying questions on the items they’re working on delivering to production.
• Ensure they feel as missionaries … by involving them early and deeply in the customer problem you’re trying to solve and the business problems you face.

Work closely with the Tech Lead … they have the responsibility to help to discover a strong solution.

Product Designer

Modern product designers continuously collaborate with product managers and engineers from discovery to delivery. The product designer is measured on the success of the product.

Deeply oriented around actual customers and the value their product brings to those customers. Incorporate the business constraints into the product design. User experience is as important to customer value as the underlying functionality.

UX is any way that customers and end users realize the value provided by your product.

Think about the customer’s journey over time:

• First learning about the product
• Onboarding of first-time uses and gradually reveal new functionalities?
• Interactions at different times of the day
• Other things competing for user’s attention
• One-month-old customer vs. one-year-old customer
• Motivation of users to increase level of commitment
• Gratification moments
• Sharing experience
• Responsiveness of the product.

Create most of the prototypes used. Constant testing of ideas with real users and customers. And build testing into weekly cadence.

We need design to discover the right product (and not just as a service to make our product beautiful).

Design informs functionality at least as much as functionality drives the design.

Company Stages

Startups

In a race to achieve product market fit before running out of money. Optimized to learn and move quickly.

Growth-Stage

Scaling to Success. Product teams complain that they don’t understand the big picture … they don’t see how their work contributes to the larger goals.

Enterprise

Tweaking and optimizing existing products (value capture). And develop each product to reach its full potential.

Often with lack of innovation, and how much slower it is for new product work to get into the hands of customers.

Product

A holistic definition of a product includes:

• Functionality/Features
• Technology that enables the functionality.
• User experience design the presents this functionality
• How do we monetize this functionality?
• How do we attract and acquire users and customers?
• Offline experiences.

Dual Track

Discovery in parallel to Delivery We work in parallel to discover the necessary product to be built - which is primarily what the product manager and designer work on every day - while the engineers work to deliver production-quality products.

Principles of strong product teams

• Durable and dedicated to a product
• Combine different specialized skills and feel real ownership for a product
• Team of Missionaries (not teams of mercenaries) … they believe in the vision and are committed to solving problems for their customers.
• Product Manager, Product Designer and Engineers work in close collaboration
• Given clear objectives and the team owns delivering on those objectives.
• No people managers in that team and PM is not the boss of anyone on the product team
• If possible co-located
• Type of work - Has responsibility for all the work - projects, features, bug-fixes, performance work, optimizations, content changes
• Scope of work
• Autonomy - they are able to solve the problems they are assigned in the best way they see fit.

Head of Product and Head of Engineering get together to define the size and scope of the teams.

The right process

A combination of techniques, mindset and culture.

2 significant challenges to tackle:

Discover in detail what the customer solution needs to be. We need to be able to test out many ideas, and we need to do this quickly and inexpensively.

We need to deliver a robust and scalable implementation. The team needs to release with confidence.

So we need to learn fast, yet also release with confidence.

The term product

A state at which we can run a business on it. It is scalable and performant to the degree necessary. It has a string suite of automated regression tests. It is instrumented to collect the necessary analytics. It is maintainable. And consistent with brand promise. And it is something the team can release with confidence.

Good teams/bad teams

Enjoy this post?