The Situation
For most of the history of professional design tools, the category had a settled shape. Serious work lived on the desktop. The dominant tools were powerful, expensive native applications that ran locally, saved files to disk, and assumed a single person sitting in front of a single screen. Designers exported flattened images, emailed them around, collected feedback in scattered threads, and then reconciled changes by hand. The file was the unit of work, and the file lived on someone's machine. This was the accepted reality, and the incumbents who owned it were not small companies you would expect to dislodge with a side project.
Into this settled category came a bet that, from the outside, looked almost foolish. A small team decided that a professional-grade design tool should run inside a web browser, and that multiple people should be able to work in the same file at the same time, the way they could in a shared document. Browsers in that era were not obviously capable of this. Rendering complex vector graphics at high frame rates, handling large design files, and synchronising live edits across many users was a set of problems that most reasonable engineers would have told you to avoid. The team chose to spend years solving exactly those problems before they had a product anyone could buy. This is the story of why that choice was correct, and what a product manager can take from it.
The Bet
The central bet had two halves that depended on each other. The first half was technical: that the browser could be made into a serious canvas. Rather than building the interface out of standard web page elements, the team committed to rendering the design surface much closer to the metal, using the graphics capabilities the browser exposed, so that panning, zooming, and editing felt as fluid as a native app. This was not a weekend's work. It was a deep, unglamorous research effort with no guarantee of success and no revenue while it ran.
The second half was about behaviour: that collaboration, not raw feature count, was the real unmet need. Design work is not solitary. It is reviewed, revised, argued over, and handed off. The incumbents treated this social reality as an afterthought, bolted on through exports and comments. The bet was that if you made the design file a shared, live space, the way teams worked would reorganise around it, and that this would matter more than matching every brush and filter the desktop tools offered.
What They Actually Did
The most instructive part of this story is not the vision. Plenty of people had wished for browser-based design before. The instructive part is the discipline of the execution, and the willingness to delay gratification for an unusually long time.
They Treated Performance As The Product
Before worrying about how many features they had, the team obsessed over whether the core canvas felt right. A design tool that stutters when you zoom is dead on arrival, regardless of its other merits, because designers feel latency in their hands. So the early years went into making the fundamental act of moving things around on a screen feel instant in an environment that was never designed for it. This is a hard moat precisely because it is boring, slow, and easy for a competitor to underestimate.
They Made Collaboration The Default, Not A Mode
Many tools added a comment feature and called it collaboration. The harder and more valuable choice was to make the shared, simultaneous state the foundation of the product. Open a file and you could see other people's cursors moving. That presence was not a bell or a whistle; it was the point. When collaboration is the substrate rather than a feature, the whole product reshapes around it, and copying it later means a competitor has to rebuild their foundation, not add a panel.
They Waited
Perhaps the boldest product decision was restraint. The team resisted launching the moment they had something demoable. They kept refining, and let the technical foundation mature, because a half-working browser design tool would have confirmed every skeptic's prior and burned the first impression. First impressions in tooling are expensive to undo. They spent their scarce attention on being undeniable at launch rather than early to it.
Why It Worked
When the product finally arrived, it landed on a combination of advantages that were hard to assemble any other way. The performance was good enough that the browser stopped being an excuse and started being a feature. Because the work lived on the web, there was nothing to install, no licence to provision, and no file to lose. And because collaboration was native, a behaviour quietly emerged that turned out to be the growth engine: the shareable link.
Distribution Was Built Into The Product
When your work lives at a URL, sharing it is frictionless, and every share is an invitation. A designer sends a link to an engineer, a product manager, or a stakeholder who has never used the tool. That person opens it in a browser with no setup and immediately experiences the product. The act of doing the work spread the work. This is distribution as a property of the product itself rather than a separate marketing motion, and it is far cheaper and more durable than buying attention.
The Wedge Widened Into A Platform
Collaboration was the wedge that got the tool in the door, but the browser foundation made it possible to keep expanding what the product could be: bringing more roles than designers into the same space, supporting whiteboarding and ideation, and building an ecosystem around a tool that everyone could already reach. A wedge is only valuable if it opens into something larger, and this one did because the underlying architecture was general, not narrowly cut for a single use case.
What Almost Went Wrong
It is tempting to narrate this as inevitable, but it was not. The same decisions that made the bet powerful also made it fragile, and a product manager should sit with the risks rather than skip to the happy ending.
- The runway risk. Spending years building deep technology before earning revenue is a financial tightrope. If the market had shifted or funding had dried up before launch, the moat would have been a grave. Long R&D bets require both conviction and the runway to survive them, and most teams have one without the other.
- The performance cliff. If the browser canvas had ended up merely acceptable rather than excellent, the entire premise collapses. There was no fallback. The bet had a binary quality that left little room for a soft landing.
- The empty-room problem. A collaboration tool is less valuable when you are the only person in it. Early on, the multiplayer magic risks being a feature with no one to share it with. The team had to get individual single-player value high enough that the tool was worth using before the network filled in.
- The incumbent's reach. The established players had enormous installed bases and could have responded aggressively. The window to become undeniable before that response arrived was not guaranteed to stay open.
None of these risks were hypothetical. Each could have ended the story. What made the bet defensible was not that the risks were small, but that the team had a credible plan to clear each one and the patience to do so in the right order: solve performance, establish single-player value, then let collaboration and links compound.
The Lessons For Product Managers
Strip away the specifics of design software and several transferable principles remain. These are the parts you can actually carry into your own work.
A Hard Technical Problem Can Be A Moat
Product managers are trained to ship fast and avoid over-engineering, and that instinct is usually right. But there is a category of bet where the technical difficulty is the moat. If a capability is genuinely hard to build and central to the experience, then the years you spend on it are not waste; they are the wall a competitor cannot climb quickly. The skill is telling the difference between necessary depth and gold-plating. Ask whether the hard thing is load-bearing for the entire product or just a nice corner.
Collaboration Is A Wedge, Not A Checkbox
When you look at a category dominated by single-player tools, ask what the work actually looks like when humans do it together. Often the incumbent has treated the social reality of the work as an afterthought. Making collaboration the substrate rather than a feature can reorganise the whole category around you, because it changes how teams work rather than just what one person can do.
Patience Before Launch Is A Real Strategy
In a culture that worships shipping early, deliberately waiting until you are undeniable is countercultural and sometimes correct. For tools where the first impression sets the ceiling on adoption, a strong debut beats an early one. This is not permission to polish forever; it is recognition that some products only get one chance to be taken seriously.
A Final Word
The lasting lesson is that the most durable products often come from refusing the category's settled assumptions and then doing the unglamorous work to make the new assumption true. It was easy to say design should be collaborative and live in the browser; almost no one was willing to spend years making it actually feel good. The bet worked because the vision was paired with the patience to earn it, and because the resulting product carried its own distribution in the form of a link anyone could open. As a product manager, the transferable instinct is to find the place where a hard technical investment, a behavioural insight, and a built-in growth loop all reinforce each other, and then to have the discipline to build them in the right order.
Key Takeaways
- Some moats are made of patience. A genuinely hard technical problem, solved well and central to the experience, is a wall competitors cannot quickly climb. Learn to tell load-bearing depth from gold-plating.
- Make collaboration the substrate. Treating how people work together as the foundation, not a bolted-on comment box, can reorganise an entire category around your product.
- Build distribution into the artifact. When the unit of work is a shareable link, every share is a free, pre-qualified acquisition. Design the work product so sharing it is also onboarding.
- Earn the right to launch. For tools where first impressions set the adoption ceiling, being undeniable beats being early. Restraint can be a strategy, not just caution.
- Sequence your risks. Solve the binary, foundational risk first, establish standalone value, then let the network effects compound. Order matters as much as ambition.