From Spreadsheet to Street: MVP, Pilot Launch and Operational Readiness

#A pilot is not a small launch

Article 10 produced a condition-aware operating calendar for Amsterdam Layers — Context & Neighbourhood Discovery. That still does not mean the product should simply be placed online and allowed to “learn in market.” Several important claims remain unresolved: visitors have not yet been recruited directly, the guide fee is still an assumption, the default route needs an accompanied field/accessibility audit, German and French remain research segments rather than validated products, willingness to pay is unresolved, local stakeholder acceptance is incomplete and the weekday schedule has no product-level demand history.

Article 11 therefore treats the MVP as a controlled learning system. The goal is not to produce flattering reviews from a handful of friendly guests. The goal is to expose the concept to reality while preserving enough control to know what failed, what succeeded and what must change.

The operating rule is simple: define success before the first pilot guest arrives. The Pilot Success Thresholds are therefore frozen before execution. A team cannot lower a threshold after a weak result merely to declare success.

#The pilot baseline: what is fixed and what remains experimental

The baseline remains the Article 07 concept: a live small-group contextual walking experience, English-first, normally Plantage→Oosterpark, 110–135 minutes, with a maximum service capacity of eight guests. The core dependency remains a qualified guide plus public realm and live transport/disruption information. Mandatory paid admissions, tastings, private transport and an app remain outside scope.

Article 11 freezes those elements as the pilot scope baseline. In PMP/CAPM terms, this is enough project discipline to stop scope creep: if the pilot suddenly adds a canal cruise, food tasting and proprietary app, the team is no longer testing the approved concept. Any material change to promise, capacity, route architecture, price logic or compliance basis enters the change log and needs Product Owner approval.

That does not make the pilot bureaucratic. Lean logic points in the opposite direction: use the smallest controlled batch that can expose defects, keep optional dependencies out of the critical path and make problems visible quickly. One clean learning loop is more useful than twenty inconsistent departures.

#Success thresholds come before pilot results

The threshold set combines earlier product requirements with explicit launch gates. Some are must-pass controls: zero critical legal blockers, zero preventable severe safety/regulatory incidents, 100% completion of the departure-day control process and no unsupported accessibility claim. Others are service targets: route completion ≥95%, context usefulness ≥4.5/5, comprehension recall ≥80%, physical-effort expectation accuracy ≥90%, interaction ≥4.5/5 and meeting-point failure below 2%.

Commercial success is deliberately separated from research learning. Article 08 showed that the current €55 midpoint can produce positive contribution in some direct-led loads but remains fragile in OTA-heavy conditions. A research-funded departure may therefore run below the commercial minimum only when management explicitly budgets it as research. It cannot be counted as evidence that the recurring product is viable. For scale, paid departures must show non-negative contribution using actual supplier, fee, channel and refund data.

These percentages are pilot decision thresholds, not claims of statistical precision. A tiny sample can reveal severe defects and directional evidence; it cannot establish population-level conversion rates with confidence. Article 12 must preserve sample size and uncertainty when it analyses outcomes.

#Pilot Plan: six phases, each with an exit gate

Each phase has an entry condition, evidence output and exit gate.

The Pilot Plan uses six phases rather than a single launch date.

Scroll horizontally to read every column. Keyboard: focus the table, then use the arrow keys.

What to learn: Read each row across to connect Phase with Purpose, Gate. Compare the rows to identify the relevant phase for your situation; use the accompanying section to interpret the result.

The initial paid evidence target is six departures, but the team is explicitly prohibited from forcing weak departures merely to hit a quota. If demand does not materialise, that is evidence. Likewise, one or two research sessions can be used before the paid MVP, but their economics remain outside the commercial proof set.

#Every practical unresolved assumption becomes a test

Unresolved assumptions become named tests rather than background caveats.

The Experiment Backlog creates twelve named tests. This is the core bridge from Articles 01–10 into street evidence.

H01 / E01 — context value: measure context usefulness, three-layer recall and the visitor's explanation of why the experience helped. H02 / E02 — group size: compare interaction and question participation across naturally occurring occupancy bands without deliberately overcrowding the product. H03 / E03 — geography: complete the accompanied field audit and then track route completion, pain points and recovery use.

H04 / E04 — language: recruit German and French target visitors for native-language preference/concept research. English reviews are not translated and relabelled as non-English VOC. H05 / E05 and E09 — economics and willingness to pay: replace the assumed guide fee and price logic with actual quotes, paid conversion and realized contribution. H06 / E06 — stakeholder conditions: combine structured local/guide debriefs with complaint and obstruction monitoring.

The assumption register is equally explicit. A02, the ability to recruit relevant visitors, becomes a two-channel recruitment experiment. A03, supplier feasibility, becomes a written quote/availability test. A04, route feasibility, becomes the accompanied field/accessibility audit. A05, positive destination contribution, becomes a local-impact/complaint and stakeholder review rather than a sustainability slogan.

Article 08's cancellation/no-show assumptions and Article 10's weekday demand assumption also become experiments. If practical evidence cannot be collected during this pilot, the item remains unresolved; it is not marked “validated by operations.”

#RACI: accountability must survive a busy departure day

The RACI assigns one accountable role to each critical work item. The exact people may change, but the accountability structure should not become ambiguous.

The Product Owner owns scope and final change decisions. The Pilot Lead is accountable for the operating pilot and GO/NO-GO process. The Guide Lead is responsible for route delivery, needs checks and live service decisions within the approved playbook. The Operations Lead controls route, accessibility and disruption readiness. The Commercial Lead owns supplier/channel/economic evidence. The Research Lead owns experiments and VOC integrity. Compliance/safety is consulted or responsible where the risk demands it.

This is where RACI is useful. It is not used to create a complicated organisation chart for an eight-person tour. It is used to answer questions such as: who can cancel a departure, who approves a route change, who owns a missing guide quote, and who closes a recurring defect?

#Launch Readiness Checklist: GO is a controlled state

The Launch Readiness Checklist contains seventeen controls. Several are already ready by design; several remain genuinely open because Article 11 cannot manufacture external completion.

Before a public paid pilot, the project still needs a named qualified guide with actual terms, the required Amsterdam guided-tour exemption where the regulated Centre route triggers it, appropriate insurance verification, the physical route/accessibility audit, compliant direct-booking/customer-information controls and actual commercial inputs. Those remain OPEN.

A departure receives GO only when all MUST items are closed and the Article 10 day-of-operation state is GREEN or controlled AMBER. A RED state overrides sales pressure. This is the same principle used in mature service operations: availability is not the same as permission to operate.

#Daily Operations Pack: standard work without turning the guide into a robot

Standard work protects safety, comparability and service recovery without scripting the guide.

The Daily Operations Pack is the pilot's lightweight SOP. It contains fourteen controls from T-24h through the next review.

At T-24h, the team checks load/channel economics, KNMI/weather and event context, route/transit disruption, guide status, permits and declared customer adjustments. At T-3h, the guide repeats the route/weather/transit check and signs the final GREEN/AMBER/RED decision. At the start, actual headcount, start time and the needs/resident-respect briefing are recorded. During delivery, any route change, safety issue, service recovery or destination incident receives an exception record.

At close, the team records route completion, basic comprehension and onward-value signals. By end of day, bookings, attendance, cancellations, no-shows, realised revenue, supplier costs, channel fees and contribution are reconciled against the same departure ID.

This is where Lean standard work and Six Sigma-style critical-to-quality thinking are useful. The product does not need a fake “Six Sigma level” from six departures. It does need clear defect definitions: missed start because instructions failed, unplanned route abandonment, regulatory breach, missing cost data, accessibility claim failure, or service-recovery case. Repeated defects move from incident logging into root-cause/CAPA review.

#Use ITIL 4 where service operations actually need it

ITIL terminology is useful only when it sharpens decisions. A one-off tram diversion is an incident: restore the customer experience using an approved variant. If the same route failure repeats, it becomes a problem: identify the underlying cause rather than repeatedly recovering. A proposed permanent route, capacity or booking-rule change enters change control so the team can compare the new version with the baseline.

The continual-improvement idea is equally practical: after each departure, capture what happened; at the scheduled review, decide which issue deserves action; implement the smallest controlled improvement; then measure again. The pilot should not rewrite the SOP after every comment because that would destroy comparability.

#Lean and CAPM/PMP controls protect learning quality

A lightweight work breakdown structure is enough: compliance and supplier readiness, route readiness, booking/customer communication, guide/content readiness, research/data readiness, departure delivery and closeout. Each has an owner and exit criterion. Risks and issues are not mixed: a possible guide cancellation is a risk; the guide cancelling tomorrow's departure is an issue requiring action.

Lean adds two important constraints. First, batch size stays small so defects are discovered before scale. Second, work that does not serve the customer job or the research decision is removed. The pilot does not need a sophisticated dashboard, branded merchandise or multiple languages merely to look launch-ready. It needs reliable evidence.

#What data must exist after every paid departure?

Every paid departure should produce one linked record containing at least:

• departure ID, date, start time, route variant and RAG state;
• available capacity, booked guests, attended guests and channel;
• realised retail price, discounts, refunds, commission/payment fees, guide fee and other actual costs;
• cancellation and no-show classification;
• start/finish time, route completion and any recovery/incident;
• customer feedback linked to Article 04 themes and Article 07 KPIs;
• experiment IDs applicable to that departure;
• resident/public-space or accessibility issues;
• approved changes compared with the baseline.

Without that linkage, Article 12 could easily compare customer scores from one departure with economics from another and call the result “product performance.” The pilot data model therefore matters as much as the itinerary.

#Readiness is not the same as launch approval

Article 11 produces a complete pilot operating design, but the current project is not yet authorised for an immediate public paid departure. The open items are external or field-based: actual guide quote/availability, the required permit position for the departure, insurance confirmation, booking implementation, accompanied route/accessibility audit and the first live GO/NO-GO check.

That is an acceptable Article 11 outcome. A readiness checklist that always says READY before those facts exist would be theatre.

The correct current status is: READY FOR CONTROLLED PRE-LAUNCH TESTING; PUBLIC PAID PILOT CONDITIONAL ON CHECKLIST CLOSURE.

#What Article 12 will receive

Article 12 should not receive a story about how the pilot “felt.” It should receive a frozen departure-level dataset, experiment outcomes, VOC, route/incident logs, channel economics, cancellation/no-show data, stakeholder/accessibility evidence and the change register. It can then decide whether to SCALE, ITERATE, REPOSITION or STOP using evidence gathered against thresholds defined before the pilot.

Until those departures actually occur, H01–H06 and A02–A05 retain their current evidence status. Article 11 defines the tests; it does not pretend to have run them.

#Human + AI pilot-control prompts

These prompts help reviewers find missing controls and compare structured pilot evidence. A named human owner retains launch, safety, compliance and change authority.

ROLE
Act as a tourism pilot-readiness reviewer.

DECISION/TASK
Determine whether one proposed Amsterdam Layers departure is authorised to proceed.

INPUT
[Paste the readiness checklist, route audit, guide roster, permit and insurance evidence, booking data, Article 10 RAG state and open risks.]

METHOD
Check every MUST item. Separate missing evidence, an open risk and an active issue. Trace each blocker to an owner and closure evidence.

CONSTRAINTS
Do not infer permits, insurance, accessibility performance, supplier terms or live operating conditions. RED overrides demand or revenue pressure.

OUTPUT
Return GO, CONTROLLED AMBER or NO-GO; list blockers, required controls, accountable owner, deadline and approval evidence.

ROLE
Act as a tourism product-operations analyst.

DECISION/TASK
Review one completed pilot departure against the frozen scope, success thresholds and assigned experiments.

INPUT
[Paste the linked departure record, financial actuals, feedback, route and incident log, experiment IDs and approved changes.]

METHOD
Compare actual evidence with the pre-launch threshold definition. Separate research-funded activity from recurring commercial performance. Identify defects and unresolved assumptions.

CONSTRAINTS
Preserve sample size and uncertainty. Do not turn directional evidence into a validated market claim or rewrite a threshold after seeing the result.

OUTPUT
Return observed outcomes, threshold status, defects, service recovery, experiment learning, required CAPA or change control and next test.

Decision Gate 6: PRE-LAUNCH CONTROL SYSTEM COMPLETE — PUBLIC PAID PILOT REQUIRES CHECKLIST CLOSURE.

#Article 11 output

The MVP is now operationally specified as a controlled experiment rather than a miniature full launch. The project has a staged Pilot Plan, clear accountability, a blocker-based Launch Readiness Checklist, a hypothesis-linked Experiment Backlog, explicit success thresholds and a departure-level Daily Operations Pack.

Current pilot state: PRE-LAUNCH CONTROL SYSTEM COMPLETE · PUBLIC PAID PILOT NOT YET AUTHORISED.