Your customers want to buy your startup’s product. They really do. So why haven’t they? The problem might be that they don’t understand what you’re selling them, because you’re selling them a package of features, not a set of solutions.
You’ve probably made them aware of a few things to catch their interest in the first place. They might know what your product does. They might know that it does what it does very well. They might know that your product is the pinnacle of cutting-edge stuff.
But they’re just not 100 percent sure what’s in it for them.
In my 20-plus years of developing both customer-facing and business-facing products, I’ve found the lack of customer focus during the product development phase to be the number-one dealbreaker for new product sales.
Everyone says they put the customer first, but when you dive into their product development process, you can quickly discover when that’s not actually the case. So let’s fix it by using customer-focused documents as the source of our product build.
A Solutions Roadmap Puts the Customer First
A solutions roadmap is not a new concept. It’s a lot like a product roadmap, but broken out by solutions to customer problems instead of by feature set.
Traditionally, a feature-based product roadmap is the single source of direction for a new product. That one document usually dictates:
A Product Roadmap Usually Directs:
- Design of the product, including user interface and user experience.
- Development of the product, including feature set.
- Testing, including the framework for customer acceptance testing.
- Release, including marketing and messaging.
- Support, including onboarding and training.
All of those things need to be directed at the customer. But when you start with a feature-based product roadmap, none of those customer-facing things are driven from a customer-centric source document.
That’s changing. Both my day-job startup and a startup I advise are now working on a solutions roadmap for a new product. We’re building this roadmap from a functional platform diagram, which takes the elements found in a technical diagram and re-communicates them as functional elements. Both of those documents are squarely focused on solving the customer’s problems and building those solutions into the product.
What’s the Difference Between Functional Documents and Technical Documents?
If you can show a technical diagram to your development team and expect them to understand it and use it as a tool to build the product, you should be able to show a functional platform diagram to everyone in your company and expect them to understand how the product works.
By the way, you’d be surprised at the number of people who work for a company and don’t understand how that company’s product works.
If you can show a product roadmap to everyone in your company and expect them to understand it and use it as the company’s how-to manual, you should be able to show a solutions roadmap to every single one of your customers and expect them to understand what your company does.
Customer Focus Starts With Functional Documents, and Flows Through the Product Build
For the functional platform diagram, think about your product from the customer’s perspective. A technical diagram, whether it’s for software, hardware, or something else, usually centers on the part of the product that influences all the other parts. For example, with a software product, it’s the backend architecture.
But the customer never sees this architecture. Instead, most of their interaction is with the UI. Start there, draw on your most prolific use case (the biggest problem you solve) and work backward along the customer journey all the way to the lowest level. Save the complex definition of each component for the technical diagram itself. This is a high-level look from the outside in. Translate that to a solutions roadmap. Think about how much of a customer’s problem you solve and how well you solve it.
You should be able to show a solutions roadmap to every single one of your customers and expect them to understand what your company does.
What else needs to be done? (Think about Amazon. They don't just sell you the product, they store, pick, ship, deliver, and in some cases support the product).
Are your feature sets grouped by technical connection? Or by customer impact? Are your customers hopping from place to place to solve their problem, or is the solution self-contained in one area and solved in one sitting?
Are you going to generate more revenue by solving more of problem A? Or is there more opportunity in solving problem B? Most problems are derivatives of larger problems. Prioritizing pain points on a larger scale can crystallize those pain points during the sales process.
How to Build a Solutions Roadmap
This Is Not About Editing Your Existing Documentation
A solutions roadmap should dictate how you design and build your product from the beginning. You should start with it, not distill it. Here’s why.
You’re probably spending tons of time and money on instructional and educational documentation—FAQs and Getting Started guides and whatnot, which no one reads. If you’re selling a B2B product, you’re also likely spending time and money on training and onboarding, which no one likes to sit through or pay for.
One question that the solutions roadmap answers is: How do you reduce the cost of instruction and training without reducing the benefit?
The outcomes of a solutions roadmap are a lower cost to acquire the customer (CAC)—by getting them to understand value earlier—and a higher lifetime value (LTV)—by encouraging more customer success.
A solutions roadmap should dictate how you design and build your product from the beginning. You should start with it, not distill it.
You’ll Have to Think Harder About Customer Needs, but That’s a Good Thing
Don’t get complacent just because you’re hitting all your company milestones, because you might be missing customer milestones—not understanding and outlining the steps your product takes to solve their problem.
Developing these documents requires talking to your customers, understanding what they need, and verifying that you’re doing it. Working from these documents as source documents makes you think more about the customer, their success, and how your product enables it.
If you’re not already using functional documentation, I’d suggest generating these documents as an exercise. When you’ve finished, match them back to your sales process, customer demos, onboarding, training, support, and maintenance.
You’ll probably find you can drive down a lot of time and costs in those areas by using a functional approach to development. What’s more, you’ll probably discover ways to close customers more quickly, satisfy more of their needs, solve more of their problems, and keep them around longer.
