"Do One Thing Well" Product Focus Roadmap
Split bloated suites into focused apps sharing one toolkit.
- Difficulty
- Moderate
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 75%
Facing a bloated, multi-purpose 'Swiss Army knife' suite inherited from Netscape, Eich and Dave Hyatt wrote a 2003 roadmap that reoriented Mozilla's entire product strategy: rather than one application trying to browse, email, and manage contacts, build separate best-in-class apps — Firefox for browsing, Thunderbird for mail — on a shared, extensible front-end toolkit. This let the team simplify the default experience for mainstream users without alienating power users, since advanced functionality could be added back via extensions instead of being baked into the core. The roadmap became the blueprint that turned a struggling open-source browser project into Firefox, which went on to take roughly a quarter of the global browser market.
Origin
Written by Eich and Dave Hyatt in Mozilla's 2003 roadmap update after Netscape's groupware-bloated suite failed to compete with Internet Explorer.
Core principles
- 01Simplicity for the default user, extensibility for the power user
- 02One focused app beats one bloated app
- 03Shared infrastructure lets you multiply focused products cheaply
How to run it
- 1
Diagnose the swiss-army-knife problem
Identify where a single product is forcing unrelated jobs-to-be-done into one interface (e.g., browsing, email, address book, and rich text editing all crammed together).
- 2
Write the roadmap publicly
Document and publish the new focused vision so the community and team can rally around a clear direction, as Eich and Hyatt did with Mozilla's 2003 roadmap update.
- 3
Build a shared front-end toolkit
Invest in a common, declarative UI toolkit (Mozilla used XUL) so multiple focused apps can be built and maintained without duplicating engineering effort.
- 4
Split into single-purpose applications
Separate the bloated suite into standalone apps — Firefox for browsing, Thunderbird for mail — so each one does its job well.
- 5
Add an extension system for power users
Give advanced users a way to add back complexity via extensions/add-ons instead of bloating the core product for everyone, avoiding losing them to competitors that kept everything built in.
Pro tip This is also what let Firefox build the first mainstream browser extension ecosystem, well ahead of Chrome's.
In the wild
The all-in-one Mozilla Suite bundled browsing, email, and address book management, making it slow and confusing versus IE.
→ Splitting into focused Firefox and Thunderbird apps on a shared toolkit drove Firefox to roughly 25%+ global browser share within a few years.
Common mistakes
Bundling failed groupware into the core suite
Netscape's earlier attempt to bolt on a Lotus Notes competitor delayed releases and didn't displace Notes — an example of feature bloat backfiring.
Overloading defaults to avoid alienating power users
Keeping every option built-in, as some rival browsers did, risks overwhelming mainstream users; the fix is extensions, not more default complexity.
Is it for you?
Best for
Product teams untangling a bloated multi-feature product
Not ideal for
Early-stage products still searching for product-market fit where consolidation may be needed
From the transcript
“let's make one app do one thing well we'll build them all on a common front-end tool kit give them extensions so that we can…”
From the episode
The Browser (with Brendan Eich, Chief Architect of Netscape + Mozilla and CEO of Brave)
Brendan Eich