What is this book about?
In today's fast-paced and ever-evolving tech landscape, creating successful products requires more than just a great engineering team. It demands a deep understanding of customer needs, cross-functional collaboration, and a relentless focus on innovation.
This book delves into the principles and practices that drive product success, drawing lessons from top tech companies and exploring the roles of product managers, designers, engineers, and other key players. Whether you're a startup founder, a product manager, or part of a growth-stage company, this book offers interesting insights and practical advice to help you navigate the complexities of product development.
PART I: Lessons from Top Tech Companies
"It does not matter how good your engineering team is if they are not given something worthwhile to build."
CHAPTER 1: Behind Every Great Product
Great products are led by someone combining tech + design to solve real customer problems while meeting the needs of the business.
This person is often the product manager, but could also be a founder or CEO
The PM role is very distinct from engineering, marketing, or project management.
It is a full-time, high-ownership job — often demanding 60+ hours/week.
Effective product managers own outcomes, not just outputs.
About a good product manager –
“ Behind every great product there is someone—usually someone behind the scenes, working tirelessly—who led the product team to combine technology and design to solve real customer problems in a way that met the needs of the business. ”
Product success requires deep cross-functional collaboration.
PM is a demanding role, not for the faint-hearted.
For commercial success, it is not enough to just have a great engineering team. It is also important to know what is worth building. A PM plays a big part in figuring this out i.e. viability & value.
CHAPTER 2: Technology-Powered Products and Services
The ideas in this book are mostly applicable to tech-powered products (service or experiences), i.e. products powered by technology, and not general consumer goods.
The tech-powered products do not need to be purely digital though. Tesla or Apple is a good example where the product is a mix of hardware, software and experience.
Many companies blend online + offline experiences (e.g., Uber, Airbnb) and can still benefit from the ideas from this book.
The tech companies must embrace keeping tech at the core of all what they do or risk being disrupted.
CHAPTER 3: Startups – Getting to Product / Market Fit
Startups are companies which are yet to achieve product/market fit. Their main task is to find it before money runs out.
PM role is often played by a founder in early stages of startup.
The main aim of startup is to find the great product which meets the market needs.
CHAPTER 4: Growth-Stage Companies – Scaling to Success
From finding product / market fit at startup stage, growth stage companies move toward the need to effectively grow and scale.
Growth requires new systems, new hires, and reorienting the product to fit scaling needs.
Scaling may introduce technical debt, organizational silos, and infrastructure issues.
CHAPTER 5: Enterprise Companies – Consistent Product Innovation
"Strong tech companies know they need to ensure consistent product innovation"
Big companies risk losing innovation as they focus on protecting existing business.
They tend to focus more on squeezing out value from current business than innovating new solutions.
This continuous act of protecting core business and credibility becomes very important, leading to risk aversion, bureaucracy and a lot of processes.
Symptoms: slow decisions, lack of vision, product decisions by committee.
To be consistently successful, innovation must be embedded, and not isolated (e.g. “innovation labs” rarely work).
Innovation is the long-term fuel to keep growing. Otherwise, the big company will start sinking slowly and slowly.
CHAPTER 6: Root Causes of Failed Product Efforts
There are two main questions which the companies want to answer for any new idea
How much cost will it take to realize the idea
How much return will it give the company, i.e. calculating the overall RoI.
The true answer to both these questions are -> it can't be known.
There are two inconvenient truths about product that we all should know:
At least half of our ideas are just not going to work.
Even if the ideas can work or have great potential, it will take several iterations to get the implementation to a level that it delivers the necessary business value. So, there is a big "time to money" part.
Bringing design late in the game when the main part is already decided is kind of a "lipstick on the pig" model.
Engineers and UX should not just get the requirements but should be part of the innovation process from the start.
The key principle in Lean methods is to reduce waste, and one of the biggest forms of waste is to design, build, test, and deploy a feature or product only to find out it is not what was needed.
The reality: Most companies use waterfall model of working and disguise it as Agile.
Sales or stakeholder driven product ideas and not tech driven
Holding on to business cases (RoI) - which can’t be predicted or trusted at the point
Product Roadmaps are created and taken too seriously
Product management is doing rather project management gathering requirements and features
UX is invited too late in the game - lipstick on the pig model
Engineers are invited too late in the game - used as mercenaries (paid contractors) and not missionaries (motivated innovators).
Working in agile mode happens way late in the process, i.e. Doing Agile just for delivery not for discovery.
Making the whole product discovery process project-centric i.e. beginning & end, outputs rather than outcomes.
Customer validation happens very late – a lot of resources and effort already put.
Huge loss of time, money and effort as well as very high opportunity cost.
CHAPTER 7: Beyond Lean and Agile
Lean and Agile values and principles are meaningful, but they should be truly lived and not just quoted on presentations.
For reference (not in the book):
Lean means reducing waste or being efficient
Agile means being flexible / adaptable
The type of risks which should be tackled up front, i.e. in discovery:
value risk (whether customers will buy it),
usability risk (whether users can figure out how to use it),
feasibility risk (whether our engineers can build what we need with the time, skills, and technology we have),
business viability risk (whether this solution also works for the various aspects of our business—sales, marketing, finance, legal, etc.).
Product, design and engineering should work together collaboratively rather than sequentially
Any good solution is all about solving the underlying problems (i.e. business result) rather than just implementing any solution
Lean & Agile aren’t silver bullets; many teams do it incompletely.
The best teams move beyond labels and focus on principles:
CHAPTER 8: Key concepts in product model
Discovery - main responsibility (80%) of UX and PM
Delivery - mostly done by Engineers (90%)
Output of product discovery is a validated product backlog. Validation means:
Value - Will the user buy this (or choose to use it)?
Usability - Can the user figure out how to use it?
Feasibility - Can our engineers build this?
Viability - Can our stakeholders support this?
Prototypes should take way less time and effort than the actual product. Prototypes are about learning the risks fast and cheap.
Strong teams test 10 to 20+ ideas per week.
Purpose of product delivery is to build and deliver the final production quality tech. product.
Product vision - long term (2 to 10 years) objective of the product.
Prototypes are built in discovery, and products are built in delivery.
"So, we use prototypes to conduct rapid experiments in product discovery, and then in delivery, we build and release products in hopes of achieving product/market fit, which is a key step on the way to delivering on the company’s product vision"
Key Concepts:
Holistic Product = features + tech + UX + monetization + experience + everything else
Continuous Discovery & Delivery are two main activities which are always ongoing and in parallel.
Discovery answers 4 risks: value, usability, feasibility, viability.
Delivery ensures scale, reliability, etc.
Product/Market Fit is the real goal, not just shipping something.
MVP is minimum viable product but should actually be a prototype → MVP = prototype for learning.
Discovery & Delivery are continuous and in parallel
MVP should be cheap & fast to test, not productized.
Delivery must follow validated discovery.
All great teams run experiments every week.
Vision connects all product work being done to the overall company mission.
PART II: The right people
PRODUCT TEAMS
CHAPTER 9: Principles of Strong Product Teams
"A product team is a group of people who bring together different specialized skills and responsibilities and feel real ownership for a product or a substantial part of the product"
"Mercenaries build whatever they’re told to build. Missionaries are true believers in the vision and are committed to solving problems for their customers. We need team of missionaries"
Team composition - PM, UX (especially important for products which have user-facing experience), and a few developers with a tech lead. Other extensions of the team are also possible as needed (Product marketing manager, automation engineer etc.).
Team empowerment - they are given problems to solve and own the objectives and are accountable for the outcomes (i.e. real results).
In a true product team, the team will feel and act like a startup within the larger company.
Team size - two pizza rule. More than size, what is needed is balance of skills.
Team reporting structure - all the people in team are Individual Contributor - PM is not the boss of anyone on the product team.
Product team works in true collaboration and not in hierarchy.
Team location: a co-located true product team will substantially outperform a dispersed team. By co-location, it means the team sits so near to each other so that they can see each other's screen. Sitting in the same building or same location is not enough.
Team scope - as much independent, complete product responsibility as possible - i.e. from type of work as well as scope of work.
In big products (Facebook), usually the whole company is about one experience. So each team is doing only a small solution of the overall experience and that is fine as well. Main aim is to keep teams empowered and operate as independently and completely as possible. So, the same team should do projects, features, bug fixes, performance improvement, optimization, content changes and everything else related to their product or their solution of the bigger product.
It is never possible to split the tasks pie perfectly. Any team topology will improve some things and compromise on some other things. We just need to identify what is important now and go with that. After a few years, or once the needs change, topology should be adjusted as well.
Team duration - the team should be stable and stay as long as possible. If the team setups are short lived, it is impossible for the individuals to come together and innovate like a missionary.
Team autonomy - the team should be free to choose how they want to solve the problems and the dependencies between the teams should be minimized.
CHAPTER 10: The Product Manager
If a PM:
Both the above approaches are wrong, and the PM is not a good PM.
"The honest truth is that a good product manager needs to be among the strongest talent in the company"
If the product manager
doesn’t have the technology sophistication,
doesn’t have the business savvy,
doesn’t have the credibility with the key executives,
doesn’t have the deep customer knowledge,
doesn’t have the passion for the product, or
doesn’t have the respect of their product team
He / She shouldn't be the product manager for the product.
Easy part of product management: Decide what needs to get built (i.e. what is on the product backlog)
Hard part: Identifying and providing evidence that whatever is on the product backlog is actually worth building
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.
PMs own the problem space and must deeply understand:
The customer
The data
The business (i.e. why the product is part of company strategy, the main stakeholder needs - key executives, sales, legal, CEO etc.)
The industry and market landscape (trends, expectations, competitors etc.)
Good to have for PM:
A good product manager must be:
Smart: Ability to learn, apply and solve problems
Creative: Think outside the box to solve problems if needed
Persistent: Able to fight through resistance to push innovative solutions and build bridges across functions
How to be a good product manager:
Start by becoming an expert in your users and customers. Share very openly what you learn, both the good and the bad. Become your team’s and your company’s go-to person for understanding anything about your customer—quantitative and qualitative.
Work to establish a strong relationship with your key stakeholders and business partners. Convince them of two things:
(1) You understand the constraints they operate under.
(2) You will only bring to them solutions that you believe will work within those constraints.
Become an undisputed expert on your product and your industry. Again, share your knowledge openly and generously.
Finally, work very hard to build and nurture the strong collaborative relationship with your product team.
PMs work side-by-side with design and engineering in discovery.
They’re not project managers or backlog owners; they’re outcome owners.
The team must continuously validate ideas with customers and data.
Product manager is not the role of a project manager, but rather something similar to that of a CEO. It is just that PM is not the boss of anyone.
PM must understand business—financial, marketing, sales, legal, partnership, service, the customer environment, the technical capabilities, the user’s experience—and figure out a solution that works for the customers as well as for the business.
PM doesn't need to know everything but should have a broad understanding of how a product affects a business and work with experts across the company to cover everything that's important.
It is critical that PM takes the responsibility of PO role. If you split the responsibilities of PO across multiple people, it becomes difficult to innovate for your customers as well as your business together.
PM must pick-up the following two skills to be a good PM in a tech company:
Computer programming - helps understand the Dev Team and their problems better. It also helps in understanding your product better
Finance, Marketing - helps understand the costs and promotion aspects of the product.
"If you aspire to be great, don't be afraid to lead"
“If you’re just managing a backlog, you’re not a product manager — you’re a project manager.”
CHAPTER 11: The Product Designer
UX is not just UI but how a customer experiences the whole product. It is how a customer realizes the value provided by your product.
In strong product teams, design informs the functionality at least as much as the functionality drives the design.
Designers are co-owners of discovery — not just UI decorators. They collaborate with PM and Engineering from discovery to delivery.
CHAPTER 12: The Engineers
A PM should not tell / demand but collaborate with Engineers on how to solve the problem at hand.
The best ideas often come from engineers because they are at the forefront of what is possible or has just become possible through technology.
Tech-Lead is not only an experienced and knowledgeable engineer but also someone who wants to be in discovery to build the best solutions with the PM and UX. He / She should at least be always present in discovery.
In discovery phase, the whole engineering team is optional or as needed and is mostly represented by tech-lead.
CHAPTER 13: Product Marketing Managers (PMMs)
PMM know about the market and have a close collaboration with PM who should know about the product.
In absence of PMM, PM needs to take over this role as well and it can be too much for a PM to handle it on top of PM responsibilities.
PMMs bridge product and go-to-market (GTM).
They own product messaging, positioning, competitive insights, and product launches.
A strong PMM ensures the value proposition resonates with the right segments.
In good product orgs, PMMs collaborate with PMs early — before features are built.
Great PMMs co-create messaging based on deep user understanding as well as product understanding (with help from PM).
PMMs should be embedded or tightly aligned with product teams.
Misalignment between PMs and PMMs leads to weak launches.
PMMs help validate if the product will actually sell.
CHAPTER 14: Support Roles
User researcher - responsible for designing tools to research what problems are worth solving and how good is the solution solving the problem. UX takes over role of User Researcher in case there is no User Researcher.
Data analyst - they help teams collect the right sort of analytics, manage data privacy constraints, analyze the data, plan live-data tests, and understand and interpret the results.
Test automation engineer - They write automation for testing the product.
Other roles – as needed.
CHAPTER 15: Profile – Jane Manning (Google)
People @ Scale
CHAPTER 16: The Role of Leadership
Head of Product, head of engineering, head of user experience - all these three leadership roles are very critical to the success of a product company.
The three should be leading and collaborating with each other very closely to harmonize the choices across the breadth of the product at their level.
CHAPTER 17: Head of Product
CHAPTER 18: Head of Technology
Even with the greatest product ideas, if you can’t build and launch your product, it remains just an idea - Head of technology makes sure that the best ideas are converted to best products.
The Head of Product or PMs should always have a very good collaboration and connection with head of Tech or Tech leads or CTO.
Tech teams should never report to CIO but to CTO.
CTO tries to see tech as a strategic enabler for business and product.
CIO has a different role - maintaining the information in a stable and accessible way inside the organization. CIO is more of a stabilizing and risk averse role which is opposite to CTO role.
Main 6 responsibilities of CTO (in priority sequence):
Build a great Tech organization - good collaboration, great people, high impact
Represent technology in all leadership levels - in any strategic discussion with CEO, in M&A, partner decisions etc.
Good delivery quality of products - rapid, reliable, repeatable at high quality levels. This includes handling Tech. Debt
Good architecture - highly functional, scalable, reliable, secure and performant - cohesive tech strategy across the company.
Great product discovery participation - engineers should not only write code but help discover the best solutions. Therefore, engineering participation in product discovery is very important
Evangelism - not just for leaders but even outside the company, CTO is the tech. Face of the company and needs to be the biggest cheerleader for creating the best products, best tech. and best solutions.
CTOs must model product-centric thinking.
They create the conditions for speed, safety, and scale.
CHAPTER 19: Delivery Manager Role
Delivery manager is kind of a project manager / program manager / scrum master whose responsibility is to make sure that obstacles are removed and right products are created.
The person must do the project management and day to day firefighting to execute on the project / program.
If the delivery manager role (or project manager, program manager etc.) is absent, the task ends up with PM. This is fine if the company is small but if the product is very big, this leads to PM doing too much project management and less of product management tasks. This situation is not good for the product.
Frees up PMs/Engineers to focus on discovery and execution.
Helps manage dependencies, blockers, and coordination.
Delivery Managers protect focus. They own flow, not product strategy. They are invaluable in scaling orgs. with many dependencies and continuously work on clearing the path for empowered teams.
Delivery Managers are often misunderstood — they are neither the boss, nor a PM.
CHAPTER 20: Structuring Product Teams
Right Vision -> Suitable Architecture -> Appropriate technology -> Correct skills -> Best products
In big companies, it makes a lot of sense to have service provider teams called platform teams because they create huge scaling and leverage opportunities.
Org. structure is a moving target. It needs to adopt and change over time. Every few months is too much change, but every few years it is certainly needed.
There is no perfect org. structure. You always optimize for a few things at the expense of others.
Key principles for structuring org. teams:
Alignment with investment strategy
Minimize dependence
Increase ownership and autonomy
Maximize leverage
Product vision and strategy
Team size (4-12 is a good range in tech product teams)
Alignment with Architecture
Alignment with user or customer
Alignment with business
Structure is a moving target
Team autonomy vs leverage through strong foundation: In certain cases, teams should be allowed to decide their individual approach. In other cases, a central investment in foundational assets and guidelines are more beneficial. It is always a compromise, but the following factors can help decide better:
Team skill level
Importance of speed
Importance of integration
Source of innovation
Company size and location
Company culture
Maturity of technology in foundation
Importance to business
Level of accountability
CHAPTER 21: Profile – Lea Hickman (Adobe)
It’s easy to see how big companies with lots of revenue at risk would hesitate to make the changes they need to not only survive but thrive.
Lea tackled these concerns head-on with a clear and compelling vision and strategy as well as clear and continuous communication to the many stakeholders.
PART III: The Right Product
Product Roadmaps
"typical roadmaps are the root cause of most waste and failed efforts in product organizations"
“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.”
1st truth: at least half of our product ideas are not going to work
2nd truth: even the ideas that do prove to be valuable, usable, feasible and viable will typically take several iterations to get the execution of this idea to a point where it delivers the expected business value that management was hoping for. i.e. time to money is a iterative, difficult and long journey.
1st truth - Check for as many of the assumptions (viability, usability, feasibility, value etc.) as possible in discovery phase (cheap and fast)
2nd truth - Do rapid iterations with cheap prototypes, fast discovery and fast delivery.
CHAPTER 22: The Problems with Product Roadmaps
Value – Will customers buy or use it?
Usability – Can users figure out how to use it?
Feasibility – Can we build it with our current team and tech?
Viability – Will the solution work for our business?
“Good Discovery is about separating the good ideas from the bad — before writing code.”
CHAPTER 23: The alternative to roadmaps
The roadmap serves two main purposes:
Shows management that teams are working on the highest business value items first
A way to structure, run, and track the business, managing dependencies and commitments.
By providing outcome based roadmaps, high integrity commitments and clear vision and objective, we can make sure that the teams only work on things which are high value (through knowing vision and objective) and have a way to structure and run dependencies (outcomes or problems are in the roadmap to be solved, and high integrity commitments are done where necessary).
So, first discovery -> then high integrity commitments.
Product Vision
Chapter 24: Product vision & product strategy
Company should define the product visions in line with the company vision. Product leadership will then define the product strategy to achieve that vision.
Vision -> what is the north star for the product for the next 2-5 years or so. It is not given by the product itself but the overall organization.
Strategy -> how will we reach the north star step by step
The difference between vision and strategy is analogous to the difference between good leadership and good management. Leadership inspires and sets the direction, and management helps get us there. Product vision is inspiring; product strategy is focused.
Chapter 25: Principles of Product Vision
Start with why i.e. your purpose
Fall in love with the problem and not the solution … i.e. main task is to solve the problem, not make the most elaborate solution.
Don't be afraid to think big with vision - be ambitious so that inspires people
Don't be afraid to disrupt yourself because if you don't, someone else will - focus on creating new value even if it means cannibalizing your current value
Product vision needs to inspire - you need to create missionaries nor mercenaries
Determine and embrace relevant and meaningful trends
Skate to where the puck is heading, not to where it was - imagining and creating future is the need.
Be stubborn on vision but flexible on the details - vision pivot is not good, discovery or product pivot is not bad
Realize that any product vision is a leap of faith
Evangelize continuously and relentlessly - explain and sell the vision everywhere.
Chapter 26: Principles of Product Strategy
Focus on one target market or persona at a time
Product strategy needs to be aligned with business strategy, sales and go-to-market strategy
Obsess over customers not over competitors
Communicate the strategy across the organization
Chapter 27: Product principles
Product Objectives
OKRs - objectives and key results
There are two fundamental principles on which OKR is based on:
Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity
Performance is measured by results - if you released all the features, but the underlying business problem remained, you didn't achieve or solve anything.
The first principle of the above is about how to emplower and motivate people to get them to do their best work, and the second one is about how to meaningfully measure progress of the work the team is doing.
Word of caution:
In terms of getting the benefits of OKR’s, there are three critical prerequisites:
Move from the feature team model to the empowered product team model
Stop doing manager objectives and individual objectives, and focus on team objectives
Leaders need to step up and do their part to turn product strategy into action
For details on issues with OKRs -> https://www.svpg.com/team-objectives-overview/
Chapter 28: The OKR Technique
Key things to keep in mind when designing OKRs
Objectives should be qualitative, key results need to be quantitative / measurable
Key results should be a measure of business results, not output or tasks
Objectives are organizational objectives cascaded to product level objectives and not at functional team levels.
Find a good cadence - annual for Org. Objectives and quarterly for team level objectives
Keep only one to three objectives and only one to three key results per objective at max.
Every product team should track their active progress against the objectives (on weekly or bi-weekly basis)
Objective covers what the team needs to accomplish
Teams should feel accountable to achieve the objectives. Failure should be inspected with a retrospective with peers / management
Agree how will you rate your key results quantitatively. (what does 0 mean, what 1 means and so on)
Make a way to mark key results which are high integrity commitments
Be transparent across the organization on the key objectives and progress
Every leader CEO to Product leader to head of teams are responsible for their OKRs.
Chapter 29: Product Team Objectives
In case of big organizations, the functional OKRs shouldn't dictate the Product team level OKRs.
A Product Team OKR is the primary OKR, and the rest of functional area OKRs, personal OKRs should be not in conflict with the team OKRs.
Rather Team OKRs should roll-up to functional area level OKRs, which roll up to Org. level or product level OKRs.
Chapter 30: Product Objectives (OKR) @ Scale
When scaling OKR system for big enterprises, the focus should be the company or enterprise level objectives. All the objectives should trickle down from these objectives.
Dealing with exceptions - There will also be many teams who are not directly contributing to these selected top enterprise level objectives (such as platform or central services teams). The OKRs for these teams need to be adjusted so that they are also somehow connecting back to the overall org. level OKRs but in their own meaningful way.
Chapter 31: Product Evangelism
Chapter 32: Profile: Alex Pressland - BBC
PART IV: The Right Process
PM and UX mostly spend time in Product discovery part, but they should still be present with the team during Product delivery as needed for questions … usually an hour a day should be sufficient.
Product Discovery
If you want to discover great products, it really is essential that you get your ideas in front of real users and customers early and often.
If you want to deliver great products, you want to use best practices for engineering and try not to override the engineers’ concerns
CHAPTER 33: Principles of Product Discovery
You can't count on your customers / users to tell you what to build - they themselves don't know many times what they need.
There needs to be strong compelling value for a customer to take your product
User experience is very critical to success many times
Functionality, design and technology are inherently intertwined
Most ideas won't work, and the ones who will, still need many iterations to make it work in a product form.
We must validate our ideas on real users / customers
Our target is to validate our ideas, fastest, and in cheapest way.
We must validate the assumptions / risks (valuable, viability, usability, feasibility, and ethical)
It is about shared learning. Missionaries learn and grow together, Mercenaries don’t.
Discovery is about learning, not shipping.
Speed matters — aim for 10-20 experiments per week.
Include engineers and designers in discovery.
PM, UX & Tech lead is 80% discovery, 20% delivery.
Dev Team is 90% Delivery, 10% Discovery
Discovery ends when a solution is validated across all 4 risks (or 5 risks - valuable, viability, usability, feasibility, and ethical).
CHAPTER 34: Discovery Techniques Overview --> CHAPTER 60: Weaning an Organization Off Roadmaps
All different types of techniques from
Discovery (Framing, planning, ideation, prototyping, testing)
Transformation (discovery sprint, pilot team, off the roadmaps)
Discovery Techniques
The purpose of product discovery is to quickly separate good ideas from bad. This involves collecting evidence and utilizing a range of quantitative and qualitative techniques.
It is considered essential for any modern good product team.
1. Discovery Framing Techniques These techniques help to identify underlying issues, clarify the problem to be solved, tease out risks, determine focus, and ensure the work integrates well with other teams. The goals are to achieve team alignment on the purpose (business objective, customer problem, target user, and success metrics) and to identify significant risks.
What business objective is this work intended to address?
How will you know if you’ve succeeded (what are the key results)?
What problem will this solve for our customers (defining the user or customer persona, target market, or job to be done)?
What are the solutions being considered, and what are the key risks?
The product manager is responsible for preparing and sharing these answers with the product team and key stakeholders.
Customer Letter Technique: This technique is designed for larger projects, or initiatives, such as a product redesign, that may have multiple goals or objectives. It is similar to Amazon's "working backward" process, where the product manager frames the work by writing an imagined press release or a letter from a hypothetical happy customer to the CEO. The letter describes how the new product or redesign has positively changed the customer's life and is often accompanied by an imagined congratulatory response from the CEO to the product team. Its purpose is to describe a desired future state and drive specific thinking about the benefits.
2. Discovery Planning Techniques These techniques help to scope and plan discovery efforts, especially for complex product initiatives.
Story Map Technique: A highly versatile technique useful for framing, planning, ideation, and design. It is a two-dimensional map where major user activities are arranged horizontally (ordered by time), and a progressive level of detail (tasks and stories) is arranged vertically. It provides a holistic view of the system, context for each story, and helps in defining releases and objectives. It also facilitates collaboration and can be updated to reflect prototypes and feed into the product backlog.
Customer Discovery Program Technique: Considered one of the most powerful techniques to ensure a strong, viable product. It involves simultaneously discovering and developing a set of "reference customers" alongside the actual product. A reference customer is a real, paying customer using the product in production who is willing to voluntarily and sincerely endorse it. This program, though requiring substantial effort from the product manager, is considered the single best leading indicator of future product success. Variations exist for different product types, including business products, platform/API products (resulting in reference applications), customer-enabling tools (using influential internal users), and consumer products (leveraging social media and press).
3. Discovery Ideation Techniques These techniques focus on generating promising solutions for pressing business or customer problems. The product team itself should ideate, driven by clear business problems and direct customer interaction.
Customer Interviews: The most basic and powerful technique. Its purpose is to deeply understand if a user or customer truly has the problem, how they currently solve it, and what it would take for them to switch to a new solution. Learnings from these interviews often inspire breakthrough product ideas and are essential for subsequent qualitative testing. The product manager should be present for these to ensure "shared learning".
Concierge Test Technique: Highly effective for generating high-quality ideas and building customer empathy. It involves going directly to users and customers to observe how they work, allowing the team to learn their job and identify opportunities for a much better solution. This is most valuable when the product manager, product designer, and an engineer participate together.
The Power of Customer Misbehavior: This powerful yet underutilized technique involves allowing and even encouraging customers to use products for purposes other than originally planned. This "misbehavior" can reveal powerful new product opportunities, such as eBay's early success with customers selling unintended items. A related concept, "developer misbehavior," involves exposing public APIs, allowing developers to create innovative solutions unforeseen by the original product team. Engineers are considered a consistently best source of innovative product ideas.
4. Discovery Prototyping Techniques The overarching purpose of any prototype is to learn something at a much lower cost in terms of time and effort than building a full product. Prototypes should require at least an order of magnitude less time and effort. They force deeper thinking, expose issues early, and serve as powerful tools for team collaboration and shared understanding.
Feasibility Prototype Technique: Created by engineers to address technical feasibility risks (e.g., algorithms, performance, scalability, new technologies, architectural changes, cost) before committing to building a solution.
Hybrid Prototype Technique: Combines aspects of other prototype types. A notable example is the "Wizard of Oz prototype," which combines a high-fidelity user experience with a human performing tasks manually behind the scenes, mimicking automation. This technique exemplifies the "build things that don't scale" philosophy for rapid qualitative learning and insights.
5. Discovery Testing Techniques These techniques aim to quickly differentiate good ideas from bad by addressing four critical product risks: Value, Usability, Feasibility, and Business Viability.
Testing Usability: This is a mature and straightforward form of testing, typically done in discovery with prototypes. Its purpose is to gain a deeper understanding of users and identify friction points in the prototype. Recruiting users can involve customer discovery programs, existing users, or professional recruiters. The test involves defining tasks, training the product manager/designer to conduct it, explaining that it's a prototype and candid feedback is welcome, and asking users to think aloud. Learnings are summarized in short emails, with quick fixes applied to the prototype.
Testing Feasibility: Involves engineers answering questions about their ability to build a solution, including required skills, time, architectural changes, components, dependencies, performance, scalability, and cost. For complex ideas, engineers may need to create a feasibility prototype to answer these questions.
Testing Business Viability: Ensures the proposed solution will work for the business, which can be a challenging but critical part of the product manager's role. It requires understanding the concerns and constraints of all main stakeholders (e.g., sales, marketing, finance, legal, customer success, privacy, compliance). Stakeholders review proposals to ensure their concerns are addressed. The source outlines three distinct ways to show prototypes:
User Test: To learn how users interact with the product.
Product Demo: To show value to executives and customers.
Walkthrough: To ensure stakeholders see and note every potential concern.
Transformation Techniques
These techniques help organizations adopt new ways of working, particularly in shifting from output-focused, product roadmap-driven feature teams to empowered, accountable teams that deliver business results.
Discovery Sprint Technique: A structured, intensive one-week timebox of product discovery work designed to tackle a significant problem or risk. It is more comprehensive than a "design sprint" as its purpose goes beyond just design. This technique helps to build trust within the product team, teaches the mindset, principles, and techniques of product discovery, and enables significant accomplishments in a short period. It involves framing the problem, ideation, creating a high-fidelity user prototype, and validating the solution with real users. Often facilitated by discovery coaches (former product managers or designers with experience in modern product companies).
Pilot Team Technique: This basic strategy involves starting with one or more specific product teams, or a subset of a business unit, that volunteer to adopt the new product model first. The goal is to expand the changes to the broader organization over time. Pilot teams understand they will encounter problems and be responsible for finding solutions, so they should be well-supported with competent and skilled individuals.
Weaning an Organization Off Roadmaps: For companies entrenched in outdated quarterly product roadmaps, the recommended approach is to continue the existing roadmap process for 6-12 months. During this period, every time a product roadmap item is referenced, a reminder of the actual business outcome that the feature is intended to achieve should be included. This helps to transition the organization towards a focus on prioritized business objectives, transparent key results, and high-integrity commitments, moving away from a mere list of features.
Process @ Scale
Chapter 61: Managing Stakeholders
Who are the stakeholders?
The only ones who can veto your work from launching
E.g. legal, finance, business development, CEO, Compliance etc.
PM has the responsibility to understand the constraints of various stakeholders and bring this knowledge to the product team.
A good PM not only brings this knowledge but also convinces the stakeholders that they are working on solving customer concerns but also the concerns of the stakeholders.
Managing stakeholders for success:
Keep them informed
Show them the product already in discovery stage
Avoid group presentations but do it in 1:1 way regularly
Counter their doubts using evidence from prototype / user interviews / data
When hiring people from other companies, be very clear about communicating your company's product culture and making sure that the person can adopt to it while leaving behind the work culture of the company he / she is coming from.
If you go to companies like Amazon or Meta, they make sure that the new joiner knows the new work culture and accepts it asap.
Good product companies should always be careful that any new hires from not so good product companies don’t bring the old product culture in the new company.
Chapter 62: Communicating Product Learnings
In big companies it is very important to continuously communicate new product learnings from discoveries across the various product teams.
A good way is doing it every few weeks in terms of new big learnings / insights based on experiments / data.
This should be done regularly, publicly, and transparently even when these learnings are through failures.
This doesn't mean one-hour presentations, but quick and short findings on big experiments / insights.
This way, we keep pushing the culture of experimentation, learning from these and discovery towards the main goals of the business
It also reinforces that the teams are not only working for the business but working on solving problems for the customers in a way that it works for the business too
Chapter 63: Profile: Camille Hearst of Apple
Part V: The Right Culture
“Beyond the details of the whole product model, the most important thing is having the right product culture”
Chapter 64: Good Product Team / Bad Product Team
