From Process to Product: What to Define Before Writing Code

In our experience, most of what a software project costs is decided before the first line of code: in what was defined, what was assumed and what nobody asked. A business process doesn’t become a product because someone described it. It becomes one when someone decides which problem it solves, for whom, under which rules, with which data — and what stays out. This guide walks through the ten definitions that make that conversion possible.

Defining isn’t writing a requirements document

A feature list answers “what should the system do?” It’s a necessary question, but it comes too late: it assumes you already know which problem you’re solving, how the work happens today and what won’t be touched. When those answers are missing, the list grows without judgment and every feature looks equally important.

Defining is something else: it’s making the decisions that let a feature list make sense. And almost all of them are made by looking at the process, not at a screen.

Understand: the problem, success and the people

1. The problem, without the solution

Write the problem in two sentences without mentioning software. “We need a supplier portal” is a solution; “purchase orders take five days to approve and nobody knows which step they’re stuck in” is a problem. The trap: describing the system you’re imagining and calling it the problem.

2. How you’ll know it worked

One metric, with its current value and a target. If nobody can say which number would change, the project has no way to end well — only to end. The trap: measuring delivery (“the system is live”) instead of the outcome.

3. Who’s involved

Who uses the system, who feeds it, who depends on what it produces, and who owns the outcome. Each actor needs to do something different. The trap: designing only for whoever asked for the system, then meeting the people nobody consulted in the first week of use.

Map: the process, its rules and its exceptions

4. The process as it works today

Not the process in the manual — the one that actually happens. Include the informal shortcuts, the spreadsheets someone maintains on their own, and the messages that stand in for a step in the system. The trap: mapping with the people who manage the process instead of the people who run it.

5. The business rules

Who approves what, within which limits, in which order, by which criteria. Each rule with its source — policy, regulation or habit — and an owner. The trap: turning into code a habit nobody ever decided to keep.

6. The exceptions

The case that “almost never happens” and happens every week. Exceptions define a system’s real complexity far more than the normal flow does. The trap: building the happy path and handling exceptions by hand, forever.

Connect: data and integrations

7. The data

What information comes in, what goes out, what gets stored and who can see it. Flag personal, financial or regulated data from the start. The trap: assuming the data exists and is reliable because “it’s in the system.”

8. The integrations

Which systems the product has to talk to, in which direction — read, write or both — and who owns the other side. The trap: treating each integration as a technical detail, when it’s usually the most uncertain part of the cost and the timeline.

Bound: constraints and scope

9. The constraints

What can’t move: deadlines, budget, regulation, existing technology, available people. Written down, so nobody discovers them in a status meeting. The trap: leaving implicit the constraint everyone knows — until someone new doesn’t.

10. What won’t be built yet

The most valuable definition, and the one least often written down. Every deferred idea, with its reason and the condition that would bring it back.

Why “what won’t be built yet” gets its own chapter

Every project accumulates reasonable ideas: one more report, one more integration, a mobile app “while we’re at it.” None of them is bad. Together they turn a first version of a few weeks into a project that never quite ships.

Writing down what stays out has three effects. Scope stops growing by accumulation. Ideas don’t get lost: they’re recorded with the condition that would trigger them. And the conversation shifts from “why didn’t we include this?” to “has the condition for including it been met?”

A good first version isn’t the one with the most features. It’s the one that solves the problem defined in step 1 and moves the metric in step 2.

An illustrative example

A distributor (an illustrative example, not a client) wants to “digitize purchase orders.” Defining it surfaces three things that weren’t in the original idea:

• An exception: urgent purchases get approved by phone and recorded afterward. If the system doesn’t account for that, people will keep using the phone and the system will stay incomplete.
• A rule without an owner: the approval limit by amount isn’t written in any policy; the purchasing manager applies it from memory.
• An uncertain integration: the accounting system allows reading suppliers but not writing orders. That changes the design and the cost.

And one scope decision: the portal where suppliers check their payments stays out of the first version, with a written condition for revisiting it — once orders have run in the new system for three months. None of these definitions required writing code. All of them would have changed the project if they’d been discovered halfway through.

Common mistakes

• Starting with screens before understanding the process they’re meant to support.
• Asking for a quote on an idea, with no written problem, metric or scope.
• Mapping the ideal process instead of the one that happens.
• Leaving exceptions “for later.”
• Underestimating integrations because “the other system has an API.”
• Not naming an owner for the outcome — or naming someone with no time to decide.
• Not writing down what stays out, and discovering the real scope in the last meeting.