What I Learned Building Products Nobody Asked For

Over the past five years, I've built more side projects than I care to count. Most of them were complete failures. A few got some traction. None made me rich.

But here's the thing—building products nobody asked for taught me more about design than any course, certification, or "best practices" guide ever could.

If you're a designer who builds things, this post is for you.

1. Your First Idea Will Always Be Wrong

I used to spend weeks perfecting the "perfect" concept before building anything. Sketching wireframes, researching competitors, writing detailed PRDs.

Then I'd build it, launch it, and... nothing.

The problem wasn't execution—it was assumption. I was solving problems that existed only in my head.

What I learned: Start building sooner. Your first idea is a hypothesis, not a solution. The faster you can test it with real users (even if it's just 3 people), the faster you can iterate toward something that actually matters.

2. Features Don't Create Value—Workflows Do

I used to think users wanted more features. More customization. More options. More power.

So I'd add feature after feature, making my apps more "powerful" but infinitely more complex.

Users didn't care about my 47 customization options. They cared about completing their task quickly and moving on with their day.

What I learned: Design workflows, not features. Ask "How does this help someone get from point A to point B faster?" If you can't answer that clearly, you're probably building the wrong thing.

3. Marketing Starts at the First Pixel

I used to think marketing was something you do after you build the product. Write some copy, make some ads, post on social media.

Wrong.

Marketing starts the moment you decide what problem to solve. Every design decision is a marketing decision. Every user interaction is a marketing moment.

What I learned: If you can't explain your product in one sentence, you haven't designed it clearly enough. If users need a tutorial to understand your main value proposition, you've over-designed it.

4. Perfect Is the Enemy of Launched

I have a folder full of "almost ready" projects. Beautiful designs. Polished interactions. Comprehensive feature sets.

All of them are worth exactly $0 because none of them ever saw a real user.

Meanwhile, my most successful projects were the ones I was slightly embarrassed to share. They were rough around the edges but solved a real problem for real people.

What I learned: Ship the minimum viable version of your idea. Real user feedback on an imperfect product is infinitely more valuable than imaginary feedback on a perfect one.

5. Users Don't Want to Learn Your System

As designers, we love elegant, consistent systems. We create style guides, interaction patterns, and interface languages.

But users don't care about your system. They care about their goals.

If your beautifully consistent interface makes their task harder, they'll abandon it for something that "just works"—even if it's uglier.

What I learned: Optimize for user success, not design consistency. Sometimes the right answer is the "wrong" answer according to your style guide.

6. The Best Ideas Come from Personal Frustration

My most successful projects all started the same way: I was annoyed by something in my own life and built a solution for myself.

The projects that failed? Those were "market opportunities" I identified through cost-effective user research methods and analysis.

When you're solving your own problem, you have perfect user empathy. You know exactly how the current solutions fail. You know what "good enough" looks like. You know when you've actually solved the problem.

What I learned: Start with problems you personally experience. You'll build better solutions and spot bad ideas faster.

The Meta-Lesson

The biggest thing I learned from building products nobody asked for? How to ask better questions.

Instead of "What features should I build?" I now ask "What job is this user trying to get done?"

Instead of "How can I make this more powerful?" I ask "How can I make this simpler?"

Instead of "What do users want?" I ask "What are users struggling with?"

Building side projects is the best design education you can get—not because you'll build the next unicorn, but because you'll learn to see product development through users' eyes instead of your own.

And that perspective is worth more than any certification you can hang on your wall.