> For the complete documentation index, see [llms.txt](https://the-gtm-hq.gitbook.io/go-to-market-course/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://the-gtm-hq.gitbook.io/go-to-market-course/course/go-to-market-pmf-course/6.-designing-the-minimum-viable-offer.md).

# 6. Designing the Minimum Viable Offer

### Learning Objectives

By the end of this chapter you will be able to:

* Build a Minimum Viable Offer not a feature set and understand why that distinction changes everything
* Apply the 5 principles of a strong offer to your current product or service
* Map the customer journey from current state to desired state and identify where your offer intervenes
* Use 80/20 logic to strip non-essential elements without weakening the core promise
* Define exactly what to include and what to cut from your version 1

### Introduction

The phrase Minimum Viable Product has become one of the most misunderstood concepts in startup culture. For many founders, MVP means a stripped-down version of the full product fewer features, rougher edges, something to ship quickly so you can start collecting feedback. That interpretation leads to a specific and costly mistake: building a product that is technically functional but commercially incomplete.

A product can work perfectly and still fail to sell. It can demonstrate impressive engineering and still not convert a prospect into a customer. The reason is almost always the same: the product was designed without enough attention to the offer the complete package of what the customer is actually buying, including the promise, the delivery mechanism, the risk reversal, and the clarity of the outcome.

This chapter reframes the MVP as a Minimum Viable Offer the smallest, simplest version of your solution that delivers real, measurable value to a real customer and generates the evidence you need to make confident GTM decisions. The shift from "product thinking" to "offer thinking" changes what you build, how you scope it, and how quickly you can get market feedback. By the end of this chapter, you will have a clear picture of what your version 1 needs to include and everything it needs to leave out.

### Why MVP Means Offer First, Product Second

A product is what you build. An offer is what you sell. These are not the same thing.

Consider what a customer actually evaluates when they decide to buy. They are not evaluating your code, your design system, or your feature roadmap. They are evaluating whether the combination of your promise, your delivery, your price, and your risk profile is compelling enough to justify changing their current behaviour. That combination is the offer and it has components beyond the product itself.

A complete offer has five components:

| **THE 5 COMPONENTS OF A COMPLETE OFFER**                                                                                                                                                                                  |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1. **The promise.** A specific, credible claim about the outcome the customer will achieve. Not a feature description a result. Tied to a timeframe and a customer segment.                                               |
| 2. **The delivery mechanism.** How the outcome will be produced. Is it software, a service, a course, a done-for-you process, a combination? The delivery mechanism needs to match the customer's context and capability. |
| 3. **The proof.** Evidence that the promise is achievable. Case studies, testimonials, demo results, or beta outcomes. Without proof, a promise is just a claim.                                                          |
| 4. **The risk reversal.** What happens if it does not work? A guarantee, a free trial, a phased payment, a refund policy. Removing the customer's risk of being wrong is often what converts a maybe into a yes.          |
| 5. **The price and terms.** How much, when, and under what conditions. Pricing is part of the offer not an afterthought attached to the product.                                                                          |

Your MVP is viable when all five components are present and coherent. It is not when the product reaches a certain feature count. 

A founder who has a clear promise, a working delivery mechanism, one piece of proof, a simple risk reversal, and a fair price has a viable offer. 

A founder who has built a sophisticated product but cannot articulate any of the five components clearly does not.

This reframe has a practical implication for scoping: before writing a single line of code or creating a single piece of content, map out all five components of your offer. The gaps you find will tell you more about what your MVP needs than any feature prioritisation exercise.

### The 5 Principles of a Good MVP Offer

Not all minimal offers are equal. An MVP offer that is too minimal fails to produce real customer evidence. One that is too broad fails to generate the focused feedback you need to iterate effectively. The five principles below define the boundaries of a good MVP offer, It describes the conditions that make it genuinely viable without making it unnecessarily complex.<br>

1. **Solves one problem completely.** Your MVP must solve one problem completely not five problems partially. The temptation to build in multiple use cases, serve multiple segments, or address multiple pain points simultaneously is almost universal in early-stage founders. Resist it. A single problem solved fully and reliably is more valuable, more marketable, and more learnable than a broad solution that partially addresses many things.<br>
2. **Delivers an observable result quickly.** The MVP must produce a result the customer can see, feel, or measure without significant effort on their part. If the customer has to work hard to perceive the value to interpret data, to adjust their workflow significantly, or to wait weeks for any visible change the feedback loop is broken. The result needs to be observable within the first use or the first session.<br>
3. **Repeatable without heroic effort.** Repeatability means the same result can be produced for different customers in the same segment without starting from scratch each time. An MVP that works only once through heroic founder effort is not viable. You need a delivery process however simple that can be repeated without significant variation in quality or time.<br>
4. **Creates a clear before-and-after.** Your MVP must create a meaningful before-and-after for the customer. Before they used your product, something was worse, slower, more expensive, or more risky. After they used it, that thing improved in a specific, describable way. If you cannot articulate the before-and-after clearly, neither you or can your customers and that means they cannot refer you  .<br>
5. **Iterative feedback.** Iterative means the MVP can be improved based on customer feedback without requiring a full rebuild. You are not trying to ship the final version. You are trying to ship the first version that generates real signal. Build for learning, not for permanence. Every architectural and design decision at the MVP stage should be evaluated against one question: will this make it easier or harder to change based on what we learn?

### Moving Customers From Current State to Desired State

Every customer who buys from you is trying to move from a current state, where they are now, with all its frustrations and limitations to a desired state, where they want to be, with the problem solved and the outcome achieved. Your offer is the bridge between those two states. Understanding both states precisely is what allows you to design a bridge that customers will actually use.

The current state is defined by:

* What the customer is doing right now to manage the problem their existing workaround, tool, or process
* What that workaround costs them in time, money, effort or frustration
* What they believe is possible their ceiling of expectation before they encountered your solution
* What is stopping them from solving it themselves the gap between their current capability and the desired outcome<br>

The desired state is defined by:

* The specific outcome they want to achieve, not a feature, a result
* The timeframe in which they want to achieve it urgency shapes what they will pay and how quickly they will act
* The secondary benefits they expect status, confidence, reduced stress, team alignment
* What 'done' looks like how they will know the problem is solved

Your MVP offer needs to address both states explicitly.&#x20;

The promise addresses the desired state: this is where you are going and when you will get there.&#x20;

The delivery mechanism addresses the current state: this is what we will replace, simplify, or eliminate to get you there.&#x20;

The gap between those two states is where your offer lives and the narrower and more specific that gap, the more compelling the offer.

### How to Simplify Without Weakening the Offer

The goal of the MVO exercise is to remove everything that does not directly contribute to the core customer outcome not to make the product worse. Done well, simplification makes the offer stronger by making it clearer, faster to value, and easier to explain.

The 80/20 rule applies directly here: in most offers, 20% of the features or components produce 80% of the customer value. The discipline of MVO design is identifying that 20% and building version 1 around it while cutting the 80% that feels important but is not essential to the first customer result.

Here is a practical framework for deciding what stays and what goes:

| **THE MVO (minimum viable offer) FRAMEWORK**                                                                                                                            |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Question 1: Does this feature or component directly contribute to the core customer outcome promised in the value proposition?                                          |
| <p>If yes, keep. <br>If no, defer.</p>                                                                                                                                  |
| Question 2: Would a customer notice if this was missing in the first 30 days of use?                                                                                    |
| <p>If yes, keep. <br>If no, defer.</p>                                                                                                                                  |
| Question 3: Does the absence of this feature block the customer from reaching the before-and-after result?                                                              |
| <p>If yes, keep. <br>If no, defer.</p>                                                                                                                                  |
| Anything that fails all three questions does not belong in version 1. Build a backlog for it, but do not let it delay or complicate the offer you are taking to market. |

### What to Include and What to Cut From Version 1

The final lesson in this chapter is the most practical: a concrete guide to what belongs in your version 1 and what does not. This is not a universal rule every product and market is different but the patterns below hold across a wide range of early-stage B2B and B2C offers.

| Include in version 1                                                 | Defer to version 2+                                         |
| -------------------------------------------------------------------- | ----------------------------------------------------------- |
| The single core workflow that produces the promised outcome          | Secondary workflows that serve edge cases or advanced users |
| Onboarding that gets the customer to first value in one session      | Advanced customisation and configuration options            |
| The minimum reporting or feedback that shows the customer the result | Comprehensive analytics, dashboards, and exports            |
| One reliable integration with the tool the customer uses most        | Full integration library and API access                     |
| Basic support email or chat with a human response                    | Self-serve knowledge base and automated support flows       |
| Simple, clear pricing with one or two options                        | Complex tier structures, add-ons, and enterprise pricing    |
| A clear mechanism for collecting customer feedback                   | In-app NPS surveys, automated feedback sequences            |

The test for every inclusion decision is this: without this, can the customer still achieve the outcome we promised? If yes, defer it. If no, it stays. This question is harder to answer honestly than it looks especially for founders who have invested time building a particular feature. The honest answer requires you to separate what you want the product to be from what the customer actually needs to get their first result.

One final principle for version 1: over-invest in the delivery experience, not the feature set. A smaller, simpler product with exceptional onboarding, clear communication, and fast support will outperform a feature-rich product with a confusing setup and slow responses every single time at the early stage. The experience of buying and using is part of the offer. Treat it with the same deliberateness as the product itself.

### Case Example

| **IRONCLAD :: PROOF THAT PRIMITIVE CAN BE VIABLE**                                                                                                                                                                                                                                                                                                                                                                                                |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Ironclad is a contract management platform used by some of the world's largest companies, including Salesforce, Dropbox, and L'Oreal. Today it is a sophisticated, enterprise-grade product. In the beginning, it was not.                                                                                                                                                                                                                        |
| Ironclad's early MVP was, by any technical standard, primitive. It was a simple workflow tool that allowed legal teams to route contracts for approval without emailing PDFs back and forth. There was no AI, no advanced analytics, no complex integrations. There was a problem legal teams were drowning in manual contract processes a simple delivery mechanism, and a clear before-and-after: contracts approved in hours instead of weeks. |
| What made the MVP viable was not sophistication. It was specificity. The offer was designed for one customer type, in-house legal teams at growth-stage companies, solving one specific problem, contract approval bottlenecks, with a delivery mechanism that was just good enough to produce the result. The promise was clear. The before-and-after was observable. The first customers could see the outcome within their first week of use.  |
| Ironclad did not try to build contract generation, e-signature, or analytics into version 1. Those came later after the core offer had been validated, after customer evidence was strong, and after the team understood clearly what their market valued most. The sophistication of the product today is built on the discipline of the offer in the beginning.                                                                                 |
| The lesson: your version 1 does not need to be impressive. It needs to be specific, repeatable, and honest. Impressive comes after viable. Viable comes first.                                                                                                                                                                                                                                                                                    |

### Do This Before Moving To Chapter 07

| **Step 1.**  Write a one-paragraph description of your MVP offer. It must include: who it is for, what problem it solves, what the outcome is, how it is delivered, and what happens if it does not work. If any element is missing, your offer is incomplete.                                            |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Step 2.**  Map your customer's current state and desired state. For the current state: what are they doing now, what does it cost them, and what is stopping them from solving it themselves? For the desired state: what specific result do they want, by when, and how will they know it is achieved? |
| **Step 3.**  Apply the MVO Framework to every feature or component in your current build. Run the three questions for each one. Anything that fails all three goes to the backlog. Be honest. This is the exercise most founders avoid.                                                                   |
| **Step 4**.  Write a version 1 scope document — two columns: Include and Defer. Share it with one customer or prospect and ask: would the included elements be enough for you to see real value in the first 30 days? Their answer is the most important feedback you will get this week.                 |

#### Key Takeaways <a href="#key-takeaways" id="key-takeaways"></a>

* A product is what you build. An offer is what you sell. Your MVP is viable when all five offer components are present, promise, delivery, proof, risk reversal, and price not when the product reaches a feature count.
* The 5 principles of a good MVP offer: solves one problem completely, delivers an observable result quickly, is repeatable without heroic effort, creates a clear before-and-after, and is iterative based on feedback.
* Every customer is trying to move from a current state to a desired state. Your offer is the bridge. The current state tells you what to replace. The desired state tells you what to promise.
* Simplifying an offer is not weakening it. The MVO Framework helps you remove what is not essential without compromising the core customer outcome.
* Over-invest in the delivery experience at version 1. A smaller product with exceptional onboarding and fast support outperforms a feature-rich product with a poor first-use experience every time in the early stage.

### What is Next&#x20;

In Chapter 07, we tackle the message, the language, you use to bring your offer to market. You now have a niche, a problem, a value proposition, and a minimum viable offer.&#x20;

The next challenge is translating all of that into a single, clear, testable marketing message that resonates with your target segment across every channel you use.&#x20;


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://the-gtm-hq.gitbook.io/go-to-market-course/course/go-to-market-pmf-course/6.-designing-the-minimum-viable-offer.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.