The first workflow in a software product should be small enough to understand in detail and important enough that somebody wants it handled differently. That sounds simple until a founder gathers a list of requests. Every department has a favorite irritation, and every request can expand into a platform. A practical selection method keeps the decision tied to work the team can actually observe and improve.
This guide uses an illustrative service business choosing between three workflows: preparing installation requests, approving supplier invoices and arranging staff leave. The business is invented for the example. The method is a working tool a founder can adapt with a prospective customer. Its purpose is to choose the next investigation, then the smallest useful product boundary.
Start with recent events
Ask each team to walk through a recent completed example. Avoid starting with a general description of how the process ought to work. A real event has people, timing, missing details and a finish. Ask when it began, what triggered it, where the information came from and what the next person needed. Note the places where the account becomes vague, because those are good places to investigate further.
For an installation request, the coordinator may open a customer email, copy details into a scheduling system and ask for an equipment image. The apparent task is entering data. The actual responsibility is deciding whether a technician can be scheduled. A product that makes the entry faster but leaves that decision unclear may miss the useful opportunity. Write down the responsibility in a sentence before describing a feature.
The GOV.UK observation guidance describes examining tasks in everyday settings. Use it as a basis for watching the work on the team’s own equipment, with permission and appropriate handling of their information. Treat the observations as evidence about this setting. They give the founder a more precise starting point than a ranked list of feature requests.
Record three selection factors
Use frequency, failure cost and access as separate factors. Frequency asks how often the work happens. Failure cost asks what happens when it goes wrong: extra coordination, a missed appointment, an incorrect payment or a delayed decision. Access asks whether the founder can observe users, inspect representative records and test a change with the people involved. Keep the evidence alongside each judgment.
A simple rating can help structure the conversation, but the number should never replace the explanation. An installation request might happen daily and cause rescheduling when incomplete. An invoice process might happen weekly with high sensitivity around access. Leave requests might be frequent but already handled adequately by an existing tool. The most attractive first workflow is the one with a meaningful problem and a practical path to learning.
Use access as a real constraint
A severe problem can still be a poor first product if the team cannot reach the people doing the work. A sponsor may be enthusiastic while the operating team has no time for research or trials. Establish who can arrange observation, provide examples and take part in a pilot. Ask whether the team can discuss ordinary mistakes and show the systems surrounding the proposed product.
For the example business, installation coordination may have an available manager and two willing coordinators. Invoice approval may require access the sponsor cannot arrange yet. That does not settle the long-term opportunity, but it makes installation coordination the stronger next investigation. The founder can learn from real use and build a repeatable route to a first customer rather than wait for a broad permission problem to resolve.
Draw the boundary around one decision
A workflow boundary should have a start, a finish and a person who knows when it is complete. For installation requests, the start could be receipt of a customer’s proposed job. The finish could be a record ready for scheduling. The first version might exclude technician routing, invoicing and equipment purchasing. Those systems still matter, so record the connections without taking responsibility for all of them.
Then list the information needed to make the readiness decision. The coordinator may require a site location, equipment model, contact person and access restrictions. For each item, identify who supplies it and who checks it. This creates the first data model and the first set of interface questions. It also shows which missing details deserve a clear recovery route instead of another free-form email.
Examine the exception that happens every week
Teams often describe an ideal sequence and treat exceptions as an implementation detail. Ask for the most recent request that had to be returned. Was the information wrong, incomplete or simply unavailable? Did someone make a judgment call? A frequent exception can be part of the normal product responsibility. Build an explicit state for it and decide who acts next.
For example, the equipment model might be unreadable in a customer photograph. The coordinator needs to request another image without losing the location and contact details already supplied. A useful first product could preserve the request, show exactly what is missing and notify the right person when the correction arrives. That is a more testable outcome than a general promise to improve collaboration.
Choose a measure before choosing the interface
Select one measure that reflects the selected responsibility. A count of requests completed without another information exchange could be useful for this example. So could the elapsed time from receipt to ready, interpreted alongside the mix of requests. Define the start and finish consistently, then inspect several current examples to understand the baseline. Keep manual work visible rather than counting only what happens inside the new software.
The Service Standard guidance on success measures pairs metrics with user research. A founder can take the same practical approach: track the chosen outcome and talk to the people responsible for it. A faster measured process is not useful if the coordinator now spends an unrecorded hour correcting the output. Ask what changed in the rest of the work.
Make a small prototype earn its next step
The first prototype can be a realistic request form and a coordinator’s review screen. It should let a participant complete one representative request and recover one incomplete request. Use believable data, including ordinary omissions. Watch what the participant understands without explanation. Record the questions they ask, the information they seek and the points where they return to an existing tool.
After each session, distinguish observations from proposed fixes. “The coordinator could not identify the next action” is an observation. “Add a dashboard” is one possible response. Compare several responses before choosing the smallest change that clarifies the handoff. Keep the product boundary visible so a single test does not expand into rebuilding the entire department’s software.
Finish with a selection memo
Write one page explaining the chosen workflow, the evidence behind it and the next test. Include the user, the start and finish, the operating owner, the common exception and the measure. List the access already arranged and the systems that remain outside scope. Name the condition that would make the team stop or choose a different workflow, such as an unavailable source of essential information.
For the example, the memo might choose installation requests because incomplete submissions create recurring coordination and the team can test a better handoff. The next step is to observe three recent requests, including one that stalled, with the coordinator who handled them. A company introduced as NV2 can begin with that precise responsibility and carry a settled identity as its product grows beyond the first workflow.