The Cost of Building Processes Around Technology Instead of Business Outcomes
On October 1, 2024, Jamboard users lost the ability to create or edit a single board. According to Google's Jamboard help page, the existing boards were later converted to PDFs and left in Drive.
A working whiteboard became a picture. Any process that lived on that board became a picture too, and in a hypothetical 25-person team, rebuilding just one workflow after a tool disappears costs about $17,625 in payroll cash. Here is the question worth asking: if the tool under one of your processes disappeared next quarter, would you be replacing software or rebuilding the process?
Table of Contents
The Whiteboard That Became a Picture
Jamboard was a shared digital whiteboard. Google's help page adds that Jams can be exported from Drive as PDF or PNG files, and a PNG captures only a single frame.
Picture a team that ran its weekly planning on one of those boards. The team did not lose a whiteboard. It lost the place where the routine happened, and the routine had no home outside the tool.
That is the pattern behind most tool shutdowns. The software is replaceable. What was living inside it is the expensive part.
Building Processes Around Technology Looks Like Progress
It starts with a reasonable decision. A team adopts a tool, and the tool arrives with fields, defaults, and a built-in workflow. Within a year, the business is following the tool's steps instead of the steps the business needs. Here is the pattern: building processes around technology.
The alternative is to build around the business outcome, meaning the result the work exists to produce, such as an invoice paid, a customer onboarded, or a month closed on time. Tools serve that result and can be swapped. A process built around a tool cannot be swapped without being rebuilt.
In my experience across industries, tool-shaped processes tend to look like this from the inside:
Steps that exist because the software has a field for them
Approval routing that follows the tool's default workflow instead of who actually decides
Reports that show what the system can export instead of what leadership needs to see
Training that teaches which buttons to click and skips the result the work must produce
Handoffs that happen inside the tool's notifications and nowhere else
A vendor's feature list quietly serving as the job description for a role
Each of these felt like good design on the day it was set up. The trouble is that the business now depends on the vendor's roadmap, and nobody put that dependency on a list.
The Cost Nobody Prices
A tool disappearing is a small event. The cost of the rebuild is not. Here is an illustration with hypothetical figures.
Take a 25-person team that has to move a core workflow to a new tool. A manager spends 60 hours rebuilding the workflow at a loaded cost of $75 an hour. Each of the 25 employees spends three hours learning the replacement at $35 an hour. Then, for six weeks, each employee loses two hours a week to slower work while the new steps settle in, also at $35 an hour.
That comes to $17,625 in payroll cash, and none of it produces a new customer. The figure leaves out errors made during the transition, which surface later as rework, delayed invoices, and management time that nobody labels as a tool problem.
Revenue comes from the front office. Cash flow is protected in the back office. A rebuild paid for out of operating cash is a tax on what the front office earned.
The larger cost is the higher-leverage work that waits while the team rebuilds. That number is almost always bigger than the cost of building around the outcome in the first place.
The Proximity Problem
A tool-shaped process is hard to spot because the tool made it feel like the way work is done. Ask a team how they onboard a customer, and they will describe the tool: click here, move the card there, wait for the notification. The result those steps exist to protect rarely comes up.
The people inside a system cannot see what is broken in it. That is not a competence gap. It is physics. Proximity blocks the view. The same limit applies to tools. AI documents what is described, so a description of clicks produces a clean record of clicks. It cannot see what was left out.
What Changes When the Business Owns the Outcome
Picture the same shutdown notice arriving at a business whose processes are built around outcomes. The team knows what each process must produce, who owns it, and which tool currently supports it. Replacing the tool becomes a project with a start date and an end date, and the process keeps running while it happens.
That outcome-first design is what the back office process improvement work I do is built to produce. An outside review finds in days which processes belong to the business and which have quietly become property of a vendor.
The argument for fixing a process before buying software is made in Fix Process Before Tech. This post covers the other end of the timeline, which is what the business pays when the tool leaves.
Free Resource: 5 Steps to Streamline Your Business
If you want to look at your own operation before anyone else weighs in, 5 Steps to Streamline Your Business is a free guide to identifying and fixing operational gaps before adding tools. Signing up also adds you to The Back Office Brief, delivered weekly.
Get the 5 Steps to Streamline Your Business guide: see where your business stands
Frequently Asked Questions
What does building processes around technology mean?
It means the tool decides the steps and the business adapts to them. Fields, defaults, and notifications become the process, and the outcome the work is meant to produce fades into the background. The process works while the tool works and stops making sense when the tool changes. Building around the business outcome reverses that order.
What happened to Jamboard?
According to Google's Jamboard help page, users could no longer create or modify Jams as of October 1, 2024. The existing Jams were converted to PDFs and remain available in Google Drive, where they can be exported as PDF or PNG files. A PNG export captures only a single frame. The boards survive as static files, not as working spaces.
What does it cost a business when a tool a process depends on disappears?
The direct cost is labor. Someone rebuilds the workflow, everyone learns the replacement, and work slows during the transition. In a hypothetical 25-person team, that can reach $17,625 in payroll cash. Errors during the transition add rework and delays, and the larger cost is the higher-leverage work that waits while the team rebuilds.
How is a business outcome different from a tool feature?
A business outcome is the result the work exists to produce, such as an invoice paid, a customer onboarded, or a month closed on time. A feature is one way a tool helps produce it. Outcomes stay the same when tools change. Features do not, which is why processes built on features break when the vendor moves on.
Should a business avoid tools that a vendor might discontinue?
No. Every tool eventually changes, moves, or disappears, and avoiding technology carries its own cost. The point is that the process should not live only inside the tool. When the business owns the outcome, the owner, and the steps, replacing a tool becomes a project instead of a crisis.
Ready to See Which Processes Belong to You?
Book a discovery call and we will look at your operation together, starting with the processes that would stop making sense if one tool disappeared.
The Back Office Brief
Get a weekly insight connecting back office operations to profit. Delivered every week, free.
Comments