Your customers want to buy your startups product. They really do. So why haven’t they? The problem might be that they dont understand what youre selling them, because youre selling them a package of features, not a set of solutions.

Youve 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 theyre just not 100 percent sure whats in it for them.

In my 20-plus years of developing both customer-facing and business-facing products, Ive 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 thats not actually the case. So lets 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. Its 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:

  1. Design of the product, including user interface and user experience.
  2. Development of the product, including feature set.
  3. Testing, including the framework for customer acceptance testing.
  4. Release, including marketing and messaging.
  5. 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.

Thats changing. Both my day-job startup and a startup I advise are now working on a solutions roadmap for a new product. Were 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 customers problems and building those solutions into the product.

Joe KnowsHere’s What to Do When You Have a Flawed Minimum Viable Product


Whats 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, youd be surprised at the number of people who work for a company and dont understand how that companys 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 companys 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 customers perspective. A technical diagram, whether its 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, its 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 customers 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

Start with the most frequently occurring use case for your customer and work backward along the customer journey, considering at each stage what problem you solve and how well you solve it.


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. Heres why.

Youre probably spending tons of time and money on instructional and educational documentationFAQs and Getting Started guides and whatnot, which no one reads. If youre selling a B2B product, youre 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 earlierand 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 milestonesnot 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. 

Joe KnowsStartups: Stop Bragging About Your Funding

Expert Contributors

Built In’s expert contributor network publishes thoughtful, solutions-oriented stories written by innovative tech professionals. It is the tech industry’s definitive destination for sharing compelling, first-person accounts of problem-solving on the road to innovation.

Learn More

Great Companies Need Great People. That's Where We Come In.

Recruit With Us