The amplified build trap: why “think before you build” is more important than ever

As a product person, your challenge is to solve a meaningful problem in a differentiated way and find customers who are willing to pay for it.

Maybe you are a product person at an established company or maybe you work at a startup. Either way, your job is to find product/market fit. But recently, the rules of the game seem to have changed.

The cost of building software has plummeted. Thanks to low-code, no-code, near-shoring and AI, you can spin up features in hours instead of weeks. It feels like the old rules of "validate before you write code" are dead. Why spend weeks testing a landing page or doing 40 user interviews when you can just build the feature and see what happens?

Because of this illusion of speed, the medium of validation has changed from mockups to finished products. But this convenience hides a risk: the "Build Trap" hasn't disappeared, it has only grown bigger.

Here is how the shift in building costs changes the way you should look at product development. There are still three angles, simplified:

1. Before development
2. During development
3. After development

Before development: the death of the mockup

In the past, developer time was your most expensive bottleneck. Teams used wireframes, fake-door tests, focus groups and click-through prototypes to protect those precious engineering hours. Some people in product management developed the habit of shipping a rough first version, which they mistakenly called an MVP, just to get early feedback. But as Eric Ries wrote in The Lean Startup:

"The MVP helps entrepreneurs start the process of learning as quickly as possible. [...] Its goal is to test fundamental business hypotheses."

Eric didn't say to start by coding. But today, a fully coded, working V1 is often just as fast to produce as a high-fidelity mockup. The shift is real: you still need to validate, but the artifact you use to validate is now a working product.

What hasn't changed is the question that comes before any artifact: who you are building for and what they are struggling with. A cheap build tells you whether your solution works, but it can't tell you which problem is worth solving. Only a conversation with customers does that, and I'll come back to it at the end.

During development: embracing rework

Because code used to be so expensive, modern "Agile" often mutated into rigid sprints designed to avoid rewriting code at all costs. It led straight into the sunk cost fallacy and mini-waterfalls. Agile was never meant to be that way, but that's for another post.

The sunk cost fallacy states that you keep committing time and resources to something because the resources already invested will be lost otherwise. Past effort heavily influences future decisions.

But when building is fast and cheap, rework is no longer a financial disaster. It is a natural part of the learning cycle. You can afford to throw code away. Throwing darts is cheaper than ever. But if you are doing it without aiming, you are still going to miss the bullseye.

After development: the product as the prototype

So, you arrive at launch with a surprisingly complete set of features. Instead of treating this as the final destination, the product itself becomes the validation experiment. You validate against real behavioral data (using Mixpanel, Amplitude or Heap) rather than hypothetical survey data.

But here the trap is set. Because it was so easy to build, you have a long menu of features to offer. You throw them all at the customer to see what sticks. Your analytics are going to explode and you'll drown in numbers that say what happened but not why. So you need to go back to customers anyway to find out their hidden drivers and motivations (struggles, habits, anxieties).

The amplified build trap

This is where teams go wrong, because they forget that developer time was never the only bottleneck. The ultimate limiting factor is customer bandwidth.

Finding customers is hard. Customers are bombarded with new products and features every single day. They cannot consume, learn or integrate 10 new features a week.

In the past, the high cost of engineering forced teams to be disciplined. Without that financial friction, they fall straight into an amplified Build Trap: shipping feature soup that overwhelms the user and degrades the core value of the product. If your product is bloated, confusing and doesn't immediately solve their problem, they leave. Or worse: they switch to your competition. You only have one chance to make a first impression.

The better way: step 1 is customer conversations

You are back exactly where you started. The advice to carefully select and validate what you give to customers still holds. Just because you can build it cheaply doesn't mean you should expose the user to it.

You must protect customer attention as carefully as you used to protect developer time. Curation, not creation, is now the hardest part of product development.

Before you rush to build a fully-coded V1, you need to know exactly whose attention you are trying to earn. This means your very first move must be to step out of the building and talk to your customers.

When you sit down to create your Business Model Blueprint (like a Lean Canvas), start directly with the Customer Segment box. This is Step 1. But don't just list a demographic; instead use the raw insights from your customer conversations to define their Job to be Done (JTBD). What is the meaningful progress they are actually struggling to make?

Once you have talked to enough customers to nail down that exact Job, you can fill in the rest of your blueprint and stress-test it for Desirability, Viability and Feasibility. Then pitch it to stakeholders for a second opinion.

Shipping feels like progress and the people around you usually reward it, so this habit is hard to break. Start with customer conversations until you can name the Job to be Done, choose carefully what reaches customers and only then let the cheap building begin.