How to Create Outcome-Driven Roadmaps with Integrations

Software roadmaps have been around forever. However, the idea of outcome-driven roadmaps is relatively new. You've likely heard about it recently, and we believe it's a great way to focus on results instead of intentions. With that in mind, this post will explain how you can include B2B SaaS integrations in your outcome-driven product roadmaps.

You may be thinking, "easier said than done" when it comes to including integrations in your product roadmap. After all, integrations are often difficult to fit into a roadmap because they can be challenging to scope. Among other issues, estimates must be revised frequently due to changing requirements and conflicts with tech partners' priorities.

But tools such as an embedded iPaaS can help. Our customers have noted that using Prismatic makes estimating and planning their integrations much more straightforward. A big part of this is that using an embedded iPaaS for integrations can turn an integration that took months to build into one that they can finish in a week or two.

What are outcome-driven roadmaps?

Many things are called software roadmaps that are not. A list of product features and the dates you expect them to be available to customers is not a roadmap but a product release plan. And release plans have their place. But a product roadmap lets us see how the product will grow and change over multiple releases. In short, the release plan is tactical, but the product roadmap is strategic.

Too many product roadmaps are slightly modified release plans. Unfortunately, using this approach to building roadmaps makes it far too easy to create output-based roadmaps. Sometimes called "feature factories," output-based roadmaps include things like:

• Add the interview module.
• Update the user interface.
• Build an integration with X.

If you achieved the above, you would get an interview module, an updated UI, and an integration with X. And that's progress, right? Well, it is movement, but it may not be progress as measured against your company and your customers' needs. These results may be necessary features or functions, but why? And the why leads us to outcome-driven roadmaps because they focus on addressing business needs and changing customer behavior.

Let's look at what the items from the above list might look like if we rewrote them for an outcome-driven roadmap:

• Cut onboarding time for new users by 20% by incorporating an interview module.
• Reduce support tickets tied to unreadable/confusing UI elements by 50% in Q2.
• Save 10 current customers 30 minutes each per day by building an integration with X.

Now that we are focusing on the why, you can see how properly designed outcome-driven roadmaps allow you to achieve valuable results for your company, your customer, or (ideally) both.

What are the benefits of outcome-driven roadmaps?

When you shift from output-focused to outcome-driven roadmaps, you'll see the following benefits:

• Product differentiation
• Flexibility for market changes
• Recency bias protection
• Company goal alignment

Product differentiation

Focusing on driving specific behavior while solving internal and external customer needs will naturally differentiate your product. You'll no longer be building product roadmaps that are little more than short-term plans to feature-match the competition. Instead, you can let your customers (who are interested in results over features) help you create a product that stands apart from the competition.

Flexibility for market changes

Features are binary; either your product has them, or it doesn't. As a result, feature-based roadmaps are unforgiving. However, if you build your roadmap to solve business needs and change customer behavior instead of focusing on particular features, you have considerable flexibility in achieving those results. This flexibility lets you move with the market instead of lagging it.

Recency bias protection

Assigning too much weight to the last request we've received (from sales, customers, etc.) is not uncommon. And you want to be responsive and flexible to address company and customer needs. However, the outcome-driven roadmap helps protect against knee-jerk responses. It enables you to justify “No” when needed because every item on the roadmap must prove its value before becoming part of it.

Company goal alignment

If you focus on adding product features, aligning your product roadmap with company goals can be hard. How does "build an integration with X" impact your company goals? How do you tie this feature into your company goal to "become profitable by 2025"? But, if your outcome-driven roadmap item is to "increase win rate by 10% in Q2 with new integrations," it can be much easier to draw a line from the result to the company goal.

How to include integrations on outcome-driven roadmaps

Integrations are product features. And if you are putting features on your product roadmap, it's not outcome-driven. The key is to link specific integrations to the desired outcomes.

Work backward from your company goals

If one of your company goals is "increase customer retention by N% YOY," then you should look at everything you could do to reduce churn. Maybe some of your customers have told you that your lack of integration with X is why they churned. So, you might have a roadmap item to "reduce churn X% by building out an integration with X in February." Yes, you are building a feature, but you are only doing so to solve an underlying business need.

Dig into the data

You've got two excellent data sources to mine for ideas on how integrations can help you achieve specific outcomes: internal data and customer feedback. Internal data includes all the metrics you collect regarding your app: how it is used, how much time is spent onboarding customers, how much time is spent on support, etc. Customer feedback includes structured data (such as customer satisfaction surveys and quarterly business reviews) and the anecdotes that fill up your onboarding and support chat and email.

Make the outcomes SMART

Defining outcomes for your integration-related items on the product roadmap doesn't ensure you will achieve them. But, if you use the SMART framework, you've just increased your probability of success. To do this, your outcomes should be:

• Specific
• Measurable
• Achievable
• Relevant
• Time-bound

For example, you have an item on the roadmap for Q1 that says, "Reduce COGS for integrations by 10% compared to last quarter." As to how you might achieve this result, an embedded iPaaS could be part of the answer.

Examples of outcome-driven objectives for integrations

Here are a few outcomes that could be tied to integration-related features. You should be able to modify these to develop several items for your product roadmap.

• Cut average onboarding time for new users by 15% in 2023.
• Reduce dev time spent on integrations by 50% YOY.
• Enter two new market verticals in Q3.
• Increase upsell to existing customers by 5% in Q1.
• Decrease churn by 20% in Q3 over Q2.
• Reduce integration COGs (such as hosting fees) by 20% for Q4.
• Increase win rate by 10% in Q2 because of integrations.
• Customers will build 25% of all deployed integrations for 2024.
• Increase customer satisfaction with integrations by 10% YOY.

Your customers will be happy with the outcome

Customers are increasingly interested in actual solutions rather than shiny tools that may or may not provide those solutions. If your product roadmap focuses on solving your company's and your customers' specific integration-related needs, the outcomes will speak for themselves.

Outcome-driven roadmaps turn things around, making you focus on the why and not the what. And that's a good thing, even if it takes some work to fit your product integrations into that way of thinking.

To learn more about how our embedded iPaaS can help you focus on integration outcomes instead of features, schedule a demo. We'll be glad to show you how.