Make Me
Let’s just say it: engineers love to build things before they really know what the hell is actually needed. And it should be the opposite: engineers should be convinced with enough arguments of why they would need to build stuff.
Premature jump into action is a reflex in the engineering practice across disciplines.
In Donald Schön’s The Reflective Practitioner, he argues that professionals, engineers included, are often so eager to jump into "problem-solving" mode that they skip the harder, slower, much more uncertain and intractable work of defining what the real problem is. Instead of rigorously analyzing needs, questioning assumptions, or even validating demand while assessing competition, engineers propel straight into designing systems, products, and solutions based on an incomplete—or sometimes entirely imaginary—understanding of what’s required. Most real-world problems are messy, evolving, and ill-defined. Rushing into solution mode is like building a beautiful bridge without checking whether anyone wants to cross the river.
The history of engineering is littered with well-designed products that failed spectacularly not because they were technically flawed, but because no one actually needed them. While failure often teaches technical lessons, it also exposes deeper failures of judgment and understanding that arise when engineers assume that technical intricacy guarantees relevance or attraction.
Engineers tend to leap into action based on pattern recognition and gut feel, especially under pressure. This might be efficient in emergencies, but when it comes to planned, complex design work, it can mean that big assumptions go untested for far too long. The engineer feels that they know what the world needs because something about the problem looks familiar. But when familiarity is a biased collective illusion, the result is a costly, labor-intensive exercise in building something no one asked for. Engineering is admittedly heuristic: it’s driven by flexible rules of thumb, trial and error, and practical improvisation. That’s fine, but without slowing down to question whether a real need exists, the engineering effort becomes a sprint in the wrong direction.
The tech world is overflowing with products built on elegant architectures that nobody ever remotely wanted. Entire startups implode not because their engineers weren’t skilled, but because they "solutioned" themselves into a cliff. The concept of "solutioneering"—designing solutions before understanding problems—has become a dirty word among seasoned product managers for a reason. Customer (and product) discovery must come before product design, not after. And yet, the engineering culture remains addicted to building first, asking questions later. Why? Part of it is surely psychological: building feels productive, tangible, and satisfying. Questioning assumptions feels slow, uncertain, abstract, somewhat political, and unglamorous. There is something around the maverick engineering culture that still prizes technical prowess over the “softer” skills of market research or design thinking. Believing that "if I build it, they will come" is a seductive lie that flatters the engineer’s identity as a tough problem-solver. The tragedy is when engineers get trapped in years-long design and iteration cycles for products, systems that will flop as soon as they see the light of day. If they ever do.
There’s a better way. But it requires that engineers slow down, resist the urge to design immediately, and engage deeply with the messy, human, ambiguous face of the process. As countless authors on the matter have taught, reflection must precede action, not just follow it. Because in the end, the hardest and most professional thing an engineer can do isn’t to build brilliantly. It’s to know when not to build at all.