I built the right product and aimed it at the wrong customer for months. Here's how I figured that out.

Appreciate the close read, that 'normal to insiders, broken to everyone else' gap is exactly what made it un-ignorable for me.

That LearnRoot realization, end user is the homeschooler but the buyer is the developer, is the exact shape, and the fact it clicked reading this is the whole reason I wrote it down. The thing I'd watch: now that you can see the demand is downstream, the trap is half-pivoting, keeping the homeschooler-framed messaging while the real buyer is the developer. Pick the one whose pain you can actually reach and point everything at them. Good luck with Lorelings too, and thanks for sharing where you're at.

The specific moment wasn't a meeting or a metric, it was watching a support channel during an exploit. The protocol's team was heads-down, correctly, on securing itself, and the comments filled with individual users asking 'am I affected, where are my funds' with nobody positioned to answer them. I'd built the support layer thinking protocols would run it for their users. Standing there I realized the protocol's incentive in that exact moment is its own survival, not fielding a thousand panicked individuals, so the support I'd built would always be deprioritized by the buyer I was selling to. The demand was with the users, not the protocols. That was the moment

This is the best advice in the thread, and I'm taking it. Leading with the incident, the user alone with the scariest question and nobody assigned to answer, instead of 'we're changing direction,' reframes the whole thing. A pivot people can feel the reason for isn't really a pivot, it's a correction they'd have made too. The 'coin flip' distrust is exactly the failure mode I was worried about, and you've named the way out of it. Genuinely useful, thank you.

Exactly, the product wasn't broken, the positioning was, that's the cleanest way to say it. And the part you flagged at the end is the thing that gave me conviction: the fact that the underlying solution didn't have to change at all, only the customer it pointed at, told me the core was right and I'd just aimed it wrong. If I'd had to rebuild the product to serve the new customer, that would've been a different and scarier signal. Customer discovery never ending is the real lesson.

The remove-the-buyer-from-the-chain test is a great heuristic, and it's exactly what happened, taking the protocol out made delivery simpler, not harder, because the B2B layer was a distribution hypothesis dressed up as a product one. That's the cleanest way I've heard it put. The protocol was a channel I was hoping would carry the value, but the value never lived there. Once I stopped treating 'the buyer keeps deprioritizing this' as a sales problem and started reading it as the signal it was, the whole thing got obvious. Stealing 'distribution hypothesis, not a product one.

Two clues, and they pointed the same way. First, the outreach: I'm a small account, cold-pitching protocols handling millions or billions, and the silence was total. Easy to write that off as 'I'm too small.' The realer clue was what I saw just being active in the space. After every exploit, the comment sections and support servers filled with users panicking, asking 'am I affected, where are my funds,' and the protocols were heads-down on their reputation and their money first, which is understandable, that IS the right priority for them in that moment. But it showed me support was never going to be the focus for these brands. I'd built TxDesk to fix the broken Discord/Telegram support system thinking protocols would jump on it. Looking back, the reason those servers are broken is that support was never a priority to them in the first place. So fixing it for them was solving a problem the buyer didn't feel. The users felt it, they had money on the line and no answers. That's when I pointed the product straight at them.

The budget-vs-urgency split is the part I'd underline for anyone reading who isn't in crypto. The B2B buyer had the budget and no urgency; the end-user had no budget and immediate panic. Exploit moments just make it impossible to miss, because they collapse the decision window from months to minutes, and that's when you can see plainly which side actually feels the problem. 'If your demand spikes during incidents, your customer is downstream' is a cleaner heuristic than B2B-vs-B2C, and it's true outside crypto too, anywhere the pain is acute and time-bound for the user but abstract and deferrable for the buyer. Good framing.

Easier to reach, not more willing to pay, and that's the slightly uncomfortable honest answer. The individual in an exploit has immediate panic but no budget; the protocol had budget but no urgency. So downstream is where the demand is loud and real, but it's panic, and monetizing panic is its own problem, different from monetizing a line item. I went there anyway because that's where the pain actually lives, and I'm betting that being the thing someone trusts in their worst moment earns the right to charge later. Your order (lead individual, defer B2B) is honestly the more disciplined version of the same bet, you're protecting yourself from over-building for the upstream buyer before you've proven the downstream one. Being pre-launch with no audience to re-aim is a real advantage here, you get to point it right the first time instead of correcting course in public like I'm doing. Consumer version launches soon, so I'll find out shortly whether the downstream bet was right or just a story I told myself. Happy to report back either way, the honest version, not the launch-post version.

It only becomes visible after the first system is working, that's the part you can't shortcut. You have to build the thing to find out who it was actually for. The first version isn't wasted even when the customer turns out wrong; it's the instrument that makes the real answer visible. I couldn't have seen the demand was downstream without having built the upstream version first.