software isn't one-size-fits-all

software isn't one-size-fits-all.

that line sounds obvious until you watch how most enterprise software actually gets bought. the buying committee falls in love with the demo. the roadmap slide impresses. the contract gets signed. and the team the tool lands on was never asked whether the shape of the product matched the shape of their work.

hubspot is the easiest example, but this is not a post about hubspot. it's a post about fit.

hubspot works swimmingly for the org it was built for.

a teams-of-teams revenue org. a dedicated marketing function with enough seats to justify a marketing hub. a dedicated sales function with enough pipeline to justify a sales hub. a service function running an inbox at volume. an ops function gluing it all together. at that shape, the density earns itself. every hub has a reason to exist because there's a team of people living inside it, and the handoffs between hubs are the actual work of the revenue motion.

for those orgs, hubspot is doing what saas is supposed to do. it makes the job easier. the density is a feature.

the failure pattern is the org that isn't that shape buying it anyway.

the pattern looks the same almost every time.

a vp sees the demo. the keynote impresses. a contract gets signed for three hubs nobody on the team actually asked for. procurement closes. it provisions. an executive sponsor sends the monday memo with a training link and a go-live date. the team is told the old workflow is disappearing at the end of the quarter.

three weeks later adoption is flat. the sales team is still in the spreadsheet because it's still faster than figuring out where the forecast lives in the new crm. the marketing team logged in once and hasn't been back. a handful of reports that were supposed to be automatic are still pulled by hand on friday afternoons. leadership asks what's wrong with the tool.

two failures already happened before the first login.

the first failure is that the org never tested whether hubspot was the right tool for the team in the first place.

hubspot is built for teams-of-teams. it assumes a dedicated marketing function, a sales function, a service function, and an ops function, each of which has its own workflows and its own seat count. the product's density is a feature at that shape — every hub has a reason to exist when there's a team of people living inside it.

most of the orgs buying three hubs do not look like that. the team is twelve people. marketing is one person wearing three hats. the "service team" is whoever picks up the inbox. a lighter crm — attio, folk, pipedrive, a well-configured airtable — would fit the team at a fraction of the weight and a fraction of the price.

the question wasn't on the table at procurement. the demo was the only signal. the roadmap slide was impressive. nobody ran a bake-off against a lighter-weight option. nobody asked whether the team was the right shape for the tool, or whether the tool was the right shape for the team.

the second failure is the one most people already understand.

nobody inside the org owned the first ten minutes of the user's experience. nobody decided which workflows the hubs were supposed to replace. nobody named what "working in hubspot" actually means on a tuesday morning. the rollout was treated as a provisioning task, not a launch.

this failure would have happened with any tool. it would have happened with attio. it would have happened with a spreadsheet. the rollout is where adoption either earns itself or dies, regardless of what sits underneath.

but the two failures compound. a dense tool the team didn't need, rolled out without a plan, lands twice as hard as either mistake alone.

underneath both failures is a voice that was never in the room: the end user.

the rep who's been logging deals in a spreadsheet for three years. the marketer who built a workflow in mailchimp that actually works. the ops lead who knows the current system's limits but also knows its rhythms. these are the people the tool is supposed to help, and they were never asked whether it would.

some of them aren't technical. some are protective of workflows that already work — not because they're resistant to change, but because those workflows are how they get their job done on a tuesday morning. learning a new platform on top of a full workload is not a line item. it's a real cost, paid in real hours, by people who already have enough to do.

the apprehension isn't irrational. it's earned. most of them have been through this before — a new tool lands, the team is told to switch, the tool is confusing, the old workflow disappears, and six months later leadership is evaluating the next platform. the people who sit in these seats know exactly how this story ends.

if the org had asked them first — what do you actually need? what's working? what's slowing you down? — the answer might not have been hubspot. it might have been a lighter crm. it might have been fixing the spreadsheet. it might have been hubspot, but only after someone translated its density into their daily workflow.

the point is: the question was never asked.

the underlying frame is simpler than any of this sounds.

saas is supposed to make the job easier — easier for the people doing the job. when a tool makes their work harder — when the team is logging in less over time, when workflows route around it instead of through it, when reports that were supposed to be automatic are still pulled by hand on friday afternoons — the tool is not working for them.

that doesn't mean the tool is bad. hubspot works beautifully for the org it was built for. notion works beautifully for some teams. retool works beautifully for some teams. the tools are fine. the failure is buying a tool that was built for someone else's workflow, rolling it out without asking the people it was supposed to help, and blaming the product when it doesn't fit.

this is not a hubspot problem. every tool at that weight has the same shape. salesforce, netsuite, workday, sap, any crm that has been around long enough to grow modules — same pattern. dense platforms fail the same way dense platforms have always failed: not in the ui, but in the handoff between the vendor's onboarding video and the user's actual work.

product teams already know how to do this work when they ship things externally. positioning. onboarding. activation metrics. champions. a readiness bar. an explicit story about what the new thing replaces.

somewhere between procurement and the end user, that rigor gets left in the parking lot.

a fix for this shape of problem starts before the contract, not after it — and it starts with the people the tool is supposed to help.

zero: user input. before procurement, talk to the people who'll live in the tool daily. what do they actually need? what's working now? what's slowing them down? the answer shapes every decision that follows — including whether the tool being evaluated is the right one at all.

one: fit testing. before signing, someone inside the org has to answer whether the team is the right shape for the tool. for hubspot specifically: is there a dedicated marketing function, a dedicated sales function, a dedicated service function, each with enough seats to justify a hub? if the answer is no, a lighter crm is the right answer. most orgs skip this question because procurement doesn't own it and the buying committee is impressed by the demo.

two: positioning for the internal team. a one-pager that says what the tool is for, what it replaces, and what explicitly stays where it is. most orgs skip this and assume the team will figure it out from the training deck. they won't.

three: onboarding built for the first ten minutes, not the full feature surface. the team doesn't need to learn every hub on day one. they need to know the three things they're going to do most often and where those live. everything else can wait.

four: a champion on every team. one person who can answer "where does the reporting live now" without opening a support ticket. without champions, every question routes to the admin, the admin burns out, and the team drifts back to the old tool.

five: activation metrics that measure behavior, not logins. "did the sales team log a deal in hubspot this week" is a real metric. "did 80% of seats log in" is a vanity metric that hides the failure.

six: a readiness bar the rollout owner is allowed to fail. if the team isn't ready, the go-live slips. most orgs won't give the rollout owner that authority, which is exactly why the rollout fails.

none of this requires a redesign. none of this requires switching vendors. none of this requires a new hire.

what it requires is someone inside the org holding the rollout the way a pm holds a launch.

the tool gets blamed in board meetings. the users were never asked. the rollout gets named in exit interviews.

where does your team draw that line?

— clarai.io