Skip to main content

adoption vs utility

stuff or split

when the next module arrives, most saas companies stuff it into the product everyone already uses, because attach rate rewards it. the bill comes later, in onboarding time and a product that no longer fits in anyone's head.

every saas company hits the same fork when growth pressure meets product complexity.

the question on the table is always some version of: the company is growing, the board wants expansion revenue, a new module is in the roadmap. does it live inside the product everyone already uses, or does it ship as its own thing? stuff, or split.

most companies stuff. most of them are wrong to.

stuffing looks like one sku, one login, one growing product. hubspot did it, 7 hubs stapled into the shell that started as a crm.1 notion did it, docs became databases became wikis became ai assistants, all inside the sidebar. photoshop has done it for 30 years, absorbing vector, 3d, video, and generative ai into the same app. slack started stuffing when it added huddles, canvas, and lists. each addition was coherent on its own. none of them was edited against the whole.

splitting looks like a portfolio of separate products with separate mental models. figma has design, figjam for whiteboarding, dev mode for handoff, slides for presentations.2 atlassian has jira, confluence, and bitbucket, overlapping use cases, distinct tools. microsoft has word, excel, powerpoint, and outlook, each still unmistakably its own application 30 years on. adobe stuffs inside each app but splits at the suite level.

the pattern across split portfolios: each product has a clear mental model. each one can be adopted standalone. the cross-sell is an invitation to try the next coherent thing, rather than a demand to learn a new mental model inside a tool the customer already uses.

most companies stuff because the metrics reward it in the short term. attach rate goes up, seats per account go up, and average contract value goes up. expansion revenue has a clean story for the board. the bill comes due later, and it is paid by someone who does not sit in the boardroom.

complexity is conserved. when a module gets stuffed into an existing product, the complexity migrates onto the user's cognitive load. onboarding gets longer. cross-team alignment gets harder. new hires take months instead of days to become useful. nps sags, and the product org cannot point to a single cause because the causes are scattered across 40 modules that nobody edited as a whole.

by the time the clarity tax shows up in hard metrics (retention, expansion per seat, time-to-value) it is already years of debt.

splitting is the conviction bet. the wager is that mental-model clarity compounds faster than attach-rate math. figma made that bet when it shipped figjam as a separate product instead of a "whiteboard mode" inside figma.2 atlassian made it decades ago and still holds the line: jira and confluence are the same company, unmistakably different products. microsoft has been running the split playbook since the 1980s and owns productivity software at planetary scale.

split products compose; stuffed products collide. the cross-sell in a split portfolio is "try the next product, which already works the way you expect." the cross-sell in a stuffed product is "learn a new mental model inside the app you already use." one of those is an invitation. the other is a tax dressed up as a feature.

the roadmap answers "what do we build next?" every quarter. the harder question, the one most leadership teams skip, is whether the next thing should live inside this product or next to it.

that question needs a seat at the table. it needs someone senior whose job is to protect the mental model, to say no to stuffing, to make the case for a new sku when the finance org would rather see a new module, to argue for clarity against the gravity of expansion revenue.

most companies do not have that seat. the ones that do are the ones whose products still feel legible 10 years in. editing is a leadership act, and so is refusing to stuff. the bet worth naming is whether the next module earns its own product or gets folded into the one people already struggle to hold.