The Hardest Thing for a Founder to Build Is Less

Why the conviction required to start a company can also make it harder to learn what the market actually wants.

One of the hardest conversations we have with founders has nothing to do with technology. It happens when we tell them they may need to build less.

That may sound strange coming from the CEO of a software company. A founder comes to us with a substantial project, a long list of requirements, and the budget to build it. The obvious commercial response would be to accept the scope and get started.

For years, we sometimes did exactly that. We would challenge the scope, explain what we thought was necessary, and recommend starting smaller. But if the founder insisted, we would eventually build what they wanted. After all, it was their product, their vision, and their money.

I've changed my mind about that.

When a detailed specification creates the illusion of certainty

Recently, a founder came to us with an RFP for a real estate investment platform that would allow multiple investors to participate in real estate opportunities.

The RFP was remarkably thorough. It included blockchain, smart contracts, ownership mechanisms, investment workflows, and many of the capabilities you might expect from a mature platform.

The problem wasn't the quality of the RFP. The problem was that the idea had not yet been validated.

We knew a great deal about how the founder wanted the product to operate, but very little about how the market would respond. Would people actually invest this way? What would they need to see before trusting the platform with their money? Which parts of the proposed experience would matter to them?

We didn't know yet.

Blockchain may eventually prove necessary. Smart contracts may create important value. The proposed workflows may turn out to be exactly what customers need. But at that point, they were still assumptions.

There is a meaningful difference between something we believe a product will need and something the market has given us evidence that it needs.

How everything becomes a must-have

We recently saw something similar with another founder who wanted to create a marketplace connecting people who needed work done with service providers who could do it.

He described the product as an MVP, but the requirements included payments, WhatsApp integrations, multiple workflows, and a long list of functionality. It became difficult to distinguish what was necessary to validate the business from what belonged to the founder's vision of the eventual product.

We've seen this pattern many times.

Most founders understand validation intellectually. They know what an MVP is. They know startups are supposed to launch, learn, iterate, and sometimes pivot.

The conversation changes when it is their own product.

A feature that seems optional from the outside can feel essential to someone who has spent months imagining how everything should work. Remove one capability and perhaps customers won't understand the value. Remove another and the experience may not be good enough. Little by little, almost everything becomes a must-have.

We've had founders become frustrated when we've recommended validating something before developing the complete product. Some haven't liked hearing that what they are describing isn't really an MVP anymore, but something much closer to the first version of a mature product.

We've even lost deals because we recommended reducing the scope.

There is an uncomfortable commercial reality behind that. Software companies make more money when their clients build more software. When we tell a founder that a significant part of the scope should wait, we may be reducing the size of our own project or losing it altogether.

Today, I'm comfortable with that. We weren't always as disciplined about it.

We learned this the hard way

Years ago, we worked with a founder who had a very specific vision for his product. Among many other requirements, he wanted the application to include a blog.

We didn't believe the blog was necessary to validate the core proposition, but the founder considered it important, so eventually we agreed to include it.

Then the requirement expanded. Users needed to comment on posts. Comments needed replies, and those replies should potentially support another level of replies.

We pushed back on some of that scope. The product launched with the blog and comments, but without the complete multi-level reply functionality the founder had imagined.

The business didn't perform the way he expected, and eventually part of the explanation became what the product was missing. Certain functionality wasn't there, and the blog didn't have the complete commenting experience he wanted.

By then, he had paid us more than $75,000.

I don't tell this story because I know those missing features wouldn't have changed the outcome. I don't know that. That's actually the important part.

There were so many assumptions inside the product that when the market didn't respond, it became extremely difficult to isolate why. Perhaps the target customer was wrong. Perhaps the problem wasn't painful enough. Perhaps the positioning or business model created friction. Or perhaps a missing feature really would have made a difference.

There was no clean answer because we hadn't designed the investment around learning the answer.

That experience changed how I think about our responsibility as a technology partner. It was no longer enough to say that we had recommended something different but ultimately built what the client requested. If we could see a significant risk that the founder couldn't see, simply documenting our disagreement and proceeding wasn't necessarily enough.

I no longer think this is really about MVPs

For a long time, I thought this happened because founders didn't fully understand what an MVP was. After seeing the pattern repeatedly, including with smart and experienced founders, I no longer think that's the most interesting explanation.

I think it has much more to do with conviction.

Starting a company requires an unusual amount of it. You have to believe in something that doesn't exist yet. You may invest your savings, leave a good job, spend years pursuing an idea, and persuade other people to believe in something they cannot yet see.

Without that conviction, many companies would never get started.

But believing strongly that a problem deserves to be solved can gradually become believing that you already know the right solution. Confidence in the solution can then become confidence in the individual features, workflows, integrations, and technical decisions that make up the product.

A hypothesis slowly becomes a requirement.

A founder may begin by thinking that customers could value a WhatsApp integration and eventually become convinced that the product cannot succeed without it. Blockchain may begin as one possible mechanism for creating trust and gradually become an essential part of the architecture.

The vision gradually becomes a specification.

Once that happens, suggesting that something be removed can feel less like a conversation about sequencing investment and more like questioning the vision itself.

Building gives us something validation often doesn't

Building creates a tangible sense of progress. A development team can work for a month and at the end there are new screens, workflows, integrations, and features. The founder can open the application and see where the money went.

Validation produces a different kind of progress. A founder can spend two weeks speaking with potential customers without producing a single new screen. Those conversations may even leave the founder with less certainty because something they believed strongly has been challenged.

But particularly at the beginning of a company, reducing uncertainty can be considerably more valuable than increasing functionality. A feature can always be built later. Capital and time spent before discovering that the feature didn't matter are much harder to recover.

This is where founders and software companies can both get trapped. The founder feels progress because the product keeps becoming more complete, and the software company feels progress because it keeps delivering against the backlog. Everyone can be executing well while the most important question remains unanswered: are we learning whether this business should exist in the form we currently imagine?

Some of our most successful founders started very differently

What ultimately changed my perspective wasn't only watching products fail. It was looking back at some of the founders we've worked with who became successful.

One came to us with a machine designed to measure a baseball pitcher's arm after training. The original setup was fairly rudimentary: the machine produced a measurement on a digital display, and we built a simple web application around that information.

As the founder learned, we introduced algorithms that provided more useful information about changes in the player's arm. The business gained traction, and eventually the product moved from web to mobile.

The important part wasn't the technology used at each stage. The founder didn't need the final product before he could begin learning whether the underlying idea created value.

We've seen the same pattern elsewhere. One founder started a Vendor Management System using no-code technology. It had limitations, but it also had paying customers. Eventually the business grew enough that those limitations became real constraints, and we helped move the product to its own platform.

Another founder in healthcare started with a basic no-code solution connecting doctors and patients. It wasn't what the company would ultimately need at scale, but it established that people wanted the service.

A founder in the travel space started with forms that ultimately generated a personalized itinerary as a PDF. It was far from the architecture of a mature travel technology company, but it was enough to discover whether customers valued the service.

None of these founders lacked ambition. They simply didn't require their first product to contain all of it.

This isn't an argument for building cheap software

“Build less” can easily become bad advice.

Some ideas genuinely require significant technology before they can be tested properly. Security, compliance, integrations, reliability, or a certain level of user experience may be fundamental to the proposition being validated. An experiment that removes what customers need in order to experience the value of the product doesn't teach us much.

The objective isn't to make the first product as small or inexpensive as possible. It is to avoid making commitments that the available evidence doesn't yet justify.

That has changed the way I think about early product conversations. Instead of beginning with which features belong in the MVP, I increasingly want to understand what we're trying to learn. What do we actually know? What are we assuming? Which assumptions could materially change the business if they're wrong? And what do we need to build to find out?

Some requirements represent things we know. Others represent things we believe. Some reflect behavior customers have already demonstrated. Others represent how we currently imagine the future product will work.

Treating all of them as equally certain is where a great deal of unnecessary risk begins.

Let the evidence earn the next investment

I've come to think about product development less as a sequence of features and more as a sequence of commitments.

The first investment should allow us to learn something important. What we learn should influence the next investment, and each subsequent commitment should be made with more evidence than the one before it.

That doesn't mean the investments always remain small. If customers are paying, usage is growing, and technology has become a constraint, there may be very good reasons to make a much larger commitment. That may mean rebuilding architecture, moving away from no-code, creating a mobile application, adding integrations, or developing more sophisticated workflows.

The difference is that the business has now taught us something.

This is not the same as imagining the mature product at the beginning, dividing its construction into phases, and calling the first phase an MVP. Both approaches involve multiple releases, but only one allows what we learn from the market to materially change what gets built next.

The less we know, the more careful we should be about how much we commit. As evidence grows, the investment can grow with it.

Conviction isn't the problem

After working with founders for many years, I don't think they need less conviction. Without it, many of the successful businesses we've helped build probably wouldn't exist.

What I've come to distinguish is conviction about the problem from certainty about the solution.

A founder needs enough conviction to believe that a problem is worth solving. What becomes dangerous is allowing that conviction to quietly turn into certainty that they already know exactly how the market wants it solved.

Today, when a founder brings us an incredibly detailed specification for a product that hasn't been validated, I don't immediately think about how we're going to build everything in the document. I want to understand which parts come from evidence, which come from experience, and which are still assumptions about a market that hasn't had the opportunity to respond.

That usually brings us back to three questions:

What do we actually know? What are we still assuming? And what is the smallest responsible investment that will help us discover the difference?

Sometimes that means recommending a smaller project. Sometimes it means telling a founder that what they're calling an MVP looks much more like the first version of a mature product. And sometimes it means we don't get the project.

After enough years of doing this, I'm comfortable with that. I'd rather lose a project because we questioned assumptions too early than win one by helping a founder turn all of those assumptions into software before the market had a chance to question them.