This series has established that markets tend to converge toward optimal solutions. Those who identify these solutions first gain significant competitive advantages. The previous articles in this series explained how this convergence works, discussed why today’s best product development practices fail at market prediction, introduced Deductive Innovation as a systematic alternative, and showed real-life examples of predicting major market shifts years ahead of time.

But knowing this pattern exists isn’t enough. You need a systematic method to apply it to your specific B2B SaaS market.

This final article provides a practical 5-step framework for turning market prediction into market leadership: identifying the customer problems in your target market, mapping the interconnections between them, finding the largest gaps in current solutions, envisioning the optimal solution, and validating your vision before investing significant resources.

Traditional approaches leave product teams climbing whatever hill they happen to find. This framework enables you to identify your Mount Kilimanjaro, the highest peak in your market space, and plot your path there directly. Companies that master this skill can shape market evolution rather than merely react to it.

Subscribe now

Five Strategic Steps to Create Your Market’s Future

The following five steps apply the basic principles of Deductive Innovation to market prediction.

1. Identify the fundamental customer problems in your industry

Begin by researching the stable, enduring problems that businesses in your target industry face. What are they trying to accomplish? What situations do they repeatedly encounter? What outcomes are they seeking?

Look deeper: What are their criteria for great outcomes? What aspects of their circumstances remain the same, with or without your solution?

The key is to discover, understand and document these problems independently of any software solutions. Don’t think about features, technologies, or existing products. Focus solely on the concrete situations, goals, and success criteria that exist regardless of how they are currently being addressed.

Discovering customer problems requires you to meet customers, talk to users, and observe how they solve their problems today. In B2B, the necessary information is not available on the internet nor can you extract it from ChatGPT. Field research is necessary.

Pay special attention to decision-making points. What information is needed to make optimal decisions, regardless of how well customers use that information today? What kind of knowledge, experience or judgement do humans apply in these decisions? You must understand all inputs and criteria of a decision-making process to actually improve it.

For the purpose of evaluating an opportunity, you need to observe what’s wrong with the existing tools and processes. You will need this information for positioning, marketing and selling.

However, to identify the customer problems, you should not pay much attention to all the details of how current tools and processes work, even though this is easy to observe. Why? Because a new solution can overhaul existing tools and processes completely.

Instead keep asking: what about the work and situations here cannot change regardless of what the solutions are like?

Document specific examples of real situations, not just abstract descriptions. Take a lot of photos and/or videos, record the interviews, and transcribe the recordings. Collect data samples. Ask questions when you don’t understand why people are doing what they are doing. The concrete details reveal opportunities that general statements miss, and are required for objective evaluation and solution deduction.

Share

2. Map the interconnections between these problems

Business problems are interconnected. Each process output becomes another’s input. Mapping these connections helps identify natural boundaries for integrated solutions.

Understanding these links reveals optimal solution scope. The stronger the interdependencies, the more customers can benefit from a single integrated solution.

Customer problems that have fast feedback loops between them should always be solved together.

Interconnected customer problems with slower feedback loops between them should also be researched upfront, even though they don’t necessarily need to be solved upfront. It’s sufficient to just identify ahead of time the necessary inputs and outputs to support optimal outcomes for each interconnected problem. That enables us to ensure that the separate solutions for the separate subproblems will work together optimally once completed later.

An example of a typical slower feedback loop is the learning cycle. Most businesses have two parallel sets of business processes: processes to plan the operations, and the actual business operations. To make better plans in the future, a planning process needs historical data from operations to analyse how well previous plans worked and to estimate the impact of new plans, relative to goals. Establishing the collection and interchange of all the right data as an afterthought is likely to pose major architectural challenges.

To map interconnections effectively:

• Identify necessary dependencies between different activities, regardless of current tools and processes

• Note where outputs from one process become inputs to another, or should become inputs to another to enable optimal outcomes

• Map all the decision points where changes in one area will impact others

• Pay special attention to processes that require frequent coordination

• Document the costs (time, effort, errors) of poor integration for opportunity evaluation

The strongest interconnections reveal opportunities for integrated solutions that will eventually emerge in the market.

Share

3. Assess the current solution in your market

Now look at the solutions that customers are using in your market. What products, software and ad hoc tools are they using today? How well do the existing solutions address the concrete situations you have identified? How good decisions and outcomes do they enable? How cumbersome is the process to reach the outcomes? Where are the gaps? Where is unnecessary complexity, usually imposed by bad tools and processes? Where are integrations and hand-offs particularly painful?

Deductive Evaluation provides methods to objectively evaluate existing solutions and measure improvement potential. However, the ability to separate problems from solutions and common sense will get you quite far here.

This assessment helps you identify the biggest opportunities for improvement. The areas with the largest gap between current solutions and optimal solutions are where disruption is most likely to occur.

Be attentive to:

• Point solutions that address only one part of an interconnected problem set

• Processes that require many manual steps between different systems

• Quality of the outcomes customers are able to reach

• Areas where customers have built elaborate workarounds

• Functionality that requires extensive configuration to be useful

• Features that exist but are rarely used

• High-value workflows that span multiple current solutions

This analysis will reveal the most significant opportunities for optimisation in your market.

4. Envision the optimal solution

Based on your understanding of the problem space, what would an optimal solution look like? One that solves the complete customer problem with minimal complexity, not an incremental improvement?

Don’t constrain your thinking by existing products and tools. Imagine designing a solution from scratch with today’s best available technology, unconstrained by today’s approaches.

Ask questions like:

• If we were designing this system today with no legacy constraints, what would it look like?

• What do the ideal outcomes look like at each point of the overall process?

• What would be the ideal workflow that contains only activities that are necessary to reach ideal outcomes?

• What information or functionality should be available at each decision point to enable optimal decisions?

• What are the activities that humans must necessarily complete because they have knowledge, understanding, or judgement that a computer lacks, even if programmed with today’s best AI technology? (The rest can be automated.)

• How could we unify what are currently separate tools or systems?

This vision becomes your North Star, the peak of your Kilimanjaro, the destination where your market will eventually arrive.

The more thoroughly you understand the underlying customer problems, the more accurate your vision can be.

5. Validate your vision with early adopters

Finally, test your vision with potential early adopters. Like I described validation in Part 3, this doesn’t require building the solution. At the first stage, validate problems across customers, and at the second stage, validate your solution concept.

When you are validating customer problems (=customers’ situations) describe your understanding of their situation in detail. Look for a reaction where the customer’s eyes light up as they recognise themself and their situation, and say “That’s right!” without adding anything to your description. If they keep correcting you or adding to what you said you haven’t yet understood the full picture.

To validate the solution, create scenarios, mockups, or prototypes that illustrate how your envisioned solution would work in specific customer situations, the same ones you have first discovered.

When you get a similar reaction, you are on the right track. Get the customer to sign a commitment, at least a conditional one, to pay for the solution. That’s how you know you have identified an opportunity worth pursuing.

Effective validation focuses on:

• Whether your problem descriptions match their reality

• If your solution concept addresses their highest-value problems

• How much better your approach is than current alternatives

• Their willingness to pay for and champion such a solution

• Any critical gaps or misunderstandings in your concept

The goal isn’t 100% perfect prediction, but rather identifying where the market is heading with enough accuracy to position your product at the forefront of that evolution.

Common Objections to Market Prediction

After presenting this approach across four articles, you might still have concerns. These are the objections I hear most often from product leaders and other software professionals.

“Markets are unpredictable”

Major technological breakthroughs are generally unpredictable (as we saw with LLMs). But how existing technologies get applied to solve customer problems follows consistent patterns. Markets converge toward solutions that address complete problems with minimal complexity. This pattern is what makes prediction possible.

“This sounds too theoretical without real-world testing”

The examples in Part 3 (from touchscreens to app stores) demonstrated that systematic analysis of customer problems consistently predicted market evolution years in advance. The validation steps in this framework ensure your predictions connect to market reality before you make significant investment.

“What about disruptive technologies?”

As acknowledged in Part 3, this approach predicts how existing technologies will be applied, not what radically new technologies will emerge. However, understanding underlying customer problems positions you to rapidly adopt new technologies when they appear, as the problems themselves remain stable.

“Our industry is too complex for this approach”

Complex industries offer the greatest opportunities for 10x improvements. When current solutions are convoluted precisely because the domain is complex, systematic analysis is most likely to reveal drastically better, more direct paths to customer value.

“We don’t have time for this analysis”

As covered in Part 2, spending a few weeks or months on discovery with a small team of 1-3 people can prevent years of building the wrong product.

This approach is not for everyone, though. If the company culture values quick action over strategic thinking, emphasises incremental improvements over radical leaps, and supports a development horizon of just a quarter instead of years, this approach won’t fit. Deductive Innovation requires a long-term mindset and an ambition for excellence. For teams committed to building category-defining products and willing to invest upfront thinking to achieve 10x improvements, the ROI can be outsized.

For everyone else, traditional agile iteration is more culturally compatible, even if less effective.

“What if the technology isn’t ready for the optimal solution?”

Sometimes the optimal solution requires technology that isn’t mature enough. In 2001, capacitive multitouch technology wasn’t ready to enable an optimal touchscreen interface. However, understanding what the optimal solution requires helps companies recognise when enabling technologies emerge. Apple acquired FingerWorks in early 2005 precisely because they understood what the optimal mobile interface needed.1 Companies that see the destination clearly can either develop missing technologies or recognise and adopt them when they become available.

“Our legacy architecture prevents implementing optimal solutions”

For established companies, this might be the hardest reality to face. When existing product architecture has evolved from years of suboptimal decisions and portfolio acquisitions, implementing even small optimal improvements tends to require relatively big architectural changes. To quote an old Finnish idiom, it’s like a magpie stuck on a tarred roof: when the tail lifts, the beak sticks. Every attempt to make some part optimal ripples through the complex interconnected system.

This is why starting toward optimality from the beginning matters so much.

Companies with complex legacy products face a strategic choice:

1. continue making incremental improvements within architectural constraints, or

2. invest in revamping the architecture to support the eventual optimal solution.

In the short run, the former seems rational. This is the famous innovator’s dilemma.2 Doing everything right according to traditional business thinking (making incremental improvements, serving the best existing customers, maintaining profit margins) can lead to failure when a competitor without legacy constraints builds the optimal solution and eventually dominates the market.

Sometimes the wisest strategic decision is to disrupt yourself before someone else does.

Subscribe now

Choosing the Right Mountain to Climb

Many companies that will dominate B2B and Enterprise SaaS markets in the coming years won’t be those with the most developers, biggest marketing budgets, or the most advanced technology. They will be those that can systematically find optimal solutions through a thorough understanding of customer problems in their industry. Once on the right mountain, they plot the most efficient path to the top and climb relentlessly.

Deductive Innovation answers the strategic question: “Which mountain should we climb?”

Traditional iterative approaches help execute: “How should we climb it efficiently?”

Both are necessary, but the sequence matters. Iterating before you have identified the right mountain can lead to years of wasted effort and missed opportunities.

This strategic advantage comes from three capabilities that no established product development methodology provides:

1. Measuring alternative solutions analytically before building anything

2. Defining optimal solutions directly from validated customer problems (cutting months or even years from development timelines)

3. Creating solutions with 10x better Problem-Solution Fit that customers immediately recognise as superior.

As you consider your own product strategy, ask yourself:

• Are you seeing the entire space of customer problems in your industry?

• What would the optimal solution look like if you started fresh?

• How would you proceed to building one well-designed, thoroughly thought-through vertical SaaS platform that solves your customers’ problems holistically?

• How close is your current roadmap to building that optimal solution?

• Are you climbing the right mountain?

While this article series provides an approach for market prediction, implementing Deductive Innovation effectively requires more methodological knowledge than I can cover in a single series.

Adopting this systematic zero-to-one methodology challenges many ingrained beliefs in technology companies, where the tendency is to jump quickly to solutions and technology. Effective adoption involves developing specialised problem discovery techniques, learning analytical evaluation methods, and mastering the process of deducing optimal solutions.

If you are interested in learning more about these methodologies, subscribe to this newsletter where I will continue to share insights on systematic product discovery for B2B SaaS products.

The Destination Is Already Encoded in the Problems

The framework in this article gives you practical steps to apply market prediction to your own B2B SaaS market: discover the fundamental customer problems, map how they interconnect, evaluate where current solutions fall short, envision what an optimal solution would look like, and validate with early adopters before committing significant resources.

The destination of your market is already encoded in the stable customer problems that have persisted for years and even decades. Customer feedback, competitive analysis, and industry trends won’t reveal it. Those reflect where the market is now, not where it’s heading. The customer problems themselves, discovered and understood in sufficient depth and detail, will. They are independent of today’s solutions and their shortcomings.

Your competitors are focused on feature requests and iterating toward a local hilltop. You can see the global maximum they are missing, and position your product where the rest of the market will eventually arrive.

You don’t need luck or genius for this. You need a systematic approach for uncovering what others miss, and the discipline to follow it through.

If you are ready to apply these principles to your B2B SaaS product, subscribe now for more insights on creating superior B2B SaaS products or get in touch for a consultation.

This concludes the four-part series on predicting market evolution in B2B SaaS. If you found these insights valuable, share the article with your colleagues!

Share

Predicting market evolution isn’t speculation. It’s a skill that can be developed and applied systematically. Product developers who focus on finding optimal solutions often observe how markets converge toward these solutions, which makes it possible to anticipate major shifts years before they materialise.

This article walks through concrete examples of how understanding customer problems and reasoning through their best solutions can lead to anticipating market direction years in advance. We’ll also look at how you can validate your predictions efficiently without costly trial and error.

The first two articles in this series established how markets converge toward optimal solutions and introduced Deductive Innovation, a systematic methodology to understand customer problems and identify such best solutions before competitors. The key to predicting where the market is going is answering the question: “What is the best solution to this customer problem?”

At the core of market prediction lies the concept of “10x solutions”: advancements that outperform existing alternatives by an order of magnitude or more. As Peter Thiel noted in Zero to One:1

Once you’re 10x better, you escape competition.

When we understand customer problems correctly, we can identify these 10x opportunities years before competitors. If a solution could be 10x better, a competitive market will ensure that it emerges, whether we create it or let someone else win.

Share

Market Evolution in Action: When Industries Found Optimal Solutions

During my career in product development, I’ve repeatedly seen how analysing customer problems and reasoning about their optimal solutions can reveal future market directions with surprising clarity.

What follows are three stories from the early part of my professional journey where our design team identified the direction of market evolution years before it happened. These examples aren’t tales of lucky guesses. They demonstrate how logical analysis can anticipate future developments, even when established industry players miss these opportunities. Sometimes this led to the frustration of watching others eventually implement solutions we had identified earlier.

Among various experiences with this pattern, these three cases were particularly formative for me. They helped establish my conviction that markets tend to follow predictable paths toward optimality that can be mapped in advance. They were foundational inspiration for my passion to uncover the principles of systematic product innovation that can help companies gain first-mover advantages.

1) The Touchscreen Prophecy: The Inevitable Evolution of Screens in Mobile Computing

By the year 2000, many people in the Finnish tech industry recognised that mobile internet would become reality, though the optimal form factor remained an open question. To some of us, it seemed evident both theoretically and practically that an effective internet-connected pocket computer would need a large touchscreen.

Why a touchscreen? The case for touchscreens was grounded in established interface design principles, many of which I had covered in my thesis work. Direct manipulation had been recognised as effective for user interfaces since the 1980s.2 Desktop graphical interfaces claimed to provide “direct” manipulation, but users were actually guiding a pointer indirectly by moving a mouse. Large vertical computer monitors were not practical for touchscreens (your arm gets tired), but in handheld devices they offered direct interaction that could be superior if the technology worked reliably.

Why a large screen? In early 2001, I worked in a Nokia-commissioned project to design a personalised news portal for WAP phones (early smartphones). The experience highlighted the limitations of devices that could display only 2-4 lines of text. Using these early internet-capable phones was painful: waiting ages for sites to load, squinting at cramped text on tiny monochrome screens, and constantly scrolling after every 1-2 sentences. It was like trying to read a novel through a keyhole. This led our design team to conclude that effective internet browsing on mobile devices would require much larger screens.

Nokia and many other established mobile phone manufacturers continued pursuing different approaches. When Apple released the iPhone in 2007, it represented the commercial realisation of what many interface designers had envisioned: a device centred around a large touchscreen optimised for internet use.

The market quickly converged on the optimal solution: internet-capable pocket computers with large touchscreens. Other types of phones and pocket devices essentially disappeared.

The prediction was a logical result of understanding the situations that mobile users encountered, where accessing and interacting with internet content would help them while away from their desks. Anyone who understood the problem space and potential alternative solutions could have anticipated the optimal solution years in advance.

The 10x advantage of touchscreens became apparent soon after the iPhone’s release. The interface was so intuitive (tapping directly on objects, swiping to navigate, pinching to zoom) that it reduced the learning threshold to near zero. In 2010 when my nephew was just 18 months old, he eagerly used my iPhone to draw and play simple games with ease. Videos of monkeys browsing Instagram on iPhones demonstrate how direct interaction eliminated countless hurdles that animals couldn’t overcome in previous interfaces. The large responsive touchscreen with pinch-to-zoom gesture enabled the iPhone’s web browser to provide a desktop-like browsing experience, and websites designed for desktop screens became usable on mobile for the first time. As a result, mobile data usage exploded and forced US mobile operators to change their business models3

2) The Instant Search Revelation: Foreseeing the Evolution of Desktop Search

Around 2001, the limitations of Windows file search were painfully apparent to anyone who used it. A typical search scenario involved typing part of a filename, clicking the misleadingly labelled Find Now, and then watching a magnifying glass sweep back and forth for minutes, often ending with no results even when the file definitely existed.

Meanwhile, Google was returning results from the entire internet in less than a second. The contrast was infuriating, like comparing a horse-drawn carriage to a Ferrari. The experience was so consistently terrible that many people avoided using Windows search entirely. Instead, they maintained elaborate folder hierarchies and painstakingly browsed through them.

Recognising this problem, my designer colleague Karri-Pekka Laakso decided to actually build a proper solution. The optimal approach required indexing all files on a PC to provide search results immediately as the user typed. He implemented a fast algorithm that supported substring search where the search string could appear anywhere in the filename, not just at the beginning of a word. No wild cards needed. His working prototype (see image below) demonstrated how much better the user experience could be.

Neither Microsoft nor other Windows software providers implemented this superior solution at the time. Then at Apple’s WWDC in June 2004, Steve Jobs lamented how “it’s easier to find something from one of a billion websites on the web with Google than it is to find something on your hard disk,” and proceeded to demonstrate Apple’s solution, Spotlight.4 This validated the obvious improvement opportunity in desktop computing.

Over time, all operating systems implemented a fast system-wide search. The improvement was radical: what once took minutes now took milliseconds, a 100-1000x speed improvement. Tasks that were so frustrating users avoided them entirely became effortless background activities.

These examples reveal a pattern: when optimal solutions offer over 10x improvements, markets eventually converge toward them and change user behaviour in ways that can’t be reversed. Market evolution becomes predictable when viewed through the lens of optimal solutions to customer problems. Desktop search evolution was convergence towards the solution users obviously needed all along.

3) The App Store Prophecy: Predicting Apple’s $30B Business Six Years Early

In 2002, Nokia tasked our design consultancy with designing a technical solution for installing apps on smartphones that would be both secure and user-friendly.

Nokia’s Communicator smartphones used the same approach as Windows: browse to a developer’s website, click through confusing security warnings, download an installation package, run it, navigate a multi-step installation wizard with cryptic technical options, and finally find the app on the device’s desktop. The process was tedious and insecure even for technical users. Apps could contain malware, and criminals could impersonate legitimate companies. Most users clicked “Yes” to every prompt without reading, just to make the interruptions stop.

Digital certificates existed so developers could sign their apps, but users didn’t understand these concepts and ignored them. Even if users checked certificates, what would that help with less known software developers?

Our 2002 report noted: “[Today] the easiest way to operate the system is often the insecure way. Turning this the other way round … is challenging, but it can be done. Realising such a secure and usable environment is the responsibility of the [manufacturer].”

Instead of limiting the analysis to purely technical solutions, our approach focused on identifying the best possible solution by reasoning from first principles.

The analysis concluded that no purely technical solution could make app installation both secure and easy. Instead, we proposed combining technology with a centralised distribution model: “A much more fruitful approach is to combine judicial and financial incentives... Since users necessarily trust their device manufacturer, the manufacturer is the most natural party to take responsibility for security.”

The manufacturer would:

• Verify developers’ identities and establish contracts with financial penalties for malicious behaviour

• Test software with standard security tests before distribution

• Handle updates centrally rather than allowing apps to update themselves

• Possibly inspect and certify free apps at no cost, “since popular software is likely to improve the device’s market position.”

Using this model “software can always be installed without any [security] questions or output to the user … [This follows] the principle of making the easiest way to achieve a goal also the safest way.”

Nokia did not implement these recommendations. Like many market leaders, they focused on incremental improvements to maintain their position.

When Apple announced the App Store six years later in 2008, it validated the central distribution model approach. The market quickly converged on this solution: third-party apps are now distributed centrally by the device manufacturer or operating system developer.

The prediction was a logical result of analysing core problems (deploying apps securely and easily) and reasoning toward optimal solutions. It demonstrated how this kind of analysis can reveal where markets will eventually move.

The 10x advantage of the App Store was apparent across multiple dimensions. It reduced the process of finding and installing an app from several minutes and dozens of steps to a few taps that took seconds. The most striking improvement came in security. The traditional software installation model led to widespread distribution of viruses and malware on the Windows platform. By contrast, Apple’s App Store has experienced very few security incidents. This risk reduction by orders of magnitude is another example of how the best solutions completely reshape the experience.

The introduction of the App Store highlighted an important lesson beyond market prediction: organisations need a culture focused on identifying the best solutions and a commitment to implementing them, not just the ability to see the opportunity. In all three examples discussed here, Apple was the company that introduced optimal 10x solutions to the market. Their culture of pursuing excellence rather than incremental improvements is likely a key factor in this pattern.

Today, Apple’s App Store generates over $30 billion annually with an estimated 85% operating margin.5 Apple implemented Peter Thiel’s advice we discussed in the previous article: it looked for the global optimum, found it, and created a monopolistic advantage for itself. The App Store as a stand-alone business now exceeds the size and value of Nokia’s entire mobile phone business at its 2007 peak6, the year before the App Store launched.

These three cases illustrate how markets tend to converge toward solutions that address customer problems with minimal complexity.

But prediction isn’t perfect, especially when new technologies emerge that change what’s possible.

Prediction Meets Technological Disruption: A Cautionary Tale

While the examples above show how analysing customer problems can lead to accurate anticipation of market evolution, intellectual honesty requires acknowledging the limitations of this approach. One significant area where this predictive method fell short was in anticipating how natural language search would evolve.

For years, I advised against natural language search interfaces. I recommended focusing on precise filtering capabilities, logical and consistent filter behaviour, search result organisation, visual representation of how filters affect results, and informative result previews. I considered these approaches optimal because they gave users explicit control while minimising the ambiguity inherent in natural language.

When asked about “smart search” or conversational search interfaces, I would explain why they weren’t practical: machines couldn’t understand language, handle ambiguity, or provide contextually appropriate responses without extensive programming for each possible scenario.

When ChatGPT and other LLMs emerged they fundamentally changed what was possible. Users could type natural language questions and receive mostly accurate, contextually appropriate responses. The idea I had dismissed as impractical turned out not just viable but transformative.

This example demonstrates an important limitation of the Deductive Innovation approach: it works well for predicting how existing technologies will be optimally integrated and applied to solve customer problems, but it cannot predict entirely new technologies that change what’s possible.

Interestingly, while I failed to predict this technological breakthrough, the principle of imagining optimal solutions still holds. Science fiction writers had long envisioned computers that could understand and respond to natural language as the ideal interface. They recognised this as the optimal solution decades before it became technically feasible. In a sense, they applied the same principle: they imagined the ideal solution, regardless of current limitations of technology.7

This limitation reinforces an important aspect of market prediction: we must separate predicting how existing technologies will be optimally applied (where systematic analysis provides clear insights and where opportunities abound) from predicting technological breakthroughs themselves, which remain forever unpredictable.8 The most dramatic market shifts often occur when a new technology makes previously “impossible” solutions possible.

While Deductive Innovation provides foresight on the use of existing technologies, we must remain humble about the potential for technological disruption to change what “optimal” means overnight.

Share

The Challenge of Discovering Customer Problems

Even though technological breakthroughs like LLMs can disrupt market predictions, they represent the exception rather than the rule. Most market evolution follows predictable paths based on solving existing customer problems with existing technologies.

In these cases, the key to identifying optimal solutions (and thus anticipating market direction) lies in understanding customer problems at depth. This is unfortunately one of the most difficult and least understood aspects of the entire process. This challenge explains why many product teams resort to collecting feature requests or addressing surface-level pain points, rather than investing in discovering the underlying problems customers are trying to solve.

What Customer Problems Really Are

What makes customer problem discovery so difficult?

First, customers themselves rarely articulate their needs independently of solutions. They express needs as feature requests (“we need a dashboard”), pain points (“this process is so complicated”), or complaints about current solutions.

Second, the whole industry lacks clarity about what “customer problems” are, even in principle. Without a clear definition, it’s impossible to discover and analyse them systematically.

This conceptual gap directly impacts market prediction ability. Companies that only understand surface symptoms will create incremental improvements to existing solutions, while those who grasp underlying problems can envision entirely new, 10x solutions that will eventually dominate markets. The difference between these approaches is the difference between following market trends and leading them.

The Deductive Innovation approach tackles these challenges by offering a specific definition of customer problems. To recap, this definition answers the question: “What in principle is that customer problem to which a software product, as a whole, is a solution?” That kind of a customer problem describes a concrete real-world situation where a particular customer is trying to accomplish something valuable.

When we understand customer problems correctly, we can:

1. Distinguish between genuinely different customer problems that require a different optimal solution

2. Recognise which problems are common across different customers and are the basis for developing a common solution (a product)

3. Separate passing fads and trends from fundamental customer needs

4. Identify which problems, if solved optimally, would create the most value

When we conduct problem discovery, the definition helps distinguish between very different kinds of problems:

• Customer pain points, which are problems in the current solution, not the problem to which the solution is a suboptimal one

• Features, which frustrated customers ask for, but which are themselves solutions, not customer problems

• Fundamental customer problems, which exist independently of any solution

The definition differs significantly from how customer problems are commonly understood in product development. When I ask an LLM to give me examples of customer problems in the context of today’s best practices (like lean startup or service design), it typically provides examples of either pain points or features that customers “need”, neither of which are customer problems in the sense that Deductive Innovation defines the term.

Deductive Discovery is my systematic discovery method to uncover these customer problems (in addition to the name of this newsletter). It relies on contextual interviews, starting with executives and managers, and proceeds to observing the practical work of end-users. For market prediction purposes, what’s crucial is that it helps us identify problems that exist regardless of current solutions, and will therefore drive market evolution over time. This approach reveals where markets must eventually go, because it is grounded in stable customer needs rather than technological trends.

Using Customer Input as Clues to Deeper Problems

This distinction between different kinds of “problems” shows up clearly in a real B2B example.

A customer of a tool for designing telecommunications service configurations contacted the company where I worked and was clearly frustrated:

• “Importing and exporting the configurations is too slow, it takes hours,” they complained (customer pain).

• “We need a fast import and export,” they demanded (feature request).

They made it clear this wasn’t a minor inconvenience but something that was destroying their team’s productivity.

The customer clearly had a problem of some kind, and obviously something was wrong with the existing solution. But neither of these statements are that kind of customer problem to which the slow import and export features were a bad solution. Input like this from customers is important to acknowledge, but must not be taken at face value. It is a clue about where the real issue is, and acts as a starting point for problem discovery.

Subscribe now

Through deeper investigation, the actual situation where the issues arose became clear: The customer was developing new technical configurations for a large number of telco services, requiring thousands of changes to the configuration data. The existing tool was so cumbersome that making just one change easily required dozens of clicks.

As a workaround, they had exported all the data to Excel, made edits there because it was faster, and then imported the data back. Each import and export took a couple of hours. Because they were still in the design stage, they needed to test how the service configurations worked, and then edit again based on the results. One iteration of the whole process took many hours, easily as much as a full day, which was a major pain in the neck.

Engineers would often start import processes at the end of the day, returning in the morning hoping to find successful results rather than error messages. Due to complex interdependencies in the configuration data, their Excel workaround couldn’t enforce the validity of the configurations, so often the import process would end in failure, leading to hours of wasted effort. This issue was affecting project timelines and undermining morale.

Quantifying the Impact of Solving the Real Problem

The optimal solution was not a better import and export feature.

What was needed was a tool with which customers could actually design large changes to technical configurations and test them efficiently in real situations. The potential impact could be quantified, following the same 10x pattern we saw in the earlier examples:

1. Interface efficiency: Instead of dozens of clicks for one change, an optimal tool would require just a couple of clicks, roughly a 10x reduction.

2. Batch operations: An optimal tool would enable making the same change to multiple configurations simultaneously, providing another 10x reduction in effort, for a ~100x total reduction compared to the existing tool.

3. Validation speed: The Excel workaround required a 2-3-hour import process to find out if there were validation errors. The optimal tool would either prevent invalid edits or highlight them immediately, reducing feedback time from hours to seconds, for another improvement of more than 100x.

These improvements would make the overall process at least 10x more efficient than either the original tool or the workaround solution. This magnitude of improvement is what enables solutions to reshape markets.

From Problem Understanding to Market Prediction

This little example illustrates a critical principle of market prediction: companies that identify and solve fundamental customer problems optimally will eventually outcompete those who spend their development resources addressing symptoms.

Companies that focus only on immediate pain points through workarounds like faster import/export might gain short-term advantages. However, organisations that recognise and address the actual underlying problem can create solutions with orders of magnitude better Problem-Solution Fit. Over time, these 10x and 100x improvements inevitably attract customers and define the direction of market evolution.

This pattern repeats across software markets. The companies that lead markets are those who look beyond feature requests and pain points. They discover the underlying customer problems, seek the best possible solutions, and develop radically better products.

Understanding the real customer problem (the real-life situation where specific customers are trying to achieve an outcome they need) enables teams to find optimal solutions that others might miss. This understanding doesn’t improve just product development. It also informs market positioning by revealing the direction in which the market will likely evolve.

With a deep understanding of customer problems, teams can anticipate market direction and validate their vision before committing significant resources.

Validation in Practice: Reducing Risk Without Excessive Iteration

Building on the telco configuration example, let’s examine how validation works in the Deductive Innovation approach.

When I discuss how this approach enables comparing solutions analytically without customer testing, and defining optimal solutions without iterating with customers, a common concern is about customer validation.

Since customers are the ultimate judges of any product, how can we be confident in solutions defined through deduction? This concern deserves careful attention.

The good news is that validation doesn’t require building and iterating on complete products. Deductive Innovation incorporates validation at multiple strategic points in the development process. This reduces risk substantially and avoids the cycles of build-measure-learn that characterise many zero-to-one product development efforts.

A Multi-Level Validation Approach

Deductive Innovation employs a two-stage validation process that addresses risks at each critical juncture:

1. Problem Validation

Before defining any solution, we validate our understanding of customer problems across multiple customers to ensure accuracy, sufficient completeness, and commonality. This moves the first validation to the earliest possible stage of product development.

While approaches like lean startup and design thinking also emphasise validating “problems” before solutions, they tend to focus on validating pain points or gaps in current solutions. Deductive Innovation validates target customers’ real-world situations: elements like their goals, concrete circumstances, desired end-results, causal dependencies, constraints, and evaluation criteria.

Customers can easily confirm whether our descriptions match their reality because we are discussing their world as it exists today, not some hypothetical future.

Subscribe now

In the telco example, problem validation wouldn’t just confirm that “importing and exporting takes too long” (a pain point). Instead, we would validate across a few customers that they regularly face situations where they need to configure many services simultaneously. By confirming that this demanding situation occurs across customers, we validate that solving it would create significant customer value.

2. Solution Validation

Once we have designed an optimal solution, we validate the solution progressively with customers before implementation through:

• Scenario-based storytelling: Narratives that show how customers would use the solution to solve specific real-world problems (start with these)

• Storyboards: Visual step-by-step illustrations showing the solution in action

• Low-fidelity prototypes: Clickthrough user interface mockups with realistic example data that show the end-to-end interaction flow for the most important situations (most recommended)

• High-fidelity prototypes: Clickable throw-away prototypes that implement key logic for the core parts of the solution (use these only if necessary to demonstrate complicated logic)

Unlike abstract requirement documents, customers can reliably evaluate these tangible representations that show how the solution works in their real situations. For our telco example, solution validation would involve walking a customer through a mockup of a specific complex configuration scenario.

A solution designed using Deductive Design solves a previously validated concrete problem very directly. It is almost certain to resonate well with customers, unlike solutions built on assumptions. At this point, we usually need to pay attention just to catching minor details of the customer’s situation that we may have initially missed.

Success Stories of Market Leadership Through Early Validation

This validation approach has proven effective in positioning companies as frontrunners before significant development resources are committed. Two examples demonstrate how early validation of optimal solutions can secure competitive advantages.

In one case, during a competitive bid with a leading European telecommunications company where we were falling behind, my team conducted two months of Deductive Discovery with the prospect. After mapping their relevant problems comprehensively, we designed an optimal product concept based on that understanding.

When we presented our low-fidelity mockup and demonstrated how it addressed their needs, the prospect was visibly impressed by our deep understanding of their problems and our clear vision for a solution that exceeded their expectations. According to our manager who worked with the customer, this turned the tide at the last minute, securing a €5M deal we nearly lost. All based on a mockup and a plan.

This went beyond closing a single deal. The approach positioned our company as a thought leader by identifying valuable customer problems that informed the whole product suite. By understanding the challenges in a telecommunications niche deeply and designing an optimal solution, we distinguished ourselves as innovators rather than followers, all before writing a single line of code.

Another example comes from a founder I interviewed who followed a similar approach. They first researched customer needs by interviewing about 20 potential customers, then devised a solution based on their discovery. When they presented their solution concept to an early prospect, the customer immediately recognised its value: “This is so good that you should set up a new company. We’ll cover the costs upfront and act as a reference customer.” The founder added with amusement: “They basically pitched it back to us in a way that it would’ve been foolish to say no.”

This founder established a strong competitive position from day one. Their solution was so clearly superior to existing alternatives that customers were willing to fund its development. This first-mover advantage gave them a significant head start over competitors who were still developing incremental improvements to existing products.

These examples show something important about product development: when an optimal solution addresses a validated customer problem, market validation often comes swiftly. Customers recognise the value immediately because the solution aligns exactly with problems they’ve been struggling to solve.

The Validation Advantage

This validation approach offers several advantages over traditional methods:

1. Early risk reduction: Major risks are identified at the earliest possible stage before committing significant development resources

2. Reliable feedback: Customers first validate problems, and later evaluate solutions in the context of their validated problems.

3. Faster time-to-value: No time is spent building features that don’t address real validated customer problems

4. Focused development: Engineering teams work from a validated foundation rather than hypotheses

The validation advantage goes beyond reducing risk. It creates the conditions for establishing market leadership by being the first to identify and deliver the optimal solution that the market will eventually converge toward.

Subscribe now

Looking Ahead: Where Will the B2B SaaS Market Move Next?

The examples above demonstrate a repeatable pattern that can help identify where markets are heading. Based on the principles discussed, here is a specific prediction for B2B SaaS markets I’ve been making since 2018:

Share

Imagine a conference hotel chain, a residential construction firm, or a veterinary clinic. Today these businesses often rely on 20 to 100+ different software tools to operate effectively. Many are generic, industry-agnostic platforms. Others are custom-built solutions or scattered Excel spreadsheets. As a result, they must invest significant time and resources into assembling, integrating, configuring, and maintaining a fragmented IT stack.

Customers don’t want to piece together solutions. The future lies in well-integrated platforms purpose-built for specific industry niches that address virtually all customer problems in one place. The core product strategy in enterprise software should always focus on solving customers’ overall problem within a single, holistic platform that is designed as one integrated whole.

The 10x advantage of vertical platforms comes from consolidating core functionality and data, eliminating integration headaches, providing consistent interfaces, and automating cross-functional workflows that previously required manual steps across multiple systems. For businesses, this means drastically reduced IT complexity and thousands of saved hours annually. For employees, it means 10x fewer logins, interfaces to learn, and context switches throughout their day.

This market evolution has already started to play out. In the US, companies like Toast (restaurants), ServiceTitan (home services) and Veeva (life sciences) demonstrate how vertical-specific platforms can dominate their industries by addressing comprehensive sets of customer problems in an integrated way.9

This perspective is gaining increasing traction within the industry. In August 2023, Thiel Fellow Luke Sophinos predicted a “vertical SaaS tsunami” that will transform all industries.10

Many of the most successful B2B SaaS companies of the next decade will

1. identify an industry with suboptimal software solutions,

2. deeply understand their complete problem space, and

3. build integrated vertical platforms that address the problems holistically, rather than competing feature-by-feature with established horizontal solutions.

Subscribe now

Next: Your Framework for Market Prediction

These examples show that anticipating market evolution requires understanding customer problems at depth and asking: “What would be the best solution for this complete customer problem?”

This approach reveals opportunities for 10x solutions that transform experiences entirely. As we’ve seen with touchscreens, fast desktop search, and app stores, markets tend to converge on optimal solutions, and companies that implement these solutions early can capture extraordinary value.

What if you could apply this same foresight to your market?

Share Deductive Discovery

Consider the competitive advantage of anticipating where your industry will be in five years, while others make incremental improvements or chase technology trends (“We need AI!”) without clearly understanding the problems they solve. A product strategy built on validated insights into customer problems rather than guesswork or hype can mean the difference between leading the market and scrambling to catch up.

The final article of this series provides a step-by-step framework to apply the key principles of market prediction to your industry. It covers how to:

• Identify the fundamental customer problems in your industry

• Map their interconnections

• Assess where current solutions fall short of optimality

• Envision the optimal solution toward which the market will converge

• Validate your vision with early adopters

• Position your product at the destination before competitors even see the path

Continue to the final piece of the series:

This was the third part of a 4-part series on market evolution and how to predict it using Deductive Innovation. Thanks for reading! Feel free to share the article with others:

Share

Agile product development methodologies are iterative approaches to help you efficiently climb whatever hill you are on. But you might be on the wrong mountain entirely. This article explores how to identify the highest peak in your market before you start climbing, and why today’s best practices won’t get you there.

In the previous article of this series, we explored how markets tend to converge toward optimal solutions that address the complete set of customer problems with minimal complexity. This concept of “optimality” is crucial: it doesn’t mean having the most features or the sleekest UI, but rather solving the whole underlying customer problem as simply and directly as possible. The solutions that ultimately dominate markets are those that maximise value while minimising unnecessary complexity.

We also examined five mental barriers that prevent people from seeking optimal solutions:

1. The Relativism Trap (believing there are no best solutions)

2. The Measurement Challenge (the difficulty of evaluating solutions without building them)

3. The Kilimanjaro Effect (when mediocre solutions appear equally good)

4. The Cost Fallacy (assuming superior solutions cost more to build)

5. The Impermanence Fallacy (the myth that customer needs change rapidly)

These barriers keep most companies trapped in cycles of iterative improvement rather than looking for radically better solutions. In this article, we’ll examine why current methodologies struggle with market prediction and introduce an approach that helps you overcome these barriers and see where your market is heading years in advance.

Share

The Limitations of Current Approaches

The product development approaches popular today, like agile, lean startup, and design thinking, all embrace iteration as a core principle. Agile’s “responding to change over following a plan”1 makes sense when you don’t have confidence in what the best plan would be.

While these approaches excel at incremental improvement, they have a critical gap: they provide very little guidance on how to identify the best possible solution, the global optimum in the solution space. Their limitations include:

1. They are primarily responsive, adjusting based on feedback rather than anticipating optimal destinations

2. They can lead to local maximums rather than finding global ones

3. They often consume significant resources through repeated iterative cycles

4. They offer limited predictive capability for market evolution

5. They struggle with complex B2B software where the solution space is vast, and testing and iterating the entire product is prohibitively expensive

As Peter Thiel observes in his influential book Zero to One:2

Making small changes to things that already exist might lead you to a local maximum, but it won’t help you find the global maximum.

He then points to the need for more visionary thinking in building new products and businesses:

Iteration without a bold plan won’t take you from 0 to 1.

But how do we develop these “bold plans” systematically? Must we rely on a rare creative genius with visionary insights from mysterious origins (think Steve Jobs)?

Why Finding the Best Solution is So Challenging

Finding the best solution to complex customer problems is extraordinarily difficult. That is why today’s best practices rely so heavily on iteration, experimentation, and feedback cycles.

I like to compare this to the evolution of artillery. In medieval times, gunners made their best guess at aiming a cannon, fired, observed the results, and adjusted. This trial and error approach was necessary because they lacked the theoretical knowledge to calculate trajectories correctly.3 Without a robust explanatory theory of ballistics, iteration was the “best practice.”

Today’s artillery can hit distant targets with remarkable precision, often without any iteration, because we developed the physics of ballistics, differential equations, and computational methods to model projectile motion. The critical advancement was better explanations, not better cannons.

Product development for complex B2B software is still largely in its “medieval” stage. We lack widely understood, predictive theories that could explain the relationship between customer problems, solutions, complexity, and value creation. Just as artillerymen once relied on trial and error, today’s product teams rely on iteration because they lack explanatory theories about optimal solutions. In the absence of such theories, thoughtful iteration is a reasonable response. But it shouldn’t be the end state of our field.

This evolution from trial and error to explanatory theories is a pattern of human progress across disciplines. Advancements come from creatively developing better explanations that can predict outcomes in a large variety of situations, and then exposing those explanations to criticisms and testing.

Just like Newton’s discovery of the laws of motion and differential equations led to more accurate artillery, his theory of optics led to inventing a better telescope using mirrors instead of lenses. Maxwell’s theory of electromagnetism explained electricity and magnetism and predicted the existence of electromagnetic waves, which led to the invention of radio. Discovery of quantum mechanics led to the invention of the transistor.

When it comes to product development, we need to be able to explain the causal relationships between customer problems, aspects of software solutions, and customer value. This understanding will enable any product team to identify optimal solutions, not just those blessed with extraordinary intuition or luck. This is where Deductive Innovation comes in.

Deductive Innovation: Finding the Global Maximum Systematically

The Core Concept: From Iteration to Prediction

Deductive Innovation represents a shift in approaching product development: moving from iteration toward prediction, from guesswork toward knowledge.

The central promise is: could we consistently identify optimal solutions before competitors? Not marginally better solutions, but ones that are 10x better, the kind that eventually dominate markets?

As Peter Thiel observes in Zero to One:

As a good rule of thumb, [a solution] must be at least 10 times better than its closest substitute in some important dimension to lead to a real monopolistic advantage. Once you’re 10x better, you escape competition.

This kind of 10x improvement is achievable in the complex world of B2B software where current solutions are often far from optimal. But achieving this level of improvement requires a different approach to product development. Thiel had a suggestion:

You can make a 10x improvement through superior integrated design.

Deductive Innovation is a structured approach to creating exceptional integrated designs in the complex B2B software space. I have developed it over 20+ years of working with software products across multiple industries. It addresses the shortcomings of common product development and design methods when it comes to complex software products that support customers’ functional needs.

The Four-Step Deductive Innovation Process

Breaking from the limitations of iterative approaches, Deductive Innovation follows a defined sequence to design an overall solution concept before resources are spent on building it.

Rather than immediately diving into customer problem discovery, which itself requires resources, we first determine if an opportunity merits that investment:

1. Measure improvement potential before investing in problem discovery (Deductive Evaluation): We first evaluate if a product opportunity has sufficient potential to create customer value compared to existing solutions. This analytical measurement approach helps us focus only on opportunities with potential for at least 5x-10x improvements in Problem-Solution Fit.

2. Discover customer problems with sufficient depth for deduction (Deductive Discovery): For opportunities with high potential, we discover, map, understand and validate the customer problem space in a very particular way. The key criterion is gathering sufficient facts about the customers’ world to make the next stage possible.

3. Design the solution by deduction from customer problems (Deductive Design): Using this detailed problem understanding, we deduce the optimal solution, potentially years before competitors.

4. Build the solution incrementally, starting where most customer value can be created with least resources, taking into account the dependencies between different parts of the overall optimal solution, and prototyping technologies to reduce feasibility risk.

Deductive Innovation reverses the traditional approach. Instead of ideating and building a solution (or even a prototype) and iterating based on feedback, it first measures value creation potential, then builds the specific knowledge about customer problems necessary to deduce optimal solutions, and only then starts investing in technology development.

This approach delivers unique advantages for developing B2B SaaS products to solve complex customer problems. While traditional methods might eventually reach the same destination through countless costly iterations, Deductive Innovation provides a map to the optimal solution before significant resources are committed. This reduces development waste and the risk of building the wrong product, shortens time-to-market for the simplest possible complete solution by years, and positions your product as the category leader from launch.

How Deductive Innovation Measures Optimality Objectively

The core of Deductive Innovation is a precise, objective approach to measuring Problem-Solution Fit: how well solutions solve customer problems. This addresses a gap in today’s methodologies: the inability to compare alternative solutions without building and testing them with customers.

In Deductive Innovation, a “customer problem” has a specific meaning: it describes a concrete situation where a particular target customer is trying to accomplish a valuable result. Expressed as one concrete example, a properly understood customer problem contains:

• Starting point: What initiates the situation, when and why?

• Desired end-result: What they are trying to accomplish in that situation, and why?

• Circumstances: Aspects of the situation that cannot be changed by a solution, such as location, available resources, hard constraints, causalities and dependencies.

• Evaluation criteria: How the customer judges both the end-result and the process of reaching it?

All these elements exist independently of any solution and can be discovered through systematic research. The customer’s own evaluation criteria are parts of the problem itself, not subjective opinions of the solution developer.

With this understanding, we can objectively measure alternative solutions against two dimensions:

1. End-result quality: How good an end-result the solution enables customers to achieve, in principle, based on their own success criteria?

2. Process efficiency: How well customers can achieve that result, in practice? This is almost always defined in terms of speed, ease of use, and risk.

   • The primary measure is the number of actions the solution requires the customer to take to achieve the result, at a minimum. This can be objectively counted for any solution.

   • There are further more refined analytical measures e.g. for functional coverage (completeness of the solution), efficiency (proportion of required actions that are actually necessary), learnability (intuitiveness), reversibility (recovery from errors).

By counting actions across alternative solutions addressing the same problem, we often find order-of-magnitude differences that represent radical shifts in solution quality. This approach makes solution comparison objective and measurable without extensive user testing. The validity of the measurement depends on the validity of the customer problems.

Subscribe now

Deductive Innovation allows us to predict which solution will create far more value before investing in development, while empirical testing remains valuable for fine-tuning the details.

Most importantly, Deductive Innovation enables seeing where the market is headed long before competitors, giving us a first-mover advantage in creating the solution that will eventually dominate.

Breaking Through the Mental Barriers to Optimal Solutions

In the previous article, I identified five mental barriers that prevent product teams from pursuing optimal solutions. These deeply ingrained assumptions limit our ability to even ask the question “what is the best solution to this problem?”

Understanding these common barriers and how Deductive Innovation addresses them will give you valuable insight into why this approach works so well for developing B2B software products.

1) The Relativism Trap: “There are no best solutions”

The Relativism Trap, as described in part 1 of the series, is the common belief that there are no best solutions, making it pointless to seek them.

Deductive Innovation breaks through this trap with a simple mathematical fact: if we can compare alternative solutions, then a best solution necessarily exists.

To enable these comparisons, Deductive Innovation begins by discovering customer problems as objective facts in the world, independent of solutions. The criteria customers use to judge solutions are recognised as an inherent part of these problems.

While there aren’t “universally best” solutions that work in all possible contexts, specific situations do have optimal solutions. Different problems require different solutions, as I demonstrated in my earlier article by comparing alternatives for boiling water. The best solution depended on each specific situation.

As product developers, once we have discovered and chosen which problems to solve, we have the objective basis for comparison between alternative solutions.

2) The Measurement Challenge: “Only empirical testing produces reliable knowledge”

The Measurement Challenge refers to the difficulty of evaluating complex B2B solutions objectively as a whole, because testing them in real-life conditions is prohibitively expensive.

However, empirical testing is not the only way to acquire reliable knowledge. We don’t need an unethical test to find out whether a cow would die if dropped from an airplane at 1000 metres. Our understanding of the causes and effects that govern the situation gives us certainty without experimentation.

Similarly, instead of relying just on testing with customers, Deductive Evaluation measures solutions analytically against concrete instances of customer problems before anything is built. Because we know what a customer is trying to accomplish in a particular situation, we can measure how good a result a solution enables and what it requires the user to do. We obtain objective measurements with orders of magnitude less effort than empirical testing: hours instead of person-years for large solutions.

For example, imagine two solutions for planning delivery truck routes. One requires the user to manually try alternatives, and it takes 1218 actions to find just one feasible plan in a specific complex situation. The other uses an optimisation algorithm that incorporates customer’s criteria and constraints for good routes, evaluates millions of alternatives, and reduces delivery times by 10% with no user intervention. The superior solution is obvious without empirical testing.

This approach works best for:

• functional needs (rather than emotional, aesthetic or social needs)

• products used for their instrumental value (rather than intrinsic value)

• large and complex customer problems

• frequently-used products where customers value productivity

That makes Deductive Evaluation ideal for measuring and comparing B2B software solutions.

3) The Kilimanjaro Effect: All Solutions Appear Equally Good

In the first article, we used Mount Kilimanjaro to illustrate how existing solutions often appear equally good because they are all similarly far from optimal.

Deductive Evaluation provides two critical capabilities to overcome this effect:

First, it enables us to measure Problem-Solution Fit objectively, so we can map the “altitude” of the solution landscape around Kilimanjaro. Often, we find that existing solutions are similarly mediocre, just in different ways, all lying on the low plains surrounding Kilimanjaro.

More importantly, we can measure how much better the Problem-Solution Fit could be without even designing a new solution. We can quantify potential improvement. While Deductive Design is required to actually locate the global maximum, if we find room for 9x, 12x, or 21x improvement, we know the highest peak is worth mapping.

The Kilimanjaro metaphor also shows how Deductive Innovation and iterative methods complement each other. Deductive Innovation identifies Kilimanjaro (the global optimum), while iteration can help climb to the peak once you’re on the right mountain.

4) The Cost Fallacy: “It costs more to build a better solution”

As discussed in the first article, the Cost Fallacy assumes superior solutions cost more to build, a misconception that is especially pronounced in B2B software.

Deductive Evaluation exposes why this doesn’t hold: When evaluation reveals that an optimal solution would require 10x fewer user actions than existing alternatives, it implies current solutions contain enormous unnecessary complexity. This customer-facing complexity creates unnecessary internal technical complexity too, often compounded by years of iteration and accumulated architectural debt.

The optimal solution is always the simplest one that fully addresses the complete customer problem. Deductive Innovation identifies this simplest solution, eliminating unnecessary complexity from both the customer’s perspective and the technical implementation.

By pursuing optimality from the start, we can simultaneously reduce development costs, speed up time-to-market of an optimal solution, and increase customer value, turning the traditional “good, fast, cheap: pick two” constraint on its head.

5) The Impermanence Fallacy: “Customer needs change fast and we must adapt”

The Impermanence Fallacy, as we explored in the previous article, is the myth that customer needs change rapidly. This stems from confusing solutions with problems. While solutions evolve quickly with technology, the underlying customer problems remain stable over long periods.

Deductive Innovation addresses this by:

• Providing a novel definition of what “customer problems” are, in principle, enabling companies to distinguish enduring problems from evolving solutions

• Offering methods to discover these stable problems through systematic research

• Building long-term product strategy on this stable foundation

Understanding this stability gives you the confidence to make substantial investments in understanding customer problems deeply. As technology evolves faster than ever, this deep problem knowledge becomes more valuable than ever. As late Steve Jobs famously said:4

You’ve got to start with the customer experience and work backwards to the technology. You can’t start with the technology and try to figure out where you’re going to try to sell it.

Deductive Innovation gives you a methodical way to follow his advice, allowing you to work backward from stable customer problems to ideal solutions.

Rather than chasing technological trends, companies adapt new technologies to solve customer problems, and create optimal solutions that remain relevant for extended periods despite technological change.

Subscribe now

Addressing Six Key Concerns About Deductive Innovation

Given how much Deductive Innovation differs from today’s best practices, it usually raises important questions and concerns that prevent experienced software professionals from embracing it.

1. “Isn’t This Just Waterfall Development?”

When I describe Deductive Innovation’s emphasis on discovering problems before designing solutions and defining the optimal solution before building it, almost all competent software professionals immediately ask: “Isn’t this just waterfall development with a new name?”

The concern is understandable. The waterfall model’s notorious failures led to the agile revolution. But Deductive Innovation differs from traditional waterfall development in critical ways.

Waterfall asked customers to provide “requirements,” which were essentially solution descriptions that customers cannot reliably produce. There’s no way to validate if such requirements are correct or complete until after building the solution. In countless cases when the customers finally got their hands on the software, the solution turned out problematic in multiple ways, if not a complete failure. This often happened 1-3 years after development started.

In contrast, Deductive Innovation starts the whole software process with something customers can validate: their problems, expressed as concrete situations that occur in their world. Customers can easily recognise if our description of their problems and situations matches their reality. We can validate our understanding of problems before we spend any thought on solutions.

As long as the customer problems we have mapped are valid and described in a way that enables deducing the solution, correct application of the deductive process will produce a good solution that is likely to impress customers when we validate it with them.

Leave a comment

2. “How Can You Evaluate Without Customer Testing?”

Another common concern is: “How can you evaluate solutions without extensive customer testing? Aren’t customers the ultimate judges of any product?”

This question gets to the heart of the Measurement Challenge we discussed earlier. For B2B software that serves functional needs, we can analyse how well a solution addresses specific aspects of customer problems without building the product.

The key is having a sufficiently detailed understanding of the customer problem expressed as a particular instance of a real-life situation, including the concrete circumstances, stakeholders involved, goals, desired outcomes, and evaluation criteria. With this understanding, we can reliably predict how specific aspects of the solution will impact the use of the product and the value it creates for customers.

3. “This Limits Creativity”

“But what about real innovation? Doesn’t this approach limit creativity and breakthrough thinking?”

This concern misunderstands the relationship between constraints and creativity. Deductive Innovation enhances innovation by focusing creative energy on solving the problems that are actually novel and unique, instead of using ideation to come up with suboptimal solutions to recurring problems that can be solved directly by deduction.

I like to compare this to mathematics. You could solve a group of linear equations by guessing and iterating, but an analytical method, Gaussian elimination, gives you the right answer straight away. But you certainly need lots of creativity and new ideas to solve unsolved unique problems, like proving the Riemann Hypothesis.

The most innovative products are precise answers to well-defined problems, not random strokes of genius. By understanding customer problems deeply, you create a fertile ground for meaningful innovation that delivers actual value rather than novelty for its own sake.

4. “This Doesn’t Work for Emerging Technologies like AI”

“This might work for established markets, but what about emerging technologies where customer problems aren’t well-defined yet, like generative AI or AI agents?”

Customer problems exist before solutions, even with emerging technologies. When cloud computing emerged, the problems businesses faced (like managing IT infrastructure, scaling computing resources efficiently, reducing capital expenditure) hadn’t changed. The technology simply offered a better way to solve them.

By identifying which stable customer problems a new technology could address more optimally, you can predict its eventual application and impact.

5. “This Slows Us Down in a Fast-Moving Market”

“But what about fast-moving markets where speed is critical? Won’t this approach slow us down?”

This is a common misconception. While Deductive Innovation requires a small team of 1-3 people to spend a few weeks or months on upfront problem discovery, it accelerates overall time-to-market for complete solutions by minimising costly wrong turns, eliminating major pivots, and preventing accumulation of unnecessary complexity. This creates a favourable return on investment: a small, focused effort that prevents the much larger waste of building the wrong product or refining a suboptimal solution.

In markets where companies rapidly develop better solutions to existing problems, those with deep customer understanding actually move faster because they aren’t wasting resources on incremental improvements or solving the wrong problems entirely.

Being first is also overrated compared to being significantly better. Market leaders like Apple, Zoom, Figma, HubSpot and Shopify weren’t first movers, they were better movers. They entered established markets with superior solutions that redefined customer expectations. Their success came from understanding deeply what customers needed and delivering solutions with far better Problem-Solution Fit.

6. “This Leads to Analysis-Paralysis”

There is a crucial distinction between deep problem analysis and analysis-paralysis. Analysis-paralysis occurs when teams get stuck in research without being able to make decisions. This often happens because they lack clear criteria for what information to discover and what constitutes “enough” understanding.

Deductive Innovation addresses these root causes directly. We conduct focused, bounded discovery with a clear purpose: gathering precisely the information needed to understand customer situations and deduce effective solutions. This research has well-defined completion criteria: we have gathered enough when we can measure complete solutions analytically for specific customer situations. Unlike open-ended exploration, the discovery process targets only elements relevant to designing solutions.

When I use terms like “optimal” and “best,” I mean them aspirationally, not literally. In markets where existing solutions are far from optimal, finding a solution that’s 80% of the way to perfection creates 10x improvements. Given that 10x represents a 1000% improvement, the last 20% matters little compared to identifying the right mountain to climb in the first place. Once the solution is on the right mountain, iteration works fine to refine the product.

Deductive Innovation includes built-in safeguards against actual paralysis. We can validate our problem understanding with customers before solution design, validate our solution concepts before development, and build incrementally once we have identified the right destination. Rather than paralysing progress, this sequential risk-reduction approach accelerates time-to-market for valuable solutions by eliminating expensive rework.

These clarifications help distinguish Deductive Innovation from both traditional waterfall development and iterative approaches. To make these distinctions clearer, let’s compare it directly with today’s best practices.

Comparison With Today’s Best Practices

To see how Deductive Innovation differs from conventional product development practices in practice, consider the comparison table below.

This comparison highlights why Deductive Innovation is particularly valuable in B2B and Enterprise SaaS contexts where existing solutions are far from optimal. While traditional methods excel at incremental improvements, they are less equipped to identify big opportunities in a complex problem space.

Next: From Theory to Practical Examples

In the next article, we will move from theory to practice. I will share real examples of major market predictions that proved accurate years in advance. The predictions were based on structured analysis rather than luck or genius. You will also learn practical steps to developing your own market prediction capabilities and validating your solutions without expensive trial and error.

This is the second part of a 4-part series on market evolution and how to predict it using Deductive Innovation. Continue to Part 3 of the series:

Subscribe now to be notified when the next article is published, and receive your free report “How to Build a Lasting Competitive Advantage in B2B SaaS” packed with insights from in-depth interviews with 31 B2B SaaS product executives and founders:

The Unfair Advantage: How Market Leaders See Years Into the Future

You can predict market direction by asking “what is the best solution to this problem?”

That deceptively simple question, shared by a CTO whose eight-figure B2B SaaS company is growing 40% annually, reveals a hidden truth about product evolution. While markets often appear unpredictable, they actually tend to follow a consistent pattern: markets converge toward optimal solutions.

Most product teams operate in perpetual reaction mode, frantically implementing features, chasing feedback, and burning resources just to maintain their market position. Meanwhile, market leaders quietly position themselves at the optimal solution where the market will eventually arrive.

This pattern proves itself repeatedly. Consider smartphones: the market ultimately converged on large touchscreen devices, despite early resistance. Or video conferencing: Zoom had recognised that customers valued one-click simplicity and rock-solid reliability, and optimised its product accordingly. When the pandemic hit, it had the best solution in a fragmented market. Zoom zoomed past its competitors, leaving them scrambling to copy its approach to the core video conferencing experience.

In both cases, companies that anticipated and built the best solution first gained a massive lead, and left competitors playing costly catch-up. Despite their efforts, Nokia and BlackBerry couldn’t recover. Microsoft had to abandon Skype for Business and urgently upgrade Teams’ video capabilities.

The Choice: Reactive Gambling vs. Predictive Confidence

Most B2B SaaS companies follow a reactive, iteration-heavy approach. But a different path is available for more ambitious and visionary ones:

A Conventional Reactive Path (Where Most Companies Are)

1. Invest in building something based on limited understanding

2. Gather customer feedback, complaints and feature requests

3. Iterate to fix issues and improve

4. Burn years and millions and gradually approach better solutions for complex B2B problems

A Predictive Path (That Creates Unfair Advantages)

1. Discover the customer problem space, independent of today’s solutions

2. Reason out what the optimal solution for these problems must be

3. Build directly toward that optimal solution

4. Gain years of advantage while competitors waste resources on trial and error

What if you could position your product at the destination where your market will arrive, long before your competitors even see the path?

The difference is real. Zoom positioned itself at the intersection of reliability and simplicity years before competitors recognised these as the critical factors. When circumstances suddenly changed, they didn’t need to pivot. They were already where the market would converge.

Your Path to Market Domination Through Prediction

Over the next four articles, I’ll show you how to develop this predictive capability and create first-mover advantages your competitors cannot overcome:

• Part 1 (this article) explores the pattern of market convergence toward optimal solutions and the five mental barriers that prevent most companies from taking advantage of it.

• Part 2 introduces a systematic methodology for market prediction that overcomes the limitations of traditional product development approaches.

• Part 3 demonstrates the effectiveness of this approach through real-world examples where I and others predicted major market shifts years before they happened.

• Part 4 provides a practical framework you can apply to your own business to predict and lead your market’s evolution.

I understand this challenges today’s best practices. The software industry has embraced iteration so completely that the idea of predicting optimal solutions may seem impossible. But conventional wisdom conflates two distinct challenges: predicting technological breakthroughs (which is indeed impossible) and predicting how existing technologies will be optimally applied to solve stable customer problems (which is surprisingly predictable).

This predictive capability isn’t reserved for rare visionaries or lucky guessers. It’s a systematic skill you can develop by understanding the hidden pattern driving market evolution.

The Convergence Law: How Markets Flow Toward Optimal Solutions

If you examine the history of many successful product categories, you will notice something striking: markets eventually converge toward optimality.

What does “optimal” really mean though?

True optimality arises when a product solves the whole underlying customer problem with minimal complexity. Optimality isn’t about feature count or UI polish.

The companies that lead markets don’t chase competitors or feature requests. They first identify what the best solution must be like, then relentlessly execute toward it, and arrive at the optimal Problem-Solution Fit first.

One important exception to this pattern deserves attention before we go further.

The Network Effect Exception: When Being First Beats Being Best

While markets generally converge toward optimal solutions over time, there’s one significant exception: products with strong network effects. In these cases, a product’s value depends primarily on how many others use it, creating a barrier to displacement even by superior solutions.

Network effects exist on a spectrum from minimal to overwhelming. The stronger the network effects, the less Problem-Solution Fit determines market convergence. If network effects are dominant, timing and aggressive scaling often become more important than solution quality.

In markets with overwhelming network effects, like social media platforms or messaging apps, even solutions with significantly better Problem-Solution Fit struggle to displace established players. The switching costs become prohibitively high as users would lose connection to valuable networks by moving to an otherwise better alternative.

For most B2B SaaS product categories, however, Problem-Solution Fit remains the primary driver of long-term success, with network effects playing a secondary role. Business intelligence tools like Tableau, accounting software like Xero, and HR systems like Workday create value primarily through their functionality rather than their user networks. Asking the question “what is the best solution to this problem?” provides strong predictive capabilities and helps achieve market leadership.

Subscribe now

Market Friction: Why Some Industries Resist Optimal Solutions Longer

Competition is the engine that drives markets toward optimal solutions. Without it, there’s little incentive to improve. Several factors may reduce competitive pressure:

1. Monopolies: In monopolistic or highly concentrated markets, whether created by regulation or market consolidation, convergence slows down or even stalls.

2. High switching costs: B2B software often creates substantial switching costs. While these don’t prevent convergence, they slow it down compared to B2C software.

3. Market opacity: When customers lack information about alternatives or cannot easily evaluate solution quality, inferior solutions persist longer. This is often the case in B2B software, and especially enterprise software, where assessment requires deep domain expertise.

Two out of these three forces slow down convergence specifically in B2B SaaS. In typical B2B SaaS categories, meaningful convergence might take:

• 2-4 years for simple tools with low switching costs

• 4-8 years for departmental solutions with moderate complexity

• 8-15+ years for complex enterprise-wide systems

Slow convergence is an advantage if you are seeking the best B2B SaaS solution. It gives you more time to research customer problems and figure out what the best solution must be like, and then build it incrementally without a panic or rush. And when the optimal solution has a 10x better Problem-Solution Fit than existing solutions, you can much more easily overcome high switching costs and demonstrate your solution’s superiority over existing solutions in an opaque market.

Despite the advantages of slower convergence, many B2B software companies fail to capitalise on the opportunity to identify optimal solutions. I have identified five common mental barriers that seem to prevent product teams from even asking what the best solution might be.

Five Mental Barriers Blocking Your Path to Market Dominance

If finding the best solution is so advantageous, why do most product teams remain trapped in cycles of iteration and incremental improvement? Why do they continue suffering through painful quarter-ends, explaining missed targets, and hoping that the next release will finally deliver breakthrough results? Five specific mental barriers prevent even experienced product teams from escaping this reactive cycle and claiming the advantages of identifying optimal solutions.

1) The Relativism Trap: How “Different” Sabotages “Better” Solutions

Modern culture is permeated by relativism, the misguided idea that all beliefs and interpretations are equally valid. As David Deutsch argues, this mindset stifles progress by discouraging the comparison of ideas and the search for better solutions.1 Anyone heavily invested in relativism rejects the concept of a “best” solution because it doesn’t fit their worldview.

In product teams this manifests as a reluctance to make definitive judgements about the quality of solutions. Instead people discuss opinions: “I don’t like that” or “this feels right to me.” Or they hide behind phrases like “it depends on the user” or “different customers have different preferences.”

To overcome this trap, we need objective criteria for measuring and evaluating solutions based on how well they address customer problems.

2) The Measurement Challenge: Why Empirical Testing Keeps You Playing Catch-Up

If we accept that some solutions can be better than others, we still need to be able to measure them objectively to see which is better.

The only generally known approach to measuring Problem-Solution Fit objectively is empirical testing with customers. For enterprise software products, valid results about the overall fit would require designing, building, deploying, and having a few target customers use the whole solution in real-life conditions. To compare alternatives, we would need to develop multiple solutions and collect significant data to overcome measurement noise2, which is clearly infeasible for all but the smallest pieces of software.

Testing with customers works well enough with small products that are used for relatively small tasks if testing can be done with prototypes rather than production code. But we cannot test user performance in many important scenarios, like complex long-lasting planning work. We can test at most small pieces of the overall process.

While we can measure the overall Problem-Solution Fit of a large enterprise software product in principle, we can’t in practice. And what we can’t measure, we can’t improve. People lose sight of the possibility of radical differences in Problem-Solution Fit, and stop asking what the best solution would be.

What instead gets measured is the cost of building the solution, which is easy, but not the result of that investment. This leads to short-term thinking and concentration on inexpensive incremental improvements, but eventually to an unnecessarily complex product that’s at best a local maximum in the solution space.

3) The Kilimanjaro Effect: Why All Current Solutions Look Equally Mediocre

When one solution outperforms another by an order of magnitude, precise objective measurements become unnecessary. The difference is so blatantly obvious that even relativists will acknowledge it.

However, in B2B and enterprise software, alternative solutions to the same customer problem are often similarly mediocre. One solution has certain strengths and weaknesses; another has different ones. When all solutions are very suboptimal, just in different ways, determining which is best is practically impossible.

Think of it like this altitude map of Mount Kilimanjaro where each point represents a different solution. The altitude corresponds to Problem-Solution Fit. The vast surrounding plains (colour-coded in green) vary in height by only 400 metres or so.

But the peak rises 4500 metres above the plains, a 10x difference. This dramatic elevation gain is typical of the improvement potential in the B2B SaaS space, and Enterprise SaaS in particular.

When all available solutions are far from optimal, meaningful differences become hard to detect. People begin to believe there are no better or worse solutions, just different ones, and stop looking for the best solution.

4) The Cost Fallacy: Why Market-Dominating Solutions Can Cost Less to Build

Product leaders often believe that better solutions demand proportionately higher investments. It’s the “Good, Fast, Cheap: Pick Two” fallacy applied to product development.

This belief is understandable. In any area of life where existing solutions are close to optimal, all choices require making trade-offs, so the fallacy likely holds true. In physical manufacturing, for example, 10x better products might require 10x more expensive materials or manufacturing processes.

But when existing software solutions are far from optimal, typically overly complex both internally and externally, building the best solution can actually cost less, not more.

Consider:

• Zoom vs. WebEx: Cisco’s WebEx was encumbered by years of accumulated complexity. Zoom focused on what really mattered (reliability and simplicity) and built a superior solution that required fewer developers and less time.

• Salesforce vs. early CRM systems: Salesforce didn’t outspend Siebel to build their cloud CRM. They recognised the optimal solution, a cloud-based subscription model, when others were stuck in on-premise thinking.

• Slack vs. Skype for Business: Skype for Business was burdened with legacy infrastructure, complex integrations, and bloated features. Slack built a more elegant, focused solution with a smaller development team and budget.

These examples illustrate the premise of this article series: Markets move toward optimal solutions that address customer problems with minimal complexity. When existing solutions are complex, bloated, and far from optimal, there’s an opportunity to build something both superior and less expensive.

By identifying what the optimal solution must look like, as Zoom, Salesforce, and Slack did, you can anticipate market evolution and position your product at the destination where the market will eventually arrive. Companies that predict this movement gain an enormous first-mover advantage that’s difficult for competitors to overcome.

The optimal solution is always the simplest one that fully addresses the complete customer problem. Complex solutions to the same problem require more code, more maintenance, more documentation, more testing, and more customer support. By deeply understanding customer problems and pursuing optimality, you can simultaneously reduce costs and increase value.

Sometimes building the optimal 10x solution might require 2x the development resources of an incrementally better solution, but not 10x more. While it costs more, the return on this investment is exponential: premium pricing, dominant market share, reduced support costs, faster sales cycles, and customer loyalty.

The real cost isn’t building the optimal solution; it’s the years spent iterating, extending, maintaining, and supporting suboptimal ones. Many product teams could save enormous resources by figuring out the best solution upfront, rather than paying the perpetual tax of complexity.

5) The Impermanence Fallacy: The Dangerous Myth of “Rapidly Changing” Customer Needs

A widespread belief in product development is that customer needs are constantly changing, necessitating continuous iteration and pivoting. This misconception leads teams to conclude that predicting optimal solutions is futile. Why bother mapping the complete problem space if it will be different tomorrow?

This fallacy stems from confusing solutions with underlying problems. Solutions evolve rapidly with technology, but the customer problems they address remain stable over long periods. When correctly understood, customer problems are situations that people and businesses have encountered for years, decades and in some cases even centuries or millennia.

A few examples:

• People have been making tea to relax for hundreds of years (the example I used in my earlier article)

• Surgeons have been trying to repair damaged tissue for centuries

• Accountants have been trying to track and report financial transactions for generations

• Shopkeepers have been trying to match the supply in their stores with customer demand for millennia

• Telecom operators have been trying to balance network capacity with demand for decades

The underlying customer problems, understood independently of solutions, change remarkably slowly. What changes rapidly over time are the tools, methods, technologies, products and services that companies offer to help solve those problems.

This stability is what makes market prediction possible. By understanding your customers’ enduring problems in depth and detail, you can deduce characteristics of optimal solutions that will eventually dominate.

Coming Next: The Blueprint for Seeing Your Market’s Future Before Competitors Do

In this article, we have explored the hidden pattern of market evolution toward optimality and the five mental barriers that prevent many people from seeing this pattern. We have discovered that the stability of customer problems provides the foundation for predicting market direction years in advance.

But a critical question remains: If traditional product development approaches like agile, lean startup, and design thinking weren’t designed for prediction, what methodology can fill this gap?

In the next article, we will explore why traditional product development approaches fail to use these stable patterns, and introduce a systematic methodology for predicting market evolution well ahead of your competitors. You will discover an inherently different approach to product development, one that relies on a structured process for identifying optimal solutions before the market discovers them, rather than on luck, genius, or slow iteration.

The companies that master this approach will shape markets rather than follow them, and create sustainable competitive advantages that last many years rather than a few quarters. They will build products that seem to anticipate customer needs before any customer ever asked for such solutions.

I have spent over 20 years developing and refining this approach, and I’m convinced it represents a fundamental advancement in how we create B2B software products. Join me in part 2 of the series as we explore this methodology in detail.

This is the first part of a 4-part series on market evolution and how to predict it using Deductive Innovation. Continue to Part 2 of the series:

They were certain they’d nailed it.

The product team was ready to launch their AI-powered solution with what seemed like the perfect pricing model. AI would automate analysis and decisions, and enterprise customers would pay €2 only for successful outcomes. No success, no charge.

“We had what we thought was a good idea,” the Chief Product Officer told me. “The pricing would be based directly on the value received by the customer.”

The team was confident. The model was elegant, fair, and aligned incentives with outcomes. But the market had other plans.

Why Value-Based Pricing Seems Inevitable for AI

If you’ve been anywhere near B2B SaaS in the last few years, you’ve heard the gospel of value-based pricing. Experts have consistently recommended this approach: “Don’t charge for seats. Don’t charge for features. Charge for value!” I’ve expounded it myself too.

Value-based pricing seems especially suited to AI products. As Kyle Poyar explained in his October 2024 newsletter article on AI monetization, “We’re moving away from charging for access to software and toward a model of charging for the work delivered.”

AI changes what’s being sold. Instead of humans logging into software, algorithms perform work directly with measurable outputs: tasks completed, conversations held, predictions made. This creates a natural opportunity to align pricing with value created rather than seats purchased, a goal that was previously elusive in traditional software.

Several major companies have already moved in this direction:

• Intercom pioneered paying per resolution with their AI customer support agent at $0.99 per successful resolution

• Zendesk followed with a similar model of charging per successful autonomous resolution

• Salesforce went all-in on “Agentforce” at $2 per conversation

• 11x charges per task completed by AI sales development reps

According to Poyar’s research, this value-based approach allows companies to capture 20-25% of the economic value they deliver, compared to just 10-15% with traditional subscription models (see image below).

Our CPO’s team wasn’t making a rookie mistake. They were following the playbook written by the industry’s forward thinkers.

Reality Check

“Our pricing was done wrong, to put it bluntly.”

What should have been a triumphant launch instead led to months of struggle.

“It wasn’t a successful launch. It took a long time until we reached a commercially good place with it,” the CPO admitted.

The team had built exactly what pricing theory recommended, but the market rejected it. The CPO was blunt about why:

“In a way, it was of course a very elegant and nice idea. But it was quite complex. And then it wasn’t predictable.”

Two problems: complexity and unpredictability. They were enough to derail the entire strategy.

Share

When Predictability Beats Value Alignment

“When we later changed our pricing model to a pure subscription fee, which wasn’t in any way volume-based, we started selling much more.”

I was surprised to hear this. After months struggling with their value-based model, they switched to a simple flat subscription, the approach experts were calling outdated for AI products. And sales took off.

“It sounds foolish. Why wouldn’t a customer want to pay only for the value produced?” the CPO reflected. “But ultimately, enterprise customers valued predictability more. They wanted to know how much this would cost them.”

Kyle Poyar documented the same pattern in his January 2025 article, where he noted a growing objection: “As AI agent businesses continue shifting away from seat-based pricing and toward charging for units of work delivered, they tend to encounter a nagging objection from customers: your pricing is too complicated and too hard for me to predict.”

Subscribe now

Enterprise Procurement: Why Finance Says “No”

When I pressed on why predictability matters so much to enterprises, the CPO explained the organisational dynamics that value-based pricing models overlook:

“Conversations about purchases tend to be more difficult with the CFO when the price isn’t fixed,” he explained. “If you say this will cost something between €30,000 and €60,000, finance immediately asks: ‘Is €60,000 the absolute maximum?’ ‘Well, no.’ ‘Then what is?’ It just becomes a more difficult conversation.”

He also pointed to a mismatch between how costs and benefits materialise: “The savings come from working hours. The savings don’t directly materialize into anything—you need to take additional actions. You need to either reduce staff or move them to other tasks.”

This is why value-based pricing creates friction: “When you have a directly variable cost [value-based pricing tied to outcomes] that’s supposed to save slowly-changing costs [labor], the equation in the decision-making situation is not so simple.”

Practitioner Insights Ahead of Industry Best Practices

Poyar’s thinking has evolved on this issue. In his October 2024 article, he acknowledged potential challenges: “Traditional enterprise procurement departments are (probably) 0% prepared for an unpredictable bill—even if that bill is better aligned with ROI.” But this was a brief aside, not a central concern.

By January 2025, however, this had emerged as a primary objection to value-based AI pricing, exactly what our CPO had discovered through painful experience many months earlier.

Industry best practices are catching up to what practitioners have already learned the hard way: enterprise buying decisions depend on buyers’ preferences and organisational complexity as much as on economic value.

How to Balance Value and Predictability?

So how did our CPO’s company turn things around?

They simplified. Their “pure subscription fee” removed the complexity that had been scaring away potential enterprise customers. No usage metrics, no outcome calculations, just a straightforward monthly cost.

This runs counter to much of the current advice about AI pricing, but the results speak for themselves.

That said, I think the industry shouldn’t give up. Value-based pricing can be advantageous both for the software vendor and the customer. There’s potential both for a lower total cost of ownership (TCO) for the customer and greater pricing power for the vendor.

Some companies are finding creative ways to address the predictability problem while still capturing more value than a pure subscription offers. According to Poyar’s latest research, several approaches are emerging.

The AI “FTE” Model

One solution Poyar highlights is positioning AI as a “Full-Time Employee (FTE) equivalent.” Companies such as 11x map the typical output of a human employee (for instance, an SDR might research X accounts and send Y emails), package it as a SKU, and price it at 20-35% of what hiring a person would cost.

As Poyar explains: “It translates complex pricing into something that feels predictable and value-based. Buying AI credits for ‘tasks’ completed by an AI SDR? That feels like a lot of math. Buying the equivalent output of a human SDR? That’s much easier to wrap your mind around.”

Skill-Based Pricing Tiers

Another approach Poyar identifies is moving from feature-based to skill-based pricing tiers. If the customer is hiring AI to do a job, software vendors must un-gate access to whatever features are needed to get the job done. More access to features leads to more jobs done which leads to more money, particularly if the pricing is based on units of work. Customers are willing to pay for higher skilled work:

• Good: “Do the job cheaply” (think intern level)

• Better: “Do the job well and for a fair price” (college grad level)

• Best: “Do the job quickly and perfectly” (experienced hire level)

Instead of gating features, companies charge more for higher skill levels, faster outputs, greater accuracy, or human verification.

Share

Creative Enterprise Accommodations

Poyar also suggests ways to make usage-based pricing more palatable to enterprise procurement:

• Annual draw-downs: Letting customers flexibly use their pre-purchased usage over 12 months. If they use the product faster than expected, they have time to plan and budget before renewal.

• Grace periods: Customers can either upgrade their contract at a higher commit or pay for the one-time flex spend after the grace period.

• Roll-over options: Allowing unused credits to transfer to the next contract period

The Discovery Gap: What To Do Earlier

This pricing saga reveals a blind spot in product discovery. Functional discovery likely happened (understanding what outcomes the AI needed to deliver), but organisational dimensions were missed.

In B2B SaaS, the purchase decision-maker is usually not the stakeholder who benefits from the product. Effective product discovery needs to cover organisational buying dynamics as well as functional needs:

• Procurement process mapping: Understanding approval steps and thresholds

• Budget cycle understanding: Learning how and when budgets are set

• Finance stakeholder discovery: Directly engaging financial decision-makers

As one founder I interviewed explained: “In B2B, there are several parties that have an interest in the product. It is not necessarily the interest of only one type of potential customer, like the CMO, but also the CTO, for example. A more comprehensive understanding of individual customers helps find a Go-to-Market model to penetrate the target market segment.”

Good product discovery must uncover both dimensions:

1. What problem does the product solve and how? (Problem-Solution Fit)

2. How will customers actually purchase it? (Go-to-Market Fit)

Even the perfect solution will fail if it conflicts with how enterprises make purchasing decisions. A product must fit the organisational realities around budgeting, approval processes, and how value is measured and realised, not only the functional customer problem.

Finding failure only after launch is expensive. A few weeks or months of thorough discovery by 1-3 people costs a fraction of building, launching, and then having to pivot a product because of misaligned Problem-Solution Fit or Go-to-Market Fit. This company spent months waiting for revenue to materialise, while burning marketing, sales and engineering resources. The opportunity cost was even higher, and could have been avoided with better product discovery.

Lessons for AI Pricing Strategy in Enterprise SaaS

• Predictability trumps perfect alignment. Enterprise customers will choose a slightly less efficient pricing model if it makes budgeting easier.

• Consider your customers’ internal processes. Enterprise purchase approvals often require fixed budgets set months or a year in advance.

• CFO psychology matters. Costs are carefully budgeted, but revenue is less controllable. CFOs resist unpredictable expenses, even when those expenses are tied to value.

• The buyer and the beneficiary are often different people. The stakeholder who benefits from the product (e.g. in business operations) is often not the person who approves the budget (finance). This creates misaligned incentives in the purchasing decision.

• Value realisation has a time lag. When the CPO said that “savings don’t directly materialize into anything,” he was pointing to a real structural problem: the benefits of many AI-based products require organisational changes that may take months or even years, especially in markets with strict employment regulations.

• Simplicity sells. Every layer of complexity in your pricing creates friction in the sales process. Test your pricing assumptions before committing.

The shift toward value-based AI pricing is still underway. But as it evolves, the companies that succeed will be those who balance value capture with the practical reality that for many enterprises, predictability still matters more than perfect value alignment.

The question is which model your customers will actually say yes to.

Did you get value out of this article? Share it with your colleagues!

Share

This article draws from my in-depth discussions with B2B SaaS product executives and founders. While names and other identifiable details have been anonymised to protect confidentiality, quotes are drawn directly from our conversations.

The Pattern of Stalled Sales

When sales just won’t take off, most B2B SaaS companies follow a predictable pattern. It plays out in early-stage startups and established corporations alike.

They train the sales team to sell based on value. Revamp the marketing message. Adjust pricing. Add the features prospects ask for.

Yet quarter after quarter, growth remains stubbornly slow.

They can’t pinpoint the root cause. Is it a sales execution problem? Is better marketing needed? Should they add more features to fulfil customers’ RFPs? Or is something more fundamental holding them back?

Often, the struggle stems from a misunderstanding of what drives product success in the first place.

The Ultimate Goal Every Product Leader Chases

“My most important goal within the next year is ensuring that our product has achieved Product-Market Fit.”

I heard this from a Chief Product Officer of a venture-backed B2B SaaS startup during my research interviewing 31 founders and product executives. It wasn’t surprising. Many product executives I have interviewed emphasise Product-Market Fit (PMF) as their critical milestone.

And they are right to obsess over it. Without PMF, even flawless execution can’t save you.

Another executive put it more directly: “The measure of whether you have Product-Market Fit is money.” Nothing else matters if you can’t generate sustainable revenue.

Yet despite universal agreement on its importance, PMF remains hard to reach. Studies estimate that between 60% and 95% of new software products fail to meet expectations. Billions in venture capital, countless engineering hours, and enormous market opportunities are squandered because companies can’t figure out how to achieve it.

What should concern every product leader is that even product teams that achieve some success often can’t explain exactly why. They either got lucky, or they have some intuitive understanding they can’t articulate. Neither is reliable or repeatable.

We can do better than treating PMF as a mysterious force that either does or doesn’t bless your product. We can break it down into components we can act on.

Subscribe now

Why Common Definitions of Product-Market Fit Set You Up for Failure

How do the industry’s best-known thinkers define Product-Market Fit?

Marc Andreessen (2007), legendary VC and tech pioneer, says PMF means “being in a good market with a product that can satisfy that market.” He describes symptoms of missing PMF: customers aren’t getting value, usage isn’t growing, word of mouth isn’t spreading, sales cycles are too long, and deals don’t close.

Andy Rachleff, who originally coined the term in the mid-1990’s, says finding PMF means proving the value hypothesis, which identifies features, target customers, and business model to get customers to buy your product. He measures it by the contribution margin of a sales team exceeding the total cost of the sales team.

Sean Ellis (2009), who coined “growth hacking,” offers another specific metric: you have PMF when 40% of users would be “very disappointed” without your product.

Brant Cooper (2010) lists three criteria for PMF in his book about Steve Blank’s Customer Discovery process: the customer is willing to pay for the product, customer acquisition cost is less than the price customers pay, and the market is large enough to support the business.

Eric Ries (2011) describes PMF as “the moment when a startup finally finds a widespread set of customers that resonate with its product.”

These definitions all share the same limitation: they describe what PMF looks like after you’ve achieved it. They describe a destination without providing directions to get there.

Worse, focusing on these observable metrics and symptoms can send you in the wrong direction. When your product isn’t achieving PMF, what should you address? A lengthy sales cycle might point to ineffective sales approaches. Or it might indicate that your product doesn’t have the right features. Without understanding the underlying structure of PMF, you are a doctor prescribing painkillers without diagnosing the disease. The symptoms may temporarily subside, but the condition continues to worsen.

These definitions capture the signs of PMF, but we need a framework that explains what causes PMF and how to achieve it systematically. We need to break PMF into its components.

Behind Product-Market Fit: Untangling Two Distinct Types of “Fit” 

The root problem with traditional PMF thinking is treating it as a single, monolithic milestone. But Product-Market Fit has two distinct components that require different approaches.

First, we need clarity on what a “market” means. A market should not be defined as a product category or an industry vertical, especially when creating something new and innovative. I define a market for B2B products as follows:

With that definition in mind, I define Product-Market Fit as follows:

Product-Market Fit is easiest to reach by concentrating not on all possible target customers, but rather on the ideal customers: that segment of companies for whom solving their common problem delivers the most value.

Share

Now we can split Product-Market Fit into its two separate components:

This distinction reshapes how you approach product development and growth.

Problem-Solution Fit means you’ve built a product that solves a real problem for your ideal customers so well that you can repeatedly deliver value for them and retain them. It concerns what your product does for your target customers.

Go-to-Market Fit means you can effectively price your product to capture value for your business, get your value proposition in front of your ideal prospects, and consistently close deals. It concerns how you sell what your product does for your target customers.

Subscribe now

Problem-Solution Fit is about building the right product for the right customers. Go-to-Market Fit is about building the right way to sell it to the right customers.

You need both to succeed, but the challenges and solutions for each are different.

The common definitions of PMF in the previous section fail to distinguish between the two components. Some definitions match my definition of Problem-Solution Fit but omit aspects of Go-to-Market Fit, or vice versa. Yet the tech industry keeps discussing PMF as if it were a clear concept that everybody understands the same way.

This framework gives you more than a description of what PMF looks like. It gives you a map for achieving Product-Market Fit. When sales stall, you can diagnose whether you are facing a product problem or a go-to-market problem. When planning investments, you can target the real bottleneck instead of throwing resources at the wrong challenge.

The framework also reveals something about the path to PMF that many companies miss. Understanding the two types of “fit” is useful, but even more important is grasping how they interact.

The Fatal Flaw in Product Strategy That Kills Sales

Problem-Solution Fit and Go-to-Market Fit are not independent. Problem-Solution Fit sets a hard ceiling on your Go-to-Market potential.

How much value your product creates for your target customer determines how much you can charge for it. Your pricing strategy, a key element of Go-to-Market Fit, is constrained by your Problem-Solution Fit.

Your value proposition is a promise about the value your product delivers, which is directly determined by your Problem-Solution Fit. If your PSF is weak, no amount of marketing brilliance can build a compelling value proposition.

When your product solves critical problems for your ideal customers, sales cycles shorten naturally. As Rachleff puts it, “the customer pulls the product out of your hands”. When it doesn’t, even the best sales team struggles to close deals.

This explains why so many companies waste resources on the wrong remedy. They see slow sales and immediately try to improve their GTM strategy: better marketing, more sales training, different pricing models. But if the root cause is poor PSF, these investments can’t solve the real issue. They are repainting the walls of a building with a crumbling foundation.

Subscribe now

One founder I interviewed understood why Problem-Solution Fit is so important for sales:1

“[Achieving Problem-Solution Fit is so important because] it would be much easier to sell the product. I would know that I’m selling something of value, something that really works. … If Problem-Solution Fit isn’t good, then selling is always a tremendous effort.”

Another product executive learned this the hard way:2

“We monitored how sales progressed after launch. The first half-year was bad, but we weren’t yet worried. However, when we had another poor half-year, we concluded that this wasn’t a sales problem nor a minor product challenge, but a real issue with Problem-Solution Fit.”

After a full year of poor sales, he realised that you can’t compensate for poor Problem-Solution Fit with great Go-to-Market execution.

With this understanding of how PSF and GTM Fit interact, you are better equipped to diagnose which kind of “fit” is holding your product back.

How to Diagnose Your Product-Market Fit Challenge

How do you know which type of “fit” you are struggling with? Here are some patterns I’ve observed across B2B SaaS companies:

Signs of poor Problem-Solution Fit:

• Customers need extensive customisation to make the product work for them

• Customer success requires substantial professional services

• Customers use only a small portion of the product’s features

• Different customers use very different features

• Churn is high despite little competition

• Product roadmap is driven by individual customer requests rather than customer problems identified as common ones

• The product is very complex from the customers’ point of view

• Support gets a large number of tickets

• Customers complain the product is difficult to use

Signs of poor Go-to-Market Fit:

• Difficulty articulating your value proposition

• Marketing messages that don’t resonate with customers

• Long sales cycles

• Inconsistent sales performance across similar prospects

• High customer satisfaction but slow sales

These symptoms require careful interpretation because many apparent Go-to-Market problems originate from poor Problem-Solution Fit. Take long sales cycles, which look like an issue with your GTM model. And sometimes they are, like with this AI-based product. The CPO of this Enterprise SaaS business admitted:

“Our pricing and packaging was wrong, to put it bluntly. We had what we thought was a good idea, that the pricing would be based directly on the value delivered to the customer. The model predicted [X] and the customer paid per successful [outcome]. It was a very elegant and nice idea, but it was quite complex. And then it wasn’t predictable.”

Then they changed their pricing model to a pure subscription fee that wasn’t volume-based, and somewhat surprisingly it worked. The CPO explained:

“It sounds foolish. Why wouldn’t a customer want to pay only for the value created? But ultimately, enterprise customers valued predictability more. They wanted to know how much this would cost them. It just wasn’t a very successful launch. The product itself worked well.”

Their Problem-Solution Fit was good; lack of GTM Fit was the right diagnosis.

But often long sales cycles hide a less obvious diagnosis: your product isn’t solving an important enough problem for your target customers, or isn’t solving it well enough. That was the case with an enterprise software company whose sales cycles sometimes extended up to three years. This quote from one of their product managers reveals it was an issue with Problem-Solution Fit:

“Our product is a platform you can customise to do anything. In addition to automating processes in [industry X] you could use it, I don’t know, to build an automation solution to dispatch taxis. Like Uber.”

Difficulty articulating your value proposition might also look like a marketing challenge, but it frequently indicates that you haven’t understood what underlying customer problem you are trying to solve and for whom.

The sequence matters: always diagnose Problem-Solution Fit first. You can temporarily mask poor PSF with extraordinary sales and marketing efforts, but you are pushing a boulder uphill.

Subscribe now

What Determines Problem-Solution Fit?

Problem-Solution Fit depends on one thing above all: understanding the real customer problems. They drive everything else.

Consider an emergency department’s (ED) patient flow management. Software vendors typically hear a stream of complaints and feature requests like these:

• “The system is too slow during peak hours”

• “We can’t see real-time equipment availability”

• “We need a better bed tracking dashboard”

• “Add notifications for when specialists are available”

But complaints and feature requests are surface-level symptoms of poor Problem-Solution Fit. They mask the concrete situation from which the pain points and requests arise: the actual customer problem.

When a critical patient arrives, ED staff must make rapid decisions about resource allocation while maintaining care quality for all patients. To make optimal decisions, they would need more than current availability. They would need predicted availability based on patient discharge patterns, scheduled procedures, and historical data. The full problem is about optimising patient outcomes while maintaining department efficiency in a complicated and ever-changing situation with interdependencies and constraints. It’s not just about allocating resources right now.

What customers ask for often bears little resemblance to what would actually solve their complete problem optimally. A dashboard might help marginally, but understanding the complete situation at the ED (the goals, circumstances, success criteria, situational dynamics, dependencies, and constraints) is likely to reveal opportunities for radically better solutions that customers themselves can’t imagine.

Understanding these customer problems is the core of value creation, and it is just as central to Go-to-Market. If you don’t understand who your ideal customers are and what common problem they are trying to solve, you can’t formulate a clear value proposition, marketing message, or offer. You don’t know how to reach them or how to close sales with them. They won’t recognise themselves, their problems, or the benefits of your solution in your messaging.

This pattern repeats across the B2B SaaS industry. Companies mistake symptoms for problems. They fix immediate pain points instead of solving common root problems of well-defined target customers. They implement requested features instead of understanding why those features were requested. They optimise existing processes instead of reimagining how their ideal customers could get radically better outcomes in a better way.

As Paul Adams, CPO of a successful B2B SaaS company, puts it:

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

Why Traditional Product Development Methods Fall Short

Most product leaders ask themselves “Do we have Product-Market Fit?” A better question is “Do we understand the entire customer problem we are trying to solve?”

If your team can’t articulate the customer problem clearly and fully, independent of any solutions, you are likely building on shaky ground.

And if you can’t objectively measure how well your solution fits the customer problem without building and testing the solution with customers, you are flying blind.

If the target customers’ complete problem space has not been discovered, analysed, understood and documented explicitly, your product is likely trying to A) solve many different problems B) for very different customers. Consequently it is not a good fit for anyone.

You have trouble marketing and selling to your target customers because you don’t know who they are.

You have trouble solving their problems because you don’t know what the problems really are.

Your product ends up a complex mess because, underneath the surface, it is trying to fulfil many different kinds of needs for different market segments.

This explains why so many B2B SaaS companies struggle despite following all the “best practices.” Common practices like agile development, customer feedback loops, design thinking, or continuous iteration, while valuable, can’t compensate for a gap in understanding the problems of your target customers. You are moving with a broken compass. No matter how efficiently you move, you can’t be sure you’re heading in the right direction.

The solution starts with a different approach to understanding customer problems, one that goes beyond surface-level symptoms and feature requests.

A New Approach for Product Success in B2B SaaS

I’ve described parts of this approach in the previous articles of this newsletter. If you haven’t read them yet, “The 8 Universal Principles of Customer Problems in B2B SaaS” reveals the universal principles that govern all customer problems. And “How to Define Customer Problems That Tell You What to Build in B2B SaaS” breaks down 10 essential elements that every customer problem contains and that your competitors likely miss. Understanding these principles and elements will immediately improve the effectiveness of your problem discovery efforts.

These foundational concepts are the basis of my systematic product discovery approach that I’ve developed over the past 20+ years. In this newsletter, I will continue exploring how you can:

• Discover enterprise customers’ problems systematically, comprehensively and effectively

• Evaluate your solutions objectively before building them, without slow testing cycles with customers

• Define B2B software products that deliver exceptional value in your target market

• Minimise your risk of investing resources in developing wrong solutions

• Accelerate your time to reach Product-Market Fit

Subscribe to Deductive Discovery now to learn about these methods before your competitors do!

Lessons from the Field: 31 B2B SaaS Leaders Share Their Experience

Want evidence that understanding customer problems is the key to Product-Market Fit?

I interviewed 31 founders and product executives from B2B SaaS companies about their experiences creating software products. Their accounts consistently support the argument of this article: deep understanding of customer problems forms the foundation for both Problem-Solution Fit and Go-to-Market Fit.

Subscribe now to receive “How to Build a Lasting Competitive Advantage in B2B SaaS”, my report based on these findings.

Subscribe now

In Chapter 3, you’ll find:

• Real accounts of companies reaching Product-Market Fit

• How Problem-Solution Fit affects Go-to-Market success and how to sequence your efforts accordingly

• Advice from successful leaders on balancing short-term customer requests with long-term product vision

• Examples of companies validating product opportunities before burning through funding

• Critical mistakes that turn an opportunity for a scalable product into custom software development

• Stories of both costly failures and breakthrough successes from product leaders who’ve experienced the challenges firsthand

Subscribe to get immediate access to the full report and start building your strategy on a solid foundation of customer problem knowledge.

This article draws from my in-depth interviews with B2B SaaS product executives and founders. While certain details have been anonymized to protect confidentiality, quotes are drawn directly from our conversations.

This happens more often than you’d think.

Subscribe now

How to Stop Burning Millions on the Wrong Opportunity

“We just had technology looking for a problem. A solution looking for a problem.”

That’s how one product executive described their company’s situation after burning through all their funding. And it wasn’t an isolated case. In my research interviewing dozens of B2B SaaS leaders, this pattern came up again and again. I’ve watched the same slow-motion failure play out throughout my career in B2B software, and chances are you have too.

Running an engineering team is expensive, especially in today’s funding climate. Yet too often, those resources go towards building on unvalidated assumptions about customer needs rather than moving the company towards Product-Market Fit.

Two examples from my interviews with B2B SaaS leaders:

1. One startup hired full engineering and sales teams while still trying to figure out what customer problem they were solving. They ran out of money before finding Product-Market Fit, not because of a lack of talent or effort, but because they were spending before they understood what to spend on.

2. An established Enterprise SaaS vendor spent 18 months and millions of euros building a solution, only to discover that no customer wanted to buy it.

The Lightbulb Moment That Saves Millions

While many companies burn cash in the dark, some product leaders take a different approach. They systematically explore the dark room until they find the light switch.

One founder described their process:

“When I founded my company, I started by talking to about 30 potential customers. I mapped out how they had approached this problem. I concluded that it would make sense to start building something.”

No code written, no team hired yet, just methodical investigation. When they finally launched, customers responded immediately, because the founders had already understood which problems to solve, for which customers, and how.

The Four Factors That Separate Winners from Expensive Failures

Get any one of these four wrong, and your product is dead before it starts.

1. Customer Problem: Does it actually exist?

Many B2B SaaS companies skip problem discovery entirely. One company learned the hard way:

“The management decided to create something without analysis to back it up. We developed a product, tried it out, and concluded that no one would pay for it. A lot of time was wasted.”

2. Customer Prevalence: Is Your Problem Common Enough?

A handful of interested prospects isn’t enough. You need a sizable group of target customers who share the same challenge.

One founder got this right:

“We went to talk to companies [and we learned that] this is a real problem, because the process is so laborious, and companies also have to leave money on the table.”

They found a problem that was both common and significant enough to warrant building a new solution.

3. Current Solutions: Are They Bad Enough?

Your product needs to be dramatically better than what’s already available, at least 3x-5x, ideally 10x or more. Anything less, and inertia wins. Customers will stick with “good enough.”

One product leader found an opportunity where an entire market segment was underserved:

“Many competing digital solutions were made from the perspective of the head office and company management. No-one offered anything at all for the [practical work on the ground]. We focus on that.”

4. Budget Reality: Will They Actually Pay?

Interest and enthusiasm don’t pay the bills. Customers need to have an acute enough need that they’re ready to put money behind it.

One founder told me what happened when they showed their prototype to a customer whose problems they had studied earlier:

“The customer said the solution was so good that we should set up a company, that they would pay the costs upfront, and they would act as our reference customer.”

Budget reality solved.

Why “Move Fast and Break Things” Breaks B2B SaaS

The best thinkers in product development agree that understanding the problem should come before building a solution. Yet in practice, the pressure to ship, the funding clock, and the allure of “validated learning” through shipping code lead most B2B companies to start building far too early.

The advice to “just ship something and get customer feedback” can work for relatively simple consumer apps, where the cost of change is low and you can pivot quickly.

With complex B2B and enterprise software, the economics are entirely different. These products are large, interconnected systems where the parts must fit together. Changing fundamental assumptions after building is slow, expensive, and sometimes impossible.

Iteration can improve parts of a large product. But if the parts aren’t the right parts, don’t fit together, are scoped wrong relative to each other, or if the scope of the whole product is wrong, iteration won’t fix it. By the time you discover a fundamental error, you may be looking at years of sunk costs.

Flip the Sequence: Discover First, Build Later

The successful B2B SaaS leaders in my research all had one thing in common: they invested in deep problem discovery before writing code. They treated opportunity selection as a careful investigation, not a gamble.

Two skilled people can validate an opportunity and discover the customer problems of even a complex domain in a few weeks or months. Compare that to a full engineering and sales team wasting millions chasing the wrong problem for a year or longer.

One B2B product executive put it bluntly:

“Product discovery is critical. The most certain way to fail in discovery is to not do it.”

The time spent validating the right problem is a rounding error compared to the cost of building the wrong solution.

What the successful leaders did differently

Through in-depth interviews with 31 founders and product executives, I documented clear patterns of success and failure in B2B SaaS opportunity selection. I’ve compiled the insights from the interviews into a 72-page report you receive when you subscribe:

“How to Build a Lasting Competitive Advantage in B2B SaaS”

Chapter 3.1 documents real stories of how winning B2B SaaS leaders validated opportunities before building their products. The report also covers:

• Why some product ideas create millions in value while others burn through funding, and what distinguishes the two

• A framework that breaks Product-Market Fit into two distinct, manageable components (Problem-Solution Fit and Go-to-Market Fit)

• The differences between building scalable products vs. getting trapped in custom development

• First-hand accounts of both costly failures and hard-won successes from the 31 interviews

Subscribe now and get immediate access to the full report:

Companies spend millions developing products based on insufficient definitions of customer problems. The result is speculation and guesswork about what to build.

One enterprise software company I recently spoke with had spent 18 months building a product no customer ultimately wanted to buy. They never really understood the problems the product was meant to solve.

This article introduces a precise test for whether you understand a customer problem well enough, identifies the most common mistakes in problem definitions, and lays out 10 foundational elements that every customer problem contains. These elements are necessary to evaluate solutions analytically before building anything.

Subscribe now

First, let’s review what we discovered about customer problems in the previous article. Skip this if everything is already fresh in your mind.

Recap: the principles behind customer problems

We are seeking the correct answer to a deceptively simple question:

The answer gives us something that very few product development approaches offer: the ability to systematically construct optimal solutions to any customer problem of a B2B SaaS product.

Last time we examined three situations where people needed to boil water for tea:

A) Alice’s evening ritual: Winding down at home

Alice is at home, exhausted after a long day, and getting ready to go to bed soon. To relax, she enjoys having a cup of tea.

B) Bob’s wilderness challenge: Hydration on the hike

Bob is trekking in the wilderness. A cup of tea would help keep him warm and safely hydrated, as boiling the water makes it sterile.

C) Carol’s family adventure: Forest fun with the kids

Carol is on an outing with her children in a forest on a Sunday afternoon. Her goal is to provide exciting and educational experiences for them.

From analysing these situations and their best solutions (electric kettle for Alice, Trangia stove for Bob, campfire for Carol), we discovered universal principles for all customer problems:

• A customer problem describes a specific example of a situation where a particular customer is

• A customer problem exists independently of any solutions

• A customer problem has multiple potential solutions

• We can objectively evaluate and compare solutions against a specific customer problem

With these principles established, the next question becomes: what elements must we understand about any customer problem to make such evaluation possible?

The non-negotiable test for understanding any customer problem

Every solution exists to enable a customer to solve their problem: to use it in their specific situation by taking some sequence of actions to reach a good end-result.

To evaluate a solution, we must analyse two aspects:

1. Value of the best possible end-result the solution enables the customer to reach

2. Quality of the process that the solution requires the customer to go through to reach that end-result

Real customer problems always occur for a specific person in particular circumstances. Many elements of the situation affect the end-result they can reach and the actions they need to take. To evaluate alternative solutions, we must know what those elements are.

This gives us our key criterion for the elements of customer problems:

This is our non-negotiable test for how well we must understand customer problems.

To evaluate any solution, we must:

• Have the ability to put ourselves in the place of the specific customer in the specific situation

• Know exactly how the solution works from the customer’s perspective in that situation

• Find out the sequence of actions that the solution requires the customer to take to reach the best end-result

Evaluating a new solution idea requires first defining it at a level of detail where it’s possible to construct the required sequence of actions. Until then, an idea is merely vague speculation: appealing in concept but completely untested against reality.

Common mistakes in problem definitions

The most fundamental mistake I see companies making is describing a customer problem in terms of solutions:

1. either as solutions customers ask for, or

2. as problems in existing solutions.

Note that while the descriptions might be called customer needs, user stories, epics, use cases, jobs or user goals, they are nevertheless attempts to describe a customer problem to which a solution is a solution.

Even when companies avoid this mistake, their problem descriptions still usually fail our non-negotiable test. Typical description look like these:

• “Boil water to make tea”

• “As a user, I want to boil water so that I can make tea”

• “Increase liquid temperature from A to B”

• “Bob is a sporty guy who enjoys spending time in nature.”

Simplistic or generic problem statements like these do not enable evaluating and comparing alternative solutions analytically and objectively.

They cannot differentiate between a vast array of different kinds of situations, such as Alice’s, Bob’s and Carol’s, for which different solutions would actually be best.

Qualities of a person that don’t affect the evaluation are not elements of a customer problem. Imagine putting Bob in Alice’s situation. No matter how “sporty” and “nature-loving” Bob is, he would boil his water using an electric kettle, just like Alice. He wouldn’t go out to make a campfire.

If we can’t compare alternative solutions, we can’t know what the optimal solution would be. This prevents us from innovating new, radically better solutions systematically and consistently, which is the ultimate goal of Deductive Innovation.

Without properly understanding customer problems, we lack a yardstick for comparing alternatives. This vacuum leads to decisions based on the loudest voice, the most popular opinion, or the HiPPO (highest paid person’s opinion).

So, what does the right kind of description of a customer problem include?

10 essential elements of customer problems

The specific situations of Alice, Bob and Carol provide a basic demonstration of what customer problems must contain.

Below I have listed 10 foundational elements of customer problems. They are present in every customer problem, even simple everyday ones like our tea examples (though often implicitly, as we’ll see in a moment). B2B software problems typically require additional elements beyond these 10, which I will cover in a future article. But these are the starting point.

In some way, they all affect:

• The sequence of actions a customer necessarily has to perform with the solution

• The best end-result the solution enables them to reach

Consequently, they affect what the best overall solution is in each situation.

1. Protagonist: Who has the problem?

   • A person at home, a hiker, a mother with children

2. Goal: What are they trying to get done?

   • Boil water to make tea

3. Motive: Why are they doing it?

   • Calm down at night, keep warm and hydrated in the wilderness, provide exciting experiences for children

4. End-result (“benefit”): What end-result are they trying to achieve? The end-result is the “benefit” the customer gets from solving their problem.

   • Hot water that is suitable for making tea

5. Timing: What initiates the situation and when?

   • Getting ready for bed, satisfying thirst during the hike, fun weekend outing

6. Location: In what physical or organisational setting does this occur?

   • Home, wilderness, forest

7. Resources: What resources and information are available in the situation and what do they cost?

   • Electricity at home, Trangia fuel, dry wood and a spot for the campfire

8. Causalities and dependencies: What forces and natural causal relationships affect and constrain the series of actions necessary to reach the end-result?

   • One must obtain the water before boiling it; the water must be placed in a container to boil it; certain containers can be damaged by boiling water, fire or microwaves

9. Criteria for the end-result (“benefit”): How does the customer measure and evaluate the end-result in the situation?

   • Water is boiling hot and evenly heated, suitable for making tea

   • The criteria for a good end-result are very specific to the situation

10. Criteria for the process (“cost”): How does the customer measure and evaluate the process of reaching the end-result? The process of using the solution is the “cost” to reach the end-result; but in consumer products, the process itself can also be a “benefit”, like in Carol’s case.

    • Convenience, saving electricity, effort, speed, safety

    • The usual criteria for the process are minimising time, effort and risk

Notice again that all these elements are solution-independent, which is our foundational requirement for what a customer problem is.

Share

How much detail you need to document

You might wonder: “Do I really need to document all those 10 elements for every customer problem?”

For familiar situations, a vivid 1-2 sentence description often suffices. Take our tea examples:

• Alice is at home, exhausted after a long day, getting ready for bed soon.

• Bob is trekking in the wilderness, needing warm hydration.

• Carol is on an outing with her children in a forest for an exciting and educational experience.

Despite lacking many of those 10 elements explicitly, such short descriptions work because:

• They describe real people in real situations

• The context is familiar to everyone

• Common sense fills in most details

But watch out for important hidden details. Even in seemingly simple situations, small variations can demand completely different solutions. Consider this twist: Alice prefers green tea, which contains less caffeine and requires water at about 80°C, not boiling. Suddenly none of the solutions we evaluated are optimal for her situation.

For B2B software, brief descriptions rarely suffice:

• Domain complexity requires explicit detail. The elements of customer problems in drug development, reinsurance, or operating a nuclear plant are not self-evident or obvious.

• Product developers are not familiar with the domain. Facts about customer problems must be documented for shared understanding.

• Business situations often include multiple people in different roles with different goals, which add layers of complexity to customer problems.

• For a solution that is used to process complex large data sets, the description of a specific situation must include an example of a realistic data set.

Describing customer problems for software, and B2B software in particular, involves some further considerations beyond these 10 basic elements. We will get to those in a later article.

Why these elements matter for B2B products

These 10 elements do more than describe a situation. Once you know them, several things become possible.

You stop speculating about what to build, because every element of your product addresses a specific, validated aspect of your customers’ real-life problem.

You can evaluate potential solutions objectively before developing them. Instead of building and testing with customers to find out if something works, you can reason through how each solution would perform in the situation, step by step.

You can identify which underlying problems are actually common across customers, irrespective of the solutions customers are asking for. This is what enables building scalable products rather than custom solutions.

And you gain a stable, long-term basis for your product strategy. Customer problems change slowly; feature requests change with every conversation. Building on the former gives you a foundation that competitors who chase the latter cannot match.

Applying these principles to complex B2B software products

The principles we have explored using the tea example already apply directly to software. But B2B software products bring additional complexity and require understanding a few more elements. Specifically:

• Multiple stakeholders with potentially competing needs

• Complex business processes

• Enterprise-scale implications

• Industry-specific regulations and constraints

• The need for scalable products that solve common customer problems across different organisations

What’s next

In the upcoming articles, I will show how the discovery method of Deductive Innovation, Deductive Discovery, addresses these complexities. You will learn how to systematically uncover customer problems in enterprise environments, and why this is possible even when many seasoned industry experts believe it isn’t.

Subscribe now to get the next article when it comes out.

In my previous article, I posed a provocative question, without answering it:

The answer to this question is the cornerstone of creating winning B2B software products. Yet this question seems to elude much of the software industry.

I argued that a customer problem must not be defined in terms of any solution, so it cannot be:

• The pain points in a solution that customers complain about

• The lack of a solution (that’s circular logic)

• The features that customers request (they are solutions)

Misunderstanding customer problems turns promising product companies into feature factories. Backlogs overflow with feature requests, customer complaints, and ideas, while the prospect of an elegant, scalable, market-winning product slips further away.

There is a way out. Before we get to it, we need to lay some groundwork. We will start with something deceptively simple: a cup of tea. By stripping away complexity, we can uncover the principles that govern all customer problems, from everyday tasks to the operations of large enterprises.

What is the best solution for boiling water?

Consider five ways to boil water:

1. Kettle

2. Microwave oven

3. Electric stove

4. Trangia stove (a portable stove that uses alcohol as fuel)

5. Campfire

Which is the best solution for boiling water to make tea? Three scenarios illustrate the answer.

A) Alice’s evening ritual: Winding down at home

Imagine Alice at home, exhausted after a long day, and getting ready to go to bed soon. To relax, she enjoys having a cup of tea. Which solution suits her best?

Going outdoors at night to make a campfire makes no sense. Digging out her Trangia from the closet and messing with fuel is equally impractical. The electric stove in her kitchen is more sensible, but slow at heating water. A microwave is faster but awkward: how long until the water is boiling hot without boiling over? And microwaves heat unevenly, with the water at the top boiling before the water at the bottom. Its benefit is that she can pour the right amount of cold water directly into the tea cup, and heat the water there.

Her electric kettle is the clear winner: it sits ready on the counter, it fills and starts easily, it heats water quickly and evenly through convection, it switches off automatically when the water boils, she is unlikely to burn herself, and it is the most energy-efficient option.

B) Bob’s wilderness challenge: Hydration on the hike

Bob is trekking through remote wilderness. A cup of tea helps him stay warm and hydrated, since boiling makes the water safe to drink. Which solution is the best for him?

Anything electric is out of the question. A campfire takes real effort: finding dry wood, locating a suitable spot, lighting the fire, and rigging something to hold a pot over it. His Trangia stove is the right answer: lightweight, designed for backpacking, and manageable in primitive conditions.

C) Carol’s family adventure: Forest fun with the kids

Carol is out in the forest on a Sunday afternoon with her children. The goal is to give them a new experience.

Unlike Bob, she has no need for convenience. Every step of making a campfire, from gathering wood to getting the water boiling, is an exciting and educational adventure for the children. Once the fire is going, maybe they will grill a few sausages, too.

The 8 universal principles of all customer problems

This tea-making example reveals a great deal about the nature of customer problems. Here is what the three situations tell us about problems, solutions, and the relationship between them.

Principle 1: Customer problem is a specific situation of a particular customer

“Boiling water for tea” is at the core of these situations. It is what each person is trying to accomplish.

But what a customer is trying to get done is not enough to define a customer problem. Alice, Bob and Carol benefit from different solutions, which means the nature of their problems is necessarily different. The difference lies in their situations.

A customer problem must be described as a specific situation of a particular customer. Beyond the basic need to “boil water to make tea”, a customer problem specifies who the customer is, where they are, when, and what their motive is, among other aspects of the situation.

Principle 2: Customer problem is independent of solutions

A customer problem, properly understood, exists in the world independently of any past, present or future solutions. The descriptions of Alice’s, Bob’s and Carol’s customer problems illustrate this: none of them mention anything about possible solutions to boil water. They describe the situations only.

Principle 3: One customer problem, multiple solutions

There are different, competing solutions to the same customer problem, and more can be invented. Some of the solutions are simply better than others for a given situation: their Problem-Solution Fit is different.

Principle 4: Different solutions to the same problem can be compared objectively

Given a specific customer problem, we can compare alternative solutions relatively objectively. We do this by analysing all the actions the customer must take in each situation to reach the desired end-result (hot water for tea), and the quality of that result.

Objective comparison does not require empirical tests, such as having a target user actually light a campfire. It only requires a detailed understanding of the situation and how each solution functions within it.

Principle 5: For a different customer problem, a different solution is best

Since we can compare alternative solutions for each customer problem, we can also determine which is the best among the available alternatives. If a customer problem is different enough, a different solution is optimal, as Alice’s, Bob’s and Carol’s situations show.

Principle 6: There is no universally best solution

There is no universally best solution for the customer problem of “boiling water”. Why not?

Because “boiling water” is too generic a description of a customer problem. Generic situations do not exist in the real world. In reality, a particular customer is always in a specific situation.

To evaluate alternative solutions to any customer problem, we must examine all the actions a real person needs to take with a solution and the result they can achieve. That analysis is impossible without a specific situation, because the situation determines how each solution can be used in it, if at all.

The quality of a solution is thus a matter of fit between it and a particular customer problem.

In other words, Problem-Solution Fit is a function of both the problem and the solution.

Share

Principle 7: Customer problem represents a class of essentially similar situations

A customer problem represents many similar situations across different customers, even though it is described as a single specific case.

Every real situation is unique to a specific person, time, place, and circumstances, but most of these differences do not matter when evaluating solutions. For example:

• Alice’s age does not change the customer problem. Personal characteristics often have little or no impact. (Except if Alice is a frail senior with arthritis.)

• The country where Bob is hiking is irrelevant: Canada or Norway, the situation is the same. (Saudi Arabia might be different.)

• Whether Carol has two or three children does not change the customer problem. (Ten kids might.)

Alice’s, Bob’s, and Carol’s situations are not the only customer problems related to boiling water for tea. Someone performing a Japanese tea ceremony faces a very different customer problem: the motive and the situation are entirely different.

How do we identify which details about a customer and their situation actually matter? That is an in-depth topic I will return to in a future article. Subscribe now to receive it when I publish it.

Principle 8: Customer problems change slowly, solutions change fast

Customer problems generally change quite slowly. Solutions change as fast as humans can imagine and develop them.

Alice’s situation has existed for hundreds of years, while solutions have evolved considerably. Humans have boiled water over fire for millennia; Trangia stoves and microwave ovens arrived in the 1950s.

Alice’s customer problem is likely to remain largely unchanged for centuries. Consider the tea-drinking Captain Picard of Star Trek set in the 2300s. His customer problem is the same as Alice’s. His solution, however, is rather better: “Tea, Earl Gray, hot.” Immediately, a cup materialises in the food replicator that reconstitutes matter out of pure energy.

Summary of customer problems vs. solutions

The figure below summarises the relationship between customer problems and solutions

• Customer problems are independent of solutions.

• Each customer problem has many possible alternative solutions.

• Different solutions fit each customer problem better or worse.

• For each customer problem, there is a best solution.

• There is no universally best solution.

• The quality of a solution is a matter of problem-solution fit.

• Problem-solution fit can be evaluated objectively.

• Customer problems are stable over time.

• Solutions may change much faster than customer problems.

From tea to tech: Why this matters for your B2B product?

You might be thinking: this is interesting, but I am building enterprise software, not brewing tea.

The same principles apply. B2B software products are solutions to customer problems. The fit between a product and the customer problems it addresses determines how well it sells and how much customers value it. A product built on a vague or solution-contaminated understanding of customer problems will always struggle, however polished the interface or sophisticated the technology.

But knowing the principles is only the starting point. To actually use them for developing products, you need to know what a customer problem contains: what specific elements make up a problem definition precise enough that you can evaluate any solution against it, before writing a single line of code.

In the next article, I introduce

• 10 foundational elements present in every customer problem,

• the most common mistakes that make problem definitions useless, and

• a non-negotiable test for whether you understand a customer problem well enough.

Read “How to Define Customer Problems That Tell You What to Build in B2B SaaS” here.

Continue reading part #4 of the series:

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?

Subscribe now

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”.

Leave a comment

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?

Subscribe now

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 valuable B2B software products systematically, 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

But all of it starts with answering one question:

That question is at the core of my approach to developing B2B software products, Deductive Innovation. I will answer it in the next article.

Continue reading part #3 of the series:

Your response to the challenge

How do you define a “customer problem” (or a “customer need”)? Please comment below and include concrete examples, they are most appreciated!

Y Combinator has been saying since 2014 that “software used by large companies is still awful and still very lucrative,” and that there is room for new enterprise software startups to solve problems in every industry and business vertical1. Ten years later, it’s still true. Why can’t a trillion-dollar industry fix its own products?

The data confirms the stagnation. The Standish Group tracked 2,500 to 5,000 software projects per year, mostly custom-made enterprise software, and the share of successful projects has hovered between 30% and 40% since the mid-1990s (see image below). Worse, their definition of “success” included projects where usability was substandard. The numbers have barely moved in three decades.

Share

60-70% of software projects fail to meet expectations, overshooting budgets, missing deadlines, or getting abandoned. And these statistics are for custom software built for a single company. Developing a scalable B2B SaaS product for many different companies is a whole new level of complexity.

Meanwhile, venture capitalists keep pouring money in. They see outdated, clunky B2B software and a market ripe for disruption. The opportunity is real.

But if agile, lean startup, design thinking, and two decades of “best practices” haven’t closed the gap, something more fundamental must be wrong.

I believe the root cause is in a place most product teams aren’t looking: the industry lacks a clear understanding of what “customer problems” are, even in principle. That missing foundation cascades through everything that follows, from discovery to design to delivery.

This article is the first in a series that will examine the problem and explore a different approach that could change how we create value in B2B and Enterprise SaaS.

The Problem with Enterprise Software

Enterprise software has issues that have been frustrating customers, draining resources, and limiting business growth for too long:

• Misalignment with business needs: Enterprise software often fails to fulfil important business needs. It lacks features essential for efficient operations and good business decisions, leaving customers scrambling to fill gaps.

• Excessive complexity: To close sales, products try to fulfil a flood of feature requests from different customers and turn into a complex labyrinth.

• Poor productivity: Using B2B products is often difficult, inefficient and frustrating due to poor user interfaces and complex interactions.

• Slow deployment: Cumbersome configuration, customisation, and integration contribute to implementation timelines that keep stretching, delaying ROI and testing customer patience.

• Lack of flexibility and customisation: Inflexible software that can’t adapt to specific business needs forces organisations to conform to rigid solutions rather than vice versa.

• High cost of ownership: Enterprise software is often so expensive to purchase, use, and maintain that its value just barely justifies the investment.

These are symptoms of a deeply flawed approach to enterprise software development. But before we can change the industry, we need to understand why these problems persist despite best efforts.

9 Common Explanations for Enterprise Software Failures

The software industry has explanations for why enterprise software often falls short. The following reasons are often cited, but do they really get to the root cause?

• Complexity of business: Enterprise software must support complex businesses with multiple user groups, intertwined processes, and large volumes of connected data, which are challenging to understand and support.

• Poor requirements: Gathering, managing and analysing the needs of many different stakeholders is difficult. Product requirements are frequently poorly defined, incomplete, and understood differently by different stakeholders.

• Purchasers are not users: The disconnect between those making purchasing decisions (typically CIOs) and those using the software leads B2B software vendors to prioritise satisfying buyers rather than improving the productivity of users.

• Vendor lock-in: The high costs associated with switching to alternative solutions create vendor dependency, which reduces the vendors’ incentive for radical innovation.

• Functionality over customer value: Vendors tend to prioritise implementing new features to fulfil RFPs from customers, often neglecting value creation.

• Communication gaps: Insufficient communication between Product, Engineering, Sales, Marketing, Customer Success and customers hinders the production of valuable software.

• Rigid development processes: Lack of agility leads to failure in responding to ever-changing customer needs and market circumstances.

• Inadequate testing and user feedback: Limited testing and user feedback during development result in overlooking defects, usability issues and pain points.

• Extensive integration: Integration complexities arise due to the multitude of software modules and products that large enterprises have from different vendors and eras, often utilising different and even outdated technologies.

While these explanations seem plausible, they are often used as convenient scapegoats. They distract from a more fundamental issue, one that could change how we approach B2B SaaS development if it were properly addressed.

Why Enterprise Software Needs More Than Just “Best Practices”

The software industry has rallied around a set of “best practices” to tackle these persistent challenges. But if these practices were truly the best possible, wouldn’t we have solved the enterprise software puzzle by now? I believe they don’t get to the root cause.

Five commonly suggested best practices, and my critique of each:

1. “Embrace more agile processes” Critique: Agile might help you sprint, but it won’t show you the finish line. While it works for incremental improvements, it has limited ability to address larger-scale software development. The worst problems in enterprise software are often “between” all the different parts of the customer’s overall IT stack. While the parts can be iterated and developed incrementally, the whole cannot.

2. “Welcome changing requirements” Critique: The agile principle to “welcome changing requirements, even late in development” assumes that customer needs are as fickle as the weather. But correctly understood, customer needs do not change quickly, and are a stable basis for developing large products.

3. “Prioritise user experience” Critique: While a sleek UI is nice, consumer-centric UX skills and methods are insufficient to tackle the complexities of enterprise software. The highest customer value in B2B often means no user experience at all: full automation.

4. “Improve testing practices” Critique: You can’t test your way to a great product. All the QA in the world won’t fix issues arising from poor, incomplete, and ambiguous understanding of customer needs. Valid testing results require valid requirements against which to test.

5. “Better communication and more feedback” Critique: While communication is necessary, we must know what should be communicated, why, when and how. Creating well-communicated mediocrity is not the answer. Even close involvement of customers and users has often resulted in lacklustre and failed products.

These “best practices” are not inherently wrong, but they fail to address the core issue.

Back to Basics: The Missing Understanding in Software Product Development

Designing and building a suspension bridge without understanding the basics of physics would be absurd. Yet that’s what I think is happening in the B2B and Enterprise SaaS industry. A fundamental piece of the puzzle is missing, and it’s costing billions in failed projects and missed opportunities.

I believe the root cause of many of these troubles lies at the very beginning of the software process:

It seems basic, but this deceptively simple question is where the industry struggles most.

I know the objections. “Of course we understand customer problems!” they might say. “We have user stories, we do market research, we have customer advisory boards! Everybody knows that understanding customer needs is key to building good products.”

But that could be confusing activity with understanding. Product teams are drowning in data about customers and their needs, yet still lacking real insight.

This is what leads to a major change in perspective:

Are “customer needs” customers’ pain points, value drivers, features, gains, benefits, specification and requirements in an RFP, wants and wishes, exciters and delighters, aspirations? Maybe all of them? No. None of them are sufficient for creating superior B2B software directly and consistently. The eight universal principles of customer problems explain why.

This fundamental issue cascades throughout the whole development process. All the concepts, ideas and methods that build on top of a faulty foundation are necessarily also flawed. The difficulties later in the software process are symptoms of failure at the very beginning.

This foundational shortcoming is not anyone’s fault. Product management discipline, software engineering practice, and their academic study are not yet mature enough.

Once you recognise this blind spot, it opens the door to a very different approach to product development.

Why This Is Critical with B2B Software

In the world of consumer apps, intuition and iteration can work. Everyone can have some kind of intuitive understanding of the customers’ problems, which helps in coming up with reasonably good solutions. Some people are even elevated on a pedestal because they are thought to have an exceptional intuitive understanding of consumers, and thus a better ability to come up with brilliant solutions (think Steve Jobs).

With B2B software this doesn’t work.

Product developers are rarely the customers or the users. We are outsiders trying to solve complex problems in industries where we have no first-hand experience. It’s like being asked to perform surgery without ever having studied medicine.

This disconnect matters. When we fail to thoroughly grasp the underlying customer problems, we are not risking just a failed product launch. We are risking entire business operations, potentially costing our clients millions in lost productivity and missed opportunities.

Product developers must therefore discover and understand the customer needs explicitly to create a good solution. But doing it systematically, effectively and comprehensively is impossible if they don’t know what customer problems are even in principle. They can’t know what facts about the customer’s world they should find out, and what they can ignore.

Share

Why This Is Critical with Large Software

If misunderstanding customer problems is a stumbling block for small software projects, it becomes far worse for large-scale enterprise software.

With relatively small consumer products, iterating the solution (“agile”, “ideate and test”, “fail fast”, “trial and error”) will gradually correct mistakes, wherever the mistakes are: in understanding of customer problems, in the solution itself, in its marketing, or elsewhere. It’s like constructing a garden shed. If you make a mistake, you can easily tear down a wall, change the location of the door, move the whole shed a bit, or even start over without incurring massive costs or time delays.

But with a large B2B or Enterprise SaaS product, you are constructing a skyscraper. Every change is slow, costly, and potentially catastrophic if the fundamentals are wrong. You can’t move load-bearing walls, rearrange entire floors, move the whole building, or start over again. As the scale of the software grows, so does the cost of solving the wrong problems or solving them wrong.

Iteration, ideation, and testing with customers can’t significantly improve large enterprise software as a whole.

They can improve parts of it at most. Iteration doesn’t work if:

1. The parts of the large software are not the right parts.

2. The parts don’t fit together well.

3. The parts are scoped wrong relative to other parts.

4. The scope of the whole is wrong.

In these scenarios, iteration is not a path to improvement but rather a long, expensive road to nowhere. By the time you realise you are off course, you could be looking at a decade of sunk costs and missed opportunities.

Why This Is Critical with Scalable Products

Now consider perhaps the most ambitious goal in B2B software: creating a scalable product. If building large software is like hitting a fast-moving target, creating a scalable B2B product is like hitting it while blindfolded.

Scalability here is not a technical issue of handling more users or data. Scalability is about solving a common problem for many different businesses that come to the software vendor with their own quirks and specific requirements.

With customer-specific B2B software, the lack of solid understanding of what customer problems are, in principle, is not necessarily an overwhelming obstacle. The development team can let the customer define the solution instead, following the fourth agile principle of close collaboration. The people who will use the software can have an intuitive understanding of their underlying problems, which helps them in coming up with a workable solution.

But that doesn’t work when creating a scalable B2B or enterprise software product for many different customers.

A product is a common solution to common customer problems. It requires a careful ability to distinguish between universal customer problems and client-specific needs. Without a clear understanding of what constitutes a “customer problem” in the first place, this task is generally not possible.

Some product teams try to look at feature requests from different customers, and assume that common requests for a solution imply common underlying problems. This is flawed. It first results in a bloated product backlog. Working through that backlog leads to bloated, unfocused products that try to be everything to everyone and end up being nothing to anyone.

The inability to properly identify and address common customer problems is fatal for scalable B2B SaaS ambitions. But there is a way to cut through the noise and see the underlying problems with clarity. That’s what this article series and my newsletter will explore.

Busting 5 Myths Holding Back B2B SaaS Innovation

There is another obstacle that stands in the way: a set of misconceptions that actively sabotage our efforts to discover and understand customer problems.

• Myth #1: “Customers don’t know what they need.” Reality: Customers know their problems intimately. We just don’t know how to ask and what to observe.

• Myth #2: “Even if customers know their needs, they can’t articulate them.” Reality: They can, but it’s our job to provide the right framework for discussion and discovery.

• Myth #3: “Customers can’t possibly know what they need from new technology, like a new product based on AI.” Reality: Their needs exist independently of our solutions. We just need to uncover them.

• Myth #4: “Customer needs are always changing, so why bother trying to pin them down?” Reality: Customer needs are more stable than we think. It’s the solutions that keep shifting quickly.

• Myth #5: “There are too many customer needs for large enterprise software to discover them all.” Reality: With the right approach, the set of customer problems is far smaller than it seems. (Though still not tiny, as most B2B and enterprise software is about solving complex problems.)

These myths prevent us from doing the deep, careful discovery work necessary to create valuable B2B software. If we cling to these beliefs, we give ourselves permission to skip the hard work of really understanding our customers.

Subscribe now

From the Ground Up: Reinventing B2B Software Development with First Principles Thinking

As an industry, it’s time to build a solid new foundation for complex B2B and Enterprise SaaS products using first principles thinking.

We must challenge today’s conventions: strip away the layers of jargon, question the most cherished best practices, and eliminate unnecessary complexity that doesn’t serve our ultimate goal of creating exceptional value for customers.

What I’m proposing is not another methodology or framework.

We need a foundational, testable, explanatory theory of how software products create customer value. We need to understand, with precision, how every feature, every function, every customer-facing aspect of the software contributes to solving real customer problems and creating value. The theory must explain and predict why some software solutions are objectively more valuable for customers.

A good theory must also explain how the best practical methods for creating valuable solutions should work, why they must be that way, and how they would differ from today’s accepted wisdom and practices.

Think about what this would mean: being able to predict, with high confidence, which solutions will succeed and which will fail, before writing a single line of code. Creating software that doesn’t just meet customer needs but anticipates and exceeds them. That’s what this new approach aims for.

By exploring and clarifying the foundational concepts and principles, we can change the B2B and Enterprise SaaS industry. We can systematically and consistently create better B2B software products with fewer resources. We can move the software industry and our customers’ industries toward greater success and productivity.

This is not just a professional interest for me. It’s my life mission, a calling to help improve the software industry and the value it creates. And I know it’s a long road ahead.

Let’s start from the very beginning. The topic of the next article is the cornerstone of this new foundation:

Continue to part #2 of the series:

Markus, the CPO of a promising B2B SaaS company1, stared at the board presentation on his screen. Their new flagship enterprise product was in trouble. After two years of development and millions in investment, it was struggling to gain traction.

It had all started well. The team had conducted discovery work and secured pilot customers. They had ideated and iterated the product with customers. They had even pivoted once, rebuilding almost from scratch. Confident they could serve their enterprise customers in a large market, they had pushed for a productised solution.

The last 6 months had been brutal. No new deals closed, two pilot customers pulled out, and others hesitated to commit.

Despite burning over half the company’s R&D resources, Markus was facing the dreaded Product-Market Fit problem. And it was not a sales problem. It was a problem with the product itself.

“We followed all the best practices,” Markus thought. “Discovery, MVP, agile development, iteration, collaboration with customers. Where did we go wrong?”

Markus’s experience is common. Many B2B SaaS product leaders have found themselves in the same position: they followed the standard playbook, did the work, and still ended up with a product that doesn’t sell. Some find their way out eventually. Many don’t.

The overlooked opportunity in B2B and enterprise software

Since the late 1990s, I have been drawn to the potential of software to change how organisations work. Consumer software has improved significantly since then. B2B and enterprise software has lagged behind, with high failure rates and products that often frustrate the people who use them.

This gap is a large business opportunity. Scalable B2B products could replace thousands of cumbersome, expensive, custom-built systems across industries worldwide. The question is whether we know how to create such products consistently and economically. I believe we can do much better than we currently do.

Questioning conventional wisdom

To realise this opportunity, we need approaches that outperform current practices in B2B and enterprise software development.

That requires questioning established best practices and commonly held beliefs. Conventional methods have not been enough to fulfil the potential of B2B software. What is needed is an approach that can simultaneously:

1. Maximise value creation for customers

2. Minimise complexity for both users and product developers

3. Produce superior software products consistently and systematically

For over 20 years, my focus has been on finding the best way to create great software products for complex domains. I have an almost obsessive need to understand fundamental causes of how things work, and I was convinced that there must be objectively better processes that produce objectively better results.

That conviction has driven me to develop a systematic alternative to conventional approaches.

Subscribe now

10 unconventional principles

The approach I have developed rests on the following principles. Most of them challenge widely held assumptions about product discovery and development of B2B software.

1. Depth of understanding customer needs is the primary measure of progress in creating successful software products for complex domains.

2. Customers know their needs, and those needs can be described explicitly, provided we understand what customer needs actually are, in principle.

3. Customers are able to articulate their needs, even for entirely new kinds of technology.

4. Customer needs, properly understood, change only slowly compared to solutions.

5. Customer needs are therefore a solid and objective basis for a stable long-term product vision and strategy for large B2B and Enterprise SaaS products.

6. Common customer needs can be distinguished from customer-specific ones upfront, ensuring we build a scalable product rather than custom software.

7. It is possible to measure and compare alternative product ideas objectively.

8. This can be done without first building the solution and without engaging customers in a testing and iteration process.

9. Since alternative solutions can be compared objectively, an optimal solution exists that fulfils the customer needs and maximises customer value, and it can be found in practice.

The value creation potential of an optimal solution can be estimated before designing or developing it, which reduces risk and improves return on product development investment.

From iteration to a systematic approach

With this approach, we can define a superior software product without guesswork, opinions, feature requests, creative ideation, brainstorming, divergent thinking, iteration, pivoting, failing fast, trial and error, or copying competitors.

Some of those methods (like implementing feature requests and copying competitors) help create some solution, but they won’t produce a substantially better one.

Others (like ideation and iteration) can be useful when solving entirely new kinds of problems.

Customer needs for B2B and enterprise software, however, have many repetitive patterns across industries. They are rarely entirely new. A solution that addresses those needs can therefore be found in a direct and consistent way, without extensive iteration.

Three questions that determine product success

Whether a B2B SaaS product succeeds or fails depends on the answers to three questions. A sound approach to product development should help answer all of them with confidence.

What is the right problem to solve?

• What are customer problems (or customer needs), in principle?

• How can customer problems be discovered systematically, reliably and effectively?

• What customer problems are worth solving, and how much value could be created by solving them?

• Which customer problems are common enough for a scalable software product?

What is the right solution to the problem?

• What is an optimal solution to the overall customer problem, from the customer’s perspective, given existing software technology?

• What is the optimal scope, given that solving some parts of the overall problem is more valuable than solving others?

• What is the most direct way to find this optimal solution?

Can we make money solving the problem?

• How to predict how much of the customer value we create we can capture as revenue?

• How can we be confident, in advance, that our solution will win against competitors?

• What is the best path to the optimal solution that maximises business value?

Product leaders who can answer these questions with evidence rather than intuition make better investment decisions and can defend those decisions to their boards.

Share

Deductive Innovation: a systematic alternative

I call this approach Deductive Innovation. Its purpose is to find an optimal software solution for large, complex customer problems as directly as possible.

The term “deductive” means that B2B and enterprise software products can be systematically deduced from discoverable facts about customers, their problems and circumstances, and from an understanding of what software technology can do.

With Deductive Innovation, defining and designing a product becomes primarily a process of inferring an optimal solution from the customers’ viewpoint, rather than a gradual process of ideation, iteration, or imitation. The role of iteration is limited to fine-tuning details.

In my experience, this approach surfaces new value for customers that they would not have asked for or imagined. It tends to produce solutions that improve customers’ productivity by 5x to 10x and deliver substantially better business outcomes.

Why this is about customers, not technology

Deductive Innovation is not a new software technology or engineering process. It does not help in inventing new technologies.

It addresses the customer-facing and business risks of B2B product discovery, which are almost always more critical than feasibility risks. Even technically excellent software will fail commercially if it doesn’t create enough value for customers.

Technology changes quickly. Properly understood customer needs stay largely the same, whether the technology is cloud computing, smartphones, analytics, big data, microservices architecture, AR/VR, blockchain, IoT, metaverse, or today, generative AI. Discovering, analysing and understanding customer problems in a way that consistently produces superior solutions is the core of this approach.

Who this newsletter is for, and what comes next

This newsletter is for B2B SaaS leaders, founders, and product managers who suspect that conventional approaches to product development are not enough, and who are willing to consider alternatives.

I write about:

• Customer problem discovery: how to find and understand the problems worth solving

• Product strategy and opportunity selection for B2B SaaS

• Systematic product design for scalable products

• How and why conventional approaches (agile, lean startup, design thinking) fall short in complex B2B domains

• Deductive Innovation: how it works, its real-world applications, and its limitations

• Case studies and practical examples

I believe the ideas explored here will, over time, change how B2B software products get built. I am not the only one arriving at these conclusions. Others are developing similar or compatible approaches from different starting points. This newsletter is where I develop this thinking, test it against real-world experience, and share what I learn.

If you subscribe, you will receive a free copy of “How to Build a Lasting Competitive Advantage in B2B SaaS,” a report packed with insights from 31 B2B SaaS product executives and founders I interviewed.