Key Takeaways

• A pre-launch demo, meaning any demo that shows functionality a buyer cannot use today, is one of the most common demos in B2B and the least governed one.
• Slides undersell an unbuilt product, static prototypes look unfinished, and verbal “coming soon” promises overcommit, because none of them separates what exists from what is intended.
• Every screen in a pre-launch demo should carry one of three labels: shipped, designed, or directional. Each label carries a different commitment.
• Buyers now check vendor claims against several sources and often run them through AI, so a roadmap promise made on a call gets quoted back later as fact.
• A pre-launch demo is a commitment, not a pitch. Product, sales, and legal should agree on what it promises before it reaches a buyer.
• The demo has to keep moving with the design. A roadmap demo that drifts from the current plan is worse than no demo at all.

A pre-launch demo is a promise. Most teams run it like a pitch, and the gap between those two things is where roadmap deals go wrong.

Every B2B company sells something that does not fully exist yet. A launch that is six weeks out. A design partner who needs to see the workflow before they commit engineering time. An enterprise deal that turns on a capability scheduled for next quarter. Some of the most important demos a company runs show screens a buyer cannot use today.

Yet the pre-launch demo gets less discipline than any other demo in the motion. Discovery has a playbook and the proposal has a review. The roadmap section is usually an AE improvising over a slide. This post covers why that fails and how to run a pre-launch demo that sells the future without writing checks the product team cannot cash.

Why Is the Pre-Launch Demo So Hard to Get Right?

The pre-launch demo has two jobs that pull in opposite directions. It has to make an unbuilt product feel real enough that the buyer can picture using it. It also has to stay honest enough that nobody mistakes intent for delivery.

Most teams pick one job and drop the other. Marketing-led launches make the product look finished, and the buyer believes they can log in on Monday. Product-led roadmap reviews state every caveat over wireframes, and the buyer leaves unsure the feature will ever ship.

Neither outcome helps the deal. The first creates a trust problem at implementation. The second creates a confidence problem at signature. The goal is a demo that does both jobs at once, and that requires structure, not improvisation.

The three default formats, and why each one fails

Teams tend to fall back on one of three formats when the product is not ready.

• The slide. Safe, fast, and approved. It also undersells. A buyer cannot click a slide, so they cannot picture their own workflow inside it, and the feature competes on adjectives.
• The static prototype. Closer to the real thing, but it reads as a prototype. Buttons do nothing, the data is placeholder text, and the buyer is asked to imagine the parts that matter most.
• The verbal promise. “That’s coming in Q2.” It costs nothing to say and costs a great deal to break. It is also the one format nobody reviews.

All three fail for the same reason. None of them tells the buyer, clearly and screen by screen, what exists today and what does not.

What Does a Buyer Actually Need From a Pre-Launch Demo?

A buyer watching a pre-launch demo is trying to answer three questions. Will this solve my problem? Will it exist when I need it? Can I trust what this vendor is telling me?

The first question is answered by experience. The buyer needs to see the intended workflow in enough detail to map it onto their own process. That means real screens, realistic data, and a path they can click through rather than a description they have to imagine. Our guide to building a clickable demo buyers actually finish covers why interaction beats narration for comprehension.

The second question is answered by labeling. The buyer needs to know which parts are live, which are designed and scheduled, and which are still a direction the team is exploring. Without that, every screen carries the same implied commitment, and the buyer has no way to price the risk.

The third question is answered by consistency. Buyers no longer take a vendor’s word in isolation. According to Gartner’s survey of 645 B2B buyers, buyers used an average of seven information sources in a recent purchase, and 45% used generative AI during the process (Gartner, B2B Buyer Survey, 2026). Your roadmap claim will be compared against your website, your documentation, analyst coverage, peer reviews, and whatever an AI assistant summarizes from all of it.

If the demo says one thing and the documentation says another, the buyer does not split the difference. They discount everything.

The Shipped, Designed, Directional Framework

The single most useful change a team can make to its pre-launch demo is to label every screen. Three labels cover almost every case, and each carries a different level of commitment.

Shipped

The functionality exists, it is generally available, and a customer could use it today. Shipped screens are captured from the live product, and the AE can make firm statements about them. If the buyer signs tomorrow, this is what they get.

Shipped screens anchor the demo. They prove the vendor delivers, which makes everything after them more credible.

Designed

The functionality is designed, scoped, and scheduled. The screens come from the actual design files the engineering team is building against, not from a marketing mockup. The timeline is the product team’s current plan, and the AE states it as a plan, not a promise.

Designed screens are where the pre-launch demo does most of its work. They should look and behave like the product will. A buyer should be able to click through the intended workflow and react to it. That reaction is valuable to the product team as well as the deal.

Directional

The functionality is a direction the company intends to pursue, without a final design or a committed date. Directional content shows strategy, not product. It belongs in a short, clearly marked section near the end, and it should never be the reason a deal closes.

The discipline is simple to state and hard to hold. Nothing directional gets presented as designed, and nothing designed gets presented as shipped. Most broken roadmap promises start as a directional idea that was described with designed-level confidence on a call.

How to show the labels without killing momentum

Labels do not need to be heavy. A small tag on each screen, a one-line guide note (“Designed, scheduled for Q1”), or a visual divider between sections is enough. The point is that the buyer can see the boundary, and so can anyone they forward the demo to.

The champion who forwards your demo to their CFO will not be there to explain which parts are real. As we covered in our piece on what makes a product demo memorable, the demo has to travel. A pre-launch demo has to travel with its labels attached.

How Do You Make Unbuilt Screens Feel Real Without Faking Them?

The case for showing designed screens in a clickable form is strong. Buyers comprehend workflows by doing them, and design partners give far better feedback on an experience they can navigate than on a static image. The risk is that a polished, clickable screen implies it is finished.

The answer is fidelity to the plan, not fidelity to a fantasy. The designed screens in your demo should be built from the same design files engineering is working from. If the shipped feature will have three filter options, the demo shows three, not the seven that looked better in a launch deck. If the data model has not been settled, the demo uses data shapes the team is confident about.

This is where the source of the screens matters. Teams that rebuild unbuilt features as marketing mockups create a second version of the product that nobody maintains. Teams that build the demo straight from the working design keep one source of truth.

Walnut approaches this by letting teams combine captured screens from the live product with designed screens in a single demo, so the shipped and designed sections sit side by side in one experience that a buyer can click through end to end. Our walkthrough on how to create a demo that actually converts covers how to sequence those sections around the buyer’s problem.

Tie every future screen to a buyer problem

A designed screen earns its place in the demo only if it answers a problem the buyer has already named. “Here is what’s coming” is a feature tour. “You mentioned approvals take four days. Here is the approval flow we are building, scheduled for Q1” is a pre-launch demo.

This keeps the roadmap section short, since most of the roadmap is irrelevant to any single buyer. It also tells the product team which future capabilities are pulling deals.

Why Do Roadmap Promises Become Contract Problems?

A roadmap promise rarely stays on the call. It goes into the AE’s notes, the champion’s internal business case, and frequently the buyer’s procurement questions. In larger deals it can appear in the contract as a delivery commitment, a termination right, or a price concession tied to a date.

When that happens, a sentence an AE said under pressure becomes a legal obligation that product, finance, and customer success have to absorb. The product team may not have known the promise was made. The date may already have moved.

The cost of a broken roadmap promise lands at renewal, not at signature. The deal closes, the feature slips, and the customer’s first year is shaped by a commitment the vendor did not deliver. That is the account most likely to churn and least likely to give a reference.

Buyers are checking

Buyers are not passive about this. Gartner found that 69% of B2B buyers turn to a sales rep specifically to validate insights they gathered from AI and other sources (Gartner, 2026). The rep is the audit step. When the rep’s roadmap claims do not match what the buyer found elsewhere, the audit fails, and the vendor loses credibility on everything else too, including the claims that were true.

This is the core argument for treating the pre-launch demo as a trust asset. Our post on why interactive demos are the B2B trust asset that still works makes the broader case. In a pre-launch context the stakes are higher, because the buyer cannot verify the product themselves. They can only verify you.

How Should Product, Sales, and Legal Govern a Pre-Launch Demo?

If a pre-launch demo is a commitment, it needs owners. The teams that do this well treat it as a shared artifact with clear sign-off, not as something each AE assembles on their own.

A workable governance model has four parts.

• Product owns the labels. Product decides what is shipped, designed, or directional, and updates those labels when plans change. Sales does not upgrade a label to win a deal.
• Sales owns the narrative. Sales decides which designed screens are relevant to which buyers and how they connect to the buyer’s stated problems.
• Legal and deal desk own the language. There is an approved way to describe timelines (“currently planned for,” never “will be available on”), and a clear rule on when a roadmap item can appear in a contract.
• One demo, not fifty. There is a single approved pre-launch demo per launch, maintained centrally, that AEs personalize but do not rebuild.

The last point does the most work. When every AE builds their own roadmap demo, each version drifts in its own direction, and a label change in product never reaches the buyer.

Keep it moving with the design

Designs change. Scope gets cut, flows get simplified, a feature moves a quarter. A pre-launch demo built in August can be wrong by October, and nobody notices, because the demo that was approved is still the demo that gets sent.

Treat the pre-launch demo like the design file it came from. When the design moves, the demo moves. When a label changes, the demo changes the same day.

This is the practical reason to build designed screens directly from the source design rather than recreating them. Walnut’s Figma import brings frames into a demo as fully editable screens, so teams can add guides, annotations, and personalization on top. When the design changes in Figma, the imported screens can be refreshed while keeping the edits and guides already added. The roadmap section stays current without anyone rebuilding it by hand.

What Changes When Buyers Use AI to Research Your Roadmap?

There is one more reason discipline matters now. The buyer’s AI assistant is reading your materials, and it does not preserve nuance.

A careful AE might say, “This is designed and currently planned for the first quarter, though dates can move.” A buyer who pastes call notes or a forwarded demo into an AI tool may get back a summary that says, “Feature launches Q1.” The caveat does not survive the compression. The claim does.

That has a practical implication. Labels should be explicit and attached to the screen itself, not spoken around it. A visible “Designed, planned for Q1” tag survives summarization better than a verbal hedge, because it is part of the content rather than part of the delivery.

AI summaries flatten tone and keep assertions. If a pre-launch demo contains a claim you would not want quoted back at renewal, remove it.

Where AI helps, and where it does not

AI is genuinely useful in building a pre-launch demo. It can draft guide copy for designed screens, adapt the narrative for a specific persona, and generate realistic sample data in minutes instead of hours. That speed matters during a launch, when the demo needs to exist before the product does.

What AI cannot do is decide what the company is willing to promise. Which screens are designed and which are directional, which timelines are firm enough to state, which buyer problems justify showing unbuilt work. Those are judgment calls that belong to people who know the plan and will answer for it.

A Pre-Launch Demo Checklist

Before a pre-launch demo reaches a buyer, it should pass these checks.

• Every screen carries a shipped, designed, or directional label, and the labels are visible in the demo itself.
• Designed screens are built from the current design files, not from a marketing mockup.
• The demo opens on shipped functionality before it shows anything unbuilt.
• Each designed screen maps to a problem this buyer has named.
• Directional content sits in a short, clearly marked final section.
• Timeline language matches the approved phrasing from legal or deal desk.
• Product has signed off on the labels within the last two weeks.
• There is one maintained version, and every AE sends that version.

A team that holds to this list will show less of the roadmap than it used to. It will also close roadmap deals that stay closed.

Frequently Asked Questions

What is a pre-launch demo?

A pre-launch demo is any product demo that shows functionality a buyer cannot use today, such as an upcoming launch, a scheduled roadmap feature, or a design-partner preview. It differs from a standard demo because it combines shipped functionality with designed or planned functionality, and each part carries a different level of commitment.

How do I demo a product that isn’t built yet?

Build the unbuilt screens from the actual design files engineering is working from, make them clickable so the buyer can follow the intended workflow, and label every screen as shipped, designed, or directional. Open with shipped functionality to establish credibility, connect each designed screen to a problem the buyer has named, and keep directional ideas in a short final section.

Should I show roadmap features in a sales demo?

Show roadmap features only when they answer a problem the buyer has explicitly raised, and only with clear labeling. Showing the full roadmap turns the demo into a feature tour and multiplies the number of promises the sales team has to keep. A short, relevant roadmap section is more persuasive and much lower risk.

What’s the difference between a prototype and a pre-launch demo?

A prototype is a design tool used to test an idea internally or with users. A pre-launch demo is a sales asset that presents the intended product to a buyer, with explicit labels on what is shipped, designed, and directional. A prototype can be the source of a pre-launch demo’s designed screens, but it needs labeling, narrative, and governance before it is ready for a buyer.

How do I avoid overpromising on product roadmap in sales?

Separate shipped, designed, and directional functionality visibly in the demo, agree approved timeline language with legal or deal desk, and let product own the labels so sales cannot upgrade them under deal pressure. Use one centrally maintained pre-launch demo instead of letting each rep build their own, so label changes reach every conversation.

Can roadmap promises end up in a B2B contract?

Yes. In larger deals, roadmap commitments often appear as delivery dates, termination rights, or price concessions tied to a feature shipping. That is why roadmap language in a demo should be reviewed with the same care as contract language, and why a pre-launch demo should never imply a commitment the product team has not made.

Ready to see what a pre-launch demo looks like when every screen is real and every label is clear? Start for free with Walnut.