By the early 2000s, Microsoft Excel had more than 1,500 commands, three levels of menus, 31 toolbars, and 20 task panes. The Office Ribbon was created because the team could no longer make that command set findable through the old interface.
Most growing software products go through a smaller version of the same arc.
They start with a few clear surfaces. Then each new team, enterprise customer, workflow, integration, and permission model adds another page, tab, panel, drawer, or settings area. Eventually the product has a command palette, a mega-menu, and an AI search box because the navigation stopped being enough.
That is not only a UX problem. It is an organizational problem made visible in the UI.
The pattern
A new product often starts with four or five surfaces. They match the core loop.
By year three, the product has admin, billing, integrations, reporting, notifications, settings, developer tools, user management, import/export, and special customer workflows.
By year seven, the top navigation cannot hold the product anymore. The team adds an app drawer, command palette, mega-menu, or search-first navigation.
Every addition made sense when it shipped. The cumulative result does not.
Why this happens to serious products
Surface sprawl is not usually caused by careless teams. It is caused by reasonable decisions that do not have a counterweight.
Enterprise customers ask for admin controls. Finance asks for billing. Security asks for audit. Product asks for analytics. Marketing asks for campaigns. Customer success asks for health scores. Developers ask for APIs and logs. AI teams ask for prompts, runs, evaluations, and memories. Each request has a real user and a real business case.
The problem is that the product starts organizing itself around internal ownership instead of user work. A top-level area becomes the place where a team can ship. Over time, the user has to learn the company's operating model before they can use the product.
This is why surface count is a strategy metric, not only a design metric. It shows whether the product still has a clear opinion about where work belongs.
Why adding is easy and removing is hard
Adding a tab is easy to justify. A customer asked for it. A team owns it. A sales deal depends on it. The work is scoped. The feature ships.
Removing a tab is much harder. Someone uses it. A team owns it. A contract mentions it. Support has docs for it. Sales has promised it. The original sponsor may still be in the company.
As long as adding costs one unit and removing costs ten, the surface count only grows.
Pendo's 2019 Feature Adoption Report found that 80% of features in the average software product are rarely or never used. Each rarely used feature still has to live somewhere. Users pay for that every time they scan the product.
The org chart shows up in the nav
Conway's Law says systems tend to mirror the organizations that build them. Navigation does too.
When a company funds a growth team, a growth surface appears. When it funds lifecycle, analytics, governance, AI, or enterprise admin, those areas want visible space. A top-level tab becomes proof that the team exists and matters.
That is how a product's navigation becomes a fossil record of its org chart.
Users do not care which internal team shipped which surface. They care whether they can do the work quickly.
The operating rule
A product should add a top-level surface only when the user's mental model changes.
If the new capability helps the same job, it should usually live inside the existing job area. If it helps a different role see the same work, it may need a different view, not a new top-level product. If it exists only because an internal team needs somewhere to ship, it should not become navigation.
This rule matters more as AI enters products. AI makes it easy to add assistants, agents, side panels, summaries, and command bars everywhere. Those can help, but they can also hide structural confusion. A product that needs AI search to find every core action may have a product-shape problem, not a search problem.
Why workarounds do not solve it
Mega-menus hide the count. They do not reduce it.
Command palettes help power users jump faster. They do not teach new users what the product is for.
AI search can find buried features. It can also make it cheaper to keep adding buried features.
These are useful tools. They are not a substitute for a product having a small number of clear places where work happens.
What good products do
Products that hold their shape usually have an editorial rule.
Linear, Notion, Stripe, and Figma have all grown large product surfaces while keeping a strong top-level model. They do not ship every new capability as a new tab. New work has to fit the product's existing structure or justify a real structural change.
That takes discipline. Someone senior has to say no to visible surface area even when the requested feature is reasonable.
What Lyberty does
Lyberty keeps a small fixed set of top-level surfaces for the main operating product. New capability does not automatically get a new home. It has to fit the work model.
That matters because Lyberty touches many workflows: campaigns, market analytics, relationships, finance, documents, approvals, AI runs, and operations. Without a hard constraint, the product would quickly become another set of tabs describing our org chart instead of the user's work.
The limit is honest: sub-routes inside each surface can still grow, and those need review. The top-level rule is the first constraint, not the final answer.
What to check
- Count your product's top-level surfaces.
- Count how many existed one year ago.
- Ask which surfaces map to user work and which map to internal teams.
- Require every new top-level surface to displace or clearly outperform an existing one.
- Treat navigation count as a product health metric.
The product gets harder to learn one reasonable tab at a time.
Sources
- Enter the Ribbon. Jensen Harris, MSDN blog, September 15, 2005. https://learn.microsoft.com/en-us/archive/blogs/jensenh/enter-the-ribbon
- The Story of the Ribbon. Jensen Harris, MSDN blog, March 12, 2008. https://learn.microsoft.com/en-us/archive/blogs/jensenh/the-story-of-the-ribbon
- Designing the Ribbon. Jensen Harris. https://jensenharris.com/home/ribbon
- The 2019 Feature Adoption Report. Pendo, January 2019. https://www.pendo.io/resources/the-2019-feature-adoption-report/
- Pendo Data Suggests $29.5 Billion in Global Cloud R&D Investment Squandered. PR Newswire, January 8, 2019. https://www.prnewswire.com/news-releases/pendo-data-suggests-29-5-billion-in-global-cloud-rd-investment-squandered-when-software-features-go-unused-300789477.html
- On the rate of gain of information. W. E. Hick, 1952. https://journals.sagepub.com/doi/10.1080/17470215208416600
- The magical number seven, plus or minus two. George A. Miller, 1956. https://psycnet.apa.org/record/1957-02914-001
- How do committees invent? Melvin E. Conway, 1968. https://www.melconway.com/Home/pdf/committees.pdf
- Inspired: How to Create Tech Products Customers Love. Marty Cagan, 2017. https://www.svpg.com/empowered-product-teams/
- Salesforce Lightning launch. Salesforce, August 25, 2015. https://www.salesforce.com/news/press-releases/2015/08/25/experience-the-future-of-crm-today-welcome-to-salesforce-lightning/
- Welcome to the new era of Microsoft Teams. Microsoft, March 27, 2023. https://www.microsoft.com/en-us/microsoft-365/blog/2023/03/27/welcome-to-the-new-era-of-microsoft-teams/
- Notion's Data Model. Notion Engineering. https://www.notion.com/blog/data-model-behind-notion
- Inside Linear: Why craft and focus still win. First Round Review. https://review.firstround.com/podcast/inside-linear-why-craft-and-focus-still-win-in-product-building/
- Time-to-Value Benchmark Report 2024. Userpilot. https://userpilot.com/blog/time-to-value-benchmark-report-2024/
- Command-K Bars as a Modern Interface Pattern. Maggie Appleton. https://maggieappleton.com/command-bar