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. 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 to walk through. the subject of this post is fit.

hubspot works 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 is a team of people living inside it, and the handoffs between hubs are how the revenue motion runs.

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

the failure pattern is the org that is a different shape buying it anyway. a vp sees the demo, the keynote impresses, and a contract gets signed for 3 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.

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

2 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. hubspot assumes dedicated marketing, sales, service, and ops functions, each with its own workflows and seat count. most of the orgs buying 3 hubs do not look like that. the team is 12 people. marketing is 1 person wearing several hats. the "service team" is whoever picks up the inbox. a lighter crm (attio, folk, pipedrive, a well-configured airtable) would fit at a fraction of the weight and a fraction of the price.

the question was not on the table at procurement. the demo was the only signal. the roadmap slide was impressive. the buying committee skipped a bake-off against a lighter option, and skipped asking whether the team and the tool were the same shape.

the second failure is the one most people already understand. inside the org, no one owned the first 10 minutes of the user's experience. no one decided which workflows the hubs were supposed to replace. no one named what "working in hubspot" means on a tuesday morning. the rollout was treated as a provisioning task. a launch would have named owners, workflows, and a readiness bar.

this failure would have happened with attio, with a spreadsheet, with any tool. the rollout is where adoption either earns itself or dies, regardless of what sits underneath. a dense tool the team did not 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 has been logging deals in a spreadsheet for 3 years. the marketer who built a workflow in mailchimp that actually works. the ops lead who knows the current system's limits and 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, 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 a real cost, paid in real hours, by people who already have enough to do.

the apprehension is 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 6 months later leadership is evaluating the next platform. the people who sit in these seats know how this story ends.

if the org had asked them first (what do you actually need? what is working? what is slowing you down?), the answer might have been a lighter crm, or fixing the spreadsheet, or hubspot after someone translated its density into their daily workflow. the question was never asked.

saas is supposed to make the job 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 does not mean the tool is bad. hubspot works for the org it was built for. notion works for some teams. retool, the internal-tools builder, works for some teams. the tools are fine. the failure is buying a tool built for someone else's workflow, rolling it out without asking the people it was supposed to help, and blaming the product when it does not fit.

this pattern is larger than hubspot. salesforce, netsuite, workday, sap, any crm that has been around long enough to grow modules: dense platforms fail 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 dropped.

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

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

1: 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 does not own it and the buying committee is impressed by the demo.

2: 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.

3: onboarding built for the first 10 minutes rather than the full feature surface. the team does not need to learn every hub on day 1. they need to know the 3 things they are going to do most often and where those live. everything else can wait.

4: 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.

5: activation metrics that measure behavior rather than 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.

6: a readiness bar the rollout owner is allowed to fail. if the team is not ready, the go-live slips. most orgs will not give the rollout owner that authority, which is why the rollout fails.

none of this requires a redesign, a vendor switch, or 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. the line that matters is whether someone inside the org treated the handoff as a launch before the contract closed.