writing
the rollout is the product
bloated software is real. so is the org that buys it because a keynote impressed a vp.
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.
nobody inside the org has asked the harder questions. is our team actually going to use this? does it fit the workflows people already have? is there someone accountable for the first ten minutes of the user experience inside the new tool, or are we relying on the vendor's onboarding video to close that gap?
a tool gets announced in a monday memo. a license is purchased. a login is sent out. three weeks later leadership is asking why adoption is flat, why the team is still working in the old spreadsheet, and whether the vendor sold them something broken.
the tool didn't fail. the rollout did.
most organizations treat software adoption like procurement. there's a contract to sign, a vendor to manage, a budget line to approve. once those boxes are checked, the work is considered done. the tool gets provisioned. the training link goes out. 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're 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's 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 is dense. hubspot is dense. most enterprise software is dense. that's a real variable, and the smarter leadership teams factor it in at procurement. but even the cleanest, lightest-weight software on the market will fail on a team that treats adoption as a line item.
product teams already know how to do this. when they ship something external, they plan the launch. there's positioning — why does this exist, what does it replace, who is it for. there are onboarding flows designed for the user's first ten minutes. there are activation metrics to measure whether the thing actually lands. there are in-app nudges, champions, feedback loops. there's a readiness bar before the product goes 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'll use the tool daily. activation metrics — not logins, but the specific behaviors that signal the tool is actually doing work. champions on each team. a feedback loop that closes. an explicit plan for what the tool replaces, because a tool that doesn't replace anything is a tool that doesn't get used.
most organizations have none of this. they have a contract and a deadline.
two things are true at once.
the software is getting denser. vendors are paid to ship more — more hubs, more modules, more ai features, more everything. human workflows are not being considered in most of what ships. that's real, and it's worth saying out loud.
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 doesn't mean it's 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.
the fix isn't more training. it isn't more licenses. it isn't switching vendors every two years. the fix is putting 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're allowed to fail.
most leadership teams won't do this. they'll keep buying tools, blaming tools, switching tools, and wondering why the numbers don't move.
the tools get named in blog posts. the rollouts get named in exit interviews.
where does your team draw that line?
— clarai.io