Rethinking Enterprise Software: 5 Ways Best Practices Are Failing Your B2B SaaS Product
A fundamental obstacle is holding the B2B SaaS industry back. Conventional methods like agile can’t solve it, and there’s a missing element needed for real innovation.
💡 This is the first article in a series that dissects issues in B2B SaaS product development and challenges common industry beliefs and practices. Subscribe to keep following!
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.
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:
“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.
“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.
“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.
“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.
“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:
What exactly are the “customer problems” that our software is supposed to solve in the first place?
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:
The industry as a whole has an insufficient, vague, and missing understanding of what “customer needs” or “customer problems” are. Not just in practice, but even in principle.
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. I believe none of them are correct or sufficient for creating superior B2B software directly and consistently.
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.
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:
The parts of the large software are not the right parts.
The parts don’t fit together well.
The parts are scoped wrong relative to other parts.
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.
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:
What, in principle, is a “customer problem” to which a software product as a whole is a “solution”?
Subscribe to get the next articles directly in your inbox.
Continue to part #2 of the series:
From Solutions to Problems: The Problem with Solutions in B2B SaaS Industry
Discover why focusing on solutions holds back your B2B software product. Avoid four very common misconceptions about the nature of customer problems that prevent creating innovative solutions.
Y-Combinator: Requests for Startups, archived from September 17, 2014: https://web.archive.org/web/20140917215752/http://www.ycombinator.com/rfs/#enterprise