A request such as "we need an approval screen" is rarely enough for sound business software development. Before the interface, the team needs to understand what is approved, under which rule, who decides, what follows a rejection, and how an error is corrected. A sustainable product emerges when the team models real work and decisions first, then builds one complete, testable flow.
That order does not slow down software development. It reduces the chance of quickly delivering a feature that works only in the ideal case while users still manage exceptions in spreadsheets, emails, or verbal arrangements.
A workshop and a process diagram are useful starting points, but they often describe how work should happen. A real task shows how people actually reach a decision: where they look for data, whom they ask for confirmation, which exceptions they check, and what they record outside the system.
Process discovery should therefore not be reduced to a list of desired screens. Combine:
The distinction between a business rule and a habit created by an old tool matters. If an employee manually copies a value from one system to another, that does not necessarily mean copying should be automated. The value may need to be available in the right place, the source may need an integration, or the rule requiring copying may no longer be explainable.
This check prevents business software from turning a limitation of an old process into a permanent feature. It also gives the team a concrete basis for decisions: which task matters, which data is missing, and which person holds responsibility at each point in the flow.
A business object has a lifecycle. A quotation can be a draft, sent, accepted, rejected, or expired. A work order can be waiting for materials, in progress, stopped, or completed. These labels are not merely interface displays. They determine what is allowed, what must be recorded, and what the next action means.
For each state, it is useful to define:
This model moves logic out of the interface and into a visible form. Without it, rules can easily remain hidden in buttons, messages, or unwritten user instructions. The consequence often appears only when the process changes: it is unclear why an action cannot be performed, who can resolve a blockage, or which data another integration may use.
Clear states and transitions also make connections across operations easier. For example, an order waiting for materials may have a different effect on planning, procurement, and reporting than an order that is actually stopped. When definitions are clear, connected operations do not depend on different interpretations of the same status.
The first version does not need every screen. It should enable one complete flow through the interface, business rules, data, and a report or another verifiable output. This vertical slice lets a user perform a real task and lets the team see where the process model remains incomplete.
In the approval example, a minimum complete flow might look like this:
This is not simply a smaller version of the final solution. It tests important assumptions. The team learns early whether an authority is missing, whether a term is understood differently, whether an error can be corrected without bypassing the system, and whether the report answers the question the business owner actually needs answered.
Ten partially built screens can create an impression of progress, but they do not show whether work passes through the system. A vertical slice exposes the whole chain to real questions before scope and cost expand.
A backlog item such as "add a new filter" locks in a solution before explaining the need. It does not say who has the problem, during which task, why the current flow fails, or how the team will verify that the change helped.
A stronger item can describe:
For example, a sales administrator cannot quickly find customers with expired quotations while preparing calls, so they export data manually. The expectation is that a view of open quotations by date will remove the export and shorten preparation. The team can then propose a filter, a saved view, a report, or a different flow. The solution is not decided before the problem is understood.
This approach to product development leaves room for technical assessment and business decisions. It also makes later verification easier: is the change being used, has the manual export actually disappeared, and has a new obstacle emerged elsewhere in the process?
A feature is not complete merely because it works with full and correct data. Business processes include incomplete entries, incorrect decisions, changing permissions, and data arriving from other systems. Sustainable business software should therefore provide at least:
Each special exception increases the surface area for testing, documentation, and future change. That does not mean exceptions should always be rejected. Some are necessary because of a real business obligation or important risk. Before building one, however, it is worth asking whether the business value is clear and whether the process can be simplified first.
The decision not to build something is part of responsible software development. Temporary compatibility with an old flow should also have an owner and an end date. If the new flow proves that it works, the old flow should be retired. Otherwise, both flows continue to create code, support work, and uncertainty.
The number of delivered features says little about whether the product supports work. A more useful question is whether a user can complete a real task without unnecessary workarounds.
Depending on the process, the team can observe:
These signals do not replace business judgement. They help prevent discussion from relying only on impressions or the number of requests. A feature that nobody uses is not neutral: it increases code, tests, documentation, and the number of future decisions.
The development team needs to see the consequence of code in day-to-day work. The business owner needs to understand the technical cost of a special rule, integration, or parallel flow. When those perspectives meet regularly, software develops as a product rather than as a series of disconnected orders.
Start by selecting one frequent, important, and sufficiently bounded task. Gather real examples, define states, transitions, and responsibilities, and agree on what will show that the new flow is useful. Then plan a vertical slice that includes a rule, data, a user action, and a verifiable outcome.
When the process involves ERP, manufacturing, accounting, or several connected modules, ERP and process screening can help separate real business rules from limitations of the current tool before development scope becomes a commitment. ORKA connects this sequence through process mapping, flow design, development, and verification of real work.