Lit Notes for the book: Inspired by Marty Cagan

These are distilled, organized, re-worded, notes from the book. Once I’m done organizing this into my own format, I will integrate each atomic note into the Miki.

The need/problem/reason for product management

The product manager has two responsibilities: 1. Find a product that addresses the four major new product risks. Most notably the “value” and “business viability” risks - because the company needs people who need the product, and it needs this to happen before it runs out of money and time. 2. Deliver a robust and scalable implementation of that product which customers can consistently rely on to provide value.

In a startup, the product team is the entire team. The only purpose of a fledgling company is to find an appropriate product/market fit before it runs out of time and money. There are many considerations for what is “appropriate” and what is “product/market fit” for every company, but startups are in a race against time with more constraints than bigger companies with more resources, and it is exclusively the young product team who will determine future business viability.

Not all products are going to be successful. Even the most talented product team will fail to produce a profitable and successful product when it doesn’t make sense. If any of the primary risks can’t be overcome, and constraints won’t allow for creativity, and customers don’t want the same product that management wants, the product discovery process will fail. This is inevitable sometimes, but having a fast, iterative process, with good communication, will prevent it from happening more often than necessary.

Most successful products require several iterations of product delivery to produce the value that customers need to feel comfortable using and/or switching to it. Part of the product process is to uncover these kinds of risks, but in the real world product development often take longer than expected, is more complicated, more costly, and sometimes does not provide the value management was hoping for.

But this inconvenient truth is no reason to avoid the process, it is simply a reason to embrace the iterative approach and look for creative ways to provide value as quickly as possible, and uncover as much product wisdom as possible before and during product development.

The primary responsibilities of the product manager

## The principles of product management ## Product manager time management and prioritization

Risks are tacked up front rather than at the end. Products are no longer designed sequentially in waterfall-style top-down roadmaps because that puts the largest risks at the end of the project instead of the beginning.

Product managers, at the end of the day, have only two jobs: 1. Discover the product to be built that mitigates the four big risks 2. Deliver that product to market

The product manager’s team is responsible for the success of a product. The product manager is exclusively responsible for the failure of a product. Spread the credit wide and take the blame yourself.

It may go without saying because it is so important, but the PMs success relies on the team they work with, so good collaborative relationships with the rest of the product team are necessary.

The product manager must have a deep knowledge of the actual/potential users and customers of a product. You must be an expert on their desires, issues, demographics, how they work, how they think, and how they decide to buy.

The product manager should have intimate knowledge of the business and market they’re in. Everything about management, departments, finances, competitors, business model, market growth, regulations, etc., should be understood because it is all applicable to the product discovery process.

The product manager should strive to create and maintain good relationships with the business stakeholders. The management and other stakeholders will give you important guidance on what is important to them and either sign off on, or squash, your product.

Other people in the organization have jobs to do as well. The product discovery process is best thought of as a time limited portion of the PMs job. The PM needs some time to figure out how to best solve the problem, or build the product, and then must be willing to commit to dates and deliverables so the rest of the company can do their jobs too.

Product evangelism and communication

The product manager is the primary evangelist for their product. You must have a passion and excitement for your product because nobody else will, and it will show through if you don’t.

If you’re a startup founder, a CEO, or head of product, product evangelism is a huge portion of your job and you’ll have a hard time assembling effective teams and hiring high quality talent if you’re not good at it.

The product manager needs to share their learnings, the good and the bad, openly and often. Organization and communication are critical skills for the successful PM, especially in the time of COVID when most people are not working together in the same space.

Ten pieces of advice from Marty Cagan to help communicate to your team, colleagues, stakeholders, executives, and investors: 1. Use a prototype 2. Show and share the customer pain you’re addressing 3. Share the production vision 4. Share learnings (both the good and the bad) generously after every user test or customer visit 5. Share credit generously so the team views it as their product, not just yours 6. Learn how to give a great demo 7. Do your homework, know what you’re talking about and people will be more likely to follow you 8. Be genuinely excited about your product! 9. Learn to show some enthusiasm 10. Spend time with your team. Spend time with your designer and engineers and let them see your enthusiasm

The team

### The role of the product designer

The product team usually consists of a product manager and engineers. If you’re designing anything that a customer might interface with, it is highly recommended to have a designer on the team as well.

Great products are exclusively the result of a small group of talented people working closely together to solve real problems for end users and customers in ways that meet the needs of the business. Functionality, design, and technology are completely intertwined and integrated, and it takes the talents of multiple people with good working relationships and a good understanding of the customer and their problems to pull it all together.

The product manager is not the boss of anyone on the product team. It is a collaborative effort with each participant contributing their portion of value.

The best product teams are located in the same physical space. The product manager, designer, and engineers are most productive and effective when they are consistently working closely together.

A good product designer must be good at creating usable prototypes that can be put in front of potential customers. It is not just “design” but interface, interaction, usability, and understandability – all with the necessary speed.

Product designers must be proficient with building functional prototypes of potential product features. They are not “graphic designers” because their design is meant to be used as a simulation of an actual product, without any actual coding.

Good product designers build with the end user in mind and constantly interface with end users to get feedback and iterate the design. They build user testing into their weekly cadence of work and use the feedback to inform/refine ideas and collect new insights.

Product design is table stakes for consumer products. It is a competitive differentiator for B2B products. Do not enter a product discovery process without the critical design skill filled adequately.

These five best practices allow the product designer to do the best job possible: 1. If possible, the PM and PD should sit next to each other. If not possible to be physically together, they should work together every day. 2. Include the designer from the inception of every idea. The PM and PD must be partners in creation. 3. Include the product designer in as many customer interactions as possible. The PM and PD should learn about the customer together. 4. Give the designer as much room as possible to come up with design ideas him/herself - fight the urge to provide the designer with design ideas. 5. Encourage the designer to iterate early and often. Don’t get critical of design ideas early, allow the end-user to judge usability and value.

The product manager and product designer are partners in product creation. One role is not above the other. They must work together from the beginning of every idea, through every learning, and iterate quickly together. This partnership is vital to the success of the product and it is difficult for one person to hold down both roles.

Engineers build and deliver the product. They are not as intimately involved in the day-to-day product discovery process as the PM and PD, but should be involved as often as possible because they (a) build the end product and (b) bring a technology perspective to the process. Engineer insights gained as part of the user testing and iteration process can sometimes be gained no other way than their involvement.

Engineer morale is directly tied to the product manager. The PM must involve them on the level of being part of the team, being a missionary to solve the user problem, being a part of the creative solution making process. If they ever feel like mercenaries, whose only job is to do what they’re told, then the product manager is failing. The PM should share customer problems, challenges, and failures openly with the engineers and they will often rise to the challenge of helping to solve them.

How to structure product teams

There are many ways to structure teams of product teams. It is slightly different for every company but there are some best practices and lenses through which to look.

Align with investment strategy: If the company has a well-defined investment strategy then product teams are often apportioned to work on each important vertical of investment.

Minimize dependencies on management and other teams, which helps each individual team move faster. In product, speed is like in battle, you can rarely have enough of it.

Allow product teams to own their product because you want to create missionary teams of people who are bought into the success of their efforts, not mercenaries who are indifferent to the outcome.

Maximize the leverage that each team gets from the infrastructure available to all teams. If there is something you can do to increase the speed and effectiveness of all teams, like tooling, and services, then make it happen!

Have a clear long term product vision and strategy. Make sure management has considered and agrees on the product direction of the company, now and in the medium term, and communicates it clearly and often to all product teams. This clarity of strategy helps every team make better decisions, faster, without bottlenecks from above.

Make sure every team has the minimum number of talented people to be able to succeed, and not too many to slow them down and/or use excess resources. In general the team needs one product manager, 1-2 engineers, and if it faces an end user/customer, a product designer.

If the company has a well-defined business or technology architecture, it can be a good strategy to align the product teams in the same way.

If the company has well-defined groups of customers, like a platform with buyers/sellers, or multiple divisions, then product teams should usually be focused on a specific part of this structure. This is because the product manager must be an expert on the user and the business, and it’s hard to be an expert on all parts of a large organization.

Make sure the right talent is on the right team. In general the product team can be on a range from superstars to beginners, and it’s important to assign the best talent to the most important projects, and provide training/mentorship to the beginners.

The role of upper management in product (product vision, strategy)

### Product vision principles ### Product strategy prioritization

A common problem for product teams is a lack of vision from the management about the future vision for the company’s products, and the strategy that will leveraged to get there. This lack of communication and organization from management makes it difficult for product teams to work autonomously and be empowered to make good decisions that support the vision. It slows teams down and causes harm to both the firm and the individual contributors who are confused about how their work contributes to the larger goals of the company.

Management should strive to provide product teams with specific business objectives that must be met, and specific business results that are expected. This clarity of directive accomplishes two things: First, the product team knows exactly what is expected of it, can make decisions faster/easier, can communicate progress clearly. Second, the product discovery process has a specific bar by which to measure progress.

The product vision is not a spec or a project. It is a persuasive piece, often a storyboard, white paper, or video, and its purpose is to inspire teams, stakeholders, investors, partners, customers, to want to help make this vision a reality.

Principles of Product Strategy

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

The product discovery process

We can’t count on executives, stakeholders, investors, or even customers to tell us what to build. They will have opinions on this topic, and they’re not wrong, but the product discovery process is all about making sure that the solution we deliver solves the underlying problem.

The modern product discovery process is an intensively collaborative endeavor between a product manager, designer, engineers, and customers, attempting to address the four primary risks and create a profitable product for the company.

Product discovery is the process of running a series of quick, inexpensive experiments using prototypes rather than fully developed products. Proficient product teams typically test many experiments per week in order to address the four critical risks and answer the necessary questions involved with creating a profitable new product or feature.

The product team expects that many (or most) of their ideas on how to solve a problem will not work out. And the ideas that do work out require several iterations to get right. This is a huge commitment which requires patience and time, usually more than you’d hope or expect.

The four critical risks to address during product discovery

### Risk 1: Value risk #### Value risk sub-component: Demand testing ### Risk 2: Usability risk ### Risk 3: Feasibility risk ### Risk 4: Business viability risk (stakeholder support risk)

These are the four critical risks of launching a new product. We want to have satisfactory answers for each of these before moving into the product build/delivery phase: - Risk 1: Value risk - Will customers buy (or use) this product? - Risk 2: Usability risk - Can customers figure out how to use this product? - Risk 3: Feasibility risk - Given our skills, technology, and time available, can our engineers build this product? - Risk 4: Business viability risk - Does this solution work for the business in terms of financial investment, time, IRR? Does it work for the marketing, sales, customer success, finance, legal, etc., departments?

What about demand risk? Are there a big enough group of people out there who actually want this product? - Demand risk is a sub-component of Value.

At every step, with every experiment, every conversation, and every written communication, the product discovery process requires a PM to always be asking: - 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?

The most important, and most difficult, risk to address is Risk 1, Value risk. Customers will almost always already have a way to solve their problem, and you’re trying to improve on that solution. But your solution has to compete with the best alternative solution anybody else has ever come up with. You can’t simply do as well as the best alternative in terms of value and price, you have to do significantly better to get a customer to switch.

Risk 4, Business Viability sub-components for executive consideration. There are 3 primary areas of thought for the executive team: 1. TAM - what is the size of the opportunity? 2. GTM - what is the launch and distribution strategy? 3. TTM - how long will it take to bring this product to market?

The use of prototypes

## rapid iteration testing ### Story maps ### Principles of user testing

The secret to discovering and delivering great products that solve problems and make money is to get in front of real users and customers early and often.

A prototype is a product simulation used in product discovery to answer questions related to the four primary risks. It is not a product, it is not for sale, and the company would never stand behind it. But it is immensely useful to help product teams learn fast and cheap without the need to write production code before product ideas are validated.

Prototypes save a tremendous amount of time because production-quality code does not need to be written. A product team can literally save months of effort by using a prototype which takes a few hours to cobble together and testing it with potential customers.

User testing is an opportunity to put a prototype in front of a prospective user/customer and learn from their experience. The goal is to address critical risks and answer critical questions, but user testing with prototypes is the method.

There is no need to prove anything during user testing. You need to let pride of creation go during this time. The only purpose of in-person user testing is to understand and learn quickly.

Each test should have a clear hypothesis on what you think the user problem is and how you’re going to confirm or debunk it.

User testing roles. Usually: - the designer drives the test - the product manager takes notes - the developer observes

(placeholder for Rocket Surgery Made Easy)

One type of effective test is called the Concierge Test. This involves learning how to do the user’s job, how they solve their own problems, and then doing it manually for them for some time while you figure out the technology solution to automate it.

Testing value qualitatively is the most common type of Value test. We are measuring the customer response/reaction. Do they love this? Will they pay for it? Will they choose to use it over their other options? Why not?

Quantitative vs Qualitative testing: - Quantitative testing is about proving something. A/B tests, for example - Qualitative testing is used to determine why customers are not responding to our prototype as well as we’d hope, which is usually the case in the early stages of testing. We are looking for rapid learning and big insights.

To test demand there are multiple version of the “fake door” test. - If you have an existing product, put a button for a new feature into the place it would normally go. When the user clicks the button, instead of seeing the actual functionality they see a message that explains how you’re exploring the possibility of adding this feature and are looking for customers to talk to about it. Then give them a way to reach out. - If you’re launching a new product, you place Google/Facebook Ads and send people to a landing page which simulates the start of the sales funnel. If they click the CTA button, instead of seeing more information about the product they see a page explaining the possibility of building this product to suit their needs and that you’d like to talk to them about it.

Most of the time demand is not the problem. We can get people to sign up for a trial, or an interview, but once they try it out they don’t get excited, don’t want to switch from their existing solution. And that’s why we need to iterate and continue learning.

A qualitative user test generally has the following steps: 1. Interview - make sure she has the problems we think she has, understand what it would take to make her switch 2. Usability test - can the user figure out how to use our prototype? 3. Value test - Will they pay for it? Would they recommend it to their friends? Are they willing to spend their time to help make it better? Will they give up sensitive information for it?

The product/market fit

### B2B PMF: Six reference customers ### B2C PMF: 10-50 beta testers ### The Sean Ellis “very disappointed” test of PMF

The goal of every product team is to find Product/Market Fit, which was originally defined by Marc Andreessen as “Product/market fit means being in a good market with a product that can satisfy that market”. The definition intentionally leaves much room for interpretation, because there are many different ways to achieve the goal.

A common target for validation in a B2B setting is to get six reference customers from a specific market who are using (and paying for) an MVP version of your product, willing to give a positive reference to other customers. It is not wise to launch a product, sell/market it, or expand the scope of it, until you have these reference customers.

The best way to find reference customers is to recruit people/companies who truly feel the pain that your solution is trying to solve. If they could have found a solution to their problem elsewhere, they would have. Often they have cobbled together their own in-house solution. The customer is so hungry for a solution that they will make time and have patience for your half-ass, buggy, minimum featured product.

If you have a hard time finding even a few prospective customers who have the problem you’re trying to solve that is a sign that perhaps your problem isn’t important. This will translate to a lack of interest for this product when it goes to market. Time to take a step back and make sure you’re spending time on something that is worthwhile.

If you’re creating a B2C product it’s a good idea to have 10-50 Beta testers who have shown consistent usage and offer feedback, advice, and love your product.

A common technique for determining if you have PMF was invented by Sean Ellis. You survey your beta testers and ask them a simple question: How would you feel if you could no longer use this product? (Very disappointed, Somewhat disappointed, Don’t care, No longer relevant because I no longer use it). The general rule of thumb is that is you get 40+% of users saying “Very disappointed”, then there’s a good chance you have found PMF.

Story maps

(placeholder for later)