adoption vs utility
the rollout is the product
the tool gets blamed in the board meeting. adoption usually failed earlier, when the org skipped whether the product fit how the team already works.
bloated software is real. so is the org that buys it because a keynote impressed a vp.
photoshop keeps adding. layers became vector, became 3d, became video, became generative ai, all stapled to the same application most users opened for the first time to crop a photo. hubspot keeps stacking hubs on top of a product that used to be a crm. notion keeps collapsing docs, databases, wikis, and ai assistants into a single sidebar. the marketing team at every major vendor is paid to make the next module feel essential, and most leadership teams buy it on the strength of a demo and a roadmap slide.
then the license lands on the team, often before anyone inside the org has answered the harder questions: whether people will actually use this, whether it fits workflows they already have, and whether someone owns the first 10 minutes of the experience or the vendor's onboarding video is expected to close that gap.
a monday memo announces the tool, a license is purchased, a login goes out. 3 weeks later leadership is asking why adoption is flat, why the team is still in the old spreadsheet, and whether the vendor sold them something broken. in most of those meetings the failure sits in the rollout, not in the install.
most organizations treat software adoption like procurement: a contract to sign, a vendor to manage, a budget line to approve. once those boxes are checked, the work is treated as done. the tool gets provisioned, the training link goes out, and calendars are marked with the date when the old workflow is supposed to disappear.
the team is expected to absorb a new product on top of everything else they are already doing, with no one inside the org accountable for the translation between "we bought it" and "it's working."
so nothing works. people stay in the old spreadsheet because it is still faster than figuring out where the reporting dashboard lives in the new system. managers log in once to please the executive sponsor and then don't log in again. reports that were supposed to be automatic are still pulled by hand on friday afternoons. the pilot team drifts back to slack and email for anything that matters. leadership blames the tool.
sometimes the tool is genuinely dense (photoshop, hubspot, most of the enterprise stack). that variable is real, and smarter leadership teams factor it in at procurement. even the cleanest, lightest-weight software on the market will fail on a team that treats adoption as a line item. mckinsey's digital-transformation research puts the same pattern in numbers: only about 16% of digital transformations both improve performance and sustain the gains; another 7% improve briefly and then lose it.1
product teams already know how to do this when they ship something external. they plan the launch: positioning (why this exists, what it replaces, who it is for), onboarding for the user's first 10 minutes, activation metrics for whether the thing actually lands, in-app nudges, champions, feedback loops, and a readiness bar before go-live.
somewhere between procurement and the end user, that rigor gets left in the parking lot.
an internal rollout deserves the same craft. positioning for the internal audience. onboarding designed for the muscle memory of the people who will use the tool daily. activation metrics that track the specific behaviors that signal the tool is doing work, not just logins. champions on each team. a feedback loop that closes. an explicit plan for what the tool replaces, because a tool that does not replace anything does not get used.
most organizations have none of this. they have a contract and a deadline.
two facts sit next to each other. the software is getting denser: vendors are paid to ship more hubs, more modules, more ai features. human workflows are not being considered in most of what ships. and even when the software is fine, the rollout is where adoption either earns itself or dies. marketing and figureheads telling leadership the tool is great does not mean it is right for your team. the vendor has already done their job when the contract is signed. the work that matters next is inside your walls.
more training, more licenses, and switching vendors every 2 years do not fix that. put someone inside the org in charge of the rollout the way a pm is in charge of a launch, with positioning, metrics, champions, and a readiness bar they are allowed to fail.
most leadership teams will keep buying tools, blaming tools, switching tools, and wondering why the numbers do not move. the tools get named in blog posts. the rollouts get named in exit interviews.