Last year I spent six months building a SaaS product. I did everything "right", polished UI, solid architecture, clean code. Launched to 12 signups. Zero paying users. Shut it down.
The postmortem was brutal but clear: I built something nobody needed. I fell in love with the solution before verifying the problem existed.
I'm sharing this because I know I'm not the only developer who's done this. And I want to do something different this time.
I've decided to start with zero code and instead spend time talking to people about what's actually broken in their work. I'm treating customer discovery like a engineering problem: gather data, find patterns, then build.
I'm looking for input from this community:
- What task do you do manually every week that you keep thinking "there should be an API for this"?
- What existing tool frustrates you so much that you've considered building your own replacement?
- If you could wave a magic wand and automate one part of your development workflow, what would it be?
I'm not promoting anything. There's no landing page, no newsletter, no beta list. I'm genuinely trying to find a problem worth solving. If patterns emerge and I build something, I'll document the entire process here.
What problems are you all facing?
Top comments (11)
The risky part is that asking people what they want automated may collect ideas, not commitment.
The useful clue is the 12 signups / zero paying users part. If someone names an annoying manual task, I would look at what happened the last time it broke: what they used instead, who had to fix it, and whether fixing it was actually part of someone's job.
Without that, you can end up with a list of annoying workflows.
True, but not yet a first wedge.
Really sharp read, "ideas, not commitment" and "not yet a first wedge" is the honest diagnosis most people skip, and I didn't see it clearly until my postmortem either.
Since then I've flipped my process around the same instinct you're pointing at. When someone names a painful task, I don't ask what they'd want automated anymore. I ask three things:
A recurring annoyance is a complaint. A recurring annoyance with a broken process and a willingness to change is a wedge.
Genuine question though: how did you land on "first wedge" as the bar? Was it a filtering framework you built up, or did it come out of a specific interview that went sideways?
It came from the failure side, not from a framework first.
I was reading public postmortems of stalled products, and the same split kept showing up: the ones that moved had a current cost someone was already paying. A workaround, a bad alternative, an annoying manual step, a risk they were already living with.
The ones that stalled had interest, but not much cost.
So "first wedge" is just my name for the first kind. Closer to an interview going sideways, except the "interview" was a pile of other people's postmortems.
Your three questions are the right flip. The one I would weight most is "would you switch tomorrow" — with one caveat. In an interview, that answer is still aspirational unless it attaches to a dated incident.
"When this broke last month, I spent two hours on it" counts differently from "yes, I would probably switch."
If the switch answer cannot attach to a specific memory, it is still a wish describing itself as a decision.
That distinction is sharper than anything I had in my toolkit. A wish describing itself as a decision, that's going to stick with me.
It reframes how I'd run the next round of conversations. Not "would you switch?" but "walk me through the last time this actually hurt you." If they can't anchor it to a specific moment with a cost attached, the signal is weak no matter how enthusiastic the answer sounds.
Basically: enthusiasm is cheap. A dated incident with a real cost is the receipt.
Appreciate you pressure-testing this in public instead of just letting me sit with a clean-sounding framework that doesn't hold up.
Your last line is the one worth keeping: enthusiasm is cheap, a dated incident with a real cost is the receipt. That's the whole test in one sentence.
One small addition: a vivid incident is not always a recurring one.
"Walk me through the last time this hurt" gets the story. "How often does that happen?" separates the one-off war story from the ongoing cost.
A founder with one dramatic anecdote and a shrug on frequency is a different signal from a boring incident that happens every week.
Both count as receipts. Only one of them is a market.
Frequency is the whole filter. One dramatic story is a blog post. The same boring incident every week is a business.
That reframes the interview itself. You don't just need the story, you need the calendar. "When did it last hurt?" gets the receipt. "How many times this month?" tells you if it's a market or an anecdote.
Stealing "a wish describing itself as a decision" and now adding "a vivid incident is not always a recurring one." This thread is building a better filter than anything I've read on customer discovery.
That line is better than my version: one dramatic story is a blog post; the same boring incident every week is a business.
Agreed on the calendar. The receipt proves the pain is real; the frequency tells you whether it is a market.
If you ever write up the fuller version of this filter, I would read it.
That's the plan. This thread gave me the skeleton - enthusiasm is cheap, a dated incident with a real cost is the receipt, a vivid incident is not always a recurring one. I want to pressure-test it against a few more conversations before I write it up properly.
If it holds, I'll publish the full filter here with the interview questions baked in. Would want your take on it before I call it done, this thread sharpened it more than I could have alone.
Deal. If you drop the draft here when it is ready, I can give it a focused
read on the filter itself.
One thing I would pressure-test is the ratio, not just the pass/fail.
Twenty conversations where five produce dated incidents and fifteen produce
adjectives is a different market than the reverse. That may be where the
filter gets sharper: not only "did one vivid story appear?" but "how often
does the same kind of costly incident repeat?"
I also have a small 20-postmortem stall index that may be useful as an
outside check when you write it up. Happy to share that if it helps.
This thread probably does deserve the full write-up.
The ratio point is the missing piece. Pass/fail tells you if a story exists. The ratio tells you if a market exists. Twenty conversations, five dated incidents, fifteen adjectives, that's a different signal than the reverse, and I wouldn't have caught that without you naming it.
I'd absolutely take the stall index. Would be useful as a sanity check against the interview data, patterns I might miss from inside the conversations.
Draft is in progress. I'll drop it here when it's ready for your read.
Draft is finally live: dev.to/n3on/the-customer-discovery...
The ratio test and the stall index section came directly from this thread. Would genuinely appreciate your read when you have time, especially on whether the frequency framing holds up against your postmortem data.