PROCESS

Here is How to Build

Design

Sub

One job, stated as a result

A part that is cut clean and placed well still has to do something. Its function is its job in the whole: what it is there to achieve. And how that job is stated decides a great deal, because the same part can be described in two ways: by what it does or by what it produces, and only one of them tells you whether the part is working.

A part's function is the result it produces, not the activities it performs. Described by its activities (take the details, request the charge, retry if it fails), a part has no finish line. The list can grow without limit, every new activity looks like part of the job, and nobody can say when the part is done or whether it did what it was for. Described by its result, the same part has a clear end: a state of affairs that is true when the part has finished and was not true before. Activities are how a part gets there; the result is where it is going. Define the part by where it is going, and the activities become its own business, free to change as long as the result arrives.

So the test for any part's function is a pair of questions. What is true when this part is done? And could you check it? If you can name the done-state and someone could verify it without asking the people inside the part, the function is stated well. If all you can name are activities, or a done-state no one could check ("payment handled", "account dealt with"), the function is still vague, and a vague function is one nobody can be held to. A function stated as a checkable result gives the part a finish line, and gives everyone else something they can rely on.

The highest possible standard is to state every part's function as one result rather than a list of activities: a done-state that is true when the part has finished and that anyone could check, so the part has a clear finish line and everyone around it knows exactly what it delivers.

Key Takeaway: A part's function is the result it produces, not the activities it performs. Described by activities, a part has no finish line: the list grows, and nobody can say when it is done or whether it worked. Described by its result, it has a clear end: a state that is true when it has finished. The test is two questions: what is true when this part is done, and could you check it? If you can only name activities, or a done-state no one could check, the function is still vague, and a vague function is one nobody can be held to.

State each part's function as one checkable result: what is true when it is done, not what it does along the way.

MarvinPro · PROCESS · Here is How to Build · Design · Sub · Discipline 5: Function · Section: One job, stated as a result

MarvinPro | October 2026

marvinpro.com

Serving the whole

A part's function does not stand alone. Every part sits inside something larger, and its function is there to serve that larger part's result. So the functions of the parts are not a set of separate jobs that happen to sit near each other; they are the pieces of one larger result, and they have to fit together into it. A part's function is right not only when it is clear, but when it is the piece of the whole that the whole needs from it.

Fitted together, the parts' functions should make exactly the larger part's result: nothing missing, nothing twice, nothing extra. Each of those has its own failure. A gap is a piece of the result that no part's function includes. It falls between the parts, and either does not happen or happens only by accident, when someone notices and steps in. An overlap is a piece of the result that two parts both claim. It is done twice, or worse, each part assumes the other did it and it is done by neither. And a leftover is a part whose function serves nothing in the result at all: it runs, it costs, someone maintains it, and the whole would be no worse without it, often a check or a step that once had a reason and outlived it.

So the test is to add the parts up. Write down each part's result, put them side by side, and ask whether together they make exactly the larger part's result. Where something in the larger result appears in no part's function, there is a gap: give it to one part. Where something appears in two, there is an overlap: give it to one and take it from the other. Where a part's result appears nowhere in the larger result, there is a leftover: find out what it was for, and if nothing, remove it. Each piece of the result should belong to exactly one function.

The highest possible standard is to fit every part's function to the result of the larger part it serves, so that the parts' results together make exactly that result, every piece belonging to exactly one part, with no gaps falling between them, no overlaps claimed twice, and no leftovers serving nothing.

Key Takeaway: Every part's function serves the result of the larger part it sits in, and together the parts' functions should make exactly that result. Three failures: a gap (a piece of the result no part includes, so it falls between them and happens only by accident), an overlap (a piece two parts both claim, so it is done twice or by neither), and a leftover (a part whose function serves nothing in the result, often a step that outlived its reason). The test is to add the parts' results up and compare them with the whole's: give each gap to one part, take each overlap from all but one, and remove each leftover.

Fit the parts' functions together so they make exactly the whole's result: no gaps, no overlaps, no leftovers.

MarvinPro · PROCESS · Here is How to Build · Design · Sub · Discipline 5: Function · Section: Serving the whole

MarvinPro | October 2026

marvinpro.com

Answering for the function

A function stated as a result does one more thing: it says what the part answers for. The part, and whoever owns it, is accountable for its result. Not for performing a set of activities, but for delivering the done-state, every time. If the result arrives, the part has done its job, however it got there. If the result does not arrive, the part has not done its job, however busy it was.

That division is what gives a part its freedom. Because the part answers for its result and not its activities, what happens inside is its own business. It can change how it works, add a step, remove one, replace a tool, rearrange its insides entirely, and nothing around it needs to know, as long as the result still arrives. The parts around it rely on the result, not on the inside. This is what makes a part something you can own apart and change on its own, the promise a sub-process made in the second discipline of this volume. That promise is kept by the function: a part with a clear result can be handed to one owner and changed freely, because everyone knows what must hold no matter what changes.

Blur the function and accountability blurs with it. A part with no clear result cannot be held to anything, so when something goes wrong no one can say whether this part failed. A part defined by its activities ties everyone around it to its internals, so every change inside becomes a change for everyone. And where functions overlap, two parts answer for the same thing, which in practice means neither does. A clear function is what lets a part be trusted from the outside and left alone on the inside.

The highest possible standard is for every part to answer for its result: accountable for delivering the done-state every time, free to change how it gets there as long as the result holds, so that the parts around it rely only on its result and it can be owned apart and changed on its own.

Key Takeaway: A function stated as a result says what the part answers for: the part, and its owner, are accountable for delivering the done-state every time, not for performing activities. That is what gives the part its freedom: it can change anything inside as long as the result still arrives, because the parts around it rely on the result, not the inside. This keeps the promise from the second discipline: a part that can be owned apart and changed on its own. Blur the function and accountability blurs: no one can say whether the part failed, every inside change becomes everyone's change, and where functions overlap, neither part truly answers.

Each part answers for its result, and is free to change everything inside as long as that result holds.

MarvinPro · PROCESS · Here is How to Build · Design · Sub · Discipline 5: Function · Section: Answering for the function

MarvinPro | October 2026

marvinpro.com

A real example

Return to activate and state its parts' functions as results. Settling the payment is a name; its function is its done-state: a payment settled, or definitively declined. Stating it that way shows something the name hid. A decline is not a loose end or an exception that somebody else will tidy up; it is one of the two results this part must produce cleanly. Opening the account has its own result: an account open for this customer. Recording the entitlement has its own: the entitlement recorded against that account. Each is a state anyone could check without asking how the part got there.

Now add them up. Activate's result is a paid customer with an open account, entitled to what they bought. The three functions together should make exactly that. But suppose that, when a payment is declined, nobody tells the customer. Settling records the decline and stops; the account is never opened, so nothing after it runs. Telling the customer falls in a gap between the parts, and happens only when the customer writes in to ask what went wrong. The fix is to give it to one function: settling's result becomes a payment settled, or declined and the customer told. Suppose too that both settling the payment and opening the account send the customer a confirmation, so every new customer receives two. That is an overlap: the same piece of the result claimed twice. The fix is to give the confirmation to one part, opening the account, and take it from the other.

And see what the clear function buys. The person fixing the retry logic inside settling the payment can change how many times it retries, in what order, and with which provider message, without telling anyone, because the parts around it rely on one thing only: its result, a payment settled, or declined and the customer told. As long as that result holds, everything inside settling is free to change. The function is what the part answers for; the inside is its own.

Activation's parts each produce one checkable result, which together make exactly activation's result: the gap filled by giving the decline notice to settling, the overlap removed by giving the confirmation to opening the account alone.

MarvinPro · PROCESS · Here is How to Build · Design · Sub · Discipline 5: Function · A real example

MarvinPro | October 2026

marvinpro.com

Function

A part that is cut clean and placed well still has to do something, and its function is the result it produces, not the activities it performs. Described by activities, a part has no finish line: the list grows, and nobody can say when it is done or whether it worked. Described by its result, it has a clear end. Ask of every part what is true when it is done, and whether someone could check it; if you can only name activities, or a done-state no one could verify, the function is still too vague to hold anyone to.

Every part's function serves the result of the larger part it sits in, and together the parts' functions should make exactly that result. A gap is a piece of the result no part includes, so it falls between them; an overlap is a piece two parts both claim, so it is done twice or by neither; a leftover is a part whose function serves nothing in the result. Add the parts' results up, compare them with the whole's, and give every piece of the result to exactly one function.

And a function stated as a result says what the part answers for. The part, and its owner, are accountable for delivering the done-state every time, and free to change anything inside as long as the result still arrives, because the parts around it rely on the result and not on the inside. That is what makes a part ownable apart and changeable on its own. Blur the function and accountability blurs with it.

So the discipline is this: give every part one checkable result, fit the results together so they make exactly the whole's result with no gaps, overlaps or leftovers, and hold each part to its result while leaving its inside to it. Done this way, placed parts become working parts: each one known by what it delivers, trusted from the outside, and free on the inside. What remains is how those results pass from one part to the next, the work of the seams within.

Give every part one checkable result, fit the results together into exactly the whole's result, and let each part answer for its result while its inside stays its own.

MarvinPro · PROCESS · Here is How to Build · Design · Sub · Discipline 5: Function · Chapter Outcome

MarvinPro | October 2026

marvinpro.com

Think Simple.