Some of the most important product work is not feature work. It is workflow authorship: redesigning the real processes products sit inside, not decorating the screens that touch them. The leverage is not in making the old workflow nicer. It is in authoring a better one.
Most workflows were never authored
A workflow is what a person actually does to get a piece of work done. Not the screens they touch, not the products they pay for, not the process diagram someone once made for onboarding. The full sequence.
Opening the laptop. Switching tabs. Copying a number from one tool into another. Asking a colleague a question the product should have answered. Checking the spreadsheet because the system might be wrong.
A process is usually the official story. A workflow is what actually happens when the official story meets tools, people, exceptions, habits, and time.
Most of those workflows were never designed. They accreted.
A tool was added because it solved one problem. Another tool was added because the first did not solve the second. A spreadsheet showed up to glue them together. A chat channel was created so the people running the spreadsheet could agree on its rules. Someone wrote a checklist. Someone else stopped trusting the checklist and made their own.
Each addition made local sense. The sequence as a whole became the residue of those additions.
The people who live inside that sequence rarely have language for it. They will tell you a single tool is annoying, or a single colleague is slow, or a single approval is broken. What they will not always say — because nothing in their day frames it — is that the entire shape of the work was never authored.
There is no document for it, no owner for it, no single product that admits it is responsible for it. The workflow is negotiated daily by the people forced to keep it alive. The friction is everyone’s and no one’s.
This is the unclaimed territory. It is large.
Wrappers vs authors
A wrapper takes the existing workflow and makes it nicer to look at. Cleaner UI. Better empty states. A smarter inbox view of the same notifications. A more polished dashboard over the same waiting. The user is still doing the same work. The work just hurts a little less.
An author asks why the workflow exists in that shape and rebuilds it. Authoring starts from the work the user is trying to do — not from the screens that already exist around the work — and asks what the shortest honest path through it would be.
Sometimes the answer is a different product. Sometimes it is the same product with three steps removed and two of them folded into the system. Sometimes it is a product that did not exist, because no existing tool was willing to take the shape the work actually wanted.
Wrapper work is crowded. Every tool category has products competing on polish over the same underlying workflow. Each generation of wrapper is a little better than the last, and almost all of them age into being compared against another wrapper.
Authorship is harder to copy because it changes the work the user has to do. Most ambitious teams are still making wrappers and calling it strategy.
The teams that pick a workflow and rebuild it from the ground up may look strange at first, because they are not optimizing the category’s familiar surfaces. They are questioning the sequence those surfaces protect.
The cheap version of this distinction is “feature versus platform” or “thin versus thick.” That misses the point. A wrapper can be deep. An author can ship a small thing first. The difference is not size. It is whether the thing being shaped is the workflow itself or the surface on top of it.
The workflow author changes the comparison. The user is no longer asking which product wraps the old sequence better. The user is asking why the old sequence existed at all.
Example: wrapping invoice review versus authoring it
Take invoice processing.
A company receives invoices by email. Someone opens an inbox, downloads the PDF, checks the sender, finds the right template, copies line items into a table, checks the amounts, maps descriptions to activity codes, flags uncertain rows, asks a colleague for missing information, waits, corrects the data, exports the result, and archives the invoice.
There may already be a product around this. A wrapper improves the existing sequence.
It gives the inbox a cleaner UI. It adds status badges. It makes the PDF preview nicer. It improves the table editing experience. It adds filters. It lets the user search. It makes the process less ugly.
That is useful, but the workflow is mostly unchanged.
The user still carries the context. The user still decides which invoices need attention. The user still checks every row because the system has not earned trust. The user still asks the same colleague for the same missing mapping. The user still performs defensive work because the product is not safe enough to rely on.
An author looks at the workflow differently. The incoming email becomes a structured work item. The system identifies the sender, extracts the line items, and marks uncertain fields clearly. Known mappings apply automatically, while low-confidence rows stay staged for review. The PDF appears where visual verification matters. Corrections are remembered but inspectable. Exceptions route to the right person with context attached. Export happens only when confidence, validation, and approval have reached the threshold the organization requires.
The screen may still include an inbox, a table, and a PDF preview. But those screens now orbit a different workflow.
The product is no longer asking the user to operate a sequence of tools. It is authoring the work around trigger, context, confidence, review, correction, and export.
That is the difference. The wrapper makes the old process tolerable. The author changes what the process is. The before-and-after is not cosmetic.
Before:
- open the email
- download the PDF
- identify the vendor
- copy line items
- map descriptions
- check amounts
- ask for missing context
- wait
- correct the table
- export
After:
- invoice arrives as a structured work item
- known fields are extracted and validated
- uncertain fields are staged for review
- exceptions are routed with context
- approved data exports when trust conditions are met
The authored workflow has fewer steps, but that is not the real point. The real point is that the remaining steps are different kinds of work.
The human is no longer carrying context between tools. The human is judging uncertainty, exceptions, and accountability.
What an author looks at
The questions an author asks before reaching for any visual tool are about the shape of the work, not the shape of the product.
Trigger
Where does the work actually start? Not where the user lands in the product. Where the work begins.
Usually that is somewhere else: an email, a meeting, a customer complaint, a legal deadline, or a thought someone writes down before it disappears.
The product that captures the trigger captures the workflow. A product that waits until the user opens it may already be late.
Context
What does the user already know when the work starts? What should the system know on their behalf?
Most products force the user to re-enter context the system could have carried forward. That re-entry is workflow tax.
The customer ID, the last decision, the related document, and the reason this case is different from the previous one. Context is not background information. It is the material the work is made from.
A workflow author asks which context should travel with the work, and which context the product keeps making the user carry by hand.
Decision points
Where does the user have to choose, and what is the choice actually about?
Many “decisions” a product asks for are not real decisions. The user always picks the same answer for the same reason, and the system is refusing to learn it. Other decisions look small but carry real consequence, taste, accountability, or risk.
A workflow author separates those. The first kind can often become a default, suggestion, or automation. The second kind should stay visible and meaningfully human.
The question is not “can this be automated?” The question is “what kind of decision is this?”
Handoffs
Where does the work move from one person, tool, system, or surface to another?
Handoffs are where workflows leak.
Names get retyped. Decisions get re-explained. State gets dropped. The person receiving the work has to reconstruct the story before they can continue it.
A weak handoff transfers a task. A strong handoff transfers context. A workflow author treats handoffs as product material, not organizational inconvenience.
Repetition
What does the user do often enough that the system should notice the pattern?
Repetition is the system’s invitation to learn.
The same vendor gets mapped to the same category. The same meeting type needs the same preparation. The same document always routes to the same reviewer. The same user always changes the same phrase in the same kind of draft.
Ignoring repetition leaves leverage on the table. But repetition is not automatically permission.
A workflow author asks what pattern the system can safely learn, how confident it is, and how the user can correct it when the pattern stops being true.
Bottlenecks
Where does the work wait?
On approvals, missing documents, overnight syncs, or a person who is not sure they are allowed to decide.
Bottlenecks are not always bad. Some exist for good reasons. They protect quality, accountability, compliance, or judgment.
The author’s job is to know which bottlenecks exist on purpose and which ones exist by accident.
Removing the wrong bottleneck is not progress. It is damage disguised as speed.
System assistance
Which steps could the system safely prepare or complete? Not which steps would feel impressive to automate. Which steps would safely save the user time.
Assistance only works when the system can show its work, recover from mistakes, and stay within the authority it has earned. Without that structure, help becomes work the user has to supervise.
The author is not looking for places where the system could act. The author is looking for places where the system has earned the right to act.
Human control
Which steps must stay in the user’s hands no matter how cheap automation gets?
These are the decisions that carry consequence, taste, responsibility, relationship, or accountability. The work that defines what the user is actually for.
The point of workflow authorship is not to remove the human. It is to remove the work that prevents the human from doing the part only they should do.
A product that automates the wrong thing makes the user smaller. A product that authors the workflow well gives the user back to the work that matters.
A canvas with these eight slots, filled honestly, looks nothing like a feature spec. It looks like a portrait of the work. The product that follows from it usually does not look like any product currently in that category.
Why workflow authorship fails
Workflow authorship sounds cleaner than it feels inside an organization.
The old workflow usually has owners. The inbox belongs to one team. The approval rule belongs to another. The export belongs to finance. The exception path belongs to operations. The customer feels one workflow, but the company funds five surfaces.
That is why many teams keep shipping wrappers. A wrapper fits the budget line. It improves the surface one team already owns. It does not require a fight about who owns the trigger, which handoff can disappear, whose metric gets worse for a quarter, or which compliance step is protection and which is habit.
Sometimes the wrapper is the honest move. A team may not have permission to change the workflow. Regulation may require a step to remain visible. A partner system may be too brittle to absorb more context. A customer may need a gradual transition because the old sequence is tied to training, audit, or legal accountability.
The author does not pretend those constraints are fake. The author names them. Then the author decides whether the current work can reshape the workflow, prepare the ground for reshaping it later, or only make the existing sequence less costly without lying about what has changed.
Workflow authorship fails when nobody is willing to own the whole path. It succeeds when someone can hold the path as one piece of product material, even while the organization still experiences it as fragments.
Why authorship matters
The honest constraints above are real. Inside them, two forces are still running in the author's favor, and both compound over time.
As more steps inside any workflow become automatable, the leverage of the person who decides which steps should exist at all goes up, not down. When production work becomes more assisted, the question does not stop at “can this step be built well?” It reaches “should this step exist, and what system would have to carry it responsibly?” That question is the author’s question.
The other force is that wrappers cap out at the workflow’s existing ceiling. They can polish the work, but they cannot raise it.
A wrapper for a ten-step workflow is a ten-step workflow with better screens.
An author can ship a five-step workflow that does the same job. Once that exists, the wrapper has nothing meaningful left to wrap.
Workflow authorship rewards patience. The first version of an authored workflow is rarely as polished as the leading wrapper in its category. It is doing harder work: convincing the user that the shape of the work itself can change.
For a while, it may feel unfamiliar. Then the old sequence starts to feel wasteful.
Once the user feels that shift, the wrapper is no longer the relevant comparison. The relevant comparison is the unauthored sequence the user used to live inside and the authored one they live inside now.
Wrappers do not compete in that comparison. They were never invited.
Framework
Workflow Authorship Canvas
A canvas for redesigning a workflow rather than wrapping it in better UI.
01 — Trigger
Where does the work actually begin, before the product is opened?
The trigger often lives outside the product. Capturing it changes the product’s position in the workflow.
02 — Context
What does the user already know, and what should the system know on their behalf?
Context that does not travel with the work becomes tax the user pays repeatedly.
03 — Decision points
Where does the user make a real choice, and where is the product asking for a choice it should learn, default, or prepare?
Not every choice deserves to stay a choice.
Not every choice should disappear.
04 — Handoffs
Where does work move between people, tools, systems, or surfaces?
A strong handoff transfers context, not just responsibility.
05 — Repetition
What happens often enough that the system should notice the pattern?
Repetition reveals leverage, but it does not automatically grant permission to automate.
06 — Bottlenecks
Where does the work wait, and is the waiting intentional or accidental?
Some bottlenecks protect quality. Others only preserve a broken sequence.
07 — System assistance
Which steps could the system safely prepare, suggest, classify, summarize, automate, or route?
The question is not what the system can do. The question is what the system can be trusted to do.
08 — Human control
Which decisions must remain visibly and meaningfully in human hands?
The best workflow gives the human more responsibility for judgment, not more responsibility for administration.
A filled canvas should not look like a feature spec. It should look like a portrait of the work.
Workflow Authorship Canvas
A canvas for redesigning a workflow rather than wrapping it in better UI.
Where does the work actually begin, before the product is opened?
What does the user already know, and what should the system know on their behalf?
Where does the user make a real choice, and where is the product asking for a choice it should learn, default, or prepare?
Where does work move between people, tools, systems, or surfaces?
What happens often enough that the system should notice the pattern?
Where does the work wait, and is the waiting intentional or accidental?
Which steps could the system safely prepare, suggest, classify, summarize, automate, or route?
Which decisions must remain visibly and meaningfully in human hands?
Workflow shape for the workflow you sketched
Commit the artifact this chapter produced. The portfolio strip in Chapter 11 reads back what you have written here.
Taste as Operational Judgment
That is where taste stops being a matter of style and becomes operational judgment.