I spent three months building a product I was convinced people wanted. I interviewed potential users, iterated on feedback, polished the features, and launched to what I expected to be immediate enthusiasm. What I got was mostly silence, a handful of polite no-thank-yous, and one friend who said, very kindly, that he couldn't figure out why he'd ever use this instead of the spreadsheet he already had.
That product taught me more than any business course ever could. The fundamental problem wasn't execution—it was that I'd started building before I'd done the hard work of understanding whether what I was building actually solved a problem people had. I'd fallen in love with my solution before I'd validated the problem.
The Problem With Premature Solutions
There's a seductive logic to building first and validating later. You have an idea, you build it, you launch it, you iterate. But this logic assumes that building is the hard part—that the problem is execution when actually the hard part is figuring out what to build in the first place.
Most of the products that fail—and roughly 90% of startups fail, usually not because of execution but because there was no market need—fail because they start with a solution rather than a problem. The entrepreneur has a clever idea, becomes convinced it's valuable, and spends months building it. By the time they get it in front of real users, they've invested so much that they can't see clearly that nobody actually wants it.
How to Validate Before You Build
The practice I've developed is simple, though not easy: before building anything, I try to create the smallest possible evidence that the problem is real and that people would actually pay to solve it. Not a landing page with a waitlist, though that can be useful. I mean actually talking to people—finding out whether they've tried to solve this problem before, what they've done, what worked and what didn't, and what it would actually be worth to them to have a better solution.
The most important question isn't "would you use this?" Because people will say yes to things they would never actually use. The question is "what have you tried before, and how much did that cost you in time or money?" If someone has already spent money trying to solve a problem, that's a much stronger signal than them saying they'd be interested in a hypothetical.
What Gets Built vs. What Matters
The other lesson I've absorbed deeply is that there's usually a difference between the thing that gets built and the thing that actually matters. You build an app; what matters is the outcome the app creates for users. You build a consulting practice; what matters is the transformation you create for clients. When you fall in love with the artifact rather than the outcome, you start optimizing for the wrong thing—and users can tell.
The best builders I know stay close to the problem throughout the entire building process. They don't let the excitement of execution distract them from the fundamental question: is this still solving the problem we set out to solve? They check in with users constantly, not to show them what they've built but to understand whether the building is still on track.
Use the Goal Tracker to clarify what you're actually trying to accomplish before you start building.