I Built the Same Mistake Across 30 Products Before I Understood It

The task management app I built didn't fail because the code was bad. It failed because Trello existed, and I'd built without a clear reason why anyone who already used Trello would switch to mine.

I didn't see that at the time. I saw a real problem and built a working solution to it. The problem just wasn't one I could solve for anyone who wasn't already me.

That happened more than once. More than five times. More than ten. Across more than 30 products built over 20 years, the same failure appeared: I built before I understood whether the people with the problem would actually use what I'd built.

What the failures had in common

Not all of them failed the same way. CheckMVP got 500 users and failed quietly — people used it, said thank you, and nothing in their behavior changed. A project management tool I built accumulated features — time tracking, messaging, file storage, document management — until nobody could tell what it was for. Several CRM builds worked technically and found no users at all.

An earlier time-tracking app showed the same pattern from a different angle. When I finally talked to potential users, they pointed me to Toggl and asked what mine did differently. I didn't have a good answer. The question I'd failed to ask before building was what Toggl didn't do for them specifically.

Across most of the failures, something specific was absent: I hadn't started from anyone's existing workflow.

I'd started from a problem I could see. Then built a solution I could imagine. Then found out, at varying speeds, whether anyone wanted it.

That sequence is the mistake. The issue isn't whether validation happened — it's that "starting from a problem you can see" and "starting from a workflow you understand" are not the same thing. The first gives you a category. The second gives you a build spec.

What the wrong sequence produces

Building because a problem category exists isn't the same as building for a specific broken workflow. Without talking to the people whose workflow actually breaks, you don't know if they're already handling it another way — or whether the person who feels the pain is even the one who makes the software decision.

The project management tool I overbuilt had too many features because I kept adding what seemed useful to me. Nobody had asked for those features. Nobody was watching me build and saying "yes, that one." I was imagining what a good product should do, and I was wrong, and by the time that was clear the product was too confused to rescue.

The CRM builds that found no users — most of them were technically sound. I'd solved what was described to me without asking what was actually being done wrong. "We need a CRM" is not the same as understanding what currently breaks, what it costs, and where the specific friction is.

The wrong sequence also produces false confidence on the way. I celebrated a thousand signups on one product and kept building for two more months before I counted how many people came back. Almost none. Signups measure reach. They don't tell you whether what you built fits anyone's actual working situation.

What the working products look like

RealEstateCRM started with a different kind of conversation. The questions were about the existing workflow: how does a new listing get added right now? How do you know what's available without calling someone? What do you actually do when a client asks about a specific property?

Those questions described a set of manual steps that failed regularly. Not a software category — a specific workflow with specific failure points. The first version was scoped to that workflow and delivered in two weeks. It went into production immediately. The first feedback came from people using a real thing: they needed a customers database too, so the CRM could work as a CRM. It's still running.

Automator started the same way. Two days of conversation about a music publishing pipeline that took four hours every day — seventeen steps, mostly file renaming and folder organization, uploads across multiple platforms. We mapped each step. What happened when a file landed wrong. What happened when an upload failed and nobody noticed. That map became the build spec. The first version handled the highest-friction step only. It's been running for years and now takes under ten minutes a day.

Both products are still running. Most of what I built without that conversation isn't.

The difference

It's not that RealEstateCRM and Automator were better built. It's that they were built from a map of how someone actually does the thing today — not from how I thought it should be done.

When you start from an existing workflow, you understand the constraints before you write code. The user's workaround — what they currently do when the workflow breaks — tells you what "good enough" looked like before you arrived. That's your real competition: not a product, but a habit they've already built.

When you start from a problem you can see, you build toward your own model of the solution. That model is usually missing the specific constraints that only come out in conversation — particularly what the user currently does when things break, which is almost always more informative than what they say they'd want instead.

Building for yourself, or building a product

Building something you need is legitimate. Some of the most durable tools started with the author as the first user — they knew the workflow because it was their own, and they knew what done looked like. That's not a failure mode.

The failure mode is building something for yourself and then treating it as a product.

That first app was the clearest version of this. I was solving my own frustration, not verifying whether anyone else shared it badly enough to change what they were already doing. The problem was real — for me. I measured it like a product (signups, return visits) without doing the product work first.

Most of the failed products I built were tools-for-myself dressed up as products. I'd see a problem that frustrated me and assume others had the same frustration. Then I'd build toward a general solution. Sometimes they did have it. Usually they'd already handled it some other way I hadn't thought to ask about.

Knowing which mode you're in before you start changes what needs to happen next. Building for yourself, you already have the workflow — it's yours. You know where it breaks and what good enough looks like. You can start. Building for someone else, that map doesn't exist yet. You need the conversation first.

The test

Before I write code, I ask about past behavior — specifically, what happened the last time the problem came up. The conversation has a specific shape.

Start with an incident. "Walk me through the last time this actually cost you something." If they can't name one, the problem doesn't hurt enough to change their behavior. If they name several without pausing, you're in the right place.

Then ask what they currently do when it happens. That answer is the real competition. Whatever workaround they've built — a spreadsheet, a WhatsApp thread — is the bar your solution needs to clear. If it's fast and good enough, it's better to know that now.

Then: "What have you already tried?" Most people with a genuine problem have attempted to fix it. What they tried and why it stopped working tells you what "good enough" already looked like, and where it fell short. That's the design brief.

Last: "What would solved look like for you?" Let them describe it. The gap between what they say and what you were planning to build is worth knowing before you write a line of code.

That conversation either confirms a real break point that my solution addresses — or it reveals that what I thought was the problem was something else. Either way, I have a build spec before I have a build.

Thirty-plus products. Most of the failures contain some version of skipping that conversation.