From Solutions to Problems: The Problem with Solutions in B2B SaaS Industry

Why focusing on solutions holds back your B2B software product, and four common misconceptions about customer problems that make it worse.

💡 This is part #2 in a series of articles that dissects fundamental issues of B2B SaaS product development and challenges common industry beliefs and practices. Read the intro article #1 here, and subscribe to follow the series!

Image by DALL-E

Software companies, particularly enterprise software vendors, often call their products “solutions”. This terminology implies that the software product successfully resolves some “customer problem”, and is therefore valuable for the customer.

But even though everybody obviously wants solutions, we must get way more interested in problems.

What exactly is a “customer problem”, to which software is a “solution”, even in principle?

A key reason for the frequent inadequacy of today’s B2B software is that product development teams don’t really understand what customer problems they are solving. At most, the understanding is superficial.

As Paul Adams, CPO of a Silicon Valley B2B SaaS unicorn, aptly stated:

“A solution can only be as good as your understanding of the problem… This is non-controversial. Like an irrefutable fact.”

While Adams refers to specific customer problems for specific software, I believe the issue runs far deeper.

The B2B software industry as a whole seems to lack a conceptual understanding of what constitutes a “customer problem” in the first place. What is that “customer problem” to which a software product, in its entirety, is a solution?

This conceptual gap isn’t limited to software companies. Customers have it too. While both parties frequently discuss “customer problems”, they don’t realise their understanding of the term can actually hinder development of good “solutions”.

Without a useful general definition of the concept “customer problem”, it is impossible to identify and understand the specific customer problems a particular software product should address. And if we don’t see the problem clearly, how can we hit the target with our solution?

I challenge you to define what a ”customer problem” is

Take a moment to consider this question. How would you define a “customer problem” in principle?

First, think of examples from products you have worked on. Then consider what your examples have in common. What therefore is a “customer problem”, conceptually?

If you wish, comment at the end how you would define a “customer problem”.

When you are done, continue reading.

Four common misconceptions of what “customer problems” are

When people discuss “customer problems”, I usually hear them talking about the following kind of concepts.

1. Customer problems are what customers complain about.

For example, customers might say:

• “Our current solution is too slow.”

• “This product is very difficult to use.”

• “There are lots of bugs in this software.”

• “Our enterprise IT stack is too complex.”

• “The cost of maintaining our solution is too high.”

• “The technology is outdated.”

These examples clearly imply that there is some kind of a problem.

But… these are complaints about a solution. They point to a problem in the solution. Complaints are symptoms that a solution fits the customer problem poorly. But what is the underlying customer problem to which the solution is supposed to be a solution?

2. Customer problem is that a customer doesn’t have a solution.

For example, customers might say:

• “We need a CRM system.”

• “We need software to automate our logistics processes.”

• “We want a modern cloud-based SaaS product to replace our in-house on-premises legacy software.”

Since customers say they need a new solution, they clearly have some kind of problem now.

But… defining the customer problem as a lack of a solution is circular reasoning. It doesn’t help in developing a better solution. What is the problem to which a “CRM system” is a solution? What is the problem to which “automation software” is a solution? What is the problem to which a “modern cloud-based SaaS product” is a solution – and to which that old “in-house on-premises legacy software” is a different, inferior solution?

3. Customer problems are the features customers request.

For example, customers might say:

• “We need an AI to predict our sales.”

• “We need a dashboard to show all the daily key metrics.”

• “We need a graphical UI to configure the parameters ourselves.”

• “We need the ordering system to integrate with the point-of-sales software.”

• “The software should visualise the inventory levels.”

When customers make these requests loudly and forcefully, they obviously have a problem of some kind.

But… all features are solutions, or parts of a solution. What is the problem to which an “AI sales prediction algorithm” is a solution? What is the problem to which a “dashboard of all key metrics” is a solution? How about “configuration UI for parameters” or “integrating ordering with POS software”? What is the problem to which “visualisation of inventory levels” is a solution?

4. Customer problems are what customers say their problems are.

Surely customers are right when they tell their problems to a software vendor? So whatever they say must be their “customer problems”?

The problems customers articulate usually fall into one of the above categories. They tell about the pain they currently experience (1). They are aware that they need a new solution (2). They will tell you many ideas for features they want in a solution (3). While all of those describe or imply some kind of problems, none of them are a “customer problem” to which a solution is a solution.

This is not a question of terminology. Instead of a “customer problem”, we could use the term “customer need” and rephrase the question: what, in principle, is the “customer need” that a software product as a whole satisfies? The argument remains the same.

Vendors and customers know how to use the language of solutions, but not the language of problems

Both customers and software vendors of B2B software usually talk only in terms of solutions: features, technologies, and the pain points in current solutions.

This isn’t a question of competence. Even if people understand the importance of describing problems before building solutions, they often don’t have a way to do so. They can’t talk in terms of the underlying customer problems because the necessary conceptual knowledge simply isn’t there.

There is no widely understood, useful definition for the concept of “customer problem”. Such knowledge is not taught in product management or software engineering courses, neither in the industry nor in academia.

To build superior, valuable, market-leading B2B software products, we must first define customer problems rather than jumping straight to solutions. Most fundamentally, we need a general definition of what a “customer problem” is, one that doesn’t constantly refer back to solutions.

The rest of this series works through what this change of perspective actually means in practice. It impacts everything in product development:

• How discovery should be conducted and what researchers should be looking for

• How solutions get defined: from ideation in workshops to reasoning from verified facts

• Why analytical evaluation of solutions is possible without building them or testing with users

• How to quantify the improvement potential of a product opportunity before committing a single engineer to it

• What building a scalable B2B SaaS product actually requires, as opposed to custom development in disguise

This question is at the core of my approach to developing B2B software products: Deductive Innovation.

---

Continue reading part #3 of the series:

---