More on this book
Community
Kindle Notes & Highlights
Read between
July 23 - July 25, 2020
Jeffrey Liker’s (2004) book The Toyota Way,
players: the key stakeholders who have an interest in your product and the power to influence it,
the product discovery team.
Collaborating with the key stakeholders, or players, provides you with a number of benefits. It encourages shared ownership, builds strong buy-in, leverages the creativity of the entire group, results in better decisions, and mitigates cognitive biases, which are faults in our thinking that cause us to draw the wrong conclusions, including overlooking or misinterpreting valuable information.
The process of capturing and subsequently testing and changing the product strategy is built on the idea that collecting feedback, data, and empirical evidence is necessary to make the right decisions.
as human beings, we all have cognitive biases that can cause us to collect the wrong data or to misinterpret it.
Albert Einstein famously said, “A person who never made a mistake never tried anything new.”
Making mistakes and failing are valuable, of course, only if they enable us to learn, to discover a new
“If I find 10,000 ways something won’t work, I haven’t failed. I am not discouraged, because every wrong attempt discarded is another step forward.”
Peter Drucker writes in his book Innovation and Entrepreneurship,
“The best, and perhaps the only, way to avoid killing off the new…is to set up the innovative project from the start as a separate business”
Steve Blank’s (2014) advice and “get out of the building.”
Visit your target customers and users to understand their needs and to see the environment where your product will be used—
“Go out to look, to ask, to listen,” as Drucker
Make sure you directly interact with the customers and the users and study the market yourself. Don’t solely rely on what others tell you about the market and the product; don’t blindly trust the sales group, support, management, or a market research company,
There is a real difference between analyzing data and observing people as they interact with your product.
product managers visit customers and users at least once per quarter.
work on one risk at a time. This creates focus and facilitates collaboration, and it makes it easier to collect and analyze the relevant data.
First, select the right validation technique—
Second, choose the right test group—
data. Sample validation techniques include observing users, interviewing customers, creating a minimum viable produ...
This highlight has been truncated due to consecutive passage length restrictions.
The benefit of qualitative techniques is that you interact directly with the customers and users. This helps you understand why people behave in a certain way.
separate data analysis from data collection.
Observation is a powerful technique not only for developing a new product, but also for spotting opportunities to improve an existing one—even if you employ an analytics tool and have plenty of usage data available.
Problem interviews are structured conversations with target users and customers. The goal is to find out how they currently carry out the relevant activities, what works well for them, and what does not.
I recommend conducting between five and ten problem interviews to address any given risk.
A minimum viable product (MVP) is an initial product version that allows you to learn how people actually use your product, even though it is still very limited and may only vaguely represent the product it will eventually become
A spike is a throwaway prototype that addresses a specific technology or architecture risk.
avoid the trap of creating a big up-front design for your product.
Cagan (2011) coined the term product discovery team. He originally used it to refer to the product manager, the lead user experience designer, and the lead developer. Ries (2009) calls the product discovery team problem team, since the team validates that a problem exists that is worthwhile to address.
Christensen and Raynor
Good fortune is what happens when opportunity meets with planning. Thomas Edison
Product roadmaps translate strategic decisions into actionable plans that provide direction for the development team and the other stakeholders.
In its simplest form, a product roadmap communicates how a product is likely to evolve by mapping its major releases onto a timeline,
a product roadmap reduces the risk of getting lost in a myriad of small changes and no longer seeing the overall direction in which you are heading.
Feature-based roadmaps are built on product features, such as registration, search, or reporting, which are then mapped onto a timeline to indicate when each feature will be released;
these roadmaps focus on goals or objectives.
An internal roadmap is visible only within the company that is creating and providing the product. Its main purpose is threefold: to align the stakeholders, to ensure that everybody has the same understanding of how the product is likely to grow, and to help the stakeholders carry out their work,
External roadmaps, in contrast, are visible to the customers and users.
lose trust in it. It is therefore important that you plan ahead only as far as you can realistically see, and capture only what you can confidently anticipate.
A great way to achieve organizational alignment and strong buy-in from these stakeholders is to involve them in a collaborative workshop.
Employ the roadmap to describe your product’s overall journey and the backlog to capture the details.
No Guarantee A product roadmap is not a guarantee; it is a high-level plan that describes the likely growth of your product based on what you currently know.
No Speculation Don’t create a roadmap if you don’t have a valid product strategy available or if you cannot look beyond the first public release.
If you are working on a brand-new product, for instance, and are about to launch your first minimum viable product (MVP), you may not be in a position to create a realistic product roadmap for the next twelve months.
you will benefit from a SMART product roadmap: a roadmap whose releases are specific, measurable, agreed, realistic, and time-bound.
Specific Your product roadmap is specific if everyone involved in making the product a success understands what the releases are about and why it is worthwhile to develop them.
Measurable The roadmap is measurable if you can determine if the release has reached its goal and delivered the desired benefits.
Agreed The product roadmap is agreed if the stakeholders, including the development team, buy into
Realistic The roadmap is realistic if it is a feasible plan that guides the work of the development team and the other stakeholders.
