Distribution was our wall twice, and both times we thought it was capability.
We have been building since late 2024. In that time we were a gen AI agency, then a voice AI company, then a procurement tool, before landing on the thing that actually worked. Every one of those pivots was decided by the same wrong diagnosis. Something was not selling, we concluded the product was not good enough yet, and we went and built more. It is a very comfortable conclusion because building is the part you control and the part you enjoy. It also has a satisfying story attached: not there yet, nearly there, one more release. What was actually happening both times was that nobody knew we existed, and the people who did know had no reason to try it this week rather than some other week. That is not a capability problem and no amount of shipping fixes it. The way we eventually found the real thing was not analysis. We ran the catalogue on ourselves, and the one item we kept reaching for was the cheapest thing on the list, the one we had been treating as a feature to sell the expensive stuff around. Two things I would tell myself at the start. First, if a customer signs and then does not use it, that is not a customer, that is a very expensive compliment, and it should be counted as churn on the day it happens rather than revenue. Second, when something is not selling, force yourself to write down the distribution version of the explanation before you are allowed to write down the product version. The product version will still be there afterwards. It just should not get to go first. Curious how many people here have made the same call. When something stalled, did you build or did you go and find out why nobody came back?
Replies
"a very expensive compliment" is going to stick with me. I've counted a signed-then-silent customer as a win more than once and never gone back to ask why they stopped opening the thing.
@irahimiam @nikkigrowently Thanks Nikki. Arash's version of it is sharper than the one I wrote, the signed-then-silent customer is the specific case that hurts. You have been through the early distribution grind with Growently more recently than me. What was the first channel that actually returned something, rather than the one that looked like it should?
@irahimiam The going back is the part nobody schedules. What helped me was changing the question. "How is it going" gets you politeness. "What did you stop doing to make room for this" gets you the truth, because if they cannot name the thing they dropped, they never actually started. Did yours go quiet right after signing, or did they use it properly for a while first? Those are two different failures and only one of them is a product problem.
This is painfully familiar. Building more feels productive because it’s measurable and fully under our control, while distribution means hearing uncomfortable answers from the market.
A rule that helps is having a short “no-build” period whenever growth stalls. Talk to active users, silent signups, and people who considered the product but didn’t move forward. Then test one distribution change before touching the roadmap: a narrower audience, clearer urgency, a different channel, or a more concrete offer.
I also agree that signed-but-inactive customers should be treated as churn immediately. Revenue can hide the problem, but usage usually tells the truth much earlier.
@alpertayfurr The control asymmetry is the actual mechanism, better put than I had it. Building has a feedback loop you own. Distribution has one other people control, so of course the hand reaches for the first one. Curious about your no-build rule specifically. Is it time boxed, or does it key on something else? Time boxed versions broke for me every time, because there is always a build task urgent enough to justify the exception, and the exception is always granted by the person who wants it.
@rabnoor_s For me it works better when it’s trigger-based rather than time-boxed. If growth stalls, no new build work gets prioritized until we’ve spoken to users and tested at least one distribution change. Otherwise “urgent” product work always finds a way back in.
@alpertayfurr Trigger-based is the right correction and I am taking it. Time-boxed fails exactly the way you describe, because the box has no teeth and urgent work always finds its way back in. One thing I would add: "growth stalls" is a lagging trigger. By the time it fires you have already built the thing, so the rule protects the next mistake rather than the one already sunk. What I keep trying is moving the same question upstream, before there is anything to stall. And talking to users tells you what they say, which is not the same as what they would pay. Those two come apart badly and usually in the direction you least want. I build something for exactly this now, blunlock.com, so discount me accordingly. The mechanic is worth stealing without it though: put "I wouldn't pay for this" on your own page as a real option and count how many people take it. It gets uncomfortable quickly, which is the whole point. When your trigger fires and you go talk to users, do you raise price at all in that conversation, or does it stay separate?
@rabnoor_s I’d keep discovery and pricing slightly separate. First I’d understand the pain and current workaround, then test willingness to pay with a concrete price before building more. Asking “would you pay?” is too easy to say yes to, but asking “would you buy this at $X today?” gives a much stronger signal.