- Who this helps
- Tourism product managers, experience designers and supplier teams.
- What you can do
- Turn research findings into a product requirements document and service blueprint with traceable requirements and feasibility checks.
#A concept is a chain of evidence, not a brainstorm
By Article 07, the project has enough evidence to become dangerous. There are attractive opportunity scores, customer-language themes, segment priorities and four strong geography corridors. This is exactly when teams often begin adding favourite features, combining everything that tested well and calling the result a signature experience.
I used a stricter rule: no feature enters the concept unless it can be traced backwards through Evidence → Insight → Requirement → Feature → KPI. If the chain breaks, the feature is either removed or labelled as an experiment. The commercial model also stays closed: Article 02 did not produce a broad comparable price set, and H05 remains untested. Article 07 can approve a concept for validation without approving its retail price, margin or channel strategy.
A feature enters the concept only when the evidence chain reaches a testable requirement and measurable acceptance criterion.
On small screens, scroll the diagram horizontally to read its labels.
#The evidence that is allowed into the room
Article 03 said INVESTIGATE, not “build the highest-scoring category.” Self-guided and walking were strong opportunity areas, while food remained interesting but operationally more dependent. Article 04 then gave the project a much more useful signal: visitors repeatedly value substantive context, guide knowledge, local discovery, low-friction navigation, a human pace and useful onward recommendations. Small-group interaction had supporting evidence, but the willingness to pay for it remained untested. Article 05 prioritised an English-speaking cultural city-break visitor for the first prototype, with German as Secondary research and French as a Test segment. Article 06 found four strong geography corridors and showed that Plantage→Oosterpark had an unusually strong balance of story density, dispersal, accessibility, transit and resident fit.
Those facts do not force one product. They do, however, narrow the design space. A canal-cruise concept would require ignoring the supply density identified in Article 02. A food-led signature would import supplier and dietary dependencies before H05 and A03 are ready. A pure self-guided product would throw away the strongest human-interaction signal from Article 04. The evidence therefore supports testing a live, small-group, modular contextual walking concept—with digital support only where it solves a traced problem rather than because an app sounds innovative.
#The working concept: Amsterdam Layers
The functional working name is Amsterdam Layers — Context & Neighbourhood Discovery. It is not a final brand. The core promise is: help visitors understand how Amsterdam became the city they are experiencing now, while discovering a lower-pressure neighbourhood arc and leaving with useful orientation for the rest of the stay.
The default pilot corridor is Plantage→Oosterpark. The standard architecture runs approximately 110–135 minutes including interpretation, with about 3.2 km of movement in the current planning model. The pilot capacity is capped at eight guests—not because eight has been commercially proven, but because Article 04 supports interaction, the number sits comfortably below Amsterdam's 15-person guided-tour ceiling, and the optional Hortus supplier module itself operates at a maximum of eight participants per guide. The capacity remains a test parameter for Article 08 and the pilot.
The concept is deliberately venue-light. Paid admissions can enrich the experience, but they cannot be required to keep the customer promise. If a greenhouse, museum or indoor partner becomes unavailable, the customer should still receive the same core job: context, discovery, orientation and a resilient route.
#Product Requirements Document
The Product Requirements Document contains fourteen governed requirements. The most important are not flashy features. They are controls.
| Requirement | Design consequence | KPI / acceptance |
|---|---|---|
| Substantive context | Every core module needs fact-checked interpretation and present-day relevance. | Context usefulness ≥4.5/5; recall ≥80% |
| Promise integrity | The route can flex, but the customer job cannot silently change. | Route completion ≥95% |
| Transparent effort | Distance, duration, surfaces, breaks and access limitations appear before booking. | Expectation accuracy ≥90% |
| Low arrival friction | Recognition cues, map, late-arrival rule and recovery contact are mandatory. | Meeting-point failure <2% |
| Operational resilience | Recovery, flex and transit-exit modules are part of the product, not emergency improvisation. | Variant-switch success ≥95% |
| Destination responsibility | Small-group conduct, moving interpretation and sensitive-stop rules are product requirements. | Regulatory breaches = 0 |
Scroll horizontally to read every column. Keyboard: focus the table, then use the arrow keys.
What to learn: Read each row across to connect Requirement with Design consequence, KPI / acceptance. Compare the rows to identify the relevant requirement for your situation; use the accompanying section to interpret the result.
One requirement is intentionally negative: no final price is approved here. That prevents a concept-design article from smuggling in commercial assumptions that belong in Article 08.
#Requirements Traceability Matrix
The Requirements Traceability Matrix is the main anti-preference control. For example, Article 04's meeting-point and navigation pain becomes the insight that arrival friction can destroy value before the experience starts. That becomes PRD-07, then the feature “pre-arrival start pack + recovery protocol,” then the KPI “meeting-point failure below 2%.”
Likewise, Article 06's five route variants do not become five products. They become one resilience feature: a variant playbook that preserves the same customer job under normal, peak-crowd, rain, accessibility and disruption conditions. The KPI is not “number of routes designed”; it is whether a route switch succeeds without breaking the promise.
This is also why food is not a core feature. Article 04 generated meaningful food requirements, but the current concept does not need food to satisfy its primary job. Adding tastings now would create supplier, dietary and value-for-money dependencies without improving the strongest traced requirement. Food remains a possible future module, not a signature-component entitlement.
#Supplier feasibility before concept lock
A concept should not be approved if its essential supply chain exists only on a slide. I therefore tested the minimum dependency set before locking the design.
Professional guide supply: Guidor, the Dutch National Guides Association, states that it has more than 160 affiliated qualified guides and provides services in more than twenty languages. Its public booking workflow can assign a guide from a submitted booking form, while clients can also contact individual guides for tariffs. English, German and French guides are visible in the current directory. This supports public feasibility, but it is not a confirmed quote or a guarantee of availability for a specific pilot date. Guidor and guide booking.
Transport and disruption: GVB's journey planner provides live journey information, planned diversions and accessibility options, including lift/escalator disruption status. That makes the transit-recovery requirement feasible, provided the guide performs a same-day check rather than relying on a static route sheet. GVB journey planner.
Optional Hortus module: Hortus Botanicus publishes a directly bookable group-tour structure: one-hour guided tours, maximum eight participants per guide, up to three tours simultaneously, Dutch/English/French/German delivery, at least two weeks' advance booking, and a published guide fee excluding admission. Its accessibility page also documents an accessible restroom and route limitations such as gravel/narrow paths. This is strong feasibility evidence for an optional module—but precisely because admission, timing and physical conditions add dependency, it remains optional. Hortus visitor and group information.
Indoor recovery: Eye confirms a free frequent ferry connection from Central Station, wheelchair access throughout the building, lifts and extensive opening hours. It is suitable as an alternate recovery/indoor anchor in the Article 06 rain/accessibility variants, but no commercial partnership is inferred. Eye visitor information.
The Supplier Feasibility Matrix therefore distinguishes publicly feasible from commercially contracted. The core concept passes because it can operate with a qualified guide, public realm and live transport information. Paid venues are enrichments, not single points of failure.
#What the concept actually contains
Only traced features survive the screen:
- Evidence-led live interpretation: a qualified guide connects history, present-day city life and place rather than delivering a landmark checklist.
- Local-texture modules: at least two less-obvious moments, selected because they support the story and destination fit—not because “hidden gems” sounds marketable.
- Pre-arrival start pack: start-point recognition, effort disclosure, weather/access note and late-arrival recovery.
- Eight-guest pilot capacity: a hypothesis for interaction quality, not a final unit-economics decision.
- Variant playbook: normal, peak, rain, candidate-accessible and disruption alternatives inherited from Article 06.
- Onward-value close: verified recommendations linked to the visitor's interests so the experience helps the rest of the stay.
- Language architecture: English prototype first; German and French remain research variants until native-language demand and delivery are tested.
Notably absent are headsets, tastings, private transport, mandatory admissions, souvenir packs, gamification and an app. None currently has a strong enough evidence chain to justify inclusion.
#Service Blueprint
The Service Blueprint converts the concept into an operating sequence from discovery to post-experience learning.
| Stage | Visitor sees | Backstage control |
|---|---|---|
| Discover / book | Clear promise, duration, effort, language and route style | Evidence-backed copy; no unsupported claims |
| Pre-arrival | Start pack and disruption/access update | Guide checks GVB, weather, route and optional supplier status |
| Meet / orient | Guide identity, plan and expectations | Needs check and resident-respect briefing |
| Experience | Anchor → context → local texture | Content QA, pace and moving-interpretation rules |
| Recover / flex | Rest, toilet, shelter or seamless route swap | Activate pre-approved variant without changing the customer job |
| Close | Recall, meaning and onward recommendations | Three-question comprehension check and verified recommendations |
| Post | Feedback and recovery if needed | Code VOC against Article 04 taxonomy; log route/supplier incidents |
Scroll horizontally to read every column. Keyboard: focus the table, then use the arrow keys.
What to learn: Read each row across to connect Stage with Visitor sees, Backstage control. Compare the rows to identify the relevant stage for your situation; use the accompanying section to interpret the result.
This blueprint exposes where the experience can fail before a pilot begins. A great guide cannot compensate for bad arrival instructions. A strong story cannot compensate for a route with no recovery. A rain variant is not useful if the operator checks the weather after guests arrive.
The blueprint connects promise, arrival, live interpretation, recovery and learning to their backstage operating controls.
On small screens, scroll the diagram horizontally to read its labels.
#KPIs are part of the design
The KPI layer prevents “signature” from becoming an aesthetic label. The prototype must be able to demonstrate context usefulness, comprehension, route completion, meeting-point reliability, interaction quality, expectation accuracy, recovery performance and destination compliance. These are product KPIs. Revenue, contribution margin, channel commission and break-even capacity remain Article 08 metrics.
The distinction matters. If the concept scores highly with guests but cannot reach target economics, H05 can still fail. If it operates smoothly but resident/stakeholder validation fails, H06 can still force redesign. Article 07 is therefore a concept gate, not permission to launch.
#What changed in the research registers
H03 moves to SUPPORTED_NEEDS_FIELD_VALIDATION. Article 06 provides evidence that value can plausibly be created outside the highest-pressure central corridors; Article 07 uses Plantage→Oosterpark as the default concept geography. But a physical accompanied route audit is still required.
H06 moves only to PARTIAL_RULES_VALIDATED_STAKEHOLDERS_OPEN. Official operating rules are now translated into the PRD, but no resident, local business or stakeholder acceptance has been invented.
A03 becomes PARTIAL_PUBLIC_FEASIBILITY_NEEDS_QUOTE: guide and optional venue sourcing pathways exist publicly, while actual pilot availability and commercial terms remain to be confirmed. A04 becomes PARTIAL_ARCHITECTURE_NEEDS_FIELD_AUDIT. A05 improves to SUPPORTED_DIRECTION_NEEDS_LOCAL_VALIDATION because the concept uses a dispersal-compatible corridor, but positive local contribution still requires real validation.
#What would force revision?
The concept should be revised if a qualified guide cannot be sourced at workable terms, if the accompanied route audit breaks the accessibility/resilience assumptions, if primary English visitors do not value the contextual job, if the eight-person format does not materially improve interaction, or if stakeholder review finds the selected route inappropriate. It should also be revised if Article 08 shows that the concept cannot reach viable economics without increasing group size or adding extractive dependencies that undermine the destination fit.
Concept approval permits commercial and field validation while price, contracts, route audit, language demand and stakeholder acceptance remain open.
On small screens, scroll the diagram horizontally to read its labels.
#Decision Gate 3
CONCEPT APPROVED.
That approval has a precise meaning: Amsterdam Layers — Context & Neighbourhood Discovery is approved as the evidence-traced concept to enter commercial and field validation. It is not launch approved. Price, margin, distribution, supplier contracts, physical route audit, German/French primary research and stakeholder acceptance remain open gates.
The strongest reason to approve is not that the concept sounds distinctive. It is that every core component can be traced to evidence, the minimum supplier architecture is publicly feasible, optional suppliers have been prevented from becoming single points of failure, and measurable acceptance criteria are already attached to the design.
Article 08 may still change the concept. That is the point of the next gate.
Connect this guide to your next step
Continue with related methods and the wider series.
- Series guideBuilding a Data-Driven Signature Tour.
Explore the complete series and its reading order.
- Related guideWhat Visitors Really Want: Mining Amsterdam Reviews and Voice of Customer
Part 04 of a 12-part Amsterdam tourism product-management case study: human-first review coding, AI-assisted VOC classification, independent validation, JTBD, Pareto and traceable product requirements.
- Related guideWho Should We Build It For? Source Markets, Segmentation, Language and Customer Jobs
Part 05 of a 12-part Amsterdam tourism product-management case study: source-market segmentation, language supply, connectivity and guide feasibility translated into Primary, Secondary and Test research segments.
Put this article into practice
- Translate verified customer needs into testable product requirements.
- Define inclusions, constraints and acceptance criteria.
- Check supplier, route, accessibility and operating dependencies.
- Keep unresolved assumptions visible before approving the concept.
Your next step
Carry the verified findings, assumptions and open questions into the next research stage.
Continue to Will the Product Make Money? Pricing, Distribution, Capacity and Tourism Unit Economics
