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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
Prismatic is the integration platform for B2B software companies. It's the quickest way to build integrations to the other apps your customers use and to add a native integration marketplace to your product. A complete embedded iPaaS solution that empowers your whole organization, Prismatic encompasses an intuitive integration designer, embedded integration marketplace, integration deployment and support, and a purpose-built cloud infrastructure. Prismatic was built in a way developers love and provides the tools to make it perfectly fit the way you build software.
Get the latest from Prismatic
Subscribe to receive updates, product news, blog posts, and more.