Understand First, Scale Second: A B2B SaaS Founder’s Story
A Finnish startup spent months interviewing customers before writing any code, then funded growth entirely through client revenue. This is the story of their disciplined product discovery.
Everyone will tell you speed is survival for a B2B SaaS startup. Ship fast, land the logo, raise the next round before somebody faster takes the deal.
Tom did it differently. Before he wrote a line of code, before he even had a company, he spent months just asking questions. He had roughly twenty conversations with CEOs and COOs who had never heard of his product, because it didn’t even exist yet. He didn’t ask them to buy anything. He asked if he could come back once he actually understood their problem and could propose a solution.
Today, that company has never taken a euro of outside investment. It has grown entirely on money from customers, one careful hire at a time. Its 7-figure revenue has grown around 20% annually and it runs deliberately at break-even so every euro goes back into building the product. When I spoke with Tom it had just closed deals worth more than its own annual turnover.
Many founders would call all that listening reckless, time spent not building. Tom would call it the best way he knew to avoid building the wrong thing.
The lesson in Tom’s approach is simple: understanding before speed. Once you understand correctly, you can move as fast as you like. In B2B, the mistake is moving fast before you’ve understood.
The Cost of Building Without Understanding
Not all SaaS teams take this patient approach. Eric, VP of Engineering at a venture-backed startup building enterprise AI tooling, experienced the consequences of insufficient problem understanding firsthand.
Under pressure to accelerate growth, his team developed a self-serve test version of their platform. The idea was that if prospects could test it themselves, deals would close faster. A dedicated engineering team started implementing the idea, assuming it would drive quick wins. But the initiative backfired:
They created the wrong experience: the UI and workflows didn’t match how customers would actually use the platform in production.
They built it for the wrong audience: casual testers, not the enterprise decision-makers who would buy the product.
The rushed solution didn’t align with strategic goals.
By the time they recognised the mistake, a full person-year of engineering effort was gone. Unfinished code from the abandoned project kept causing bugs for months afterward. “This was really expensive, it cost us about 150,000 euros to implement, and opportunity cost on top of that, whatever it was,” Eric reflects.
Tom’s team spent that same stretch of time on customer interviews instead of code. They took the time to thoroughly understand the problems they were solving before building and scaling.
The Enterprise Software Development Challenge
Building B2B software comes with a built-in pressure to expand capabilities and demonstrate progress. In every customer meeting, someone raises an urgent feature request that sounds like it could change the business, and there’s always a reason to say yes.
If you say yes often enough without a disciplined way of understanding what’s underneath each request, you end up with scattered development priorities. Complexity grows for both the customers and the development team. Engineering wastes time building functionality that a handful of customers try once. What began as a plan for a scalable platform turns into a system trying to please everyone a little, and nobody completely.
Prioritising Deep Understanding Before Code
When Tom and his co-founders started building their enterprise software, they took a methodical approach focused on understanding before building.
“We started developing a solution in a situation where we were highly aware of the problem and had studied it quite thoroughly, meaning we had interviewed customers, but we didn’t yet have a solution for it,” Tom explains. “In other words, we first made sure the problem was real, and only then began considering whether we could solve it.”
Instead of writing code, they invested in upfront understanding. “I initially conducted about 20 such conversations with CEOs and especially COOs,” Tom recalls. “We told them we’re interested in researching this problem. We asked if we could come back with a proposed solution if we came up with something.”
They worked this way because discovering and understanding enterprise problems requires interaction with customers. Customer problems in B2B aren’t public knowledge you can just pull from an AI or a search engine. “Enterprise software is a very challenging type of software,” Tom says, “because the business problems being solved here aren’t something you can just google. You need to get to talk about them with customers.”
Their approach began with high-level problem exploration, gradually moving to specific user situations they could address. Only after establishing this foundation did they begin developing solutions.
The Depth of Effective Product Discovery
Tom’s team approached their customer conversations with unusual patience. Where many software companies might schedule a quick discovery call, they invested hours with each potential customer.
“Such a process doesn’t arise in a day or a week,” Tom explains. “It takes many months to really interview people and really get into what’s a good solution. We wanted to spend more time than just 15 minutes on these conversations. Often it takes 30-45 minutes just to get to the core of the issue.”
In enterprise software, the most valuable discovery often starts only once those first 30 to 45 minutes. In these meetings, Tom had developed a particular habit for listening. As people talked, he kept separating what they said they wanted from what they actually needed, which was often not the same thing and which they typically couldn’t put into words at all.
“The wants are indications of demand you can tackle with marketing, because people are already actively looking for something,” Tom explains. “The needs are harder, because people aren’t necessarily looking for what they need. But if you manage to address the need with your solution, your product gets very good retention.”
Their approach was built around this methodical exploration and the distinction between wants and needs. They kept finding how surface-level feature requests often mask deeper organisational challenges.
“You need to build the best possible relationships with as many companies as possible, in a way that fosters trust,” Tom emphasises. “Only then can you truly start solving deep problems.”
Tom separated “wants” from “needs” intuitively. But:
How do you systematically distinguish what customers “want” (solutions they ask for) from what they actually “need” (their underlying problems)?
How can you discover the underlying customer problems in any B2B domain, without fail, even though customers typically can’t articulate them?
Deductive Innovation is the answer to these questions for B2B software. Read more:
Uncovering the Real Problems Beyond Feature Requests
When potential customers expected a common feature that every competitor already offered, adding it looked like an easy win. Building the obvious feature would match customer expectations and could help close some deals.
But interviews and observations with 20-30 people uncovered deeper issues. For example, underneath the immediate task, users were frustrated by a communication gap in the process. In certain situations, they would be left waiting indefinitely for decisions they needed, which prevented them from making other commitments.
“It’s incredibly frustrating for users,” Tom explains. “They take action but don’t know when they’ll get a decision. They’re left in limbo, unable to plan ahead. Then the deadline passes, and they never even got a response.”
So the team built more than the feature competitors had. The software enforced communication timelines. It tracked commitments and reminded decision-makers of their deadlines, giving users a clear answer about when they’d hear back.
Behind the obvious feature was a real communication problem that was driving away valuable users. Because Tom’s team spent the necessary time to understand the situation in depth, they built a solution for the real underlying problem rather than just shipping the feature everyone else had.
“This is just one of twenty small details that decide whether you end up with a solution that actually satisfies both sides,” Tom says. “That’s why it takes months, in addition to the coding.”
A Deliberate Two-Phase Strategy
Instead of trying to pursue rapid growth immediately, the founders developed a thoughtful two-phase strategy that required patience.
Phase 1: Customer-funded validation
“First phase: Find a suitable number of companies interested in this problem, and willing to collaborate on a solution that, in a way, is customised to address their specific problems,” Tom explains.
These were not ordinary early adopters. Each first-phase customer provided revenue and, just as importantly, insight into how the software needed to work in their real, messy enterprise environment.
Their “suitable number” of companies was a deliberate choice aimed at two different risks at once.
The first was a validation risk. A problem that shows up with one customer might just be that customer’s quirk, not an industry-wide problem. “If we get a hint from one source that a certain feature would be a good solution, we need to verify it with other customers,” Tom explains. “Because we are creating a product we need to ensure it’s not a company-specific problem, but rather a more generalisable one.” Without enough customers, you can’t tell a real pattern from a one-off occurrence.
The second was a dependency risk that Tom had watched sink other companies. Some B2B startups make a different bet early on: land one large anchor client, treat it as proof of demand, and build almost exclusively around what that one company needs. It works, for a while. Some of those companies are still limping around, others aren’t.
“Those big customers suck up all the oxygen,” Tom says of the pattern. While a problem clearly exists, one customer doesn’t provide proof that the solution generalises to anyone else. Tom admits his own team hasn’t sidestepped this trap perfectly either, but avoiding it was a conscious goal from day one, not a lucky accident.
So the target was a narrow middle: few enough customers that the relationships could stay close, but not so few that a single logo could hold the company hostage.
The strategy paid off. After presenting their solution concept to early prospects, one customer immediately recognised its potential. “This is so good that you should set up a new company,” the customer told them. “We’ll cover the costs upfront and act as a reference customer.”
Tom still remembers the moment with amusement: “They basically pitched it back to us in a way that it would’ve been foolish to say no.” Even before the company formally existed, they had real validation: commitment from customers, not just interest. “At that point, we felt fairly confident that multiple companies were interested in the solution.”
Phase 2: Scalable go-to-market model
Phase two is the shift to a more scalable go-to-market model. The founders had identified, years in advance, specific capabilities their product needed before that transition made sense. “We have known for a long time exactly what we need to achieve,” Tom explains. “Once we have these key elements in place, we’ll open the product so anyone can subscribe with just a credit card, without needing our direct involvement.”
This transition to product-led growth was part of their strategy from the beginning, not just an afterthought. But Tom’s team wouldn’t rush toward it before their groundwork, the deep cross-validated understanding from phase one, was actually laid. With only a few features left to implement, they approached this milestone on their own terms.
The Strategic Advantage of Customer-Funded Growth
Their approach to funding was just as deliberate. While many competitors sought venture capital, Tom’s team chose to grow entirely through customer revenue.
“From an intellectual property perspective, we are developing a product, but financially, we are funding it by serving our first phase customers.” Those early customers weren’t investors but they weren’t quite ordinary clients either. They paid close to the cost price for a solution focused on their specific problem. From the customers’ viewpoint, they were getting essentially a customised solution. From Tom’s perspective, that revenue was building a product his company would own outright while proving that there is genuine customer demand.
“Loss-making operations are terribly dangerous,” Tom observes. “But being profitable doesn’t make sense either when the goal is to grow. Our intention is to run at zero-profit.” Every euro of revenue went straight back into development. “Every time we’ve had money left over, we’ve always recruited someone new. We’ve grown according to cash flow.”
Tom doesn’t claim outside capital would have been useless. “Another company that chooses a different funding strategy, such as taking investor money early on, could do this faster, at least financially,” he explains. “But I’m not sure they could do it much faster in terms of the insight you gain into the customers.”
The revenue that kept the company going, the conversations that kept it solving the right problem, and the evidence that proved there is demand for their solution came from exactly the same source: customers.
How Validation Eliminated the Worst Product Fear
Verifying problems across multiple customers, rather than trusting a single loud request, meant every feature they built addressed a real and shared problem, not just one client’s preference. This approach ensured they were building a scalable product rather than a collection of client-specific customisations.
“The biggest success has been that we’ve been able to validate that the product really does the job,” Tom reflects. “You fear that you make a product and then it doesn’t solve the problem. That’s the worst that could happen. That fear is now gone.”
Shipped something that turned out to not solve the right problem? Leave your comment in the end:
Tom’s company is still small by ambition’s standards, a 7-figure revenue and dozens of carefully chosen customers, not yet the thousands he is aiming for. But the expansion now underway is what that patient discovery bought them: scaling no longer feels like a gamble. They know their product solves real, verified problems, and does it well.
What Every B2B SaaS Leader Should Learn From This
Three convictions guided everything Tom’s team did: understanding comes before building, patience in development beats rushing to ship, and revenue from real customers is worth more than a term sheet.
None of this is unique to B2B software. But in complex enterprise environments, skipping the sequence is unusually expensive, which is exactly what happened to Eric’s team. Their self-serve platform experiment burned a full person-year of engineering effort building for customers who were never going to buy it.
In complex B2B, get the direction right before you move fast. Understand customer problems before building, and don’t rush to scale the business until revenue from several customers shows the direction is right.
The 4-Step Sequence That Drives Enterprise Software Success
Tom worked through the problem in a deliberate order. Eric’s team built first and understood later, at real cost. To build enterprise software that scales:
Deeply understand customer problems through sustained investigation of the underlying problem space, well beyond a quick discovery call.
Validate that these problems are common across customers by checking whether different companies share the same underlying problem situations, rather than collecting feature requests.
Develop solutions with a small set of committed customers. They fund the work, but they also cross-validate the problem, keep you from depending on any single customer, and provide a source for deep insight into how the product must behave in messy real conditions.
Shift to product-led growth only when you’ve reached problem-solution fit where your product delivers real value consistently, and you have ongoing revenue from customers to prove that.
If you skip that sequence, you pay for it later, when it is harder and far more expensive to change direction, as Eric’s team discovered.
A Sustainable Path to Winning in B2B SaaS
This kind of patience runs against almost everything B2B SaaS culture rewards. AI-supported development puts pressure to iterate solutions faster than ever. Investors want hockey-stick charts. Conference stages look for a founder who disrupted something in 18 months.
Tom’s story doesn’t fit that model, and he isn’t trying to make it fit. But it is proof that a small team can out-build larger competitors by refusing to guess at what customers need before finding out for sure.
There is a discipline that removes Tom’s fear that you build the wrong thing. Discover the customer’s problem space, as a fact, independent of any solution, before you let yourself design anything. Verify the problems hold across more than one customer. Only then start thinking about solutions. Work out what the product should actually do based on the customer problems you uncovered. Then build it.
I have spent twenty years building a systematic version of that discipline, mostly because I kept watching companies skip straight to building without doing the first part properly. I call it Deductive Innovation. Tom never used a name for his approach. He just made sure, at every step, that he wasn’t about to find out far too late that he had built the wrong thing.
This article is based on my confidential conversations with a B2B SaaS founder and a VP of Engineering. Names and identifying details have been changed. Quotes are drawn directly from our conversations, but they have been translated from Finnish and lightly edited for clarity, brevity, and confidentiality.
More from the 31 interviews behind this story
Tom’s story came out of a series of in-depth interviews I ran with 31 B2B SaaS founders and product leaders. His was one of the most interesting, but the same questions came up across all of them: how do you find the right customer problems to solve, and how do you avoid expensive detours?
I wrote up what I learned in a report, How to Build a Lasting Competitive Advantage in B2B SaaS. It covers:
How these companies validated product opportunities before burning through funding
Why some get stuck building custom solutions for individual clients while others create scalable products
The key mistakes that turn a promising product into a services business
Real stories of both successes and failures, in their own words
Subscribe now and I’ll send the report to you, along with new articles like this one (at most weekly; quality over quantity, no spam):