Alternative title: Getting off the ground with lean product research
In Marty Cagan’s talk, Product is Hard, Cagan offers a comprehensive look at his vision for product management. Cagan touched on a key difference between feature teams and Cagan’s "product teams." He emphasized that product teams have a process for product discovery, which sequences work differently and separately from the product delivery process.
Make sure to watch the full talk if you have the time. For now, let’s take a look at one of Cagan’s diagrams which illustrates the relationship between the product discovery and product delivery.
Today, I want to highlight the core strategies of each process.
Discovery strategy:
-
Build high-fidelity mocks from scratch
-
Iterate on design independently of the delivery process
-
Discover value, viability, feasibility, usability
Delivery strategy:
-
Build and maintain a production-ready product
-
Deliver production-ready features incrementally
-
Deliver scalability, reliability, performance, maintainability
If you are doing lean product research, you are only concerning yourself with the discovery process. If you are trying to get your product off-the-ground, you usually don’t need to start your delivery process until after you have collected some product research from a customer.
Let’s explore some of the challenges implicated by Cagan’s process by designing a transportation product. In the example from Cagan’s diagram, the discovery team started with a skateboard, and iterated to other transportation products like a bicycle, motorcycle and finally a car.
To address the topic of this blog post, we need to zoom in a little bit and focus on the first iteration of discovery. Let’s say we want to know how we decided to use a skateboard for the first iteration of discovery. Cagan does not provide a solution for teams that don’t know what their first iteration will look like.
For an established product, the first iteration of lean product research can be inferred from the product that you have already built and delivered. This article focuses on discovery teams that are beginning their product research for the first time.
It is important to know here that the discovery team is building high-fidelity mocks. These mocks should be small enough and fake-enough to build quickly for research purposes. Even though the discovery team is still researching feasibility, the feasibility of their mocks should be unquestioned and trivial. The real feasibility research focuses on the feasibility of the deliverable product.
The discovery team has three possible ways of evaluating feasibility for their mocked-up designs:
-
The discovery team is the delivery team, and evaluates feasibility on their own.
-
The discovery team syncs with the delivery team between research iterations.
-
The discovery team ignores feasibility until after there is value and viability.
If we revisit the skateboard example, it would be easier to decide on a skateboard if we knew more about our potential customers ahead of time. Some product teams prefer to ask questions and use these to outline one or more "personas" of their customers. What do they use transportation for? Where are they traveling? How far are they traveling? The questions could go on forever.
At a high-level, you know you are going to build a board with wheels. A painter knows they are going to brush a surface with paint. There is a limit to the amount of influence that your preliminary questions can have on your first iteration.
Even when the grand vision for your product looks like a car, your first iteration of discovery can only take into consideration small, insignificant differences like the size of the skateboard, the materials used or the sensitivity of the axles.
If you are tempted to gather as much user research as possible up-front, then you might as well be "single-track" which Cagan considers to be the "antithesis of lean." Lean product research involves research cycles with prototypes, demos and mocks that respond to each iteration of feedback. If you are in a never-ending first-iteration, you are just doing waterfall development.
Waterfall-driven feature teams are especially common in business-to-business teams, where the customer persona is already well-known up front. To avoid waterfall, it is important to build high-fidelity mocks for low-fidelity personas.
This is because lean product research involves continuously exploring new or alternative personas at any stage in the product’s life. After you have iterated, collected research and delivered your product, then you will have what you need to evolve your personas.
In the above diagram, I am highlighting the differences in personas used for waterfall, pre-delivery lean and post-delivery lean. In Waterfall, we have a static number of personas and we learn as much as we can up-front. In Lean, we try to start with a small number of low-fidelity personas, and we aim to expand our persona definitions over time as we conduct more user research.
Let’s say you want a research-informed design, but you haven’t started your first research iteration. You have prior knowledge of the customers that you will start researching, but you don’t have anything mocked up for a customer to try.
In this first iteration, you need to design something, literally anything, in order to push the needle. When you are iterating on questions, without a demo or a prototype, then you are still iterating outside of Cagan’s discovery process for products. Product research begins when you are building a high-fidelity mock. If you are asking questions before you have built anything, you are only conducting user research or market research.