Building a product nobody asked for

The market research industrial complex is killing more startups than bad ideas.

Two products I'm building right now started the same way. One generates and schedules content across multiple brands. The other packages AI agent capabilities into shareable, sellable units. Nobody asked for either. There was no survey. No customer discovery call. Just problems I kept running into and solutions I started building.

Neither has gone through a traditional validation process. They might fail. But they exist because I needed them, and that matters more than most founders think.

The validation trap

The standard startup advice goes like this: talk to 50 potential customers, identify a pain point, validate willingness to pay, build an MVP, test it with early adopters, iterate based on feedback.

This process is not wrong. It's just slow, expensive, and biased toward problems that are easy to articulate. The best products often solve problems people don't know how to describe yet. Nobody was asking for "a marketplace for AI agent skills" in 2024 because the concept barely existed. You can't validate demand for a category that hasn't been named.

The validation loop also selects for crowded markets. If 50 people can describe the problem clearly, 10 other teams are already building a solution. You've validated yourself into a competition.

What works instead

Build for yourself first. Not as a growth hack or a marketing angle. As a filter.

If you're building something you actually use, three things happen automatically:

You know the problem is real because you have it. Not "I think users might want this" but "I need this right now and nothing else does it." That's a different level of conviction. It survives the first bad week.

You're your own first tester. Every edge case, every friction point, every moment where the product falls short hits you before it hits anyone else. The feedback loop is instant. No surveys, no analytics dashboards, no waiting for support tickets. You just feel it.

You build faster because you skip the specification phase. When you're building for yourself, you already know the requirements. The PRD is in your head because you lived it. The "what should this do?" question has an obvious answer: whatever you need it to do right now.

The market research industrial complex

There's a whole ecosystem that profits from making founders feel like building is the risky part. Market research firms, customer discovery consultants, survey tools, validation frameworks. They all sell the same premise: the biggest risk is building the wrong thing, and their process reduces that risk.

The premise isn't entirely false. Building the wrong thing does happen. But for solo founders and small teams, the bigger risk is building nothing at all. Analysis paralysis kills more projects than bad product-market fit. You can pivot a launched product. You can't pivot a spreadsheet full of interview notes.

A founder who ships something ugly in two weeks and gets 5 real users has more useful information than a founder who spent three months interviewing 50 people and hasn't written a line of code.

When validation actually matters

There are situations where building without validation is genuinely reckless:

Enterprise software where each sale takes 6 months and costs $200K to close. You need to know the buyer exists and has budget before you invest a year of engineering.

Hardware products where the manufacturing minimum is 10,000 units and $500K. The cost of being wrong is bankruptcy, not wasted weekend hours.

Products that require regulatory approval. If you need FDA clearance or financial licensing, validate first because the compliance timeline is measured in years.

For software products built by a small team with low overhead? Just build it. The cost of being wrong is a few weeks of work. The cost of over-validating is months of delay while someone else ships the thing you were researching.

There are no new ideas

The other thing founders get wrong: chasing originality. Spending months looking for an idea nobody's had before. That's backwards.

If nobody has built it, there's usually a reason. Either the problem doesn't matter enough, the timing is wrong, or someone tried and failed for reasons you haven't discovered yet. Searching for a completely novel idea is one of the slowest ways to start a company.

The better approach: find something that already exists, that people already pay for, and build a version that's better for a specific group. Content scheduling tools exist. Dozens of them. But none of them were built for someone running five brands from one desk with AI agents handling the drafting. That's a niche. That's a differentiator. The category is validated. The specific angle is not.

Stripe didn't invent online payments. PayPal existed. Stripe built a payments API for developers instead of for merchants. Same category, different angle, better product for a specific audience.

Notion didn't invent note-taking or project management. They combined them in a way that attracted a specific kind of user who wanted flexibility over structure.

Linear didn't invent issue tracking. They built a version of it that was fast when everything else was slow, and opinionated when everything else tried to be configurable.

Competition is validation. If other companies are making money in the space, the demand is real. Your job is not to find a market with zero competitors. Your job is to find the gap in an existing market where nobody is serving a specific need well.

Look at what's already working. Find the group of users that existing products are ignoring or underserving. Build for them. That's faster, cheaper, and more likely to work than chasing a completely original idea.

The unfair advantage of building what you need

Products built for yourself have a quality that's hard to replicate: they're opinionated. They make decisions about how things should work instead of trying to accommodate every possible use case.

Basecamp was built because 37signals needed project management for their own client work. Stripe was built because the Collison brothers needed a payment API that didn't make them want to throw their laptop out a window. Slack was a chat tool built inside a gaming company that realized the chat was more valuable than the game.

None of these started with "let's research the project management / payments / enterprise chat market." They started with "this sucks, let me build something better." The product reflected specific, strong opinions about how work should happen. Those opinions attracted users who agreed and repelled users who didn't. That's not a bug. That's positioning.

Generic products built from surveys and focus groups tend toward the middle. They satisfy the average case and delight nobody. Products built from frustration tend toward extremes. They nail one workflow perfectly and ignore everything else. Users who have that exact workflow become devoted fans. Everyone else uses something else, and that's fine.

The practical version

If you're sitting on an idea and debating whether to validate or build:

Ask one question: do you personally have the problem this solves? If yes, build it this week. Use whatever tools get you to a working version fastest. Don't worry about scale, don't worry about the tech stack, don't worry about what happens at 10,000 users. You don't have 10,000 users. You have one: yourself.

Use your own product for two weeks. Write down every time it frustrates you, every time it's missing something, every time you work around a limitation. Fix the worst one. Repeat.

After a month of daily use, show it to three people who have the same problem. Not 50. Three. If two of them say "can I use this?" you have something. If all three shrug, you learned that in a month instead of three months of interviews.

The validation happened. It just happened through building and usage instead of through research and surveys. The information is better because it came from real behavior, not hypothetical answers to hypothetical questions.

The thing nobody tells you about market research

Survey responses are aspirational. Interview answers are performative. People describe the version of themselves they want to be, not the version that actually opens their laptop at 9 AM.

"Would you pay $20/month for a tool that does X?" gets a 70% yes rate in a survey. Actual conversion when the tool launches is closer to 3%. The gap between stated intent and real behavior is enormous, and no amount of careful survey design closes it.

Usage data is the only honest signal. And you can only get usage data from something that exists. Which means you have to build it first.

The entire market validation industry exists because of a reasonable fear (building the wrong thing) applied to the wrong solution (asking people what they want instead of watching what they do). Asking is cheap and feels productive. Building is expensive and feels risky. But building gives you the only data that actually predicts whether the product works.

Build the thing. Use the thing. Fix the thing. Show three people the thing.

That's the whole process.