How to tune your SaaS roadmap to maximize launch potential.

Recently, Derek Osgood, CEO of Ignite (a guest on my podcast earlier this year), posted one of his blogs on Linkedin.

  • 80+% of features are never adopted (Pendo)
  • 40+% of new products fail to meet targets (Mckinsey)
  • 10+% of revenue is lost to poor GTM alignment (IDC)
  • 81+% of CMOs believe launches ‘make or break’ product success. Yet only 31% of SaaS companies believe their internal org is well-prepared for upcoming launches.

I knew the metrics for successful SaaS product launch strategies weren’t rosy, but this bad!?!

What’s worse – the real impact is way bigger. This is just the tip of the iceberg.

Just think about this:

  • All those features and products took 1000s of hours to design, build, and test – by highly paid engineers.
  • All those ‘bad features’ typically are ‘asked for’ by customers who shouldn’t have been customers in the first place.
  • All these new products and features just blur a once remarkable product. Fans will notice – and churn.

And the list goes on.

So the million-dollar question becomes – how can you prevent this?

To answer this, this is what this essay is about. To provide you with the guidance to solve it once and for all.

Note: For this essay, I will focus on what happens even before the pre-launch phase, i.e., the decisions you make on what makes it into your roadmap and what not.

Beyond that – pay attention to the following three essays I wrote earlier on. They’re foundational:

 


Question for you to reflect upon:

On a scale of 1-10, how happy have you been with your last 3 product launches? What do you believe caused that feeling?


Why do SaaS product launches fail?

Seeing Derek Osgood’s demoralizing stats above, the first question I’d like to dig into is: “Why do SaaS product launches fail?”

To answer this question, I’ve reflected on my experience heading up Global Product Marketing and Product Management for +15 years at Unit4.

To me, it’s less about the typical excuses I hear a lot:

  • Too much competition
  • Lack of resources
  • Wrong pricing

A product that solves a meaningful ​problem for someone, a problem well communicated to the market – will take off – even with a small team, in a dense market, and priced at a premium.

So, here’s a top 5 from my own experience:

  1. There is no valuable solution to a problem. It’s a big one. The reason? Often, it is poor research, but more often, it is a shiny object syndrome. The result: Lack of pull from your target market.
  2. It’s too minimal to be viable. The product (MVP) is simply incomplete and lacks the features to make the product usable and (most importantly) sticky. The result: Negative user experience.
  3. Persistent technical issues, downtime, or poor performance. No matter how good the idea behind a feature, module, or product is, customers need to be able to rely on it. The result: users abandoning the product.
  4. The ‘throw it over the fence’ mentality. Without solid internal alignment across all departments, even the most remarkable products fail to make an impact.
  5. Poor market communication. A great product fails if its value isn’t effectively communicated. New products (even automatic SaaS updates) require users to change their behavior. That takes effort and convincing.

The red thread: All five points suffer from answering three simple questions:

These three simple questions give context to everyone in the process to do the best possible job to build a remarkable product, create and capture enough demand, ensure rapid adoption (without the churn),  and meet targets.

 


Question for you to reflect upon:

For what % of the features on your roadmap have you answered the three core questions? What would it mean if that was 100%?


How to fix your SaaS product roadmap to fuel success?

 

SaaS roadmap tuning

Step 1: Balance – Define guardrails to focus your resources for impact.

A product launch is just the end of the process. Success or failure starts at the beginning: What are your roadmap bets?

There are three common challenges:

  1. The urge to keep improving what’s table stakes – things everyone takes for granted and have no differentiated value.
  2. The never-ending flow of customer feature requests. The more customers, the more diversity in requests.
  3. Apples & pears. Not every roadmap item is comparable to another.

So how do you go about:

One principle that makes a difference is this: define 4 buckets. The buckets I always used at Unit4 were:

  1. Innovation,
  2. New Products Development (NPD)
  3. Tender Love & Care (TLC), and
  4. Platform maintenance.

Each bucket got a % development capacity for a defined period (typically a year) that we agreed upon with top management.

  • It helps to compare apples with apples.
  • Secures your focus on every aspect important for long-term success.
  • It stops the problem that all capacity goes to customer feature requests while your platform grows technical debt, and focusing on what you need to win in 2025 is sacrificed.

Buckets funnel quality discussions – so you can make the best choices in each category. And if you reach full capacity for a bucket – something else in that bucket has to drop. As simple as that.

On customer feature requests. A way to always be able to answer:  Make them part of the challenge by offering options if you decide NOT to add their request to your roadmap:

  1. Involve them in the broader set of choices, including the requests other customers have made. It makes them feel involved, and often, requests drop because another one solves it even better.
  2. Offer a workaround. Often, requests come from ‘how they did things in the past.’ That doesn’t mean you cannot achieve the goal in another way.
  3. Offer a paid customization. Skin in the game solves many prioritization issues. It’s easy to ask. It shows commitment if they pay.
  4. Solve it with a 3rd party solution/integration. If it’s not your core business, it will be someone else’s. Acknowledge that.

In short:

Not every item on your roadmap is equal.

Create buckets to channel decision-making that ensures your roadmap fuels success.

 


Question for you to reflect upon:

What % of your roadmap is assigned to table stakes? How much capacity would you free up if you’d define guardrails?


 

Step 2: What? Aggregate within each bucket

The first step to building your SaaS roadmap is to aggregate every idea, customer feedback item, requirement, feature, or even spec.

Input for this can come from everywhere – customers, consultants, sales, management, (obviously) product management, R&D – and so on.

And that’s good. Keeping everything on one list is essential. And your backlog is a good place to aggregate everything.

Your backlog is not a good place to decide, though. It cannot be that you apply a first come, first go principle cause that would turn you into a custom software shop.

Your backlog is just a list.

 

The next important step is sensemaking, i.e., answering the ‘Why this?’ question.

 

Step 3: Why this? Rank the problem, not the feature

This step is about sense-making.And no feature or requirement or spec makes sense on it’s own. It needs to be tied to a context.

I always approached that by linking each feature to a problem.

Given the problem is defined well (here’s an essay on that topic), problems give a feature context and meaning in a variety of ways:

  • You can tie it to value for your internal/ideal customers/buyer persona (scale 1-10)
  • You can tie it to criticality for your internal/ideal customers (scale 1-10)

Note 1: I deliberately mentioned internal customers because not all features on your backlog target something your end-users will directly value. Think f.ex. about essential development at the platform level.

Note 2: I deliberately mentioned ideal customer because that’s where your focus needs to be. Most SaaS businesses have customers who appear to be a not-so-good fit. And they will (because the fit is not ideal) overload you with feature requests. Be careful with prioritizing those. They’ll take you off-course.

Back to ranking each problem. Giving it context this way makes it formulaic: [value x criticality] = outcome

If [value x criticality] = < 49, it’s TLC stuff at best

If [value x criticality] = > 64, it has a business potential

That doesn’t mean you should put everything >64 points on your roadmap. But it gives you a simple way to tie everything you prioritize to value rather than gut feel. It drives a business discussion and avoids falling into the trap of a ‘shiny object’ syndrome.

In short:

Rank the problem, not the feature.

 


Question for you to reflect upon

What % of the features on your roadmap score <49 points if you tie them to value & criticality? What would happen if you deprioritize them?


 

Step 4: Rinse – Define Table Stakes – enough is enough

Now you can see the trees before the forest again i.e. what are the areas where you can make the biggest impact for your customer: the problems that score +64 points (in the eyes of your ideal customers.)

Let’s say you select three problems from a particular bucket to focus your next release on.

Going back to the topic of this essay, the next question is: ‘What can we do to maximize impact and success?’

And this requires you to answer another question: What does success look like?

This has two components:

  1. Your ideal customers’ definition of success.
  2. How important is this within the overall schema of your differentiation?

 

Here’s the thing:

Your SaaS solution consists of 100s, if not 1000s, of features. Not all of them are equally important. So, by looking at these two questions, you can define ‘Table stakes’ and ‘Strategic core.’

It is essential when defining what goes into your product roadmap and what does not. It

My definition of table stakes is: The minimum capabilities or features allow you to sit at the table with your ideal customers and be considered a viable option. These are features standard to all your ‘competitors’ and easily imitated.

My definition of the strategic core is: The capabilities or approaches that allow you to create a shift in value for your ideal customers that competitors cannot easily imitate.

Clarifying where each feature on your roadmap belongs creates resourcefulness. It allows you to say ‘no’ with ease.

In essence you solving each problem in your release is now about decide what’s the minimum you need to do for it to be considered viable. This is about shrinking scope where possible to free up resources for your strategic bets (see next step).

It’s so easy to lose 1000s of scarce development hours on features, making better what’s just table stakes. It’s like painting your house every week of the year. It keeps you busy – but there are no gains.

 

How do you identify what’s tablestakes?

By using the same formula as described above but now on a feature level. Table stakes is typically everything where the formula of [Value x Criticality] of the feature in relation to solving the problem doesn’t exceed 49 points.

Enough is enough in table stakes. Once you meet the basics, you’re done. Better use your time to focus on differentiation.

Note: Table stakes is a moving target. It’s not defined by you but by the market. As technology evolves, expectations change. So what was enough last year might not be enough anymore.

That said: You’ll never win a deal because you do table stakes better than others. You’ll only lose out when you don’t meet table-stakes requirements.

 


Question for you to reflect upon

Critically review your SaaS roadmap: What features are table stakes, i.e., keep your developers busy without shifting customer value? How many hours could you free up by dropping them?


 

Step 5: Challenge: Optimize for meaningful value

As said earlier, launch success is not about what you build but HOW you build it.

It’s about the value you create in the eyes of your user.

It’s where you can set the bar for the product market fit, i.e., the point where a customer will scream if you take the product away from them.

That has two levels:

  1. It meets expectations (= table stakes) or
  2. exceeds expectations.

Launch success is fueled by the latter

  • It sparks word-of-mouth
  • It accelerates adoption
  • It determines how much people will be happy to pay.

 

But where do you draw the line? It’s not feasible to exceed expectations on every feature you’ll add. So again, it’s about making intelligent choices.

Here are three questions I have come to value over my career to narrow down the options:

  1. What’s the shift in value that a user will notice?
    Here, I mean a 10x-type value, not a meager 10%.
  2. What’s the magic moment where we can matter most?
    Not every moment is equal. Pick them wisely.
  3. How can we approach it so it will be remarkable and hard to copy?
    Sometimes, the best experiences are not about what a user can do but what the user doesn’t have to do anymore.

Answering the three questions is a vital part of your release planning. Brainstorm your options and then rank them against three criteria:

  1. Customer impact / value
  2. Feasibility
  3. Risk

 

It’s OK you can’t do it all –

It’s about the choices you make and what drives those choices.

Take that seriously.

 


Question for you to reflect upon:

What’s the one feature on your next release where you’ll create a shift in value for your users? Do you create it at the moment that matters most?


 

Summary: Tuning your SaaS product strategy to maximize launch potential.

We started this essay with shocking stats: 80%+ % of features are never adopted, and 40%+ % of new products fail to meet targets.

So why is that? A deeper reflection showed five core reasons:

  1. There is no valuable solution to a real problem.
  2. It’s too minimal to be viable.
  3. Persistent technical issues, downtime, or poor performance.
  4. The ‘throw it over the fence’ mentality.
  5. Poor market communication.

The red thread: lack of context to everyone in the process. There is a lack of context on what it’s for, who it’s for, and what’s expected.

Answering these three questions is the first step at the start of each release. Why? Alignment. Because that creates resourcefulness.

What comes next is a 5 step process:

  1. Step 1: Balance – Define guardrails to focus resources for impact. A product launch is just the end of the process. Success or failure starts at the beginning: What are your roadmap bets? I suggest defining four buckets and assigning development capacity to each bucket.
  2. Step 2: The What – Aggregate within each bucket. Gather every idea, requirement, feature, or specification on one list – so everything weighs in.
  3. Step 3: Why this? – Rank the problem, not the feature. This step is about sense-making. And no feature or requirement or spec makes sense on its own. It needs to be tied to a context: a real problem.
  4. Step 4: Rinse – Define Table Stakes – enough is enough. Launch success is not about what you build but HOW you build it. The 1st step: Denough is enough in table stakes. You’ll never win a deal because you do table stakes better than others. Better use your time to focus on differentiation.
  5. Step 5: Challenge: Optimize for meaningful value.Narrow your options to three areas:  The value itself, the moment, and how it’s delivered. From there, rank your options against three criteria: customer impact, feasibility, and risk.

Following this 5-step flow will help you put all your roadmap decisions in context of success:  lifetime value for your customers and profits for your organization.

Having your product roadmap done right, you can now work on a launch strategy that people will talk about for a long time.

Good luck!

 


Question for you to reflect upon:

If you apply this five-step framework to your 6-month roadmap, what weak spots can you identify that you can still correct course on?


Additional resources to help you maximize the impact of your SaaS business.

The easiest way. Book a free call to explore if there’s a fit to do this together.

Otherwise – here are three other options

 

 

A daily email for B2B SaaS CEOs who want to end unpredictable traction.