"Product-market fit" is two words stitched together with a hyphen, like it's a single, simple thing to find. In reality it's a moving negotiation between a problem, a solution, and a market that keeps reacting to both in ways you didn't predict. The market doesn't just accept or reject what you build. It bends it, repurposes it, and sometimes hands you back a completely different problem than the one you set out to solve. Here's how that played out for me in crypto.
The harder part of the job was never spotting the problem. It was navigating between two things that often point in opposite directions: the feedback users give you today, and the vision of where the solution is actually headed. Henry Ford's line about faster horses gets quoted so often it has lost its teeth, but the tension it describes is real. Users tell you what they need using the vocabulary of the tool they already have. Your job is to hear the problem underneath the request, and sometimes that means building the car when everyone in the room is asking for a faster horse.
The problem we set out to solve
In crypto, I spent years chasing this fit between a problem and a solution, and the clearest lesson came from something we built for community currencies. These were tokens tied to a specific group or cause, and they had a structural weakness: they were siloed. Each one lived in its own small pool of liquidity, disconnected from every other currency, which meant none of them could survive real growth. The moment a community currency got any traction, the lack of liquidity and the lack of connectivity to other currencies became the ceiling. That was the problem we identified, and it was a real one.
The solution was an automated market maker: an on-chain smart contract that let a community provide constant liquidity for its own currency, with asynchronous price discovery so people could enter and exit whenever they needed to. The cost of that flexibility was slippage, the price you pay for trading against a pool instead of a matched buyer. For a community currency, that trade-off made sense. Liquidity on demand was worth more than a perfect price.
The realization
What we had not accounted for was that money is not limited to community currencies. Almost as soon as we were live, users started telling us, directly and through their behavior, that they wanted to use this same mechanism for real money, for tokens, for assets that had nothing to do with any community. That was a different use case wearing the same interface, and it exposed the seams in our original design almost immediately.
Nothing about the product had changed. What changed was who was using it and why. The design choices we made with one audience in mind, tuned for a specific kind of trade-off, turned into the biggest growth disabler once a much larger and much less patient audience started showing up. We had built a solution that was correct for the problem we set out to solve, and increasingly wrong for the problem the market had decided to hand us instead.
What this teaches about fit
This is the part of product-market fit that rarely makes it into the framework slides. Fit is not a single measurement you take once and file away. It is a relationship between a solution and a problem, and either side of that relationship can shift. The market can redefine what your product is for faster than you can redesign it.
- The solution is sometimes more suited to a different problem than the one you built it for. Watch for signals that your product is being pulled toward a use case you did not design.
- Your initial users are not always your real users. Early adopters can point you at a market that looks like your target and isn't. Pay close attention to who shows up and why.
- Any solution can be repurposed. It is on you to notice when your product is being used differently than intended, and to adapt the design to optimize for that new reality rather than defending the original spec.
- Product-market fit is hard to find and harder to keep. As you grow and reach new markets, the fit you had can quietly erode under you, even while every metric still looks fine.
The car did not replace the horse because people asked for it. It replaced the horse because it solved a bigger version of the same underlying problem, one people did not yet have the language to ask for. Our job is not just to build what the first users describe. It is to keep checking, as the audience and the market shift, whether the problem we are solving is still the problem worth solving.