Minimum Viable Process¶
Minimal workflow release — instantiates Minimum Viable Learning Release
Runs the smallest real version of a workflow that still does actual work, to reveal handoffs, exceptions, and throughput before formalizing it.
A Minimum Viable Process runs the smallest real version of a workflow that still does genuine work, so the operational structure — handoffs, role burden, exception patterns, throughput — becomes visible before the process is formalized, automated, or scaled. Its defining claim, and the line that separates it from its near-twin the Minimum Viable Product, is that the release unit is a process, not a product: success is not a user's uptake of an artifact but a documented picture of how work actually flows. What comes back is a learning record — where the queue built up, which case broke the happy path, how long each handoff really waited — read over a window of live operation. The mechanism exists because the true shape of a workflow is invisible on a whiteboard and only appears once real work runs through the smallest honest version of it.
Example¶
A factory wants a formal quality-escalation procedure across every production line. Instead of writing the full standard operating procedure up front, it runs a minimum viable version on one line for three weeks: when an operator flags a defect, a two-step handoff — operator to shift lead to quality engineer — with a single logged paper ticket. No software, no governance board, no rollout. Over the three weeks the team records every handoff: how long each ticket waited at each step, which defect types broke the two-step path and needed a fourth person, and how many tickets that one line actually generated. That learning record — not a survey of what people think would happen — reveals that most delay piles up at the shift-lead step, which reshapes the real procedure before a line of software is written.
How it works¶
- Cut the workflow to a coherent minimum. The smallest sequence of steps that still does real work end to end.
- Run it in the live operating context. One line, one team — actual work flows through it, not a tabletop rehearsal.
- Log the true flow. Record handoffs, waits, and exceptions as they happen, so the operational reality is captured rather than imagined.
- Read throughput over a window. Watch queue points, exception rates, and cycle time across a fixed run to locate where work actually stalls.
Tuning parameters¶
- Process-scope narrowness — how few steps you keep; too few and the pilot skips the hard handoffs, too many and learning arrives late.
- Work realism — live work versus a shadow run alongside the old process; live is truer but riskier.
- Record granularity — how finely each handoff and exception is logged; finer detail reveals more but can itself slow the work.
- Window length — long enough to see steady-state throughput and rare exceptions, short enough to decide.
- Automation restraint — deliberately keeping the pilot manual so the real flow and bottleneck are visible before tooling hides them.
When it helps, and when it misleads¶
Its strength is exposing the real operational structure — where work stalls, which exceptions matter, how much each role actually bears — before that structure is frozen into software or policy. Its failure mode is that a one-line, one-team pilot can hide the cross-team handoffs where the true bottleneck[n1] will move once the process scales, so the pilot's clean throughput does not survive the full rollout; over-instrumenting until the logging itself changes how people work is the mirror-image trap. The guarding discipline is to pick a segment that genuinely exercises the hard handoffs and to keep the record light enough that measuring the process does not distort it.
How it implements the components¶
minimum_viable_scope— cuts the workflow to the smallest coherent sequence that still does real work.real_context_release— runs in the live operating context, with actual work flowing through it rather than a simulation.measurement_window— a fixed run over which throughput, queues, and exception rates are read.learning_record— logs the true flow — handoffs, waits, exceptions — as the primary evidence the process design consumes.
Unlike its near-twin Minimum Viable Product, it names no product core_user_need, tests no viable_value_threshold, and reads no adoption learning_signal — that product-value trio is the MVP's business. This mechanism watches a workflow's internal flow, not a user's uptake of an artifact.
Related¶
- Instantiates: Minimum Viable Learning Release — the minimum viable process is the pattern applied to operations, where the release unit is a workflow rather than a product.
- Sibling mechanisms: Minimum Viable Product · Pilot Service · Concierge Test · Alpha Release · Limited Cohort Rollout · Small-Batch Policy Pilot · Feature-Flag Release
Editorial Notes¶
Form Classification¶
Form family: Experiment, Test & Rehearsal
Rationale: Minimum Viable Process operates as a bounded trial, probe, simulation, or rehearsal that generates evidence from performance because it runs the smallest real version of a workflow that still does actual work, to reveal handoffs, exceptions, and throughput before formalizing it.
Independent corroboration: The frozen evidence defines Minimum Viable Process as 'Runs the smallest real version of a workflow that still does actual work, to reveal handoffs, exceptions, and throughput before formalizing it', so its operative form is Experiment, Test & Rehearsal.
Nearest alternative: Protocol, Workflow & Routine — A real workflow sequence is enacted, but it is released in bounded scope specifically to generate evidence before formalization.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Innovation & Entrepreneurship
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Running the smallest real workflow that yields learning is a process-level adaptation of the lean-startup minimum viable product. Organization design contributes handoff, exception, and throughput analysis.
Related originating lineages:
- Organizational & Management Science — Retained as a formative lineage independently identified as primary: Releasing a minimally complete workflow to learn from real handoffs belongs to lean process management.
Review resolution: Harvard Business School's lean-startup case describes minimum viable products as tests of business hypotheses through real-world learning. The entry deliberately transfers that entrepreneurial logic from product to process, so it is marked as an encyclopedia synthesis. The alternates are retained only as formative or independently established origins, not because the mechanism can be applied there. origin_mode=cross_disciplinary_synthesis states the provenance relationship; domain_reach=multi_domain separately records breadth because independent established uses occur in several fields. confidence=high reflects the strength and specificity of the evidence; encyclopedia_synthesis=true because the entry deliberately composes those documented lineages into this exact artifact.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
- https://store.hbr.org/product/hypothesis-driven-entrepreneurship-the-lean-startup/812095 — Harvard Business School case material documents lean-startup hypothesis testing and minimum viable products.
Notes¶
The whole distinction from a Minimum Viable Product is the release unit: a product is something a user operates and adopts; a process is a flow of work a team runs. When the open question is "does this workflow actually hold together?" it is a minimum viable process; when it is "will users take up this thing?" it is an MVP. Choosing the wrong unit points the pilot's instrumentation at the wrong evidence.
[n1] The bottleneck, or constraint — from the Theory of Constraints (Goldratt): a workflow's throughput is governed by its single slowest step, and improvements anywhere else barely move the whole. A minimum viable process exists largely to find where that constraint actually sits before the process is scaled. ↩