Before we begin
This is a full-length summary of Dan Olsen's The Lean Product Playbook, published in twenty-fifteen. If Eric Ries told you why to work this way, Olsen tells you how. He was a product manager at Intuit, then head of product at Friendster, and he now runs workshops and consults; the book reads like a workshop, dense with frameworks and worked examples.
The premise is that product-market fit is the single most important concept in Lean Startup thinking, and that most treatments of it stop at the definition. Marc Andreessen coined the phrase and said it means being in a good market with a product that can satisfy that market. Olsen's definition, consistent with that one: you have built a product that creates significant customer value, meaning it meets real customer needs and does so better than the alternatives.
He deliberately excludes some things people fold in. Some definitions add a validated revenue model, or a cost-effective acquisition model, which effectively equates product-market fit with having a profitable business. Olsen argues that glosses over the essential idea. In business there is a distinction between creating value and capturing value, and you must create it before you can capture it. This book is about creating it.
Two frameworks carry the whole book: the Product-Market Fit Pyramid, which is the model, and the Lean Product Process, which is the six-step method for climbing it. Everything else hangs off those.
Part One. Core Concepts
The Product-Market Fit Pyramid
The pyramid has five layers, in two sections. The bottom two are the market; the top three are your product. Each layer depends on the one immediately beneath it, and product-market fit is the join between the two sections.
From the bottom up.
Target customer. A market consists of all the existing and potential customers who share a particular need or set of related needs — everyone in a country who needs to prepare their income tax, for example. You describe a market's size by the number of customers or the revenue they generate, currently or potentially.
Underserved needs. This is the layer that carries the strategic weight, and the word "underserved" is doing the work. You do not want to enter a market where customers are already delighted with existing solutions. When you build something new, you want to address needs that are not adequately met — and because customers judge you against the alternatives, how underserved a need is depends on the competitive landscape.
Value proposition. This is the set of needs you aspire to meet, and how you intend to be better than the others in the market. Olsen calls this the essence of product strategy.
Feature set. The specific functionality you build to deliver that value proposition. Each feature exists to meet a customer need.
User experience. The top layer. For software, the product itself is intangible code running on servers the customer never sees; the real-world manifestation is the experience. The UX is what brings a product's functionality to life.
Product-market fit, in this model, is the measure of how well the top three layers satisfy the bottom two. And because each layer rests on the one below, a weakness low down cannot be fixed higher up. A beautiful interface on the wrong feature set is wasted. A brilliant feature set serving an unimportant need is wasted.
His worked example is Quicken, which Intuit launched into a market that already contained forty-six personal finance products. Customer research told Scott Cook and Tom Proulx that none of them had achieved product-market fit: they did not meet customer needs and were hard to use. The founders hypothesised that a design based on the checkbook — something everyone was familiar with — would resonate. It did, and Quicken became the leader.
Read through the pyramid: the market was large, the needs were real (balancing a checkbook, tracking balances, seeing where the money goes), and despite forty-six competitors those needs were still underserved. Talking to customers ensured the feature set addressed them. The design insight produced a UX that customers found dramatically easier to use, and that ease of use was the main differentiator in the value proposition. The founders joked about having "forty-seventh mover advantage."
Olsen also notes what Intuit did that would now be called Lean: usability testing of every version before launch, public betas years before that was normal, and the "follow me home" programme, where employees waited in retail stores for someone to buy a copy of Quicken and then asked to follow them home and watch them use it.
The Lean Product Process
The six steps climb the pyramid from the bottom up.
One: determine your target customers. Two: identify underserved customer needs. Three: define your value proposition. Four: specify your minimum viable product feature set. Five: create your MVP prototype. Six: test your MVP with customers.
Two clarifications matter. First, not all six steps are needed every time. The first three are largely for a genuinely new product; once settled, you may not revisit them for a while, and after launching version one you loop continuously through the last three — specify features, create them, test them. Second, the process applies to a single feature as well as a whole product; if it is clearer, think "minimum viable feature."
Olsen is direct about what the process is for. It enforces rigour in product thinking, and it works as a checklist for the key assumptions and decisions involved in creating a product. His sharpest line: if you are not making these assumptions and decisions explicitly, you are making them implicitly. Skip these steps and you leave things like your target customer and your product strategy to chance.
He also connects it to lean manufacturing's idea of rework — time spent fixing what you did not build correctly the first time. Minimising rework is central to eliminating waste. The process will still produce some rework, because it is iterative, but quick and rigorous thinking up front reduces it.
And he quotes Bruce Lee twice, as licence to adapt: "Obey the principles without being bound by them," and "Adapt what is useful, reject what is useless, and add what is specifically your own."
Problem space versus solution space
This is the conceptual distinction that makes the rest of the book work, and it is the one most product teams get wrong.
The problem space is where customer needs live: the benefits a customer wants, described without reference to how they will be delivered. The solution space is any specific implementation.
Olsen opens with the space pen story. The popular version says NASA spent a fortune developing a pen that writes in zero gravity while the Russians used a pencil. The story is largely apocryphal, but it makes the point: "write in zero gravity" is the problem space, and the pen and pencil are two points in the solution space. If you define your problem as "build a better zero-gravity pen," the pencil is invisible to you.
Two consequences follow.
Problems define markets. A market is a set of customers with a shared need, not a set of products. Products are how the need is currently met. Framing your competitive set by products rather than by the need is how you miss the substitute that eats you.
And customers live in the solution space. They can tell you what frustrates them about what exists; they cannot specify the solution, because the space of possible solutions is not theirs to search. The famous Henry Ford line about faster horses gestures at this. Olsen's version is more useful: you should listen intently to customers about the problem space, and treat their solution-space suggestions as data about their frustrations rather than as requirements.
He also introduces "outside-in product development": deriving your product from a rich understanding of the market rather than from what your team happens to be able to build. And he uses a pair of Apple examples to show that neither pure customer-listening nor pure vision is a strategy on its own. Some Apple features came from acutely understanding needs customers could articulate; others came from Apple's own reading of the problem space that customers could not have described. What connects both is depth of understanding of the problem space, not the source of the idea.
Finally, and importantly, he says you can use the solution space to discover the problem space. Showing customers a concrete artefact — a mockup, a competitor's product, anything specific — provokes reactions that reveal needs they would never have volunteered in the abstract. This is why testing early designs teaches you about the problem, not just the design.
Part Two. The Lean Product Process
Step one: determine your target customers
You define your target customer by capturing the attributes that identify someone as being in your market. Olsen gives four kinds of segmentation.
Demographic: quantifiable statistics such as age, gender, marital status, income and education. For businesses, the equivalent is firmographics — company size, industry, and so on.
Psychographic: attitudes, opinions, values and interests. Olsen argues these are more useful than demographics for many products, because demographics are often incidental rather than causal. For a baby-photo sharing app, "women aged twenty to forty" is a consequence of targeting mothers with young children; the actual driver is that they enjoy social media and want to share pictures.
Behavioural: whether someone takes a particular action and how often. Mothers who share three or more baby pictures a week. Investors who place ten or more trades a week.
Needs-based: dividing the market by distinct needs. His example is Dropcam, the wireless camera. He uses it as a baby monitor. Others use it for home security, or to check on pets, or as a business security camera. No single demographic or psychographic description covers all four, but through the lens of needs they are one group: people who need to easily capture and view video remotely. Dropcam markets to each segment separately and tailors features — cloud recording of the video stream is critical for the security-minded and worthless to a parent watching a sleeping child in real time.
Two refinements. Users versus buyers: in business products the person who uses the product is often not the person who decides to buy it, and there may be several stakeholders who can veto. Distinguish the economic buyer who controls the budget from the others, who are potential blockers, and define your target buyer as well as your target user, because the buyer has distinct needs that also have to be met.
And the technology adoption life cycle, from Geoffrey Moore, which segments a market by risk aversion toward new technology. Innovators are technology enthusiasts who enjoy exploring new products and tolerate rough edges. Early adopters are visionaries who want an advantage over the status quo — not from love of technology but for the edge it gives. The early majority are pragmatists with no interest in technology for its own sake, who adopt only after a proven track record, want references from trusted sources, and tend to buy from the category leader. The late majority are conservatives who adopt when not adopting becomes costly. Laggards resist. The practical point is that the same product needs different messaging, different proof and often different features for each segment, and that the transition from early adopters to the early majority is where most products stall.
The deliverable from this step is the persona: an archetype of your actual users, conveying their goals along with the relevant psychographic, behavioural and demographic attributes. A good persona has a name, because when the team argues over design alternatives they can ask which one better meets Nancy's needs.
Step two: identify underserved customer needs
This is the longest and most valuable chapter in the book.
Olsen starts with vocabulary, because the field is a mess of near-synonyms: need, want, desire, outcome, benefit, job to be done, problem, value. He treats them as broadly interchangeable at the level of the problem space, and settles on "benefit" for precision.
The first tool is the customer benefit ladder, which is a way of moving up levels of abstraction. Take an attribute of the product, ask what benefit it gives, then ask why that matters, and keep going. The lower rungs are functional benefits; the higher rungs are emotional. TurboTax at the lowest rung imports your data; a rung up, that saves you time; higher, it reduces the chance of error; higher still, you feel confident you got your maximum refund and did not make a mistake the tax office will punish you for. That top rung is the real reason people buy. Laddering up finds the benefit worth competing on; laddering down finds the specific thing to build.
Related is the hierarchy of needs. Just as Maslow arranged human needs in a hierarchy, product needs have a hierarchy: the higher-order benefits do not register until the basic ones are met. Olsen learned this the hard way at Friendster, the first popular social network, where usage grew so fast that it outstripped the web servers. Plenty of users loved the product — and it did not matter, because the site was slow or unavailable. He built a hierarchy of web user needs to help the team prioritise, with availability and performance at the bottom. A delightful interface on a site that will not load is worthless.
Then comes the framework the book is best known for: importance versus satisfaction.
Plot every customer need on two axes. Importance is how much the customer cares about that need. Satisfaction is how well existing solutions currently meet it. That produces four quadrants, and only one of them matters: high importance, low satisfaction. That is where needs are underserved and where the opportunity to create customer value lives.
Olsen makes a subtle observation about the two axes that is worth carrying around. The satisfaction scale is defined by the high-water mark of solutions currently in the market, so it moves. When a better solution arrives, the top of the satisfaction scale is redefined and everything else shifts left — yesterday's satisfying product becomes today's mediocre one. The importance axis is far more stable. The need to listen to music while out of the house was roughly constant across the transistor radio, the cassette Walkman, the portable CD player and the MP3 player, over fifty years. Needs are durable; satisfaction with solutions is not.
On measurement, he is practical. Ask customers directly, in person or in a survey. For importance, use a five-point unipolar scale from "not at all important" to "extremely important," because importance is a matter of degree with no negative value. For satisfaction, use a seven-point bipolar scale from "completely dissatisfied" to "completely satisfied," because people can genuinely be dissatisfied. Average the scores, and map them to zero-to-one-hundred if that makes interpretation easier. Fewer than five points loses granularity; more than eleven overwhelms people. Ask both your own users and prospects who use competitors, with identical importance questions, because comparing satisfaction across products shows exactly where you are better or worse.
Then the part that liberates most teams. He calls it "doing quant on qual" — quantitative analysis on qualitative data. If you interview twenty-five frequent taxi users and a very large proportion rate something high or low, there is a decent chance you have uncovered a real pattern that will hold as you gather more data. Statistical significance is wonderful when you have the sample size, but too many product people have convinced themselves they must prove things beyond doubt. That is often not even possible early in a version one product.
He goes further: you can use the framework with a sample size of zero, by plotting your hypotheses about importance and satisfaction on the four quadrants — with Post-it notes if you like — and then moving, revising and adding to them as you learn. The Lean approach is about articulating clear hypotheses and designing tests for them, and you can articulate them before you have spoken to anyone.
He then relates his framework to two others.
Gap analysis simply subtracts satisfaction from importance. Its strength is a single easy number; its weakness is that it treats all gaps of equal size the same. On a zero-to-ten scale, an importance of ten with satisfaction of five gives a gap of five, and so does an importance of six with satisfaction of one — but the first is plainly the bigger opportunity.
Anthony Ulwick's outcome-driven innovation, from What Customers Want, fixes that. His opportunity score is importance, plus the difference between importance and satisfaction, floored at zero. So the first example scores ten plus five, fifteen; the second scores six plus five, eleven. Importance becomes the tiebreaker. Scores above fifteen are very attractive; below ten, unattractive. Ulwick's underlying idea is the jobs-to-be-done view, also promoted by Clayton Christensen: customers buy products to get a job done, and choose based on how well a product delivers their desired outcomes for that job.
Olsen agrees with Ulwick's criticism that needs and benefits are usually stated too imprecisely, and adds that defining them precisely is the job of the product team, not of customers. He quotes Ulwick's observation that most jobs have fifty to a hundred and fifty or more desired outcomes, not a handful — which supports his own belief that teams can and must build a detailed, precise definition of their problem space. And he quotes Steve Jobs on the same theme: the first solutions you come up with are very complex, and most people stop there; if you keep going and peel more layers off the onion, you can often arrive at very elegant and simple solutions, but most people do not put in the time or energy to get there.
His own contribution is a way of visualising it. Treat importance and satisfaction as ranging from zero to one hundred per cent. The customer value a product delivers for a given need is the area of the rectangle formed with the origin: importance multiplied by satisfaction. A need with importance seventy per cent, satisfied at seventy per cent, delivers value of zero point four nine.
The opportunity is then the area of the rectangle to the right — the maximum value that could still be added, which is importance multiplied by one minus satisfaction. Opportunity A at seventy per cent importance and seventy per cent satisfaction has an opportunity of zero point two one. Opportunity B at ninety per cent importance and thirty per cent satisfaction has an opportunity of zero point six three: three times as much potential value.
And the value created by an improvement is importance multiplied by the increase in satisfaction. Raising satisfaction from seventy to ninety per cent on a need of seventy per cent importance creates zero point one four of value.
He shows real data from a product where thirteen features were rated. One sat at a hundred per cent importance and ninety-eight per cent satisfaction, and as product manager he deliberately spent nothing further on it. The feature he prioritised was at eighty-two per cent importance and fifty-five per cent satisfaction. Another feature had lower satisfaction still, at forty-one per cent — but its importance was only fifty-three per cent, so its opportunity was smaller.
Then the Kano model, developed by the quality expert Noriaki Kano, which adds a dimension the importance-satisfaction framework does not capture: not all needs produce satisfaction the same way. Kano sorts needs into three types.
Performance needs, where more is better. Satisfaction rises steadily as the need is more fully met. Fuel efficiency in a car.
Must-have needs, where meeting them creates no satisfaction but failing to meet them creates dissatisfaction. Table stakes, the cost of entry. Seat belts in a car. And note the asymmetry: a car with a hundred seat belts is not twenty times better than a car with five. Once every passenger has one, the need is met.
Delighters, which provide unexpected benefits that exceed expectations and produce very high satisfaction — and whose absence causes no dissatisfaction at all, because customers were not expecting them. Satellite navigation in a car in the mid nineteen-nineties. Cup holders, which Chrysler introduced with the minivan in the early nineteen-eighties.
Two properties of the model matter enormously in practice.
Needs migrate over time. Yesterday's delighters become today's performance features and tomorrow's must-haves. Cup holders are now universal; navigation is standard. Growing expectations and competition continuously raise the bar — which is the same phenomenon as the satisfaction scale shifting left.
And the model is hierarchical. A delighter does not matter if you are missing a must-have. A navigation system is pointless in a car with no seat belts. You must meet basic needs before you get credit for performance features, and you must be competitive on performance features before delighters matter. Think of it as must-haves at the bottom, performance in the middle, delighters at the top.
The way to use it: classify the benefits relevant in your category into the three types, informed by evaluating competitor products and reading reviews. That gives you the map you need for the next step.
Step three: define your value proposition
Olsen opens with the line every product leader needs on a wall: strategy means saying no.
Your value proposition is the set of needs you will meet and how you will be better than the alternatives. It is a set of deliberate choices about which needs to address and, just as importantly, which to leave alone.
The Kano classification tells you how to construct it. You must cover the must-haves — no credit for them, but you cannot compete without them. You must be at least competitive on the performance benefits your target customers weight most heavily. And you should aim to be clearly better on the small number of performance benefits where you can win, plus one or more genuine delighters.
His illustration is search engines, which he uses because everyone has a mental model of them. He walks through the benefits — relevance of results, response time, coverage, interface simplicity — and shows how the winning proposition concentrated on relevance, the benefit of highest importance.
The counter-example is Cuil, launched in two thousand and eight, when search was already firmly in the upper-right quadrant: very important, and customers were pretty satisfied, with Google holding over sixty per cent share. Entering there requires a clear account of how you are better. Cuil's marketing focused on index size — it claimed a hundred and twenty billion web pages, three times Google's estimated index — plus a magazine-like results layout with more photographs, and a promise not to retain search histories. What users actually encountered was slow response times and poor relevance. It shut down two years later.
Olsen's reading is instructive. Cuil did not plan to be slower and less relevant; that is simply what users experienced. To have a shot at the incumbent you must at minimum match them on the important performance benefits — relevance and response time — and even then you need a genuinely valued differentiator to make people switch. It is unclear that a bigger index or extra privacy were worth much to customers. Changing behaviour in the upper-right quadrant is hard, and you need to create a lot of excess value to shift someone off a product they use every day. This is where the old rule of thumb about needing to be ten times better comes from.
Then the forward-looking part of the chapter, which he calls skating to where the puck will be. Because the satisfaction scale shifts and needs migrate, a value proposition should be defined against where the market will be when you ship, not where it is when you plan. His example is the Flip video camera, launched by Pure Digital in two thousand and six as the point-and-shoot camcorder, and better than traditional camcorders on ease of use, size and price. Cisco acquired Pure Digital for five hundred and ninety million dollars in two thousand and nine, and killed the Flip business two years later. Nothing went wrong with the product. In the same year Cisco bought it, Apple shipped the iPhone 3GS, its first iPhone with video recording, and the smartphone was more portable and always in your pocket. The lesson is the same one as the iPod: a stand-alone benefit gets absorbed into a set of related benefits met by a single device, and the stand-alone product disappears.
Step four: specify your MVP feature set
Now you cross from the problem space into the solution space, and the unit of work becomes the feature.
Olsen's format is the user story, which he likes because it forces a benefit into the statement: as a certain type of user, I want to do something, so that I get some benefit. The "so that" clause is the link back to the problem space, and a story without one should be treated as suspicious.
Then breaking features down, and this is where a lot of teams go wrong. Most things called features are actually bundles. Break them into the smallest pieces that still deliver value, because smaller batch sizes are better — the same lean principle Ries argues, applied at the level of the backlog. Smaller items are easier to estimate, easier to sequence, easier to cut, and they let you discover you were wrong sooner.
For sizing, he recommends story points, which measure relative effort rather than absolute time, and warns against confusing size with value. For deciding what makes the cut, he recommends explicit return on investment thinking: estimate the customer value each item delivers — using the importance-satisfaction opportunity as your value input — and divide by estimated effort. Rank on that ratio, and the shape of the MVP emerges rather than being negotiated.
And then the definition of the MVP candidate itself: the smallest feature set that your target customer would consider viable, meaning it delivers enough value to be worth using. Not the smallest thing you can build. The smallest thing they would accept.
Step five: create your MVP prototype
Olsen's contribution here is to settle the endless argument about what counts as an MVP.
He notes the debate: some insist a landing page is a valid MVP, others insist an MVP must be a real working product or at least an interactive prototype. His resolution is a piece of vocabulary. These are all methods for testing the hypotheses behind your MVP, so call them MVP tests, and reserve the term MVP for an actual product. The argument dissolves.
He is unusually firm about the abuse of the word minimum. People use it to justify a partial product with too little functionality to be viable, or to rationalise a shoddy experience and a buggy build. His model, adapted from a well-known diagram by the designer Jussi Pasanen, describes a product with four hierarchical attributes: functional, reliable, usable, and delightful. The wrong reading of MVP is a product with limited functionality where reliability, usability and delight can be ignored. The right reading is a product with limited functionality that is nonetheless complete on all four attributes — a narrow slice through the whole pyramid, not the bottom layer only.
Then the framework the chapter is built on: the matrix of MVP tests, on two dimensions.
The first dimension is product versus marketing. A marketing test shows people how you describe the product; a product test shows them functionality, even if only as a wireframe. Both tell you how compelling people find what you showed them, but the learning goal differs, and a marketing test is not an actual product creating customer value. At some point you have to test a prototype of the product itself.
The second dimension is qualitative versus quantitative. Qualitative means talking to customers directly, usually in numbers too small for statistical significance, and caring about the detail from each one. Quantitative means running at scale and caring about the aggregate.
Olsen's crisp statement of the difference: quantitative tests are good for learning what and how many — what actions customers took and how many took them. They will not tell you why. Qualitative tests are good for learning why. Both matter, and he observes that most teams lean too heavily on one, usually quantitative. His advice is to start qualitative when developing something new; if you jump straight to quantitative tests they usually do not perform well, and even when they do, you will not know why. Mature teams alternate rounds of each.
That gives four quadrants.
Qualitative marketing tests mean showing people your marketing materials — a landing page, a video, an advertisement, an email — and soliciting reactions. You learn which benefits resonate and how well your framing lands. You can show them a competitor's materials too, to test your differentiation. His favourite specific technique is the five-second test: show someone your home page for five seconds, then ask what they remember and what they liked. Customers make snap judgements constantly, so this is a good measure of whether your messaging conveys what the product does and why anyone would want it.
Quantitative marketing tests validate demand and optimise acquisition. The landing page or smoke test is the most common: a live page describing the product you plan to build, with a sign-up or a plans-and-pricing button, leading to a "coming soon" page that collects an email address. The metric is conversion rate. Buffer is the canonical example: Joel Gascoigne stopped himself from coding, built a two-page site with a headline, three bullets and a pricing button, tweeted the link, and considered the idea validated when people left their addresses. Then he inserted a page offering three tiers — free, five dollars a month, twenty dollars a month — to test willingness to pay, and watched how many clicked each. Nobody had paid anything at that point, but he had enough validation to proceed.
The explainer video is a variant, useful when a product is hard to describe in words; Dropbox is the standard case. Ad campaigns let you test taglines against each other by click-through rate, though ads are usually too small to convey a whole value proposition, so they are better for optimising acquisition than for validating fit. A-B testing runs alternatives concurrently — and Olsen insists on concurrently rather than sequentially, because running version A for a while and then version B lets seasonality or promotional differences contaminate the result. Multivariate testing varies page elements rather than whole pages, testing all combinations. And crowdfunding is a quantitative marketing test where people actually pay before you build: Pebble set a hundred-thousand-dollar goal, hit it in two hours, and finished a month later with over sixty-eight thousand backers and more than ten million dollars.
Qualitative product tests are, he says, the most valuable way to assess and improve product-market fit when developing something new. You can run them before you build, on design artefacts, or after you build, on the real thing. Both have value. Testing designs first reduces waste, because changing a design is far faster and cheaper than changing code. Testing the live product has the advantage of a hundred per cent fidelity, so you catch things design testing cannot — that the page is slow to load, or broken in a particular browser. His position is that there is nothing wrong with live testing, but waiting until the product is live to test at all means taking an unnecessary risk.
He classifies design artefacts on two axes, fidelity and interactivity. Hand sketches are lowest on both, and he loves them for internal use — the whiteboard, he says, may be the ultimate Lean tool, because it lets teams iterate ideas so rapidly — but he considers them too low-fidelity to show customers. Wireframes are low-to-medium fidelity, showing components and arrangement without colours, images or final fonts. He recommends using real copy from the start rather than placeholder text, to catch layout problems early. Mockups are high fidelity. Interactive prototypes add clickability. And his advice on tools is worth hearing: he has seen too many designers and product managers miss the next capability because they cling to a tool they are proficient in, and he lists the warning signs — drawing basic page elements from scratch instead of using a widget library, wireframes that are not clickable, difficulty sharing them, using a desktop tool for mobile screens, taking longer than you would like, or not wireframing at all.
Quantitative product tests are the ones run on live functionality at scale: A-B tests of the product itself, fake door tests where a feature entry point is shown and the click-through measured before the feature exists, and analytics on real usage.
The UX design chapter
This chapter is not a separate step; it is guidance for step five, and Olsen devotes a whole chapter to it because UX is the layer customers actually touch.
He starts with what makes a great experience. A product with poor UX feels unintuitive: you cannot find things, you are not sure what to do next, you hit dead ends and cryptic errors. A great UX feels effortless — you stop noticing the interface and focus on the task, sometimes reaching what psychologists call flow.
But the first thing he says about UX is that it cannot rescue the layers beneath it. No matter how easy to use or beautiful a product is, it cannot deliver a great experience if the customer does not value the benefits it provides. One way to evaluate UX is to ask how much it helps or hinders the functionality in conveying the intended benefits.
Beyond that, a great UX has two attributes.
Usability: can customers use it? Measured by task completion — what percentage of users successfully complete each key task, and what percentage complete it but hit problems along the way — and by efficiency, which you can assess simply by counting the clicks, taps or keystrokes a task requires, and timing it. He also insists on perceived effort and cognitive load: you can overwhelm people with too much information or too many choices, or tax their memory. A great UX avoids demanding much physical or mental effort.
Out of this he states what he calls Olsen's Law of Usability: the more user effort required to take an action, the lower the percentage of users who will take it; the less effort required, the higher the percentage. He notes this is not only a usability principle but a conversion principle — it applies directly to registration forms and payment flows.
He adds that usability is always relative to a user profile. Expectations differ enormously between a product for trained power users and one for mainstream consumers, which is what your personas are for. And ease of learning matters especially for new users, who decide very quickly whether a product is for them.
Delight: do customers enjoy using it? Usability answers whether they can; delight answers whether they want to. Sources of delight include aesthetics, which create a first impression of quality and credibility; simplicity, since eliminating clutter reduces cognitive load; experiences that seem to read the user's mind through smart defaults; personality conveyed through tone and humour; dynamic response, like the rubber-band scroll at the end of a page in iOS; sound, like the cash-register sound in Quicken or the Mac startup chime; and surprise, like Twitter's fail whale. His own favourite example is MailChimp's email preview, where the mascot points to a pixel ruler and, as you widen the preview past the recommended maximum, his expression turns pained, warnings appear, and eventually his arm detaches with a "POP." Olsen still remembers it years later, which is the point.
Then the framework: the UX design iceberg, four layers, only the top of which is visible.
Conceptual design, at the bottom, is the core concept that forms the essence of the experience, and it should resonate with how your target customers already think. This is where product innovation most often comes from. Quicken's checkbook metaphor is one example. Uber's is another: a map-centric design whose innovation was showing the real-time location of nearby cars, both before you book and once your driver is coming. That required technical innovation to track drivers live, and it was chosen because Uber knew taxi customers are frustrated by late pick-ups and no-shows, so transparency about arrival was central to the value proposition. The conceptual design makes the value proposition immediately obvious to a first-time user.
Information architecture, the second layer, defines how the product's information and functionality are structured, organised and labelled. Customers infer the organisation from navigation labels and guess where things live. Card sorting is the research technique for learning how customers think about the parts of a product. The goal is findability, which you can measure by asking test users to find a specific screen and seeing what percentage succeed, and by looking at navigation paths in analytics — are people taking the shortest route, or getting lost and using the back button?
Interaction design, the third layer, defines how the user and the product interact: flows, states, controls, feedback, error handling.
Visual design, the top layer and the only one above the waterline, is how the product looks. We are visual creatures, and visual processing is the main way our brains take in information — but looking good on the surface is not enough. Excellent UX requires skill at all four layers and a workflow that works bottom-up.
He adds a point about research that generalises well beyond UX: it is critical that the researcher is not the only person who gains the learning. Team members should observe as much research as they can, because experiencing it firsthand is far more impactful than reading a report — the difference between a front-row seat at a match and reading about it the next day. Hold team debriefs promptly afterwards, and document the summary to solidify and share it.
Step six: test your MVP with customers
The chapter opens with the concept that justifies all user testing: product blindness. When you are close to a product it is difficult, often impossible, to see it as a new customer does. You are more familiar with it than any new user could ever be, so you have blind spots for the issues a new user will hit within minutes. User testing is the antidote.
His practical guidance is specific.
Test one customer at a time. Group sessions produce worse results because of group dynamics — some people will not speak candidly for fear of being judged, one or two vocal participants dominate, and groupthink converges the room on an artificial consensus. He is explicit that focus groups, with six to twelve people, suffer this badly. One-to-one gives you a richer conversation and truer feelings, especially if the moderator is the only other person in the room. If observers want to watch, use a webcam feeding a monitor in another room, or have them join the screen share for a remote session.
On sample size, his answer is waves of five to eight customers at a time. That is enough to uncover the major issues and see patterns across users, without passing the point of diminishing returns where you just keep hearing the same thing. After each wave, revise the product or the design artefact and test the next version with a fresh wave. Expect roughly a ten per cent no-show rate, so schedule one more than you need.
On recruiting, screen properly against your target customer definition — the whole exercise is worthless if you test with people outside the market. And he endorses "ramen user testing," his phrase for the cheap end of the spectrum: going where your target customers already are, offering a small incentive, and running sessions on a laptop. It costs almost nothing and the alternative is usually no testing at all.
On structure: start with background questions to establish context and put the person at ease, then move to the task or the artefact, then close with wrap-up questions.
On asking good questions, his rules are the heart of the chapter. Ask open questions rather than closed ones — closed questions can be answered yes or no and teach you very little, so favour what, how and why. Do not lead the witness; the way you phrase a question can hand the customer the answer you were hoping for. Do not explain your design; if you have to explain it, that is the finding. Ask the person to think aloud as they work. Sit on your hands and let silence do the work rather than rescuing them. And treat their expressed pain as the signal — his phrase is "I feel your pain" — because a customer's frustration is data about the problem space, whatever they suggest as a fix.
Finally, a distinction that matters and is constantly confused: usability is not product-market fit. A test can show that people can use your product perfectly and still tell you they would never bother. Usability problems live in the UX layer of the pyramid; a fit problem lives further down, in the value proposition or the needs. When you capture and synthesise feedback, sort it by which layer of the pyramid it belongs to, because the remedy is completely different.
Iterate and pivot
Olsen presents the loop in two forms. The Build-Measure-Learn loop, from Ries, describes the activity. But he prefers his own framing for design work: hypothesise, design, test, learn. Explicit hypotheses first, then an artefact designed to test them, then the test, then the conclusion.
Iterative user testing is the engine. Each wave of five to eight customers produces changes, and the next wave tests those changes. What you are watching for across waves is whether the same issues keep arising. When a redesign stops producing new major problems and customers start describing the value in your own intended terms, you are converging.
And the persevere-or-pivot decision, in his framing, is a question about which layer of the pyramid is broken. If customers understand and want the value proposition but stumble on the interface, iterate on the UX. If they use it easily and shrug, the problem is higher up the stack than you thought and lower down the pyramid — the value proposition, or the needs, or the target customer. Pivots are moves down the pyramid, and the further down you have to move, the bigger the pivot.
The end-to-end case study
Chapter eleven works the whole process on a real product, MarketingReport dot com, which offered small businesses a report on their online marketing performance. It is worth listening to in the book itself if you want to see the frameworks applied in sequence, but the shape is this.
Step one narrowed the target customer from all small businesses to a specific segment. Step two used discovery interviews and the importance-satisfaction framework to find the underserved needs — small business owners knew they should be doing something about their online presence, did not know what, and found existing analytics tools incomprehensible. Step three defined a value proposition centred on telling them plainly how they were doing and what to fix. Step four cut the feature set to the minimum that would deliver that. Step five produced wireframes and then a higher-fidelity prototype. Step six tested with waves of customers, and the early waves went badly — the first version was too data-heavy and people could not see what to do with it.
The iterations moved toward a simple graded score with a short list of prioritised actions. Olsen's reflection is the useful part: most of the value came from the early steps, and the team's instinct had been to skip them and start designing screens. The frameworks earn their keep precisely because they slow you down at the point where being wrong is cheapest to fix.
Part Three. Building and Optimising Your Product
Build it with agile
The third part shifts from finding fit to building and running the product, and the agile chapter is a compact orientation rather than a manifesto.
He covers Scrum — fixed-length sprints, a prioritised backlog, a defined increment, the roles and the ceremonies — and Kanban, which drops fixed iterations in favour of a continuous flow with work-in-progress limits. His guidance on choosing is pragmatic: Scrum suits teams that benefit from the rhythm and the forcing function of a sprint boundary, especially teams new to agile; Kanban suits work that arrives unpredictably, such as support-heavy or operations work, and teams mature enough to self-regulate flow. Many teams end up with a hybrid.
On succeeding with agile, his emphasis is that the practices are not the point — the outcomes are. He gives particular attention to the engineering practices that make iteration actually possible: quality assurance, test-driven development, continuous integration and continuous deployment. This is the same argument Ries makes with the andon cord, from a different angle. If your deployment process is slow and risky, your learning loop is slow whatever your process diagram says. The technical capacity to ship safely is a product capability, not an engineering luxury.
Measure your key metrics
Olsen begins by placing analytics among the other ways of learning, and he does it with a nice contrast: Oprah versus Spock. Qualitative methods — user interviews, usability testing — are Oprah: they tell you why, in depth, from few people. Quantitative methods — surveys at scale, analytics, A-B testing — are Spock: they tell you what and how many, precisely, from many people. Neither is sufficient. Surveys sit in the middle, capable of both if designed well.
The single most important quantitative measure of product-market fit, he argues, is retention. And the way to see it is cohort analysis: group users by when they joined, and track what percentage of each cohort is still active in each subsequent month. Plotting the cohorts as curves shows three things at once — the initial drop-off, the decay rate, and the terminal value where the curve flattens. If your product-market fit is improving, successive cohort curves move up: lower initial drop-off, slower decay, higher terminal value. That is the cleanest quantitative picture of fit anyone has proposed.
Above retention he uses Dave McClure's AARRR framework, sometimes called pirate metrics: acquisition, activation, retention, revenue and referral. Acquisition is people arriving. Activation is their first meaningful engagement — a broader idea than conversion, since someone might leave an email address without becoming a customer. Retention is coming back. Revenue is paying. Referral is existing customers causing new prospects to hear about you.
His addition is the metric that matters most, which he abbreviates MTMM. At any point in the life of a business, one of the five macro-metrics offers a much higher return on effort than the others. That is your MTMM, and the "right now" is essential: once you have made significant progress on it, it stops being the MTMM and something else takes over. His worked example: you launch and discover only ten per cent of people who start sign-up finish it, so sign-up conversion is your MTMM. You run user tests, find several usability problems and a browser bug, check the server logs, find an intermittent error, fix everything, and get to ninety per cent. At that point sign-up conversion is no longer the MTMM, and you go looking for whatever now offers the highest return.
Then the tool he uses on every consulting engagement, which he calls the equation of your business. Every business can be expressed as an equation, built from metrics you can actually influence. The universal starting point is that profit equals revenue minus cost. That is too high-level to act on, so you decompose each term into more detailed metrics, several levels deep — what he calls peeling the analytics onion. For an e-commerce business, revenue breaks into visitors times conversion rate times average order value times purchase frequency, and each of those breaks down further. For a subscription business it breaks into new subscribers, price and churn. The value of writing it out is that it shows you exactly which levers exist and how much each one moves the outcome, which is what turns a dashboard into a strategy.
He notes that most high-tech companies pursuing fit focus far more on increasing revenue than reducing cost, because marginal revenue exceeds marginal cost and the gap widens with volume. And he covers the profitability constraint that governs the paid acquisition path: lifetime value must exceed customer acquisition cost, and the ratio between them determines how aggressively you can grow.
Use analytics to optimise
The final framework is the Lean Product Analytics Process, which is a repeatable loop for improving the numbers.
You start global, across all your metrics, and assess the upside potential of each — not just how bad it is, but how much room there is to improve it and how much that improvement would be worth. You select the metric that matters most. You then go deep on that one metric: segment it to find where the problem concentrates, form hypotheses about the cause, design tests, run them, and measure the result. Then you return to the global view, because the MTMM has probably changed.
His case study is Friendster, where he led product management, and it is worth following closely because it shows the method rather than just asserting it.
He began by drawing the viral loop: current users, of whom only the active ones send anything; active users send email invitations to friends who are not yet members; those prospects either click the link or do not; those who click either complete registration or abandon it; and those who register become users who can go round the loop again.
Then he chose metrics to track it, and made a deliberate choice that most teams get wrong. He did not want atomic metrics like the number of active users, because those fluctuate with the size of the user base and cannot be compared over time. He wanted normalised ratio metrics. He landed on five that together capture the whole loop: the percentage of registered users who are active; the percentage of active users who send invitations; the average number of invitations per sender; the invitation click-through rate; and the registration conversion rate. Multiply those five together and you get the viral coefficient of the loop.
He then measured baselines. Taking three of the five: fifteen per cent of users sent invitations, senders sent an average of two point three invitations each, and eighty-five per cent of people who reached the registration page completed it.
Now the question the whole chapter turns on. Which of those three should you work on first? The instinct of most teams is to fix the worst-looking number, and here that is the fifteen per cent.
Olsen's tool when you do not yet know what improvements are possible is what he calls the upside potential of a metric: the maximum improvement the metric could conceivably support, expressed as a percentage of where it stands now.
Registration conversion is at eighty-five per cent and can at best reach one hundred, so it can gain fifteen points, and fifteen divided by eighty-five is an upside of about eighteen per cent. That is the healthiest-looking metric and the worst place to spend effort.
The percentage of users sending invitations is at fifteen per cent and could theoretically reach one hundred, a gain of eighty-five points; eighty-five divided by fifteen is an upside of five hundred and seventy per cent.
The average number of invitations per sender is not a percentage, so it has no obvious ceiling — but it must have one, because people have a finite number of friends. Olsen estimated the ceiling as the average number of friends a user has, somewhere between one hundred and two hundred, and settled on a hundred and fifty, which happens to be Dunbar's number, the psychologist Robin Dunbar's estimate of how many stable social relationships a person can maintain. A hundred and fifty divided by two point three gives an upside potential of over six thousand per cent — far beyond the other two, even using the conservative estimate of a hundred.
Upside potential is not the same as return on investment, and Olsen is clear about that: it tells you what the ceiling is, not how much effort it takes to approach it. But when you have no better information, it is a fast way to stop your team polishing the metric with the least room to move.
On A-B testing for optimisation, he repeats the discipline: run alternatives concurrently, size your samples for the difference you expect to detect, keep a champion and periodically challenge it, and remember that very similar alternatives require very large samples to distinguish.
What this means if you run a product organisation
A few translations, offered as one reader's reading.
The pyramid is the most useful diagnostic in the book. When something is going wrong, the first question is which layer. Low usage of a well-built feature is usually a needs or value-proposition problem, not a UX problem, and teams that treat every symptom as a UX problem redesign their way through a year without moving anything. Make your team name the layer before they propose a fix.
Run importance versus satisfaction on your own product, on the features you already have. It takes one survey and an afternoon. The output — a list of your features plotted by how much customers care and how satisfied they are — will reorder your roadmap more decisively than any prioritisation framework, because it is grounded in the two things that actually determine value.
Use the Kano classification when you argue about scope. Most scope fights are really disagreements about whether something is a must-have, a performance benefit or a delighter, conducted without those words. Naming the category usually ends the argument, and it stops teams shipping delighters while a must-have is broken.
Adopt "MVP tests" as vocabulary. It ends the recurring argument about whether a landing page counts, and it keeps the word MVP attached to something you would actually be willing to release. And hold the line on the four attributes: an MVP is narrow, not shoddy.
Start qualitative, then go quantitative. If your organisation only runs A-B tests, you know what happens and never why, and you will optimise a local maximum for years. Waves of five to eight one-to-one sessions, run continuously, is the cheapest capability you can add.
Insist that the team watches the research. The single biggest multiplier on user testing is not the testing, it is who is in the room. Engineers who have watched three people fail to complete a flow do not need to be persuaded about the backlog.
Make cohort retention your headline measure of fit. Not monthly actives, not registrations. Curves per cohort, watched for whether newer cohorts sit above older ones.
Name your metric that matters most, out loud, and change it when it stops being true. A team with one named metric and a hypothesis about how to move it is worth several teams with a balanced scorecard.
And write the equation of your business on a whiteboard. Most product organisations have never done this, and the exercise usually reveals a lever nobody was pulling.
Rapid recap
Here are the things worth keeping.
Product-market fit means you have built something that creates significant customer value: it meets real needs better than the alternatives. Creating value comes before capturing it.
The Product-Market Fit Pyramid has five layers. From the bottom: target customer, underserved needs, value proposition, feature set, user experience. Each depends on the one below, and a weakness low down cannot be fixed higher up.
The Lean Product Process climbs it in six steps: determine your target customers, identify underserved needs, define your value proposition, specify your MVP feature set, create your MVP prototype, test your MVP with customers.
If you are not making your key assumptions explicitly, you are making them implicitly.
Problem space is the customer need; solution space is any implementation of it. Problems define markets. Customers live in the solution space, so listen to them about problems and treat their solutions as evidence of frustration.
You can use the solution space to discover the problem space — showing something concrete provokes reactions people would never volunteer in the abstract.
Segment your market demographically, psychographically, behaviourally or by needs. Needs-based segmentation often unites groups that look unrelated. Distinguish users from buyers, and know where you sit on the technology adoption life cycle.
Ladder from product attributes up to functional and then emotional benefits. The top rung is usually the reason people buy.
Importance versus satisfaction is the core framework. Opportunity lives in the high-importance, low-satisfaction quadrant. Importance is stable over time; satisfaction shifts left as better solutions arrive.
Customer value equals importance times satisfaction. Opportunity equals importance times one minus satisfaction. Value created equals importance times the increase in satisfaction.
You can do quant on qual, and you can use the framework with a sample size of zero by plotting your hypotheses.
The Kano model sorts needs into must-haves, performance benefits and delighters. It is hierarchical — a delighter does not matter if a must-have is missing — and needs migrate: today's delighters become tomorrow's must-haves.
Strategy means saying no. Your value proposition covers the must-haves, competes on the performance benefits that matter, wins clearly on a few, and adds a delighter.
Skate to where the puck will be, because satisfaction scales shift and stand-alone benefits get absorbed into devices that meet whole sets of related needs.
Write features as user stories with a "so that" clause. Break them down; smaller batches are better. Prioritise by value over effort.
The MVP is the smallest feature set your target customer would consider viable — narrow in functionality, but still functional, reliable, usable and delightful.
Say MVP tests, not MVP, for landing pages and prototypes. They sort on two axes: product versus marketing, qualitative versus quantitative. Quantitative tells you what and how many; qualitative tells you why. Start qualitative.
The UX design iceberg has four layers: conceptual design, information architecture, interaction design and visual design. Only the top is visible, and the bottom is where innovation usually comes from.
Olsen's Law of Usability: the more effort an action requires, the fewer users will take it. This is a conversion law as much as a usability law.
Product blindness is real, and user testing is the antidote. Test one person at a time, in waves of five to eight, with open questions, and never explain your design.
Usability is not product-market fit. Sort every piece of feedback by which layer of the pyramid it belongs to.
Persevere or pivot is a question about which layer is broken. The further down the pyramid you must move, the bigger the pivot.
Cohort retention curves are the best quantitative measure of fit. Improving fit shows as newer cohorts sitting above older ones.
AARRR — acquisition, activation, retention, revenue, referral — plus the metric that matters most right now, which changes once you have fixed it.
Write the equation of your business, and peel the analytics onion until you reach metrics you can actually move.
Track normalised ratio metrics, not atomic counts, so you can compare over time. And when you cannot estimate the return on improving something, use its upside potential — how far it could possibly move, relative to where it is now. The healthiest-looking metric usually has the least room in it.
And the thing to carry out of the book: every product decision is a bet about a layer of the pyramid. Name the layer, name the bet, and go and find out.