Product or Service
Launch
A best‑practice process from concept to shipping — designed so stakeholders shape the work early, risks surface before they’re expensive, and your team spends their hours doing the work, not coordinating it.
A launch is the process of building the right thing, in the right order, with the right people aligned along the way.
Most teams confuse launching with building. They move fast — genuinely fast — and they ship something real. But without a structured process behind that movement, they’re driving confidently toward a destination nobody actually confirmed. They build exactly what they planned. They just have no idea if it was the right thing to build.
More than fewer mistakes —
better work, together.
Stakeholders shape the work — early.
Departments, subject-matter experts, and the people closest to the customer get structured ways to contribute — surfacing risks, use cases, and scenarios where the solution may need a different approach. Discovery becomes something they can actually shape, not a meeting they react in once the design is done.
Each step has an owner — and a decision-maker.
The process bridges your team from where they are now to shipping — each step with a defined owner, a defined decision-maker, and the minimum expectations and considerations that need to be true before the team moves on. Less time negotiating roles or chasing decisions across channels. More of each person’s actual capability — design, engineering, strategy, customer insight — flowing into the work itself.
Built on what the discipline has proven works.
Jobs to Be Done. User Story Mapping. Working Backwards. Build–Measure–Learn. Over thirty years of product practice, structured into one process — so your team spends its energy executing, not reinventing how to plan a launch.
Before you build anything,
ask one uncomfortable question.
Do you actually know where your solution sits in the market — and why that matters? Not theoretically. Not based on the pitch you gave investors. Right now: if someone lined up your product or feature next to three competitors, could your team clearly articulate what makes yours worth choosing? Could they explain who it’s really for, without hedging? If there’s even a moment of hesitation — that’s your signal.
Are we building something genuinely different — or are we just building it too?
Different doesn’t mean better in every way. It means your team can name — in one sentence — what makes your version worth choosing over alternatives that already exist.
Are we leaders in this space, or fast followers?
Both are legitimate positions. Innovating in new territory is one path. Executing a known solution better than anyone is another. What’s not legitimate is being unsure which one you’re doing.
If we’re somewhere in the middle, do we know that — and is it on purpose?
A muddled middle position is the most expensive place to land by accident. Pick it deliberately — or don’t pick it at all.
Who appreciates what we’re focused on — and does our solution actually speak to that?
Your ideal market values one thing more than another. If you don’t know what that is, you’re building features for a customer who doesn’t exist yet.
A launch doesn’t begin with action. It begins with positioning — not just about what you’re building, but about where it sits in the world it’s entering. The competitive question is the diagnosis. Everything else is treatment.
Map where your
solution actually sits.
Once you’ve looked at the landscape honestly, plot it. There’s a simple but powerful matrix for thinking about positioning: price against innovation. Where does your solution land? Where do your competitors land? Each quadrant is a legitimate position — but you need to choose one. Intentionally.
The positioning quadrant.
Plot you and your closest competitors against price and innovation. The position that wins isn’t necessarily the “best” one — it’s the one your team can actually defend, day after day, against the alternatives a customer is comparing you to.
Pick one — deliberately.
Each quadrant is a real strategy with real customers. The trap isn’t landing in the “wrong” one. The trap is landing somewhere by accident, then trying to defend it as if it were a choice.
Score yourself against the alternatives the customer is actually considering.
Don’t score against the competitors who flatter your product. Score against the ones a buyer is genuinely choosing between. The gap between those two lists is usually where strategy gets vague.
| Feature / Capability | Your product | Competitor A | Competitor B | Competitor C |
|---|---|---|---|---|
| Core feature | 4 | 1 | — | 1 |
| Differentiator | 5 | 3 | 2 | 1 |
| Onboarding ease | — | — | 4 | — |
| Pricing clarity | 4 | 3 | 2 | 5 |
| Integrations / ecosystem | 3 | 4 | 5 | 3 |
| “Secret sauce” (hard to replicate) | 5 | 2 | 3 | 1 |
Four frameworks.
One shipped product.
These aren’t the only lenses — but they’re among the most powerful and the most often missing from launch conversations. Each one adds a dimension that most teams skip when they’re moving fast. Use them in sequence to sharpen your thinking before committing engineering resources.
Jobs to Be Done
Customers don’t buy products — they “hire” them to do a job. Understanding the real job your customer is hiring you for reveals who your true competitors actually are — which is rarely the company you think you’re fighting.
- What job is the customer hiring your product to do?
- What were they using before — and why did they fire it?
- What emotional and social jobs sit alongside the functional one?
- What would make them fire you — and hire someone else?
User Story Mapping
The most-skipped step in most launch processes — and the one that pays off the most. Walk through the complete journey from the user’s perspective, step by step, before you commit to building anything.
- The backbone — what the user must do, in order, to get the job done.
- The walking skeleton — the thinnest path through the backbone that delivers value.
- Slices — releases organized by user value, not by feature category.
- Use it to surface assumptions hiding as facts — and features that seemed important but are actually secondary.
Working Backwards
Write the press release before you write a line of code. If you can’t describe the customer benefit in language a customer would actually use, you’re not ready to build it. The PR-FAQ exposes vague thinking faster than any planning meeting.
- The PR — one page, written for the customer, describing the launched product as if it already exists.
- External FAQ — what customers will ask. If you can’t answer them, the offer isn’t real yet.
- Internal FAQ — what your team will ask. Pricing model, hardest engineering call, biggest risk.
- If the PR is boring to read, the product will be boring to use. Iterate the PR, not the spec.
Build · Measure · Learn
An MVP is not a small product — it’s the smallest experiment that produces validated learning. The discipline isn’t cutting scope; it’s being honest about what you’re trying to learn and what would change your mind.
- Build — the minimum that lets you test the riskiest assumption.
- Measure — behavior, not opinions. What did people actually do?
- Learn — what does this evidence change about our plan?
- The dangerous version: building an MVP and skipping the measure-learn loop because the team is in love with the idea.
Two mental models
for shipping the right thing.
These are thinking tools, not frameworks to fill out. Use them before, during, and after launch conversations to challenge the assumptions hiding inside your roadmap. Both are uncomfortable — which usually means you’re using them correctly.
Two ideas always beat one
A single idea is a default. Two ideas are a choice. When a designer brings only one option, the conversation collapses to “do we like this?” When two genuinely different options sit on the table, the conversation becomes “what are we actually choosing between — and why?” That second conversation is where strategy becomes real.
This applies far beyond design. It applies to messaging angles, pricing structures, GTM motions, and architecture decisions. Two ideas force the team to articulate trade-offs they would otherwise leave unspoken. Variations don’t count — you need real alternatives, with real differences in what they prioritize and what they sacrifice.
Applied to your launch process
- Ask the designer for at least two distinct directions, not two coats of paint on the same idea.
- For pricing, draft two structures — one optimized for adoption, one for revenue — and choose deliberately.
- For positioning, write two competing one-liners and test which one customers actually repeat.
- If a teammate pushes back with “but option A is obviously better” — that’s the moment to surface why option B was even drafted.
- The cost of having a second option is hours. The cost of having only one is sometimes the entire launch.
The Pre-Mortem
A post-mortem asks “why did this fail?” after the damage is done. A pre-mortem asks the same question before launch — while there’s still time to fix the answer. The team imagines it’s six months after launch and the product has clearly failed. Then everyone writes down, individually, why. The differences between people’s answers are the risks no one was naming.
The pre-mortem works because it gives skeptics permission to speak. In normal planning meetings, raising concerns reads as obstruction — so people stay quiet. In a pre-mortem, naming what could go wrong is the literal task. Every objection that would have been swallowed gets surfaced — and the most-mentioned ones become the risk register you build mitigations against.
Applied to your launch process
- Run it once after the product requirements are drafted — before design starts.
- Run it again before engineering builds — right after the stakeholder feedback session.
- Have everyone write silently first; share after. This prevents the loudest voice from anchoring the room.
- Cluster the failure stories. The clusters are your risk themes — and where mitigation effort should concentrate.
- If the same risk shows up in three people’s pre-mortems, treat it as confirmed, not speculative.
From concept to
Product/Service Launch.
Built on industry best practices, each step is a structured conversation with a specific purpose — with a defined owner, a defined decision-maker, and the minimum that needs to be true before the team moves on. People spend their hours bringing their actual work rather than coordinating who does what next. The full process scales from a two-week sprint for a small feature to a multi-month process for a major launch — but the sequence stays the same.
The complete Launch Clarity process.
All seven steps, structured as a multi-session process with facilitation guides, templates for the competitive scan, the user story map, the stakeholder feedback session, and the launch strategy — built in. Run it with your team directly in Nova.
The process bends.
The logic doesn’t.
A process is a framework, not a formula. It scales up for high-stakes launches and compresses down for small features — but the sequence and the underlying logic don’t change. Two things help you adapt without losing the protection: knowing what to add or archive based on context, and knowing the most common ways teams quietly break the process while telling themselves they’re still running it.
Adapt the process to your context.
The default sequence works for most launches. But complexity, risk, and team experience all shift what’s worth adding — and what’s safe to compress.
Add when you need...
- A co-creation session with users during the design phase, especially for complex or sensitive products.
- An accessibility review before feedback goes to stakeholders.
- An internal demo or dry run before the wider launch conversation.
- A risk assessment step for high-stakes or regulated contexts.
- A pre-mortem after the design phase — before engineering commits.
Archive or simplify when...
- The initiative is a small feature with low risk and high internal clarity.
- The team is deeply experienced and has run this process together before.
- The timeline is short and the competitive context is already well-understood.
- The audience and the job-to-be-done are already validated by recent launches.
The seven ways teams quietly break the process.
Most launch failures aren’t dramatic. They’re the slow result of skipping a step that felt unnecessary at the time. These are the most common ones — named so you can spot them.
Skipping the competitive analysis
“We already know the market.” You know a version of it from a point in time. The landscape shifts. Check it.
Treating the initiative doc as a formality
If it’s written to check a box and never discussed with the team, it will not do its job. Read it together. Ask the hard questions.
Asking for one design direction
Two ideas require two starting points. Give space for genuine exploration — not two coats of paint on the same idea.
Letting feedback become a reaction session
You’re not there to hear gut feelings. You’re there to surface what you missed, challenge assumptions, and pressure-test risks.
Giving engineering the design and nothing else
A Figma link is not a spec. Requirements need to be written. Decisions and reasoning documented. The builders deserve a clear brief.
Mistaking a checklist for a strategy
A checklist helps you not forget things. A strategy helps you win. You need both — and they are not the same.
Starting the launch conversation after the product is done
By then, you’re rushing. Begin the launch strategy in parallel with the design phase — never for the first time at ship.
Confusing momentum with direction
Moving fast and shipping something real is not the same as shipping the right thing. Activity is not progress.
The complete process —
from concept to ship.
All four phases — market & requirements, design, feedback, and launch strategy — are structured as connected sessions in Nova’s process library. Run them in sequence with your team, with templates and facilitation built in.
Want help from one of
our coaches?
Contact our team to get hands-on guidance running this process with your team. We’ll point you to the right starting place — and help you avoid the most common ways launches go quietly off the rails.