Knowing the Problem Isn't the Same as Knowing the Solution

Founders with deep industry experience often have an advantage: they know the problem firsthand. But knowing a problem intimately doesn't necessarily mean the solution has been validated. I was reminded of that during a project we chose not to pursue, even though it was worth more than $55,000.

A while ago, a founder came to Soluntech through a startup community with what looked like a very promising project.

He had spent years working in the industry he wanted to build for, and the problem he described was one he knew firsthand. The product was essentially intended for people doing the same kind of work he had done, so he wasn't an outsider trying to understand an unfamiliar market. He knew the industry, had experienced the problem himself, and had enough budget to build an MVP.

He also had a very clear idea of what he wanted us to build.

His RFP was unusually detailed. It described the technologies he wanted to use, the integrations, how different parts of the product should work and even aspects of the interface. From a software development perspective, there was more than enough information for us to estimate the project and start talking about execution.

During our first conversation, however, I asked him a question that changed the tone of the meeting:

How do other people in your role solve this problem today?

I could tell he didn't particularly like the question, and looking back, I understand why.

He had spent years in this industry. I hadn't. He was the domain expert and had personally experienced the problem he was describing, so I imagine my question sounded as though I was questioning whether he really understood his own profession.

That wasn't what I meant.

I believed the problem was real for him. What I wanted to understand was whether other people doing the same job experienced it in a similar way, how they were dealing with it today, and whether the solution he had designed for himself would make sense to them as well.

The question wasn't whether he understood the problem. It was whether we had enough evidence that the market wanted the solution he had designed.

We didn't really have an answer to that yet, and that made me uncomfortable with moving directly into an MVP.

We Had Seen This Before

We've been building software at Soluntech for about 14 years, and this wasn't the first time we'd found ourselves in this situation.

We've worked with founders who knew their industries extremely well and came to us with a very clear idea of what they wanted. In the past, our response was often straightforward: understand the requirements, estimate the project and build it. After all, the client knew the business better than we did. Who were we to tell them what their users needed?

Sometimes we built exactly what was requested. Technically, the projects were successful: the software worked, the requirements were delivered and the product did what it was supposed to do.

But sometimes the market didn't respond the way the founder expected.

Experiences like those changed the way I think about our responsibility when someone comes to us with a product idea. Knowing an industry very well is an enormous advantage, and experiencing the problem yourself is an advantage too. But neither automatically means that the solution you have in mind is the one other people will want.

It's an easy distinction to understand intellectually. It's much harder when you've lived with a problem for years and have already spent months thinking about how to solve it. By then, what you know about the problem and what you believe about the solution can start to feel like the same thing.

They aren't.

He Might Have Been Completely Right

I think this distinction is important because we weren't telling this founder that his solution was wrong.

We didn't know that. He might have been completely right.

What concerned me was that I couldn't see enough evidence to distinguish between what we knew and what we were still assuming. We knew he had the problem, we knew he understood the industry, and we knew he had thought deeply about the solution. What wasn't clear was whether enough other people experienced the problem in the same way and would respond to the solution he had designed.

So rather than proposing the full MVP immediately, we suggested doing something smaller first.

The product involved some advanced technology, so there were technical assumptions that could be tested through a proof of concept. We also thought a prototype would allow him to put the proposed experience in front of potential users before committing to the full product.

This wasn't about delaying the MVP or turning validation into a long consulting exercise. We wanted to answer a few important questions relatively cheaply. If potential users responded as he expected, we could move forward with greater confidence. If they didn't, it would be much cheaper to learn that while changing a prototype than after building the product.

This is the kind of uncertainty we now try to make explicit through Testing Assumptions: separating what appears to be known from what still needs evidence before a larger investment is made.

He wasn't interested in that approach.

He wanted the MVP he had already specified, which I can also understand. From his perspective, he had already done much of the thinking. Going backwards to test decisions he considered settled probably felt unnecessary.

From our perspective, however, building the entire product would have required us to treat those decisions as validated simply because they had been written into an RFP.

We weren't comfortable doing that.

So we decided not to pursue the project.

It was worth more than $55,000.

A Detailed RFP Can Still Hide Uncertainty

I've thought about that conversation several times since, and strangely, one of the things I remember most is how detailed the RFP was.

Normally, detail makes a software project feel safer. The requirements are clear, the technology has been selected, the integrations are defined and the interfaces have been imagined. There is less ambiguity, which usually makes estimating and executing the project easier.

But I've learned that detail can also create a false sense of certainty.

A specification tells you what someone has decided to build. It doesn't necessarily tell you whether the assumptions behind those decisions have been tested.

A detailed specification is not evidence of a validated product.

That doesn't mean I believe founders should spend months researching every assumption before writing a line of code. You can take validation too far as well. At some point you have to build something, put it in front of people and make a bet. That's part of creating a product, and no amount of research is going to eliminate that uncertainty completely.

The important thing is knowing where the evidence ends and where the bet begins.

In this case, we believed there was still an important assumption that could be tested relatively cheaply before committing much more money to it. The founder disagreed, and ultimately that meant we weren't the right partner for the project he wanted to execute.

When the problem itself, the user, or the expected outcome still needs clarification, Product Discovery can help establish that foundation before scope becomes fixed. And when the direction is sufficiently clear, MVP Strategy is about defining the smallest responsible build that can create useful evidence without turning every uncertainty into production software.

I Still Don't Know What Happened

I don't know what the founder did after our conversations.

Maybe he found another software company willing to build the MVP exactly as he had specified it. Maybe they built it and it worked. I genuinely hope it did.

That's why I've never thought of this as a story about Soluntech being right and the founder being wrong. We didn't know he was wrong. The issue was that we didn't have enough evidence to know that he was right either.

Years ago, I probably would have been more comfortable saying: He's the client. He knows his industry. He knows what he wants. Let's build it.

I'm less comfortable with that today.

Not because I think we should make decisions for our clients. We shouldn't. Founders ultimately decide which risks they are willing to take, and sometimes they'll choose differently from what we would recommend.

But if someone is going to invest a significant amount of money with us, I think part of our responsibility is to tell them when we see a risk they may be underestimating, even if they disagree with us and even if raising that concern means we don't get the project.

There is an obvious commercial tension in doing that. A software company gets paid when software gets built. Asking whether something should be built, or whether it should be built yet, can work directly against that incentive.

That's precisely why I think the question matters.

After 14 years of building software, I've become much more comfortable saying, “I don't know.” I've also become much less comfortable accepting someone's money while pretending that I do.

Sometimes our job is to build what a client asks us to build. Sometimes it's to ask one more question before we do.

I think that's part of the job.