Product market fit pyramid: top-down or bottom-up testing?

That sequence puts the highest-cost assumptions first.

Dan Olsen’s product market fit pyramid reverses the order. It starts with the market: the target customer and the underserved need. Product decisions come after that. The model has five layers, with two market layers at the base and three product layers above them.

The distinction is not academic. CISQ data cited by UserTesting puts US software rework at $2.26 trillion. A material share of that cost comes from shipping products and features before the team has tested whether the market needs them. In startup terms, this is capital converted into code before demand has been established.

The practical verdict is binary:

• Bottom-up testing is the correct default for discovering product-market fit.
• Top-down testing is useful after the market hypothesis has survived contact with customers.

The product market fit pyramid is not a substitute for execution. It is a way to stop execution from running ahead of evidence.

The anatomy of the 5-layer framework: market versus product

The PMF pyramid has a strict dependency structure. Each layer constrains the layer above it.

The bottom two layers define the market:

1. Target customer

2. Underserved needs

The top three define the product:

3. Value proposition

4. Feature set

5. User experience

This order matters because product quality has no independent value. A clean interface for the wrong customer is waste. A complete feature set aimed at a solved problem is waste. A strong value proposition attached to a weak market is a funding problem waiting to happen.

The framework was created by Dan Olsen and published in The Lean Product Playbook in 2015. Marc Andreessen had popularized the broader product-market fit concept in 2007. Olsen’s contribution was operational: he turned a market condition into a sequence of hypotheses that teams can test.

That sequence is the useful part. The pyramid is not a scorecard. It is not a maturity model. It does not tell a founder that the company has reached product-market fit because the team has completed five design exercises.

It tells the team where the next failure is likely to occur.

The two market layers are not interchangeable

A target customer is not the same as a demographic label.

Small businesses, enterprise finance teams, developers, clinics, and online retailers are broad categories. They do not describe a buying unit with enough precision to support product decisions.

A usable target-customer definition includes operational facts:

• The role that experiences the problem.
• The company type or environment where it occurs.
• The workflow that contains the problem.
• The existing workaround.
• The person who approves the purchase.
• The economic consequence of leaving the problem unresolved.

The second market layer is the underserved need. This is where many startup plans become vague. The team sees a customer segment and then attaches a general desire to it: faster reporting, better collaboration, lower costs, more automation.

Those statements are not needs. They are category language.

An underserved need should connect to a job, a delay, a cost, a risk, or a lost opportunity. It should also reveal why current products fail to solve it. If the need is already handled by a mature incumbent and customers show no switching pressure, the startup has a feature idea, not a market opening.

The base of the pyramid is not customer interest. It is a customer with a costly problem and a weak current solution.

Why bottom-up validation prevents the rework trap

Bottom-up testing begins with the assumptions that sit closest to the market. The team defines who it serves, identifies the problem, and only then specifies the product.

Top-down testing starts at the opposite end. The team builds a feature or prototype, puts it in front of users, and measures reactions. This can produce useful data. It can also create false confidence because the test is already constrained by earlier untested decisions.

The difference is not that one method uses prototypes and the other does not. Both can use prototypes. The difference is the order in which the team commits capital.

Bottom-up testing

A bottom-up sequence asks:

1. Is the target customer defined with enough precision?

2. Does that customer have a recurring or expensive problem?

3. Is the need underserved by current tools or processes?

4. Does the proposed value proposition address the problem?

5. What is the smallest feature set that can deliver the outcome?

6. Can customers use the product with enough speed and clarity to repeat the behavior?

This sequence reduces the size of each commitment. The team can reject a weak hypothesis through interviews, workflow analysis, sales conversations, and lightweight prototypes before building a full system.

The method does not eliminate uncertainty. It moves uncertainty to the cheapest testing stage.

Top-down testing

Top-down testing usually follows a different path:

1. Define a product concept.

2. Build a feature set.

3. Create a prototype or MVP.

4. Observe user behavior.

5. Adjust the interface or feature mix.

6. Search for a market after the product exists.

This approach can work when the market is already known, the buyer is clear, and the main risk is execution. It is also common when technical teams mistake buildability for demand.

The failure pattern is predictable:

• The team chooses a large addressable market.
• It builds a broad feature set.
• Early users praise the concept but do not change behavior.
• The team interprets low adoption as a UX problem.
• More features are added.
• Burn increases.
• The product becomes harder to explain and harder to sell.

The company is now optimizing a product that has not earned the right to exist.

What top-down testing is good for

The top-down method has a legitimate role. It is useful for testing product-layer assumptions after the market-layer assumptions have evidence behind them.

For example, a B2B startup may know that revenue operations teams lose time reconciling data across systems. The market problem has evidence. The next question is product-specific: should the MVP automate data mapping, provide exception alerts, or produce a management report?

That is a top-down product decision. It should not be confused with discovering whether revenue operations teams have a problem worth solving.

The boundary is simple:

• Use bottom-up testing to establish who and why.
• Use top-down testing to establish what and how.

The Lean Product Process: from target customer to MVP prototype

Olsen’s Lean Product Process has six steps. The steps map directly to the five pyramid layers, with the final stage testing the assembled product against the market.

1. Determine the target customer

The first decision is segmentation. The goal is not to identify everyone who might use the product. The goal is to isolate the group with the strongest combination of pain, access, and ability to act.

A useful segment has a clear context. A company selling workflow software might target finance managers at multi-entity businesses that close their books across separate systems. That is more actionable than targeting finance professionals.

The narrower definition supports better testing. Interview questions become specific. Sales objections become comparable. Product usage can be tied to a known workflow.

Customer acquisition cost also becomes measurable. If the target customer cannot be reached through a defined channel, the product-market fit discussion is incomplete. A product can solve a real problem and still fail as a business if distribution costs exceed the gross margin available from the account.

2. Identify underserved needs

The next step is to map the customer’s current process.

The relevant evidence includes:

• The tools used today.
• Manual steps that remain after using those tools.
• Delays that affect revenue, cash, compliance, or capacity.
• Workarounds built in spreadsheets, email, or internal scripts.
• Events that trigger a search for alternatives.
• The budget owner and the approval path.
• The cost of doing nothing.

The last point matters. A complaint is not automatically a buying signal. Customers complain about many things that they will not fund.

A need becomes commercially relevant when it has a measurable consequence. That consequence may be labor cost, slower sales conversion, missed renewals, excess inventory, operational risk, or management time. The number does not need to be precise at the start. The economic direction must be clear.

This is also where teams should separate users from buyers. The person who suffers from the problem may not control the budget. A product that improves an individual workflow but creates integration, security, or procurement costs for the buyer may fail despite positive user feedback.

3. Define the value proposition

The value proposition converts the underserved need into a reason to choose the product.

It should state:

• The customer segment.
• The problem being solved.
• The outcome delivered.
• The alternative being displaced.
• The reason the product can deliver the outcome.

Weak propositions describe features. Strong propositions describe a change in the customer’s economics or workflow.

A reporting dashboard is a feature. Reducing the time required to identify cash exposure is an outcome. A sales automation tool is a category label. Increasing qualified pipeline coverage without adding headcount is a commercial claim that can be tested.

The claim must remain narrow. If the value proposition promises lower costs, faster execution, better visibility, fewer errors, and higher growth at once, it is not a proposition. It is a funding presentation.

4. Specify the MVP feature set

The MVP is not the smallest version of the full product. It is the smallest product that can test the core value proposition.

That distinction prevents feature accumulation. Each proposed capability should answer one question: does this feature deliver the primary outcome, enable access to the workflow, or remove a barrier to adoption?

If it does none of those things, it belongs outside the first test.

A useful MVP feature set often looks incomplete to the product team. That is a feature, not a defect. Completeness is expensive. Learning is the objective.

The right constraint is not a fixed number of features. It is a fixed hypothesis. If the team cannot state what customer behavior would confirm or reject the MVP, the feature set is not ready.

5. Create the MVP prototype

A prototype can be a clickable interface, a concierge workflow, a manual service behind a thin front end, or a limited production release. The format depends on the risk.

If the main risk is whether users understand the workflow, a clickable prototype may be enough. If the risk is whether the promised result has economic value, the team may need to deliver the result manually to a small number of customers.

This is where many teams overbuild. They treat technical automation as proof of demand. It is not. Automation proves that a system can perform a task. It does not prove that a customer will pay for the task, adopt the workflow, or renew access.

The prototype should expose the minimum path from customer problem to customer outcome. Latency, setup time, data import, permissions, and handoffs belong in the test if they affect adoption. A demo that avoids the hard parts can create a false positive.

6. Test the MVP with customers

Testing requires more than asking whether customers like the product.

Useful signals include:

• Whether customers complete the target workflow.
• Whether they return without being prompted.
• Whether the product displaces an existing process.
• Whether the buyer accepts the commercial terms.
• Whether implementation blocks deployment.
• Whether the customer expands usage.
• Whether the customer renews or commits to a next step.

The strongest evidence is behavior with a cost attached. A customer who schedules implementation, grants data access, changes a process, or pays has created a different signal from a customer who offers positive feedback in a meeting.

This is not a license to ignore qualitative evidence. Early-stage samples are small. Teams need to understand why behavior occurs. But explanations should support behavioral evidence, not replace it.

Bottom-up versus top-down testing

The comparison becomes clearer when the two approaches are evaluated against the same operating constraints.

Neither column guarantees product-market fit. The bottom-up approach can produce a precise answer to the wrong problem if the team selects a segment without studying alternatives. The top-down approach can produce strong engagement from a small group that cannot support a scalable acquisition model.

The framework works when teams preserve the dependency between layers.

The cost of skipping a layer

Skipping the target-customer layer creates a distribution problem. The team cannot define a sales motion, content strategy, or channel because the audience is too broad.

Skipping the underserved-need layer creates a positioning problem. The company enters a category without proving that buyers need another option.

Skipping the value-proposition layer creates a pricing problem. The team cannot connect the product to an economic outcome, so it defaults to competitor pricing or cost-plus logic.

Skipping the feature-set layer creates a scope problem. The MVP becomes a compressed roadmap instead of a testable product.

Skipping the UX layer creates an adoption problem. The product may solve the problem but fail in the customer’s actual operating environment.

The pyramid is hierarchical because these failures are connected. A lower-layer error contaminates the layers above it.

A polished MVP does not repair a weak market hypothesis. It only increases the cost of discovering it.

Aligning product execution with underserved market needs

The central operating task is alignment. Every product choice should trace back to the customer problem that justified the company.

That trace can be tested through a simple chain:

• Target customer: who experiences the problem?
• Underserved need: what remains unresolved?
• Value proposition: what outcome changes?
• Feature set: what must the product do?
• UX: how does the customer reach the outcome?

When a feature cannot be connected to that chain, the team needs a reason to build it. Competitive pressure may justify it. Security may require it. Procurement may block the deal without it. But those are separate hypotheses. They should not be presented as proof of customer value.

Acquisition economics expose weak alignment

Growth teams often separate product and acquisition too early. They build a product, then buy traffic, then measure conversion. That process treats customer acquisition cost as a channel problem even when the underlying value proposition is unclear.

A customer acquisition model depends on more than traffic and conversion:

• The customer must recognize the problem.
• The message must describe a credible outcome.
• The product must deliver the outcome.
• The customer must retain the behavior.
• Gross margin must support the payback period.
• Expansion or renewal must support lifetime value.

If the first two PMF layers are weak, paid acquisition amplifies waste. More traffic produces more unqualified conversations. More sales activity produces more objections. More onboarding produces more churn.

This is why growth should not be defined as a volume target. Scaling a broken acquisition loop increases burn multiple.

The same discipline applies to market expansion. Entering a new country or vertical changes the target customer, the underserved need, the buying process, and often the product requirements. Translation is not validation. A product-market fit claim in one segment does not transfer automatically to another.

Pricing is part of the product-market fit test

Pricing sits across the pyramid. It reflects the value proposition, affects the buyer, and changes adoption behavior.

A low price can hide weak value. Customers may try the product because the risk is low, then abandon it because the workflow does not matter. A high price can expose implementation friction before the product is ready. Neither result is self-explanatory.

The relevant test is whether price corresponds to the customer’s economic exposure and the delivered outcome.

For a B2B product, the team should understand:

• Which budget absorbs the purchase.
• Whether the buyer measures the promised outcome.
• How long procurement takes.
• What implementation costs the customer.
• Whether usage expands with account size.
• Whether the contract creates a credible path to renewal.

A pricing page cannot answer these questions. Customer behavior can.

For leaders who evaluate public-market growth through the same separation of operating drivers, dividend growth stock screens that distinguish yield from growth apply a similar discipline: one metric should not be used as a proxy for the whole economic case. Startup teams make the same error when they treat signups as proof of product-market fit.

Iterative scaling: moving beyond initial product-market fit

Initial product-market fit is not a permanent status. It is a relationship between a product and a defined market under specific conditions.

Change the customer, channel, price, geography, use case, or competitive environment and the relationship must be tested again.

Scaling introduces new failure modes:

• The original customer segment is exhausted.
• New customers have lower pain intensity.
• Sales hires target accounts outside the validated segment.
• Product teams add features for larger accounts and increase complexity for the core user.
• Support costs rise faster than revenue.
• Infrastructure creates latency or reliability limits.
• Retention falls as acquisition expands beyond the initial wedge.
• The sales pipeline becomes dependent on discounts.

The correct response is not to declare that product-market fit has disappeared. The correct response is to locate the layer that changed.

Scaling the target customer

The first customer segment often gives the company a narrow entry point. Expansion should move to adjacent customers with similar needs, not to a broad market selected for presentation purposes.

A practical adjacency test looks at:

• Similar workflow.
• Similar problem frequency.
• Similar buyer.
• Similar implementation requirements.
• Similar willingness to pay.
• Similar retention drivers.

If several of these variables change at once, the company is not scaling the same product-market fit. It is testing a new one.

Scaling the feature set

Feature requests accumulate after early adoption. Some represent genuine market pull. Others reflect the internal priorities of a single large account.

The product team should separate:

• Features that increase usage of the core workflow.
• Features that improve retention for the validated segment.
• Features required for security or compliance.
• Features that open a new segment.
• Features that serve one account without repeatable demand.

The fourth category may be worth building. It should be labeled as expansion, not hidden inside the core roadmap. Otherwise, the company loses the ability to see which investment is maintaining current PMF and which is funding a new bet.

Scaling the acquisition engine

The acquisition system should be built around the validated value proposition. Channel expansion comes after message and segment fit.

The main metrics are not vanity counts. They are operating ratios:

• Customer acquisition cost by segment and channel.
• Gross-margin payback.
• Conversion by stage.
• Sales cycle length.
• Activation rate.
• Retention by cohort.
• Expansion revenue.
• Churn by customer type.
• Burn multiple during growth investment.

A channel with low acquisition cost but weak retention is not efficient. A channel with high conversion but poor gross margin is not efficient. A high-growth segment with negative contribution economics is not automatically attractive.

The spreadsheet should show the mechanism. The narrative should not replace it.

A practical test sequence for founders and product leaders

The pyramid becomes useful when translated into operating decisions. A team preparing an MVP can use the following sequence without turning it into a ritual.

Start with the market definition

Write one target-customer statement that includes the operating context. Reject broad labels.

Then list the customer’s current alternatives. Include manual work, internal tools, spreadsheets, agencies, and the decision to do nothing. The incumbent is not always a software company.

Rank needs by economic pressure

Separate frequent inconvenience from costly failure. Ask what event causes the customer to search for a solution.

The strongest needs tend to have a trigger:

• A compliance deadline.
• A capacity limit.
• A revenue leak.
• A recurring reconciliation task.
• A service-level failure.
• A margin problem.
• A management reporting gap.

The trigger creates timing. Without timing, a need may remain interesting but unfunded.

Define one measurable outcome

A value proposition should make a claim that can be tested. It may concern time, error rate, conversion, throughput, cash visibility, or operating cost.

The team does not need perfect measurement on day one. It needs a baseline and a direction of change.

Build only the path to that outcome

Remove features that support hypothetical future segments. Remove features that exist because competitors have them. Remove features that make the demo look complete.

Retain the functions required to reach the outcome and to observe whether the customer reaches it.

Test behavior and economics together

A product can generate usage and still fail commercially. A buyer can sign a contract and still fail to adopt. The test needs both sides.

Track whether the customer:

• Completes the core workflow.
• Repeats it.
• Replaces an existing method.
• Accepts the implementation burden.
• Pays or commits budget.
• Produces measurable value.
• Continues after the initial trial.

The exact threshold depends on the business model. The logic does not.

Decide whether to move up, iterate, or stop

Each test should end with one of three decisions:

• Move up the pyramid because the current layer has evidence.
• Iterate because the problem is real but the product assumption failed.
• Stop because the market or need does not justify further capital.

This is where many teams fail. They treat every negative result as a design problem. Sometimes the correct answer is that the target customer does not care enough.

Final verdict: bottom-up for discovery, top-down for execution

The product market fit pyramid is a model for capital control.

Its five layers impose an order:

1. Define the target customer.

2. Identify the underserved need.

3. State the value proposition.

4. Limit the MVP feature set.

5. Test the user experience against customer behavior.

The two lower layers belong to the market. The three upper layers belong to the product. The product cannot compensate for a market that lacks urgency. The market cannot compensate for a product that fails in the customer’s workflow.

Bottom-up testing wins when the company is still deciding what to build and for whom. It lowers the cost of being wrong. It also creates cleaner evidence for customer acquisition, pricing, retention, and expansion.

Top-down testing wins after the market problem has survived validation. At that point, teams should test feature priority, workflow design, activation, latency, implementation, and retention. These are product execution questions.

The binary conclusion is clear:

Use bottom-up testing to discover product-market fit. Use top-down testing to improve and scale a validated product. Reversing that order turns engineering capacity into rework.