Minimum Effective Dose

A team can learn a great deal without getting any closer to deciding what to do.

Benchmarking databases might be useful. It does not answer whether anyone needs the report. Interviews might establish that people dislike their current process. They do not establish that our integration can obtain the required data before Monday morning.

I care about decision-relevant information: what we need to know to choose the next action.

Dan North’s Deliberate Discovery frames engineering work around identifying the ignorance constraining progress and deliberately reducing it.¹ Wes Kao uses minimum effective dose for a closely related business idea: do enough work to obtain the insight needed for the decision.²

Before starting, I want three things to be clear: what we do not know, which decision that prevents us from making, and what we would do differently depending on the result.

For the report, we might be deciding whether to invest in recurring delivery. The first useful evidence is whether the customer can use the information, in time, to make the decision they described.

An enthusiastic response is not the same as use. Use is not the same as a better outcome. One customer’s result is not proof of a market. Each observation justifies a different next step.

If every possible result leads to “continue building the original plan,” we are not really running an experiment.

A project can become an inventory of everything that might eventually be required. Every customer, exception, dependency, failure mode, and future extension gets a place in the design before we have established a useful path through any of them.

I think of positive space as the part of the problem where we have evidence that useful action is possible: a concrete route from a need to an outcome under conditions we understand.

For the Monday report, that route might be one data source, one agreed calculation, one recipient, and one decision. It gives us somewhere to stand. We can then ask what prevents that path from being dependable, repeatable, or useful to someone else.

A failed attempt can locate the path too. If the customer receives correct information and does nothing differently, perhaps the report answers the wrong question, arrives too late, or reaches someone who cannot act.

Positive space is not positive results. It is evidence about where useful action is possible.

Once a path produces a useful result, what prevents it from doing so reliably or at the required scale?

Goldratt’s Theory of Constraints gives a useful rule for choosing the next intervention: improve what limits the system’s objective rather than whichever component is easiest to optimize.⁴

Suppose the report proves useful but repeatedly arrives after the customer’s decision. Tracing the path suggests that corrections and a shared review queue cause the delay.

The next dose could be a bounded trial with clearer input requirements and checks that prevent avoidable rework before review. That uses the reviewer’s existing capacity better and changes the work upstream. It does not justify a reporting platform or a faster query.

Then measure the path again. Did usable reports reach decisions sooner without worsening errors or delaying other necessary work? Moving this report to the front of the queue may simply transfer the delay.

A steel thread makes the path observable. Constraint thinking helps choose where to intervene. Minimum effective dose keeps that intervention proportionate to what the evidence can justify.

Adding custom schedules to the first report is not just another task. It postpones the value question and commits more effort to an assumption the report was supposed to test.

Martin Fowler’s account of YAGNI includes the carrying cost of speculative capability: even before it is useful, its complexity makes later changes harder.⁵ Here there is another cost too: speculative scope delays the evidence that could redirect the work altogether.

I use a simple test for proposed additions:

Does this help us answer the question in front of us, or is it something we expect to need after that question is answered?

Correctness checks may be necessary to interpret the result. Access controls may be necessary to run the trial responsibly. Instrumentation may be necessary to know whether anything changed. Those belong in the minimum when the experiment depends on them.

Multiple export formats, a configuration interface, and support for other departments need a different argument. “We will probably need them eventually” is not enough.

The boundary protects the question long enough to answer it. It should not protect the original solution from what we discover.

Kent Beck’s “make it run, make it right, make it fast” is useful to me as an ordering rule, especially when paired with small slices and short feedback cycles.⁶

For the report, establish one useful path. Make it dependable enough for the commitment being tested. Then invest where the evidence says improvement matters.

I think of this as keeping the machinery movable while the requirements are still moving. In software, we can bolt an unsettled answer down with a public interface, a deep dependency chain, or a general-purpose framework. In a business, we can do it with a service promise, a specialized team, or a contract built around the current process.

The implementation may be small while the commitment is large.

That is why the dose includes the cost of changing our minds. A narrow boundary around an uncertain integration, tests around the behavior we need, and enough observability to understand failures can all make the next change cheaper. They may be part of the minimum rather than overhead to remove.

Reducing breadth does not reduce the standard. If the result arrives too late to be useful, performance is already a requirement. If the trial handles sensitive data or moves money, the relevant safeguards belong in the trial.

The engineering path might end with a correct response. The business path usually does not.

If we are testing a paid service, we may also need to know whether the customer understands the offer, can adopt it, receives the promised benefit, and will pay enough to justify delivering it. Those are separate uncertainties.

For an initial trial, an existing sales process, a straightforward agreement, a standard invoice, and explicit manual work may be enough. There is no reason to build a new commercial system around the first customer.

But count the manual work. If every report needs an hour of intervention, the trial has demonstrated delivery with an hour of labor attached. Hiding that effort does not establish good economics.

Minimum effective dose becomes local cost-cutting when complexity is merely moved into Operations or onto the customer. A system has not become simpler because the obligation changed owners.

Manual delivery may still be the cheapest credible way to test usefulness. Once delivery is understood and recurring, automation may become the smaller continuing burden. The dose changes as the evidence changes.

Minimum effective dose does not mean permanently doing less. It means refusing to make every possibility a prerequisite for progress.

Once the original outcome is achieved, additional investment may be worthwhile. Greater reliability, lower operating cost, or a broader offering can justify substantial work. But that work needs an argument of its own.

I want a steel thread through the problem, not a miniature version of every system we might eventually need. Enough of the real path to obtain credible evidence. Enough care to meet the standard of the commitment. Little enough speculative machinery that the answer can still change what we do.

Start narrow. Finish the path. Expand for a reason.