The Work We Give Our Customers
I built a drinkware company before I started building software. One question applies to both: how much work does the product leave for the person using it?
With a physical product, that work is relatively easy to picture. Imagine a lid with several removable parts. It has to be taken apart, cleaned, and put back together. The design might achieve something valuable, but the customer pays for it in a way that never appears on the price tag.
Software can impose the same cost less visibly. A dashboard needs information. Someone has to provide it, keep it accurate, and decide what to do when it disagrees with another system. The interface can be simple while the responsibility behind it is considerable.
This complicates the claim that a product saves time. Whose time, and which work are we counting?
Suppose a tool reduces the time required to prepare a report from two hours to ten minutes. But each of three recipients now spends an additional hour checking its output. If those checks are new, the process consumes three hours and ten minutes across those people. The report appears sooner, but more work goes into making it usable. If the recipients did the same checking before, that work cannot all be counted as a new cost. We have to compare the whole old process with the whole new one.
The saving is easy to demonstrate. The new work is scattered across other people's days.
This is a tempting mistake for a builder to make, because we see our product much more clearly than we see the life it enters. We know how many steps we removed from a workflow. We may not know how many steps someone added before they felt comfortable using it.
A demonstration can begin with the information already available and end when the output appears. The customer's task begins earlier and ends later. They have to collect the information, resolve the exceptions, explain the result, and live with the consequences if it is wrong.
A product can perform its part perfectly and still make the whole task harder.
That does not mean products should demand nothing from their users. Learning a difficult tool can be an excellent investment. Maintenance can be worth the performance it preserves. There are also things we buy precisely because we enjoy the work they involve.
At COOLIQ, shared tooling and separately offered accessories helped us meet manufacturing requirements while expanding the product range. BevTab and straw colour packs also supported COOLIQ by you, where customers could choose their own combination of colourways. Making those choices is part of what customisation offers. The design could serve our production needs and give the customer more freedom at the same time.
The question is what the effort gives someone. Choosing a colour combination lets them shape the result. Reconciling two systems may simply be necessary to obtain the result a product promised. Even that work may be worth doing if the benefit is large enough. It still belongs in the assessment.
If a product asks for an hour of setup and saves ten hours every month, the trade may be obvious. If it saves ten minutes but introduces another place to check, another account to manage, and another decision to make, it may be less useful than its demonstration suggests.
For a product promising to simplify an existing task, one useful question is what someone can stop doing once it works. Can they retire the spreadsheet? Stop entering the same information twice? Or does the new product sit beside everything they already use, waiting to become trustworthy enough to replace it?
The old process remaining in place is not always evidence of a bad product. Sometimes it is a sensible precaution. But the work of running both processes belongs in the account until one can be retired.
The cost of producing an experiment and the cost of asking someone to depend on it are different. A prototype can be worthwhile for what it teaches its maker. Adopting it may require someone else to move information, change a routine, and maintain a fallback. Making the first cost smaller does not automatically reduce the second.
I want to get better at seeing the work that begins where the demonstration ends. Some of it is necessary. Some is a reasonable exchange for something better. Some is simply a problem we have handed to the customer. A product is not finished merely because it does what we built it to do. We also need to understand what it asks everyone else to do.
Michael Macdonnell · 6:48am