We’ve all seen it happen. A team spends months building something useful, then ships it in one of two ways: they either tell no one and hope adoption happens organically, or they trigger a company mobilisation, briefing sales before the feature is stable, setting customer expectations they can't yet meet.
The mistake isn't caring too little or too much about the launch but treating the launch as a binary decision, ship it or celebrate it, rather than a sequence. Most successful product releases follow a logical progression from internal testing through to full public commitment, and the stage at which you stop depends on what you've learned about four dimensions of risk: value, usability, viability, and feasibility. The more open risk you're carrying on those four dimensions, the earlier in the sequence you belong.
This playbook walks through that sequence: five stages, when to use each one, and what success looks like at every step.
Step 1: Always start with an internal launch
An internal launch means making the feature available inside your organisation (in your testing environments and sometimes in production) before customers see it. Its job is simple: give you one more opportunity to catch problems before they matter.
We've worked with product teams that skip this step to save time, and almost every one of them regrets it. Bugs that should have been caught in testing surface instead during client-facing demos. Messaging that looked fine in a product brief turns out to be confusing to the sales team who now have to explain it. Both are avoidable with an initial round of internal exposure.
Run it for two weeks. Brief your internal stakeholders through your primary communication channel, give everyone a structured way to log feedback, and set a clear deadline. Two weeks is almost always enough, longer than that, momentum drops, engagement drops, and the signal you get becomes less reliable.
The exception: For technical products like APIs, internal employees can rarely give you meaningful signal. If that’s your case, move directly to an early access programme with a small group of trusted clients instead.
Internal launch checklist:
- Communicate the launch through your main internal channel
- Time-box it
- Provide a structured feedback intake, use the dualoop internal launch template so signal stays comparable across releases
- Prioritise and action the feedback
- Close the loop with testers
- Get a clear go / no-go signal before proceeding
Step 2: Run an early access programme when your confidence is low
An early access programme, sometimes called a soft launch, means releasing to a carefully selected group of existing clients before going public. The group is typically small: ten to fifty users chosen because they fit a specific profile and are willing to give you feedback in exchange for early access to something new.
This step is optional. We want to be clear about that, because we see teams treat it as the default, and it shouldn't be. Running early access properly takes significant time and attention from the product manager.
There's a second risk that's less visible but just as damaging: leaving early access programmes open indefinitely. The result is a fragmented customer experience, different cohorts seeing different versions of the product, and no clear picture of who has access to what. Early access is a temporary state by design.
It is the right call when your confidence in the product is low on one or more of these four risk dimensions:
- Value : does the current version solve the problem at a level customers recognise, or do adjustments need to be made before broader release?
- Usability: will the workflow feel intuitive to your users without significant guidance or training?
- Viability: can we sustain this commercially (pricing, willingness to pay, unit economics, support load)?
- Feasibility: can we technically deliver and operate this at the scale we plan to release to (infrastructure, data, integrations, support and operational load)?
Three things determine whether an early access programme will be successful:
- Recruit carefully. Treat this exactly like recruiting for product discovery research: define the profile you're looking for, the company size and role, the current usage depth, and actively select participants. The same rigour that protects the validity of a discovery interview also protects the signal from an early access programme. A bulk email to your entire customer base yields self-selected enthusiasts instead of representative users; ten engaged early adopters give you more usable insight than a hundred passive ones.
- Stay close. Monitor usage behaviour, do not rely on survey responses alone. Follow up with users who haven't engaged, send personalised emails, get on calls. If you're not prepared to invest that level of attention, the programme won't generate a signal worth acting on. This is why we insist so much on the time you must invest in this programme to get you where you want to go.
- Keep it low profile. At this stage, you do not yet have confidence in your deliverable. Keep the Sales & Customer Success team out of it, they should be aware of what's going on, but the product manager should be on top of it. You should own all external communication. The goal is controlled learning, not visibility.
💡 Define one or two success metrics and set a firm deadline of one quarter. If you run the program correctly but miss your targets, the problem lies with the product, not the program. Extending the deadline once is fine if you're close to a breakthrough, but a second extension usually means you're avoiding the hard truth: the solution might not be the right one.
Early access checklist:
- Define your participant profile (company size, role, usage maturity)
- Choose and communicate your registration approach
- Create a single internal document as the source of truth for the programme, a product brief can do the work properly
- Define your communication cadence and feedback collection approach
- Monitor behaviour weekly, not just survey scores
- Set 1–2 success metrics with a clear decision deadline
- Make an explicit go / extend / kill decision at the end
Step 3: Use a minimal launch as your default
A minimal launch releases the feature to your entire customer base with minimal or no dedicated marketing and external communication effort. No press release, no campaign, no company-wide announcement.
In practice, most of your releases should look like this, and that's appropriate. The majority of product improvements don't warrant a public launch. They're incremental upgrades, requested fixes, or capability extensions that add real value without needing a dedicated go-to-market push. Treating every release as a marketing moment is one of the fastest ways to burn out your marketing team and dilute the signal from launches that matter.
The minimal launch is not passive, though. Minimal does not mean silent. Customer-facing teams, sales, customer success, and support must know exactly what is shipping, when, and why. How much briefing this needs depends on your organisation:
- In a small, high-trust team, sharing the product brief in advance is enough.
- In a complex organisation with multiple regions, customer segments, or commercial layers, you'll need more, alignment meetings with sales leads, walkthrough sessions with customer success, and explicit handoff moments with support.
Before releasing broadly, you need to have cleared the four risk dimensions and briefed the people who will field the first questions. If you still have unresolved high-risk items, particularly around usability or value, your options are two: run an early access programme if you have the capacity to do it properly, or run a tightly monitored minimal launch with the customer success and sales teams briefed and ready to absorb friction. What you do not do is escalate to a public launch; the messaging won't survive the gap between what you've claimed and what the product currently delivers.
What are the purposes of a minimal launch?
Minimal launches do double duty. The first and most common: a terminal release for incremental improvements that don't warrant a commercial push. The second, less obvious but valuable: a deliberate soft landing before a public launch. You release the feature quietly to your existing base, observe natural adoption, surface friction the customer success team starts hearing about, and use early reactions to sharpen positioning and messaging before you scale the commercial effort.
When you escalate later, your campaign builds on validated signals rather than guessed-at value propositions. If you're planning a public launch, ask whether a two-to-six-week minimal launch beforehand would de-risk the messaging. In our experience, it almost always does.
Collect feedback through softer methods: in-app prompts, usage monitoring, proactive customer success outreach. Keep your success metrics simple and actionable. Give yourself a defined decision point at the end: does this move to a public launch, or does it stay as is?
Minimal launch checklist. The first two items are mandatory; the rest depend on the size of the change, the complexity of your organisation, and how visible the feature is to existing customers.
- Create your product brief in close collaboration with the Product Marketing Manager and CS team. Where no PMM is available, the PM owns the brief and pulls in marketing resource as it exists
- Brief customer-facing teams (sales, CS, support) before release
- Run a company demo and share the recording, when the change is material enough to warrant it
- Ensure demo environments are correctly set up, if the feature will be demoed externally
- Have communication and support materials ready before release, scaled to the change
- Set success metrics that will inform a decision on whether a public launch is warranted, if a future public launch is plausible
Step 4: Escalate to a public launch when the stakes justify it
A public launch means creating visibility around a significant product change: marketing effort, targeted communication, and a proper go-to-market strategy. You escalate here when you've made a change that's material enough to drive upsell, attract new customers, or shift how existing customers understand your product's value.
When a launch fails, the results are immediate: a campaign goes out, but reality doesn't match the hype. Sales demos diverge from the actual product, support tickets spike, and customer confusion sets in. This generates visibility without trust: a far worse outcome than a quiet release. Beyond the external impact, it burns goodwill with your commercial teams, making it harder to rally them next time.
The rule is simple: no public launch until the messaging has been tested against real customer reactions and all high-risk items on those four dimensions are solved, closed, accepted, or explicitly mitigated.
Once you're ready, the Product Marketing Manager leads. They own the campaign, the messaging, the sales enablement content, and the coordination. If you don't have a dedicated PMM, the product manager takes the lead on launch strategy and pulls in whatever marketing resource is available. The product manager's role in either case shifts from execution to oversight: monitoring product metrics, flagging positioning gaps, and ensuring the product brief stays accurate as messaging evolves.
The launch plan should include an executive summary, product brief, target audience and personas, key messaging, KPIs, deadlines, core team composition, marketing channels, deliverables, and budget. That's the minimum viable coordination structure for a launch where multiple teams are working in parallel without bumping into each other.
Step 5: Reserve full-scale launches for game-changers
A full-scale launch, sometimes called a hard launch, is a public launch multiplied. Live events, a full campaign, leadership visibility, significant budget, company-wide coordination. It's what marketing teams plan for months in advance, and it should be exceptional. When it works, it shifts market position. When it doesn't, it is expensive, exhausting, and public.
The bar is high deliberately. Use it only when you believe the innovation will change your competitive position: a new category entry, a major geographic or sector expansion, or a product moment that demands broad public attention. A full-scale launch is a magnet for prospects, not a satisfaction play for the people you already serve.
What goes wrong most often is logistical. A team that underestimated the preparation lead time, started coordinating too late, and ended up with different parts of the organisation running separate campaigns toward the same moment without alignment. The result is a diluted impact that looks to the outside world like a major launch but delivers the ROI of a public one.
Be honest about frequency. One full-scale launch per year, per business area, is a reasonable ceiling. More than that, and you're either setting yourself up for underdelivery or burning out the teams that make it happen. After every full-scale launch, run a post-mortem; the investment is too large not to extract every lesson from it.
Choosing the right approach: a quick reference
If you'd like to build this kind of thinking into your team's operating rhythm, not just for one launch, but as a repeatable practice, dualoop's product coaching engagements are designed for exactly that. We've helped product teams across industries move from ad hoc launch decisions to a structured, risk-aware approach that their commercial teams can actually follow.
Key takeaways
- Every release follows a similar sequence: internal → early access → minimal → public → full-scale. You stop when your risk, confidence level and business needs justify it.
- The internal launch is non-negotiable. It's the minimum viable safety net for any feature release.
- Early access is the exception, not the norm. Use it when confidence is genuinely low. Time-box it. Make an explicit go / extend / kill decision at the end and never leave it open indefinitely.
- The minimal launch is your default. Most feature improvements belong here and nowhere else and it doubles as a deliberate soft landing before a public launch when messaging still needs validation.
- Public and full-scale launches require validated messaging, pricing, and commercial readiness. Skipping that validation doesn't accelerate the launch, it undermines it.
- The product manager's role shifts as launch scale increases: from hands-on execution in early stages to coordination and oversight in public and full-scale launches.
