> 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/10.-delivery-retention-and-making-the-offer-stick.md). # 10. Delivery, Retention and Making the Offer Stick ### Learning Objectives By the end of this chapter you will be able to: * Understand why delivery is a PMF function not a post-sale operational task. * Choose the right delivery model for your current offer and market context. * Design a fulfilment system that produces repeatable, observable customer outcomes * Identify at which step in your delivery customers see their first result and restructure if needed. * Know when and how to introduce a back-end offer without disrupting the primary customer relationship. ### Introduction Most GTM frameworks treat delivery as a post-sale concern something that happens after the marketing and sales work is done. This is a costly framing error. Delivery is not downstream of GTM. It is part of it. How you deliver your offer determines whether customers stay long enough to become proof, whether they refer others, and whether the outcome you promised in your value proposition actually materialises in a way the customer can see and feel. At the early PMF stage, delivery has three jobs that are inseparable from your GTM motion. First, it produces the customer outcome that your value proposition promised without which everything else collapses. Second, it generates the social proof, testimonials, case studies, referrals that makes your next acquisition cycle easier and cheaper. Third, it reveals the gaps in your offer that no amount of customer discovery work will surface until a real customer tries to use what you built in their real context. This chapter covers how to choose the right delivery model for your offer, how to design a fulfilment system that gets customers to their first visible result as quickly as possible, how to build the habits and checkpoints that drive retention, and how to sequence your back-end offer so it feels like a natural next step rather than an upsell. ### Why Delivery Is Part of PMF, Not Post-PMF The standard mental model of a business separates acquisition from delivery: marketing and sales bring in the customer, operations delivers the product, and customer success manages the relationship. This model makes sense at scale. At the early PMF stage, it is actively harmful because it creates a false boundary between what you learn before the sale and what you learn after it. The most important PMF signal often arrives during delivery not during the sales process. It arrives when a real customer tries to use your product in their real environment and you discover that the problem you were solving was slightly different from the problem they actually had, that the outcome you promised required a prerequisite they did not have, or that the delivery mechanism created friction you had not anticipated. These discoveries are not failures. They are the most valuable data in your PMF journey. But you only get them if delivery is treated as an active learning process, not a passive operational routine. Three specific PMF insights that only delivery reveals: * The gap between the promised outcome and the experienced outcome. The customer bought the promise. Delivery tells you whether the product actually closes the gap between their current state and desired state or whether the gap is different from what you assumed in your messaging. * The real time to first value. Your messaging probably states a timeframe. Delivery tells you whether that timeframe is accurate, and at which point in the delivery process the customer actually starts experiencing value. If the real time to first value is significantly longer than the promised timeframe, that is a positioning and delivery design problem. * The friction points that drive churn. Customers rarely tell you why they are about to leave. They just go quiet and then cancel. Active delivery monitoring, check-ins, usage data, milestone tracking surfaces the friction points before they become churn events. Each friction point is a delivery design problem that is also a PMF insight. The implication for solo founders: treat your first ten customers not as revenue, but as a paid discovery cohort. The insights you gather from their delivery experience are worth significantly more than the income and they will shape every GTM decision you make for the next six months. ### Choosing the Right Delivery Model The delivery model is the mechanism through which your customer achieves the outcome you promised. It determines how much of the work the customer does versus how much you do, how quickly they reach their first result, and how scalable your fulfilment is as you grow. Choosing the wrong delivery model for your current stage creates friction in the customer experience and operational un-sustainability for you as the founder. The three primary delivery models for early-stage solo founders are:
Delivery modelWhen it works and what to watch for

Done-for-you (DFY)

You do the work on behalf of the customer. They receive a finished output: a strategy document, a configured system, a set of assets, a research report.

Works best when: the customer lacks the time, skill, or context to do the work themselves and the outcome is clear and transferable. Watch for: scope creep, dependency, and low scalability. DFY builds proof fast but does not scale without systems or team.

Done-with-you (DWY)

You guide the customer through a process they execute themselves, with your support and expertise alongside them. Coaching, consulting, intensive workshops.

Works best when: the customer needs to develop capability, not just receive an output. Produces stronger retention than DFY because the customer owns the result. Watch for: inconsistent customer effort and variable outcome quality depending on their execution.

Do-it-yourself (DIY)

The customer uses your product, tool, framework, or course to achieve the outcome independently, at their own pace.

Works best when: the process is clear, the customer is motivated and capable, and the outcome is achievable without significant guidance. Watch for: low completion rates, slow time to first value, and high churn from customers who do not engage deeply enough.
At the early PMF stage, DFY and DWY models produce faster proof and better early learning because you are close to the customer throughout the delivery process. DIY models produce faster scale but slower learning and higher early churn. The recommendation for most solo founders at pre-traction stage: start with DFY or DWY for your first ten customers, use what you learn to systematise delivery, and then introduce a DIY option once the outcome is reliable and the process is documented. ### How Delivery Affects Customer Success At the early stage, customer success is the delivery discipline you build into the fulfilment process that maximise the probability that the customer achieves the outcome they paid for. It is not customer support, which is reactive. It is not account management, which is relationship-focused. It is proactive, outcome-oriented delivery design. There are four delivery practices that most consistently predict customer success and retention at the early stage:
1. Engineer the first win early. The first win is the most important moment in any customer relationship. It is the point at which the customer experiences tangible evidence that your product is delivering on its promise. Everything before the first win is faith the customer is hoping the decision to buy was correct. Everything after the first win is momentum they have evidence it was. Design your delivery explicitly around producing the first win as early as possible. In most offers, the first win can be delivered within the first session or the first week if the delivery process is designed deliberately for it.
2. Build milestone tracking into delivery. Most customers who are about to churn do not announce it. They go quiet. They miss check-ins. They stop engaging with the product or process. A proactive milestone tracking system, a simple set of checkpoints that the customer is expected to reach at defined intervals, makes disengagement visible before it becomes irreversible. When a customer misses a milestone, that is your trigger to reach out, not a reason to wait.
3. Collect feedback mid-delivery, not just at the end. The most underused retention tool in early-stage businesses is structured feedback collection, not a survey at the end of the engagement, but a mid-delivery conversation that surfaces problems while you can still fix them. A simple question at the halfway point, 'what is working well and what is creating friction?' generates more useful retention intelligence than any post-churn analysis.
4. Maintain outcome certainty throughout. Every interaction the customer has with your delivery, every email, every deliverable, every check-in either increases or decreases the certainty they feel that the promised outcome is on track. Certainty maintenance is the job of delivery communication. Be specific, be proactive, and always connect the current moment in the delivery to the promised outcome. Never let the customer feel uncertain about where they are in the process. ### Making Your Offer Sticky Stickiness is the quality that makes a customer's decision to stay feel more obvious than their decision to leave. Locking customers in through contracts or technical barriers produces resentment, not retention. True stickiness comes from three sources: habit integration, switching cost built on value, and relationship depth. Habit integration means your product or process becomes embedded in how the customer works on a daily or weekly basis. The product is not something they use when they remember to, it is part of a workflow they would have to actively redesign to remove. Habit integration is the strongest form of stickiness because it is entirely value-driven. The customer stays because the product is woven into how they get results, not because leaving is difficult. To build habit integration deliberately: * Identify the natural workflow trigger that precedes the problem your product solves. Design your onboarding to connect your product to that trigger from day one. * Reduce the activation energy required to use the product. Every barrier to opening, loading, or starting a session is a place where the habit can break. Minimise friction at the point of entry. * Build visible progress into the product experience. Customers who can see their progress -in a dashboard, a streak, a milestone counter are significantly more likely to maintain the habit than those who cannot. Switching cost built on value means the customer has invested enough time, data, and customisation into your product that moving to an alternative would require them to start from scratch on something they have already built. This is not artificial friction it is the natural result of a product that accumulates value over time. Data histories, customised workflows, trained models, and institutional knowledge stored in your system all create legitimate switching costs that reinforce retention. Relationship depth is the stickiest form of retention for service-oriented businesses. A customer who has a genuine relationship with you, who trusts your judgment, values your perspective, and feels that you understand their situation better than anyone else could without starting from scratch is not going to leave over a price comparison. Relationship depth is built through consistent, personalised, outcome-focused communication throughout the delivery process. ### When to Introduce a Back-End Offer The back-end offer is the natural next engagement for a customer who has completed your front-end offer and experienced the outcome. It is not an upsell in the traditional sense it is a logical extension of the relationship, designed around the next problem the customer will face once the first one is solved. The timing and design of the back-end offer are both critical. Introduce it too early and it feels like a premature pitch that breaks the trust you have been building. Introduce it too late and the customer finds an alternative solution in the gap. Design it around features rather than the customer's next outcome and it will feel like a product sale rather than a natural progression. | **THE BACK-END OFFER TIMING FRAMEWORK** | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Signal 1.** The customer has achieved the promised outcome from the front-end offer and can articulate it clearly. They can describe the before and after in specific terms. This is the earliest point at which the back-end conversation is appropriate. | | **Signal 2.** The customer has started asking about what comes next. Questions like 'what should we do now that this is working?' or 'how do I take this further?' are direct invitations to introduce the back-end offer. | | **Signal 3.** You can clearly identify the next problem the customer will face and it is a problem your back-end offer is designed to solve. The back-end offer should feel inevitable to the customer, not engineered by you. | | **The wrong time:** before the front-end outcome has been achieved. A customer who has not yet seen the result of what they paid for will experience any back-end conversation as premature and will disengage from both the primary offer and the expansion opportunity. | Structurally, the back-end offer should be designed as a natural escalation in scope, depth, or duration not a completely different product. The customer who completed a 30-day GTM audit should see the back-end offer as the obvious next step: a 90-day implementation, a monthly advisory retainer, or a done-for-you execution of the recommendations from the audit. The logic should feel so clear that the customer almost presents the back-end offer to themselves before you name it. One practical rule: never make the back-end offer in the same conversation in which you are celebrating the front-end result. Let the customer sit with the success for at least 24 to 48 hours before introducing the next conversation. This respects the moment and avoids the impression that every outcome is just a gateway to another sale. ### Case Example | **SLACK :: STICKINESS BAKED INTO DELIVERY FROM DAY ONE** | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Slack's extraordinary retention numbers among the highest in SaaS history at the time of its growth phase were not the result of a customer success team or a sophisticated churn-prevention programme. They were the result of a delivery design decision made at the product level from the very beginning: make the product the place where work happens, not a tool used alongside work. | | Every design decision in Slack's early product was oriented around habit integration. Notifications were designed to be informative enough to pull users back into the product without being so frequent they became noise. The channel structure mirrored how teams actually organised their work by project, by topic, by team so the product embedded itself into the existing mental model rather than requiring the team to adopt a new one. Search and history made the product a record of institutional knowledge, creating switching costs that were entirely value-driven. | | The delivery model was DIY teams set up Slack themselves but the design made the first win immediate and visible. Within the first session, a team could see all their relevant conversations in one place for the first time. That first win happened in minutes, not weeks. And because the first win was experienced collectively rather than individually, the habit formed at the team level making it almost impossible for any single person to abandon the product without disrupting their entire team's workflow. | | The lesson for solo founders building service or software offers: stickiness is a delivery design decision, not a retention programme you add later. Ask at the product or process design stage: where does the first win happen? How does the product embed itself into the customer's existing workflow? What does the customer accumulate over time that they would not want to lose? Answer those questions before you launch, not after your first wave of churn. | ### **Do This Before Moving To Chapter 11** | **Step 1.** Map your current delivery in five steps. Write down every major step from the moment a customer pays to the moment they achieve the promised outcome. At which step do they see their first result? If it is step 4 or 5, redesign so the first visible win happens by step 2. | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Step 2.** Identify the three milestone checkpoints in your delivery, the moments at which a customer should have completed a meaningful portion of the process. Write down what you will do if a customer misses any of these checkpoints. This is your early churn prevention system. | | **Step 3.** Write a mid-delivery check-in message for your current customers. Ask two questions only: what is working well, and what is creating friction? Send it this week. The answers will tell you more about your delivery gaps than any internal review. | | **Step 4.** Design your back-end offer that will the natural next engagement for a customer who completes your front-end. Write it as a logical extension of the front-end result, not a new product pitch. Identify the three signals from the timing framework that will tell you when to introduce it. | ### Key Takeways * Delivery is a PMF function, not a post-sale operation. The insights you gather from your first customers' delivery experience, outcome gaps, time to first value, friction points are the most valuable data in your early GTM. * Choose your delivery model based on your current stage: DFY and DWY produce faster proof and better learning. DIY produces faster scale but higher early churn. Start close to the customer, then systematise. * The four delivery practices that predict retention: engineer the first win early, build milestone tracking in from the start, collect feedback mid-delivery not just at the end, and maintain outcome certainty in every communication. * True stickiness comes from habit integration, value-driven switching costs, and relationship depth not from lock-in mechanisms. Design for stickiness at the delivery stage, not as a retrofit. * Introduce the back-end offer only after the front-end outcome has been achieved and the customer can articulate it. The back-end should feel inevitable a logical next step the customer almost identifies themselves. ### What is Next In Chapter 11, we bring the full GTM picture together by mapping the right marketing and sales strategies to each of the four PMF levels. Now that you have an offer, a message, a channel, and a delivery model, the question becomes: what GTM motion is appropriate for the stage you are actually at and how do you avoid the trap of running level 3 and 4 tactics when your PMF evidence only supports level 1 or 2? Chapter 11 gives you a clear, stage-matched GTM playbook. --- # 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/10.-delivery-retention-and-making-the-offer-stick.md?ask=&goal= ``` `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.