Marty Cagan: Inspired; How to Create Tech Product Customers Love

Lessons from the Top Tech Companies

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

The state of the art is very different from the state of the practice.

Behind Every Great Product

Behind every great product there is someone. Usually they have the title product manager, but they might be a startup co-founder or CEO. This product management role is very distinct from the design, engineering, marketing, or project manager roles.

Technology-Powered Products and Services

It is author’s belief that most products are transforming into technology-powered products, and the companies that don’t realize this are rapidly being disrupted.

Startups: Getting to Product/Market Fit

Three stages of companies: startups, growth-stage, and enterprise companies. Startup are product companies that has yet to achieve product/market fit. In them the product manager role is usually covered by one of the co-founders.

Growth-Stage Companies: Scaling to Success

Growing brings different challenges. Replication of early success. A lot of hiring. Keeping the early growth. GTM model adjustment. Technology infrastructure growth.

Enterprise Companies: Consistent Product Innovation

Strong tech-product companies know they need to ensure consistent product innovation.

The Root Causes of Failed Product Efforts

Everything starts with ideas.

Ideas. Biz Case. Roadmap. Requirements. Design. Build. Test. Deploy. That is the road to new products.

10 biggest problems with this way of working:

• At the top – the source of ideas. This model leads to sales-driven specials and stakeholder-driven products. Lack of team empowerment. They’re mercenaries.
• Regarding biz case. We ask how much money you’ll make and how much it will cost. The cold, hard truth is that, at this stage, we have no clue about either of these.
• Product roadmap. Vast majority of roadmaps are only prioritized lists of features and projects. But half of the ideas will not work. And time to money counts also.
• The rule of product management. It is really a form of project management. Gathering requirements and documenting them for engineers.
• The role of design. The lipstick on the pig model.
• Engineering gets brought in way too late.
• The principles and key benefits of Agile enter the picture far too late.
• The entire process is very project-centric.
• Customer validation happens way too late.
• The opportunity cost of what the organization could have and should have been doing instead.

Beyond Lean and Agile

Three overreaching principles at work:

• Risks are tackled up front, rather than at the end.
• Products are defined and designed to collaboratively, rather than sequentially.
• Finally, it’s all about solving problems, not implementing features.

Key Concepts

Holistic definition of product:

• The functionality – features.
• User experience design that presents this functionality.
• How we monetize this functionality.
• How we attract and acquire users and customers.
• Offline experience.

We need to discover the product to be built, and we need to deliver that product to the market.

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. Answering four critical questions: will the user buy this (or choose to use it), can the user figure out how to use this, can our engineers build this, can our stakeholders support this.

We use prototypes. We think about product delivery. We think about product/market fit, and we think about product vision.

The concept of MVP (minimum viable product). The term was coined by Frank Robinson in 2001. It was popularized in the book The Lean Startup by Eric Ries in 2011.

The Right People

Principles of Strong Product Teams

It is all about product team. They are sometimes referred to as dedicated teams or as a durable product teams, or sometimes as a squad.

John Doerr: “We need a team of missionaries, not teams of mercenaries.”[1]

Mercenaries build whatever they’re told to build. Missionaries are true believers in the vision and are committed to solving problems for their customers.

A typical product team is comprised of a product manager, a product designer, and somewhere between two and about 10 to 12 engineers.

A product team is not about reporting relationships – it has an intentionally flat organizational structure. The product manager is not the boss of anyone on the product team.

We try very hard to co-locate this team.

The product is the full customer experience and each team is responsible for some smaller but meaningful piece of that experience.

What is critically important is alignment between product management and engineering.

A product team is not something we create just to deliver a specific product.

Instead of the old product-oriented model, in the dedicated-team model, the team is not off the hook just because something launches.

The Product Manager

There are essentially three ways for a product manager to work and only one of them leads to success:

• The product manager can escalate every issue and decision up to the CEO.
• The product manager can call a meeting with all the stakeholders in the room and then left them fight it out.
• The product manager can do his or her job.

When a product succeeds, it’s because everyone on the team did what they needed to do. But when a product fails, it’s the product manager’s fault.

There are four key responsibilities of a strong product manager:

• Deep knowledge of the customer.
• Deep knowledge of the data.
• Deep knowledge of your business.
• Deep knowledge of your market and industry.

The successful product manager must be the very best versions of smart, creative, and persistent.

Good product managers:

• Jane Manning of Google
• Lea Hickman of Adobe
• Alex Pressland of the BBC
• Martina Lauchengco of Microsoft
• Kate Arnold of Netflix
• Camille Hearst of Apple

Product owner is the name of the role on an Agile team for the person responsible for the product backlog. In product companies, it is critical that the product managers also be the product owner.

The Product Designer

Modern product designers are responsible for the following:

• Product discovery. They continuously collaborate with product managers and engineers – form discovery to delivery.
• Holistic user experience design. User experience is much bigger than user interface.
• Prototyping.
• User testing. User testing is broader than usability testing.
• Interaction and visual design. Interaction includes the task flows and control layouts. Visual design includes composition, typography, and how the visual brand is expressed.

The Engineers

The engineering role is also called developer or programmer.

There is probably no more important relationship for a successful product manager than the one with your engineers.

It is good to have technology knowledge as project manager but don’t use that knowledge to do engineers work.

Product Marketing Managers

There are typically fewer product marketers than product teams. In the best tech product companies, product marketing plays essential role in discovery, delivery, and, ultimately, go-to market, which is why they are important members of the product team.

The Supporting Roles

Some of the roles. User Researchers. Data Analysts. The Automation Engineers.

Profile: Jane Manning of Google

AdWords is currently 16 years old, and in the most recent year alone, it generated well over 60 billion USD revenue. Jane Manning was the engineering manager asked to serve as product manager on AdWords in 2000. She coordinated the hard project so that everybody accepted it.

There are always so many good reasons for products not to get built. In the products that succeed, there is always someone like Jane.

The Role of Leadership

The primary job of leadership in any technology organization is to recruit, to develop, and to retrain strong talent.

One of the big challenges of growth is knowing how the whole product hangs together. Some people like to think of holistic view as connecting the dots between the teams. The three distinct but critical elements to the holistic view: leaders of product management, leaders of product design and leaders of technology organization.

The Head of Product Role

Organizationally, this role typically manages the product managers and product designers, sometimes the data analysts, and generally reports to CEO.

You are looking for someone who is proved to be strong in four key competencies: team development, product vision, execution and product culture. There is one more thing: Your product leader must be able to work well on a personal level with the other key execs, especially the CEO and CTO.

The GPM is a hybrid role – individual contributor and people manager. The GPM is actual product manager for one product team, but in addition, she is responsible for the development and coaching of a small number of additional product managers.

The Head of Technology Role

They are six major responsibilities of a CTO:

• Organization
• Leadership
• Delivery
• Architecture
• Discovery
• Evangelism

The Delivery Manager Role

Delivery managers are a special type of project manager whose mission is all about removing obstacles – also known as impediments – for the team.

They are also typically the Scrum Masters for the team.

Principles of Structuring Product Teams

Some critical core principles:

• Alignment with investment strategy.
• Minimize dependencies.
• Ownership and autonomy.
• Maximize leverage.
• Product vision and strategy.
• Team size.
• Alignment with architecture.
• Alignment with user and customer.
• Alignment with business.
• Structure is a moving target.

Foundation of team building, key factors to consider:

Team skill level. Three team skill levels: A team – experienced individuals, B team – right intentions but maybe lack some expertise, C team – juniors.

Importance of speed.

Importance of integration,

Source of innovation.

Company size and location.

Company culture.

Maturity of technology.

Importance to business.

Level of accountability.

Profile: Lea Hickman of Adobe

One of the absolute hardest assignments in our industry is to try to cause dramatic change in a large and financially successful company.

In 2011, Lea Hickman led product for Adobe’s Creative Suite. To Lea, there was no such thing as over-communication.

The Right Product

The Problems with Product Roadmaps

The first inconvenient truth is that at least of our product ideas are just not going to work.

The issue is that anytime you put a list of ideas on a document entitled “roadmap”, no matter how many disclaimers you put on it, people across the company will interpret the items as a commitment.

The Alternative to Roadmaps

Roadmaps serve two purposes:

• The first purpose is because the management of the company wants to make sure that teams are working on the highest-business-value items first.
• The second purpose is because there are cases where they need to make date-based commitments, and the roadmap is where they see and track those commitments.

The product teams need to have the necessary business context. There are two main components that provide this business context:

• The product vision and strategy.
• The business objectives.

The high-integrity commitment is the concept used where we need to commit to a date or a specific deliverable:

• The teams are much more motivated when they are free to solve the problem the best way they see fit.
• The team is not off the hook just by delivering the requested feature or project. The feature must solve the business problem.
• Where often the initial approach doesn’t work.

It is all about outcome rather than output. We should introduce outcome-based roadmaps. They are essentially equivalent to using a business objective-based systems such as the OKR system.

Majority of the commitments are made too early. In the continuous discovery and delivery model, the way we manage commitments is with a little bit of give and take. Once we come up with a solution that works for our business, we now can make an informed and high-integrity commitments.

Product Vision and Product Strategy

The product vision describes the future we are trying to create, typically somewhere between two and five years out. This is not the company mission statement.

The product strategy is our sequence of products or releases we plan to deliver on the path to realizing the product vision.

For consumer-focused companies, we often structure each product/market fit around a different customer or user persona. Sometimes, the product strategy is based on geography. And sometimes, the product strategy is based on achieving a set of key milestones in some sort of logical and important order.

The difference between vision and strategy is the difference between good leadership and good management. Leadership inspires and sets the direction, and management helps get us there. The product strategy should be inspiring, and the product strategy should be focused.

Prioritizing Markets:

• The first input to your decision is market sizing, usually referred to as total addressable market (TAM).
• The second factor concerns distribution, usually referred to as go to market (GTM).
• The third factor is a (very rough) estimation of how long it will take, referred to as time to market (TTM).

Principles of Product Vision

The 10 key principles for coming up with an effective product vision:

• Start with why.
• 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 because, if you don’t someone else will.
• The product vision needs to inspire.
• Determine and embrace relevant and meaningful trends.
• Skate to where the puck is heading, not to where it was.
• Be stubborn on vision but flexible on the details.
• Realize that any product vision is a leap of faith.
• Evangelize continuously and relentlessly.

Principles of Product Strategy

Good product strategies have five things in common:

• Focus on one target market or persona at a time.
• Product strategy needs to be aligned with business strategy.
• Product strategy needs to be aligned with sales and go-to market strategy.
• Obsess over customers, not over competitors.
• Communicate the strategy across the organization.

Product principles

The principles serve as a clear statement of what you believe – intended for your users, customers, partners, suppliers, investors, and your employees.

Product Objectives

Management by objectives (MBO) is the antithesis of management by control.

George Patton: “Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity.”[2]

The OKR Technique

The Objective and Key Results (OKR) technique is a tool for management, focus and alignment.

Objectives should be qualitative: key results need to be quantitative/measurable.

Key results should be a measure of business results, not output or tasks.

The product management, design, and technology organization, focus on the organization’s objectives fore each product team.

The heads of product and technology are responsible for the product team objectives.

Product Team Objectives

If you deploy OKRs for your product organization, the key is to focus your OKRs at the product team level. This means don’t let functional team or individual person OKRs confuse the issue.

Product Objectives @ Scale

It is very common to have some significant number of product teams that are there in support of the other product team. These are often called platform product teams, or shared services product teams.

Product Evangelism

Product evangelism is, as Guy Kawasaki put it years ago, “selling the dream”.

Top-10 pieces of advice to sell the dream:

• Use a prototype.
• Share the pain.
• Share the vision.
• Share learnings generously.
• Share credit generously.
• Learn to give a great demo.
• Do your homework.
• Be genuinely excited.
• Learn to show some enthusiasm.
• Spend time with your team.

Profile: Alex Pressland of the BBC

She was responsible for a dramatic shift at the BBC – from broadcast content to content distribution – and this work dramatically affected reach and soon became the basis for BBC’s mobile efforts.

The Right Process

The Right Process is more accurately described as a combination of techniques, as our focus is on product managers, and that is their primary responsibility.

Product Discovery

Two significant challenges for most of the teams:

• First, discovering in detail what the customer solution needs to be. We need to come up with a single solution that works for many customers, and not a series of specials.
• Second, we need to ensure we deliver a robust and scalable implementation that our customers can depend on for consistently reliable value.

We need to learn fast, yet also release with confidence.

The purpose of product discovery is to make sure we have some evidence that when we ask engineers to build a production-quality product, it won’t be a wasted effort.

Principles of Product Discovery

The purpose of product discovery is to address these critical risks:

• Will the customer buy this, or choose to use it? (Value risk)
• Can the user figure out how to use it? (Usability risk)
• Can we build it? (Feasibility risk)
• Does this solution work for our business? (Business viability risk)

We need to collect the evidence.

Customers don’t know what’s possible, and with technology products, none of us know what we really want until we actually see it.

The hardest part of all is creating the necessary value so that customers ultimately choose to buy or to use.

Functionality, design, and technology are inherently intertwined.

Marc Andersen said that the most important thing is to know what you can’t know. And we can’t know in advance which our ideas will work with customers and which won’t.

We must validate our ideas on real users and customers.

Discovery is about the need for speed.

We need to validate the feasibility of our ideas during discovery not after. Same goes for business viability.

It’s about shared learning.

We loosely define an iteration in discovery as trying out at least one new idea or approach. To set your expectations, teams competent in modern discovery techniques can generally test on the order of 10-20 iterations per week.

Discovery Techniques Overview

Discovery framing techniques help us to quickly identify the underlying issues that must be tackled during product discovery.

Planning, ideation, prototyping and testing. Testing feasibility, usability, value, business viability.

Ensure that team is on the same page in terms of clarity of purpose and alignment. Identify the big risks: financial risks, business development risks, marketing risks, sales risks, legal risks and ethical risks.

Three favorite techniques:

• An opportunity assessment is designed for the vast majority of product work.
• A customer letter is designed for a larger projects or initiatives.
• A startup canvas for those times you’re creating an entirely new product line or a new business.

Opportunity Assessment Technique

It answer four key questions:

• What business objective 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 focused on? (Target market)

Customer Letter Technique

Amazon uses working backward process, where they start the effort with a pretended press release. The press release is intended to the product team and leadership.

Some people also consider this a demand-validation technique (if you can’t get your team excited, maybe it’s not worth doing).

One variation of this technique is customer letter instead of press release.

Startup Canvas Technique

To get someone to switch to our new product, it must be demonstrably and substantially better.

Story Map Technique

Story maps are one of the most generally useful techniques. They are essentially a framing and planning technique, but they are just as useful for ideation.

Jeff Patton, one of the early Agile thinkers, leveraged some proven UX design techniques, and adapted them to Agile concept and introduced user story maps.

These are two-dimensional maps, in which major user activities are arrayed along the horizontal dimension, loosely ordered by time from left to right. As we flash out each major activity into sets of user tasks, we add stories for each of those tasks. The critical tasks are higher vertically than the optional tasks.

Customer Discovery Program Technique

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.

Without reference customers, it’s very hard for the sales team to know where the real product/market fit is.

For products and services aimed at businesses the key number is six reference customers.

If you have problem getting five to six prospects than it’s very possible you are working on the wrong problem. This is one of the very first reality checks (aka demand validation).

Product/market fit shows up in terms of happier customers, lover churn rates, shortened sales cycles and rapid organic growth.

One of the most common techniques for assessing product/market fit is known as the Sean Ellis test. The categories of product validation (based on the question how disappointed they would be if they could not use product or service anymore) are: very disappointed, somewhat disappointed, don’t care and no longer relevant because I no longer use it.

Profile: Martina Lauchengco of Microsoft

In 1993, Word 6.0 was the biggest release, feature-wise, Microsoft had ever produced. But there was issue with Mac users. Martina was a young product manager that helped launch 6.1.

If the product team is given actual business problems to solve rather than solutions, and the product team does their job and interacts directly and frequently with actual users and customers, then getting a sufficient quantity and quality of product ideas is not really a problem.

Customer Interviews

The customer interview is the most basic technique.

• 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?

Concierge Test Technique

A concierge test is one of my favorite techniques for quickly generating high-quality ideas. The idea is that we do customer’s job for them – manually and personally.

If you are building a customer-enabling product, the users may be employees of your company, but the technique is the same.

The Power of Customer Misbehavior

Author considers developers to be one of the consistently best sources of truly innovative product ideas.

Hack Days

There are many variations of hack days. The two main types of hack days are directed and undirected. In a directed, there’s a customer problem.

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.

Discovery Prototyping Techniques

Fred Brooks: “Plan to throw one away, you will, anyhow.”[3]

Feasibility prototypes, user prototypes, live-data prototypes and hybrid prototypes.

Principles of Prototypes

The overarching purpose of any form of prototype is to learn something at a much lower cost in terms of time and effort than building out a product.

There are many different levels of fidelity for a prototype. The fidelity primarily refers to how realistic the prototype looks.

Feasibility Prototype Technique

Building a feasibility prototype requires usually just a day or two of time.

User Prototype Technique

A user prototype – one of the most powerful tools in product discovery – is a simulation.

The big limitation of a user prototype is that it’s not good for providing anything – like whether or not your product will sell.

Live-Data Prototype Technique

Sometimes, in order to address a major risk identified in discovery, we need to be able to collect some actual usage data.

Hybrid Prototype Technique

A Wizard of Oz Prototype is a hybrid prototype which 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.

We think of four types of questions we’re trying to answer during discovery:

• Will the user or customer choose to use or buy this? (Value)
• Can the user figure out how to use it? (Usability)
• Can we build this? (Feasibility)
• Is this solution viable for our business? (Business viability)

Testing Usability

Usability testing is typically the most mature and straightforward form of discovery testing, and it has existed for many years.

We usually do usability testing with a high-fidelity user prototype.

Testing Value

Customers don’t have to buy our products, and users don’t have to choose to use a feature. They will only do so if they perceive real value.

There are several elements of value, and there are techniques for testing all of them.

Testing demand, testing value qualitatively, testing value quantitatively.

Demand Testing Techniques

We have a fake door demand test and a landing page demand test. We can show it to just a very small percentage of users or withing in a specific geography.

We get some good evidence on demand and a list of users who are ready and willing to talk with you about this specific new capability.

Qualitative Value Testing Techniques

It can tell us what’s happening (or not), but it can’t tell us why, and what to do to correct the situation.

Qualitative testing is not about proving anything. That’s what quantitative testing is for. Qualitative testing is about rapid learning and big insights.

Quantitative Value Testing Techniques

Quantitative testing is all about collecting evidence. Collect enough data that we have statistically significant results.

Gold standard for this kind of testing is A/B testing.

User analytics is just one type of analytics. Product team should have some business objectives – with measurable goals, and they should track product progress.

Testing Feasibility

Validating feasibility:

• Do we know how to build it?
• Do we have the skills?
• Do we have enough time?
• Are there any architectural changes needed?
• Do we have all the components?
• Do we understand the dependencies?
• Will the performance be acceptable?
• Will it scale?
• Do we have the infrastructure?
• Can we afford the cost?

Testing Business Viability

We must have a business model that will work.

A direct sales channel is very expensive.

Some tech companies have a high-touch customer service model, others a low-touch.

A user test is when we test out product ideas on real users and customers. A product demo is when you sell your product to prospective users and customers, or evangelize your product across your company.

Profile: Kate Arnold of Netflix

She was responsible for moving to subscription service. They knew they need to somehow get customer to want and ask for a blend of expensive and less expensive titles. This is where Netflix’s queue, ratings systems, and recommendations engine all came from.

Discovery Sprint Technique

A discovery sprint is one-week time box of product discover work, designed to tackle a substantial problem or risk your product team is facing.

Pilot Team Technique

To maximize the chance of the pilot teams having a good outcome, we carefully consider the people involved, their location, and their degree of autonomy.

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.

It is all too easy to institute processes that govern how your produce products that can bring innovation to a grinding halt.

Managing Stakeholders

For many product managers, managing stakeholders is probably the least favorite part of their job.

In many companies, just about anyone and everyone feels like they have a say in the products.

One practical test of whether a person is considered a stakeholder is whether or not they have the power, or can otherwise prevent your work from launching.

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.

The key technique is to spend one-on-one time with the key stakeholders.

Presentations are notoriously terrible for testing business viability. The reason is that they are far too ambiguous.

Communicating Product Learnings

Sharing in startup environments is easy, in scale up environments it gets difficult. One way is to have regular all-hands meetings.

Profile: Camille Hearst of Apple

She was a product manager on the iTunes team.

The Right Culture

Good Product Team/Bad Product Team

Creating the right product culture is mandatory for success.

Good teams have a compelling product vision that they pursue with a missionary-like passion. Bad teams are mercenaries.

Top Reasons for Loss of Innovation

Organizations that lose the ability to innovate at scale are inevitably missing one or more of the following attributes:

• Customer-centric culture.
• Compelling product vision.
• Focused product strategy.
• Strong product manager.
• Stable product teams.
• Engineering in discovery.
• Corporate courage.
• Empowered product teams.
• Product mindset.
• Time to innovate.

Top Reasons for Loss of Velocity

If you are seeing a slowdown, these are the first things to look for:

• Technical debt.
• Lack of strong product managers.
• Lack of delivery management.
• Infrequent release cycles.
• Lack of product vision and strategy.
• Lack of co-located, durable product teams.
• Not including engineers early enough during product discovery.
• 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.
• Changing priorities.
• A consensus culture.

Establish a Strong Product Culture

Thinking about product culture along two dimensions: the first is whether the company can consistently innovate to come up with valuable solutions for their customers and the second is execution.

We are looking for a culture of experimentation, empowerment, open-mind, customer and business-savy, discovery driven, urgency, high-integrity commitment, accountability, collaboration, results and recognition.

---

[1] In the book on page 34

[2] In the book on page 137

[3] In the book on page 223