Inspired - How To Create Products Customers Love by Marty Cagan

These are my personal notes for future reference I took reading Inspired: How To Create Products Customers Love by Marty Cagan. This isn’t meant to be a Cliff Notes version or replacement for reading the book. Chapter number is in parenthesis with the header (for future reference). Especially important things are highlighted.

Additional notes I’ve taken while reading other books can be found here.

Introduction

It doesn’t matter how good your engineering team is if they aren’t given something worthwhile to build. You shouldn’t be spending time/money on a product that we don’t know users and customers want.

The truths of great products

1. The PM’s job is to discover a product that is valuable, usable and feasible.
2. Product discovery is a collaboration between the PM, interaction designer and architect.
3. UX is even more important and even more difficult than engineering.
4. Engineers are typically poor at UX - they think in terms of implementation, users think in terms of conceptual models.
5. UX design means both interaction design and visual design.
6. Functionality (product requirements) and UX design are inherently intertwined.
7. Product ideas must be tested - early and often - on actual target users in order to come up with a product that is valuable and usable.
8. High fidelity prototypes are necessary to quickly, easily and frequently test our ideas on real users.
9. The PM needs to identify the minimum possible product that meets the objectives (valuable, usable and feasible) minimizing time to market and user complexity.
10. Once the minimal successful product has been discovered and validated, it is not something that can be piece mealed and expect the same results.

Key Roles & Responsibilities (1)

The product manager has two key responsibilities (1) accessing product opportunities and (2) defining the product to be built. Ideas can come from anywhere, but the PM’s job is to take a hard look and decide if something is worth pursuing.

Once we have decided what a good opportunity is, someone (the PM) needs to discover what the solution (e.g. the product) actually is - the features, the functionality, the UX, and the release criteria.

Recommended benchmark: one PM to 5-10 engineers.

Product Management vs Product Marketing (2)

The PM should define in detail the product that the engineering team should build. Every product should have a single, accountable PM - who is responsible for the product definition (the combination of product requirements + UX design that describe the product to build).

Product Management vs Project Management (3)

PM’s used to double as project managers back when software release packages were every couple of months or even couple of years later. This is no longer feasible.

What makes a great project manager?

Why? Your product will get to market faster - which could ultimately make the difference between getting your product shipped at all.

• Sense of urgency
• Clearly and concisely frame problems and run constructive meetings
• Good judgement: knowing when to push, when to escalate, when to get more information, etc.
• Great problem solvers - don’t make excuses. Make it happen. Tireless and unstoppable.

Product Management vs Design (4)

Interaction Design: responsible for developing a deep understanding of the target users (each persona you’re trying to satisfy with the product), and coming up with the tasks, navigation and the flow that are both usable and productive.

Visual Design: Put flesh on the wireframes and create the actual pages and the interface’s look and feel

Rapid Prototyping: Prototype that can be tested on real users and iterated upon.

Usability Testing: Research and analysis of the users, evaluating whether products or prototypes allow a user to easily achieve objectives.

Product Management vs Engineering (5)

Product defines the right product, engineering is responsible for building the product right. Engineering is essentially an execution based activity - which makes it hard to perform discovery activities (in an organization optimized for execution).

How to help engineering

1. Don’t define the ultimate product. Define the smallest possible product that will meet your goals.
2. Do everything you can to minimize “churn” - changing the requirements/definition once engineering has started to build the product.
3. Jump on questions as fast as possible (e.g. use cases that were missed or not completely thought through)

Dealing with Technical Debt

Allocate a certain percentage of engineering capacity for “headroom” (e.g. 20% of the team’s capacity right off the top) to allow engineering to rewrite, re-architect, or re-factor problematic parts of the code base.

Recruiting Product Managers (6)

What traits should PM’s have?

Product Passion: People who love products - live, eat and breathe them. PM’s have to inspire the rest of the product team, and a passion for a product is contagious.

Customer Empathy: PM’s should empathize with the target market. One of the most common mistakes is confusing themselves for their customers / target users. The target market very likely has different values, priorities, perceptions, tolerances, experiences and technical understandings.

Intelligence: There’s no substitute.

Work Ethic: Hard work is necessary. The PM is the person ultimately held accountable for the success of the product.

Integrity: The PM can’t simply direct people to do his bidding. Rather, he must work to influence those on his team. This persuasion is done by mutual trust and respect - both of which come from the integrity of the PM. While he may not be an expert in every role of the product team, he should have a deep understanding and respect for what each team member is responsible for, and he should be willing to trust those people to do their job.

Confidence: In communicating persuasively, confidence is critical. People are more likely to follow a leader who is confident, rather than one who is not.

Attitude: The successful PM sees himself as the CEO of the product. He takes full responsibility for the product, and does not make excuses.

This does not mean he micro-manages the product team or tries to do everything himself, but rather he is quick to take the blame if something goes wrong, and equally quick to give credit to the rest of the team when it goes well.

Applying Technology: A big part of defining a successful product is understanding new technology and seeing how it might be applied to help solve a relevant problem.

Focus: Focus helps reduce the number of cluttering features, reduce the time it takes you to build the product, and thus the time it takes to get to market and your costs of getting there.

Time Management: Spend time on activities that will actually make a difference.

Communication Skills: Especially written skills

Business Skills: PM's need to be bilingual - able to converse equally well with engineers about technology as they do with executives and marketers about costs structures, margins, market share, positioning, brand, etc.

Does age matter?

Remember that the internet has only been used by the widespread public since ~1995, so anyone who is 25 or order probably has the same amount of experience online as the rest of us do.

Managing Product Managers (7)

Director or VP of Product Management has two responsibilities

1. Build a strong team of PM’s
2. Responsible for the company’s overall product strategy, and the various products in the company’s portfolio.

The only true measure of the PM is the success of his/her product.

Patton’s Advice for Product Managers (8)

Customers will tell you how your product should work, rather than what your product should do. It’s human nature to envision solutions to problems. However, a PM should be focused on the problem to be solved.

Assessing Product Opportunities (11)

Look before you leap.

PM’s should answer ten fundamental questions. Again, this should be the problem to be solved, not the solution you have in mind.

1. What is the problem this will solve? (value proposition)
2. For whom do we solve that problem? (target market)
3. How big is the opportunity? (market size)
4. How will we measure success? (metrics/revenue strategy)
5. What alternatives are out there now? (competitive landscape)
6. Why are we suited to pursue this? (our differentiator)
7. Why now? (market window)
8. How will we get this product to market (go to market)
9. What factors are critical to success? (solution requirements)
10. Given the above, what’s the recommendation? (go or no -go)

Choosing the right set of products to pursue is among the most important decisions a company will make.

Build new or fix old?

Many times, the best product opportunities sit under a company’s nose. In particular, the biggest bang for the buck comes from improving existing products that are not performing at the level they should or could be. The tendency is to assume the product is already as good as it can be.

Examples: Funnel improvement, improving usability (could reduce the need for customer service staff - cost savings).

Product Principles (13)

Product principles mean deciding what’s important to you. What’s strategic and fundamental? What’s simply tactical and temporary?

This is a process for understanding the DNA of a company, and what the founders hope to achieve.

Example: If a movie site believes the user community’s opinions on movies are more valuable than a professional reviewer’s and a movie studio comes along and wants to put reviews on your site - you can decide if this is consistent with your principles or not.

Product principles should also be prioritized. Countless products want to be easy to use and also safe and secure. Which is a priority though - is ease of use paramount? Or is safety and security the primary concern?

It’s important that PM’s are completely transparent in their decision making process. You don’t want the team thinking you’re just following your intuition.

Charter User Programs (15)

Companies should have a solid set of reference customers for launching products.

PM’s need to gain a deep understanding of the target customer, the problem to be solved and whether you can come up with a product to meet those needs.

Be mindful that you're trying to build a general product - something that can be sold to a large set of customers, not a custom solution for one company.

Reinventing the Product Spec (17)

The majority of the product spec should be replaced by the high fidelity prototype - functional requirements, information architecture, interaction design, and visual design of the user experience.

Because typical spec is so poor (incomplete, ambiguous, untested), so few of the hard questions and critical details are actually addressed and resolved. This leads to churn (spec changes leading to delays and engineering frustration) or engineers just make assumptions the best they can.

Design vs Implementation (19)

Many product tasks can be done in parallel, but user experience design and implementation should NOT be done in parallel.

Don’t wait until your beta to start getting feedback - a good UX designer will want to try out dozens of ideas and approaches in a matter of days.

Product Validation (21)

Usability testing (if users can figure out how to do the necessary tasks) vs Value testing (do users actually care about those tasks and how well you’ve solved them)

Prototype Testing (22)

Testing your ideas with real users is probably the single most important activity in your job as a product manager.

Preparing the Test

• Define in advance the set of tasks you want to test
• Start with learning how your users think about this problem today, without your product. Start them out with an empty browser and see what they do. Once the tester uses the prototype, you can ask what they like better.
• Before using the prototype, ask your tester if they can tell from the home page or landing page what you actually do (while they still have the first time visitor context).
• Ask NPS
• Using a scale (1-10) allows you to track averages as they improve over time. Value can be gauged by asking users how much they would pay for your service (even if you don’t intend to charge).

The Test Environment

• You can learn a lot from observing a customer’s office. How big is their monitor? How fast is their computer and network? How do the communicate with their colleagues on their work tasks?
• It’s always better to prepare tests in person. There’s no substitute for looking at a person’s eyes and body language.
• One person should administer the test while another person takes notes.

Testing the Prototype

• The sooner you get to the test the better - you want a user’s untainted impressions first.
• Make sure to stress (1) this is a prototype - a very early product idea (2) you won’t hurt your feelings by giving their honest opinion - good or bad (3) you’re testing the prototype - not testing him or her.
• Keep users in “use mode” and out of “critique mode” - what matters is if users can easily do the tasks they need to do and whether the value the product.
• Learn to keep quiet - resist the urge to help the tester out or “leading the witness” (it’s okay to ask the user what he/she is specifically looking for - since that information is valuable to you)
• Fundamentally, you’re trying to get an understanding of how your target users think about the problem and identify where the prototype is inconsistent or incompatible with how the user thinks about the problem.

Make updates to the prototype as soon as you know you need to make a fix - you don’t have to be hit on the by eight users in a row to know this.

Improving Existing Products (23)

Most product organizations are just feature factories - all too often these features end up making the situation worse and not better. Start with a clear understanding of what you’re trying to achieve.

Your job as a PM is to live and breath the product metrics. Every day you should ask yourself what you can do to improve them. And you work closely with an interaction designer, user researcher, and lead engineer to consider possibilities,

Gentle Deployment (24)

As a general rule, users don’t like change. Sure they want the software to be great, and they clamor for new functionality, but most people aren’t excited about taking the time to learn a new way to do something the can already do.

• Communicate changes in advance
• Ensure you won’t have to rollback your updates
• Deploy a parallel version of your product and invite people to opt-in and try out the new version when they have time. Allow those who try to use the new version to make it their default with they like it.
• Give users sufficient notice for when support of the old version will be discontinued.

Rapid Response (25)

When measuring success, you need to have a clear prioritized set of business metrics. You need to know what results you would consider a success and what results you would consider a problem.

Succeeding with Agile Methods (26)

Using Agile is not an excuse for a lack of product planning. As a PM, you still need to know where you’re going, what you’re trying to accomplish, and how you’ll measure success.

You and your designers should be one or two sprints ahead of your team. You shouldn’t be trying to do design work during the sprint while implementation is already underway.

Ensure there is sufficient functionality to warrant a release to the user - remember that constant change can be upsetting to your customers.

Demo the current state of the product at the end of each sprint.

Succeeding with Waterfall Processes(27)

There’s no actual working software until nearly the end of the development process, so there is little if any visibility into whether the software will be useful until after the majority of the investment has been made.

Succeeding in Large Companies (31)

Most people wander around in the dark and bitch about it being dark, instead of learning where the light switches are. -David Weiden

Beware of Specials (32)

A special is when a company gets a big check from a prospective customer or partner with the condition that you build into your product exactly what they say.

What’s the problem? After all, you want to be “market driven” and listen to your customers. You’ll probably going to be adding these features at some point anyway - so why not let the customer underwrite them?

One of the surest ways to derail a product is to confuse “customer requirements” with “product requirements.”

1. It’s extremely difficult for a customer to know what he needs until he sees it.
2. Customers don’t know what’s possible.
3. Customers don’t often interact with other customers in order to identify common themes.

The PM needs to work with the customer to tease out the core issues and needs. You can help them recognize that there may be other approaches to this problem that provide a solution they might even like better.

The New Old Thing (34)

Great product leaders know what is now possible is always changing. New technologies enable new solutions that may not have been possible or feasible until now.

The Emotional Adoption Curve (35)

Interview with Jeff Bonforte

I like my product managers to focus on the most miserable thing people have to deal with everyday. If you can solve that problem, that actually changes behavior, and that can lead to the truly big product wins… Too many product managers talk in terms of features and technology, and we don’t really talk in terms of the user’s core needs or emotions.

An analogy for Moore’s Technology Adoption Model: the Lover, the Irrational, the Efficient, the Laugher and the Comfortable.

The Lover (Innovators): Techies who buy the product because they find the technology cool. These people are very dangerous to PM’s because they are driven by different needs than the larger population.

The Irrationals (Early Adopters): Feel the same emotions as the general population but with more intensity - which can lead to buying behavior that isn’t economically rational.

The Efficients (Early Majority): Will adopt when technology becomes practical. They feel the same emotions as the Irrationals but are more pragmatic about the costs.

The Laughers (Late Majority): Feel the same emotion but don’t want to deal with any grief in order to get the benefits.

The Comfortable (Laggards): The 15% that want the benefits but it just has to be drop dead simple and convenient for them to make the move.

What do you teach your PM’s to look for?

Look for anger, exasperation, and frustration. If you just take a look at all those we love to hate - the telcos, banks, consumer credit firms, the tax man, government bureaucracy, airlines, healthcare - these are all great opportunities for innovation because the consumer latent frustration is so high.

Google is a big winner in this way of thinking because of how many countless critical needs it addresses - how to treat a disease you’ve been diagnosed with, if you want to buy something. They’re good guys who help you with whatever problem you have.

The “Freshman Test”

Think back to the first day you walked into high school. You feel more pure emotions of human frailty in that one day than any other day in your life - loneliness, insecurity, fear, frustration, anger.

Product Manager Worry List (41)

The questions a PM is constantly asking himself/herself…

1. Is my product compelling enough to our target customer?
2. Have we made this product as easy to use as humanly possible?
3. Will this product succeed against the competition? Not today’s competition but the competition that will be in the market when we ship.
4. Do I know customers who will really buy this product? Not the product I wish we were going to build but what we’re really going to build.
5. Is my product truly differentiated? Can I explain the differentiation to a company executive in two minutes? To a smart customer in one minute? To an industry analyst in 30 seconds?
6. Will the product actually work?
7. Is the product a whole product? How will customers actually think about and buy the product? Is it consistent with how we plan to sell it?
8. Are the product’s strengths consistent with what’s important to our customers? Are we positioning these strengths as aggressively as possible?
9. Is the product worth the money? How much money? Why? Can customers get it cheaper elsewhere?
10. Do I understand what the rest of the product team thinks is good about the product? Is it consistent with my own view?

Photo taken with VSCOcam