After Understanding the Work, What Do We Decide?

Why this record exists

Building SaaS for business operations requires a deep understanding of the customer’s work.

Who decides what, when, and based on which information? What is the standard flow? Where are the exceptions, and what differs between customers? We conduct interviews, draw workflows, and organize requirements and cases. It is better to understand the work before building than to build without that knowledge. There is no question about that.

As the investigation continues, a precise map eventually takes shape.

• The current workflow
• The people involved and their responsibilities
• Differences between customers
• Conditions for decisions
• Exceptions and rework
• Forms and systems currently in use

Even then, the specification and sequence of the product may remain difficult to decide. The documents describe reality correctly. Every requirement has a basis. Yet when the result is viewed as one product, it is unclear where that product is going.

The map may not be wrong. The destination may never have been chosen.

The map does not determine the destination

Suppose an investigation of three customers reveals the following.

• Customer A performs work a, b, and c
• Customer B performs work a, d, and e
• Customer C performs work b, c, and f

This gives us a view of how the work is distributed. But several questions remain.

• Should the product include everything from a through f?
• Can a and b be treated as shared work?
• Should c be supported through operations rather than the product?
• Will building d first also help us serve the next customer?
• Are e and f exceptions, or evidence of another trunk we have not yet seen?
• Whose work will this release make possible from beginning to end?

These questions do not remain because the investigation was insufficient. Even if every detail were known, the observed facts alone would not produce a single answer.

What is needed is not only more evidence, but a choice about which customers and work to place at the center, and what the product will turn into a shared form.

Record 001 examined the need for a model of the work that can place unknown requests, rather than a list of requirements. But even after the model exists, the product has not yet been decided. A model is a structure for understanding reality, not the destination of the product itself.

A product is not a copy of the current workflow

Reproducing the current workflow precisely does not necessarily produce the right product.

Suppose a piece of work currently happens as follows.

A person checks the details
Enters them into a spreadsheet
Copies them into another system
A manager makes a decision
The result is sent by email

Replacing this flow directly with screens and features would produce a system that fits the current operation. But entering data into a spreadsheet and copying it into another system may be steps created by the limitations of earlier tools. The check and the decision might also be tasks that the same person could perform at the same time.

The current workflow mixes domain rules that must be preserved with detours created by past constraints. Reproduce both without distinction and the product will not improve the work; it will preserve the detours as well.

There are at least three choices when shaping a product.

1. Keep — Preserve meaningful human judgment and controls required by the work
2. Replace — Reduce the effort required to achieve the same result, such as for transcription or reconciliation
3. Remove — Eliminate steps that the new system makes unnecessary

Observing the current work does not decide which option to choose. The choice requires an intention about what to preserve and what to change.

Everything can be right without making the whole right

When development follows only the map, each observed piece of work becomes a requirement.

The customer really performs it. It has been explained as operationally necessary. It was requested during a sales conversation. Therefore, the requirement is implemented. Each decision is reasonable.

But adding reasonable parts together does not necessarily produce a coherent whole.

A feature covering the first half of work a, a setting for an exception in work d, and a screen showing only the result of work f may all enter the same release. Every feature has a basis, but that does not mean a particular user can accomplish one goal from beginning to end.

Priority then becomes a comparison of which request matters more. The prior question—what work should be changed, and into what state—has not been answered.

Moving from the right map to the wrong place does not always mean the map was misread. It can also happen when no destination is chosen and the roads drawn on the map are simply followed one after another.

What to decide after understanding the work

Between understanding the work and defining product requirements lie product choices.

Record 002 examined the process of turning business strategy into product choices. Understanding the work provides the material for that conversion. Once the material is assembled, at least the following choices remain.

Which change to create

Do not stop at describing the current workflow. Define what will change after the product is used.

• Will it reduce the time required?
• Will it make the quality of decisions more consistent?
• Will it make knowledge held by individuals shareable?
• Will it eliminate the work itself?
• Will it make previously impossible work possible?

Even when the same work is in scope, a different intended change requires a different product.

How much responsibility to take

A product does not need to handle every part of the target work from the beginning.

It can record information and make it visible. It can present the information needed for a decision. It can automate processing governed by fixed rules. It can handle standard cases and return only exceptions to people. It can operate autonomously within one limited scope.

These are not rungs on a simple maturity ladder. When the consequence of an error is large, retaining human approval may be the better choice. When the work is infrequent and a person can complete it quickly, choosing not to automate may also be rational.

The question is not “How advanced should we make it?” but How much of this work will the product take responsibility for now?

In what order to move closer

Even when the final destination is the same, there can be several routes toward it.

First bring the work into one place where a person can complete it, then automate routine processing. Start by recording decisions, and add decision support after enough cases have accumulated. Narrow the target customer, make the complete workflow viable, and expand to exceptions afterward.

Sequence is not merely the division of a delivery date. It is the design of stages that each deliver value, produce learning, and open the next set of options.

What to leave on the map

Not every piece of work discovered through research has to enter the product.

It may be important but outside the current scope. It may remain a customer-specific operation. It may belong to an external system. It may be preserved only as information for a future decision. We can acknowledge that the work exists while choosing not to include it in the product.

Removing something from the map and declining to choose it as a destination are different things. The work is not discarded from our understanding; it is understood and then placed outside the product boundary.

Do not make the product small in the wrong place

“It is an MVP, so we should cut the features down” is a common explanation. Starting small has value. But cutting a screen or process halfway through does not create a small product.

Suppose a complete piece of work consists of input, processing, review, and completion. If the product supports only input and processing, leaving the user unable to proceed through review, the user cannot receive the value.

By contrast, the product can handle input and processing, return review safely to a person, and still allow the work to be completed. Its automation scope is narrow, but the complete value remains viable. The team can learn from that use and support or automate review next.

What matters is not the number of features, but whether a viable fallback exists beyond the point where the product stops.

To make it small, do not cut the flow of value halfway through. Reduce the scope of responsibility the product takes on.

Where does the product stop, and where do people or existing operations take over? The burden created at that boundary, and the impact when it fails, are important inputs when deciding the initial product.

The more we know, the harder it becomes to choose

Deeper knowledge of the work reveals more exceptions.

“This customer has another approval step.” “Under this condition, the process runs in reverse.” “Once a year, a different form is used.” As knowledge grows, so does the set of requirements that appear necessary.

Without a decision criterion, the depth of understanding becomes the size of the specification.

Understand the work
Discover an exception
Add a requirement
Investigate in more detail
Discover still more exceptions

This failure does not result from poor research. On the contrary, the more seriously the investigation is conducted, the easier it is to enter this cycle.

Deep knowledge of the work expands the options. Product strategy reduces them. With only one side, the product either drifts away from reality or becomes unable to choose anything.

AI expands the map

AI is reducing the cost of organizing information.

Interview summaries, workflow drafts, differences between customers, requirement classification, searches for similar cases, and first drafts of specifications can increasingly be produced faster than when people process everything from the beginning. The result still depends on the quality and context of the input.

AI can also produce options and propose priorities. The division is therefore not as simple as “AI organizes, and only people decide.”

Even so, the work of accepting a proposed choice as our product remains.

• Which facts will carry more weight?
• Which customer will be placed at the center?
• Which uncertainty will be tested first?
• Which exceptions will not be addressed?
• Who bears the consequence when the choice fails?
• Which direction will the organization commit to?

If AI organizes one hundred cases, those one hundred cases do not all become the product. The faster the map expands, the greater the burden of deciding where not to go.

Even if business-process analysis becomes ten times faster, without product choices we merely arrive ten times faster at a state in which we know a great deal but still have not decided what to build.

What loses value in the age of AI is not understanding the work. It is treating the collection and organization of information as a substitute for decision-making.

Tests for whether we have stopped at the map

Three questions help reveal whether understanding the work has been mistaken for deciding the product.

1. The change test — Can we explain what the product will change, rather than only describe the current workflow?
2. The boundary test — Can we name work that we understand but will not address in the product, and explain why?
3. The arrival test — In the next release, who will be able to complete which work, and how far?

If the first cannot be answered, we have stopped after describing the current location. If the second cannot be answered, everything on the map has become a destination. If the third cannot be answered, we may be moving, but we have not decided where we will arrive.

In short

• A precise understanding of the work is necessary, but it does not determine the product to build
• A model of the work is a map for understanding reality, not the destination of the product itself
• The current workflow mixes rules that must be preserved with detours created by past constraints
• After understanding the work, choices remain about the intended change, scope of responsibility, sequence, and exclusions
• An MVP should not cut the flow of value halfway through; it should reduce the scope of responsibility the product takes on
• As AI expands the map, the value of deciding where to go—and where not to go—rises

Following the work is indispensable for choosing a destination. But the product does not need to travel every road on the map.

Which road will we choose, which will we leave, and how much will the product take responsibility for? Product development begins after the work is understood.