The second product hiding inside your first

Almost every product that gets used at all contains a smaller product it wasn’t trying to be. You built a broad thing with ten surfaces, and somewhere in the usage data there’s a knot: a small group using one surface far more than the rest, or bending a feature into a job you never designed it for, or exporting one screen over and over to paste somewhere else. That knot is easy to file under “power-user edge case” and ignore. Sometimes it’s the actual product, and the thing you set out to build is the packaging it arrived in.

The public histories that get retold at conferences are the extreme version of this. Instagram started life as Burbn, a cluttered check-in app; the photo-sharing corner was the part people actually used, and the founders had the nerve to throw the rest away. Flickr fell out of a massively multiplayer game that wasn’t working — the photo-sharing tool built for the game outlived the game. Slack was the internal chat system of a different failed game studio. These stories get sanded smooth in the retelling, so don’t take the tidiness literally, but the shape is real and it repeats: the winning product was already running, small and unglamorous, inside a product aimed somewhere else.

Here’s why it hides in plain sight from the person best positioned to see it — you. You’re anchored on the product you meant to build. That’s the thing in your roadmap, your pitch deck, your sense of what the company is. When usage clusters somewhere off to the side, your first instinct is to read it as noise, or as misuse to be gently corrected, or as a niche to be politely deprioritized so you can get back to the plan. The anchor isn’t stupidity; it’s identity. The second product doesn’t look like an opportunity. It looks like users doing it wrong.

The way to find it is to stop staring at your averages and go look at your intensity. Averages smear the knot flat. The signal lives in the tails: where is a small group doing something effortful, repeatedly, that they clearly care about? What single feature do people screenshot, export, or rebuild by hand in a spreadsheet because your version almost — but not quite — does the job? A workaround is a feature request with its hands dirty, and a workaround that a cluster of users performs inside your own product, week after week, is the loudest request you will ever get. Follow it to the job. Ask what these people are actually hiring the product to do, and whether that job is bigger than the one on your roadmap.

Seeing it is the whole skill. What you do about it is a separate, deliberate decision with several honest answers, and only one of them is “pivot the company.” Sometimes the right move is smaller: take the thing users are hacking together and make it first-class — name it, give it its own front door, stop treating it like a side effect. Sometimes it’s a positioning change: the second product is what you should be talking about, even if the first one stays in the box. And sometimes, rarely, it really is a different company, and the brave thing is to admit the packaging was never the point. The senior act is not the pivot. It’s refusing to let the anchor decide for you — noticing the knot, naming what it is, and choosing on purpose.

The reason this needs a cool head is that the failure mode is just as common as the success. For every Burbn there are a thousand teams who spotted a shiny edge case, fell in love, chased it, and abandoned a core that was quietly working. Survivorship makes the pivots look inevitable and hides the graveyard. So put a test on it before you bet the roadmap: is the intense cluster growing on its own, without you feeding it attention — and is the job it’s doing genuinely larger than the job you built for? Growing-on-its-own rules out a niche you’re artificially propping up. A bigger job rules out a cul-de-sac. When both are true, you’re not looking at misuse. You’re looking at the next product, and it’s already shipped.