Built Well, Never Adopted

What I built, and why it was genuinely good

The whole lesson depends on the design not being the problem, so it is worth establishing that it was good.

The team is spread across several countries and time zones, meeting in a mix of English and Spanish. Decisions get made in two languages and then evaporate the moment the call ends. Nobody can find what was agreed. Action items live in one person's memory. The Meeting Room closed that gap. It transcribed the meeting live in both languages, translating as it went. It attributed each line to the right speaker automatically, based on who was logged in, so the transcript read like a real record. It listened for action items and pulled them out as they were spoken, de-duplicating intelligently so the same task mentioned three times did not become three items. It filtered out the nonsense speech-to-text engines hallucinate during silence, so the record stayed clean.

And then it did the thing I was proudest of: any action item could become a real, routed ticket in the same system with a single click. The meeting did not just produce notes. It produced tracked work, flowing directly into the pipeline where work actually gets done, with no retyping and no handoff. If adoption were decided by quality, it would have won.

What actually happened

It did not win. The team kept meeting and coordinating in WhatsApp. Not because they evaluated the Meeting Room and found it lacking. Most of the time they did not evaluate it at all. They did what they had always done, in the place they were already sitting, with the people they were already talking to. The more efficient tool was one tab away, and it stayed one tab away. I watched a genuinely better instrument lose to a group chat, and the group chat did not even have to try. That stung, and then it taught me something.

Why WhatsApp won

My mistake was thinking of WhatsApp as a competing product. It is not a product I was competing with. It is a place my team already lived, and that distinction turns out to be everything.

The incumbent is not a feature set. It is where attention already pools. When you ask someone to use your tool instead of the thing they use now, you are asking them to leave the room where all their colleagues, all their clients, all their history, and all their notifications already are. No feature competes with that, because the competition was never about features. It was about presence. Zero activation energy beats low activation energy every time: the Meeting Room asked people to be in the app, in a specific place, at a specific time, while WhatsApp asks for nothing, because you are already there.

This is the part that is easy to resent and important to accept. My team knew, on some level, that scattering decisions across an untracked chat was inefficient. They did it anyway, because the pull of the familiar place where everyone already is beats the promise of a better outcome you have to leave that place to get. That is not laziness. It is how humans actually behave, and a system that ignores it is designing for people who do not exist. The switching cost was invisible to me and obvious to them: from where I sat, adoption cost near zero; from where they sat, it meant breaking a habit and being the one person working somewhere the others are not. Builders systematically underestimate this cost because we do not pay it. The user pays it, and they feel every cent.

The distinction that actually matters

Design quality and adoption are two completely different axes. A thing can score high on one and near zero on the other. The Meeting Room was excellent on the design axis and close to zero on the adoption axis, and the second number is the one that determines whether any of the work mattered.

The formula I keep now is simple: realized value equals value created times adoption. The Meeting Room created a lot of value per use and was used almost never. Multiply a large number by something close to zero and you get something close to zero. All the cleverness in that transcription pipeline, all the care in the de-duplication and the one-click tickets, got multiplied by an adoption rate that made it nearly irrelevant in practice. You do not get credit for value you created. You get credit for value that gets used.

The proof, inside the same platform

The reason I am confident this is a lesson about human nature and not about my design is that the same operating system proves it twice, in opposite directions.

The platform also has a messaging feature, built to bring the team's conversations into the system where the work lives. It fights the same uphill battle against WhatsApp, and it struggles for the same reason. Consistent so far.

But the flyer engine works differently, and it gets used. Its intake does not ask anyone to come to the system. It goes to them. A manager sends a plain-language request in WhatsApp, in the group they are already in, and a conversational agent gathers what is needed right there in the thread they never had to leave. The work still flows into the system on the back end, into the same tickets and the same pipeline. But the human never had to relocate.

Same builder. Same platform. Same goal of getting work into a tracked pipeline. The Meeting Room asked people to leave WhatsApp, and it lost. The flyer intake rode inside WhatsApp, and it won. The only variable that changed was whether the tool fought the incumbent habit or moved with it. That is the whole lesson, written in my own product's adoption data.

The design is still right, and there may be a home for it

None of this means the Meeting Room was a mistake to build. The design is still right. Bilingual live transcription, clean attribution, action items that become tracked work with one click, that is a real answer to a real problem, and the problem has not gone away. What it lacked was not quality. It was the right soil to grow in. A design like this can win where no incumbent habit has already claimed the ground: a setting where the meeting is already a deliberate ritual, so a dedicated space is expected; a team that does not already live in a group chat; or a client-facing context, where a clean bilingual record is a service you deliver rather than a behavior you ask your own team to change.

And the version I would build now is not a destination at all, but an integration. Let the meeting happen wherever it already happens, and have the transcription, the record, and the action items flow in from there. Meet the behavior instead of fighting it. That is the same correction the flyer intake already proved. The instrument is good. It was pointed at the wrong ground, and good instruments can be re-pointed.

The takeaway

If I could go back, I would not build the Meeting Room worse or better. I would ask a different question before building it at all. Not "can I make this better than what they use now," which I could, but "am I asking people to leave a place they already live, and if so, what makes me think they will."

The lesson is not that good design does not matter. It matters enormously, once someone is actually using the thing. The lesson is that good design is necessary and nowhere near sufficient, and that the hardest part of systems design is not the system. It is the human on the other end, who is already somewhere, already busy, already surrounded by their people, and who will accept a surprising amount of inefficiency to avoid the small discomfort of moving. Build with the grain of that, and a modest tool gets used every day. Build against it, and the best thing you ever made sits in an empty room. I have one of each in the same platform to prove it.