Inspired

Highlights

• The first truth is that at least half of our ideas are just not going to work.
• the second inconvenient truth is that even with the ideas that do prove to have potential, it typically takes several iterations to get the implementation of this idea to the point where it delivers the necessary business value. We call that time to money.
  • Tags: [[product-discovery]] [[product-management]]
• 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.
  • Tags: [[product-management]]
• Risks are tackled up front, rather than at the end. In modern teams, we tackle these risks prior to deciding to build anything. These risks include 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), and business viability risk (whether this solution also works for the various aspects of our business—sales, marketing, finance, legal, etc.).
• Products are defined and designed collaboratively, rather than sequentially. They have finally moved beyond the old model in which a product manager defines requirements, a designer designs a solution that delivers on those requirements, and then engineering implements those requirements, with each person living with the constraints and decisions of the ones that preceded. In strong teams, product, design, and engineering work side by side, in a give‐and‐take way, to come up with technology‐powered solutions that our customers love and that work for our business.
• Finally, it’s all about solving problems, not implementing features. Conventional product roadmaps are all about output. Strong teams know it’s not only about implementing a solution. They must ensure that solution solves the underlying problem. It’s about business results.
• Discovery and delivery are our two main activities on a cross‐functional product team, and they are both typically ongoing and in parallel.
• We are always working in parallel to both discover the necessary product to be built—which is primarily what the product manager and designer work on every day—while the engineers work to deliver production‐quality product.
  • Tags: [[product-management]]
• Discovery is very much about the intense collaboration of product management, user experience design, and engineering. In discovery, we are tackling the various risks before we write even one line of production software.
• The purpose of product discovery is to quickly separate the good ideas from the bad. The output of product discovery is a validated product backlog.
  • Tags: [[product-management]]
• So, in the product world, we strive to achieve product/market fit. This is the smallest possible actual product that meets the needs of a specific market of customers.
  • Tags: [[product-management]]
• 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.
  • Tags: [[product-management]]
• while the P in MVP stands for product, an MVP should never be an actual product (where product is defined as something that your developers can release with confidence, that your customers can run their business on, and that you can sell and support).
• The MVP should be a prototype, not a product. Building an actual product‐quality deliverable to learn, even if that deliverable has minimal functionality, leads to substantial waste of time and money, which of course is the antithesis of Lean.
  • Tags: [[product-management]]
• Mercenaries build whatever they’re told to build. Missionaries are true believers in the vision and are committed to solving problems for their customers.
  • Tags: [[leadership]] [[product-management]]
• Usually, everyone on a product team is an individual contributor, and there are no people managers.
• And to be clear, a product team is not something we create just to deliver a specific project. It’s nearly impossible to have a team of missionaries when they’re pulled together for a project that lasts only a few months and is then disbanded.
  • Tags: [[product-management]]
• If we want teams to feel empowered and have missionary‐like passion for solving customer problems, we need to give them a significant degree of autonomy.
  • Tags: [[management]] [[organization-design]] [[product-management]]
• in the dedicated team model, the team is not off the hook just because something launches. They don’t rest until and unless it’s working for the users and for the business.
  • Tags: [[product-management]]
• it is not enough to have feature parity with a competitor. Rather, you need to be substantially better to motivate a user or customer to switch.
  • Tags: [[product-management]]
• To summarize, these are the four critical contributions you need to bring to your team: deep knowledge (1) of your customer, (2) of the data, (3) of your business and its stakeholders, and (4) of your market and industry.
  • Tags: [[product-management]]
• UX is any way that customers and end users realize the value provided by your product.
• Some of our research is generative, which is understanding the problems we need to solve; and some of our research is evaluative, which is assessing how well our solutions solve the problem.
• Similarly, for quantitative learning, data analysts 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.
  • Tags: [[product-management]]
• you need to have an investment strategy, and your team structure should be a reflection of that.
• strong product teams understand these truths and embrace them rather than deny them. They are very good at quickly tackling the risks (no matter where that idea originated) and are fast at iterating to an effective solution. This is what product discovery is all about, and it is why I view product discovery as the most important core competency of a product organization.
• It’s worth pointing out that it isn’t the list of ideas on the roadmap that’s the problem. If it was just ideas, there’s not much harm in that. 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.
• There are a few product teams out there that have modified their product roadmaps so that each item is stated as a business problem to solve rather than the feature or project that may or may not solve it. These are called outcome‐based roadmaps.
• The product team asks for a little time to do product discovery before commitments are made, and then after discovery, we are willing to commit to dates and deliverables so our colleagues can effectively do their jobs as well.
  • Tags: [[product-management]]
• The product vision describes the future we are trying to create, typically somewhere between two and five years out. For hardware or device‐centric companies, it’s usually five to 10 years out.
  • Tags: [[product-management]]
• The product strategy is our sequence of products or releases we plan to deliver on the path to realizing the product vision.
  • Tags: [[product-management]]
• For a product team to be empowered and act with any meaningful degree of autonomy, the team must have a deep understanding of the broader context. This starts with a clear and compelling product vision, and the path to achieving that vision is the product strategy.
  • Tags: [[leadership]]
• the product vision should be inspiring, and the product strategy should be focused.
  • Tags: [[product-management]]
• The first is market sizing, usually referred to as total addressable market (TAM). All things considered equal, we like big markets rather than small markets.
  • Tags: [[product-management]]
• It is not very hard to identify the important trends. What’s hard is to help the organization understand how those trends can be leveraged by your products to solve customer problems in new and better ways.
• An important element to product vision is identifying the things that are changing—as well as the things that likely won’t be changing—in the time frame of the product vision.
  • Tags: [[strategy]] [[product-management]]
• It is very possible that you may have to adjust course to reach your desired destination. That’s called a discovery pivot, and there’s nothing wrong with that.
  • Tags: [[product-management]]
• We can’t ignore the market, but remember that customers rarely leave us for our competitors. They leave us because we stop taking care of them.
• Where the product vision describes the future you want to create, and the product strategy describes your path to achieving that vision, the product principles speak to the nature of the products you want to create.
• Objectives should be qualitative; key results need to be quantitative/measurable.
  • Tags: [[product-management]]
• Key results should be a measure of business results, not output or tasks.
• Keep the number of objectives and key results for the organization and for each team small (one to three objectives, with one to three key results each is typical).
• 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.
• One of the most common traps in product is to believe that we can anticipate our customer’s actual response to our products.
• Our goal in discovery is to validate our ideas the fastest, cheapest way possible.
  • Tags: [[product-management]]
• As a rule of thumb, an iteration in discovery should be at least an order of magnitude less time and effort than an iteration in delivery.
• Ideation techniques are designed to provide the product team with a wealth of promising solutions aimed at the problems we’re focused on now.
• Our go‐to tool for product discovery is typically a prototype.
  • Tags: [[product-discovery]] [[product-management]]
• we are defining a good idea as one that solves the underlying problem in a way that customers will buy, they can figure out how to use, we have the time and skills and technology on the team to build, and that works for the various aspects of our business.
• the way to think about discovery is that we only validate what we need to, and then we pick the right technique based on the particular situation.
  • Tags: [[product-management]]
• We like to use our discovery time and validation techniques for those situations in which we know there’s a significant risk, or where members of the team disagree.
• The idea is to answer four key questions about the discovery work you are about to undertake: What business objective is this work intended to address? (Objective) How will you know if you’ve succeeded? (Key results) What problem will this solve for our customers? (Customer problem) What type of customer are we focused on? (Target market)
  • Tags: [[product-management]]
• The idea is that rather than communicate the benefits in a press release format, you describe them in the format of a customer letter written from the hypothetical perspective of one of your product’s well‐defined user or customer personas.
  • Tags: [[product-management]]
• As a reminder, qualitative testing is not about proving anything. That’s what quantitative testing is for. Qualitative testing is about rapid learning and big insights.