The Journey Map in the Lobby

Diagnosis: the artifact was delivered to the organization, not built with it, and it describes experience without assigning ownership or a decision. A 47-touchpoint, six-persona map is a description of everything, which functions as a priority list of nothing. No product team can act on it Monday morning, and none of its rows carries a name, a metric, or a date. Framing it in the lobby is the tell: it became a symbol of the program rather than a tool inside the work.

Seven-week plan, sequenced to the planning cycle:

1. Collapse to one journey, one segment, one measurable gap. New SMB customer, bank-connection to first payroll run, 38% non-completion. Everything else is deferred. A map that covers 47 touchpoints competes with the backlog; a map that covers one journey with a 38% failure rate beats it.
2. Re-derive the map with the people who own the screens. Two half-day sessions: onboarding PM, support lead, tax ops, and 5-6 recent customers who abandoned and 5-6 who completed. Abandoners are the group the original study almost certainly under-sampled, and they are where the design insight is.
3. Attach evidence to each stage. Funnel drop-off counts, ticket volume by topic, and verbatim quotes placed at the exact step. The map's authority inside a product org comes from the data attached to it, not from its visual quality.
4. Land in the backlog with a shaped bet, not a theme. Frame it as a proposal the VP of Product can accept: 'Reduce first-run failure by X by changing the tax-form decision from a form to a guided default; here's the prototype and the metric.' Tying to an already-committed roadmap item (e.g., the onboarding rework that is already funded) is not compromise - it's the only route to shipping inside seven weeks.

What to stop doing: no new personas, no additional touchpoints, no map refresh for its own sake.

Start from the mechanism, not the screen. Three ticket clusters - which tax forms apply, what if the first run is wrong, how to undo a mistake - are all fear of irreversible error expressed in different vocabulary. The drop-off is not friction in the flow; it is the customer refusing to press a button they believe they cannot take back.

Interventions, ordered by cost to test:

1. Reversibility messaging at the moment of the first run. Explicit, plain-language: 'You can edit or void this payroll until [date]. Nothing is filed before then.' Cheap, testable in a week with a copy variant, and directly addresses all three ticket clusters. Test A/B on completion rate, not on satisfaction.
2. Tax-form decision as a guided default rather than a form. Most SMBs in the same situation have the same answer. Replace the question with a recommended answer plus a 'why' expander and a path to a human. This is the highest-leverage structural change and the one that needs real design work.
3. Pre-first-run confidence check. A short, plain-language summary of exactly what will happen when the customer presses the button - who gets paid, what gets filed, what it costs. Reduces the imagined downside.
4. Human safety net surfaced, not buried. A named person or a scheduled call offered at the drop-off step. This contradicts 'live in a day' positioning less than it appears - it supports it.

Prototype and test: clickable prototype with 8-10 abandoners first (qualitative, days), then a live A/B on the guidance and reversibility copy with completion as the primary metric and support-ticket volume as the guardrail. Do not test all four at once; if the guided tax default is the mechanism, you want to be able to attribute the lift.

Treat both constraints as design inputs, not obstacles.

On 'live in a day': the promise is not inherently wrong - it is a commitment about time-to-value that the current onboarding cannot meet because it front-loads tax configuration and back-loads confidence. Redesign around it: get the customer to a completed first payroll in a day by making the first run small, reversible, and defaulted, and defer the tax complexity that does not need to be resolved before the first run. Then measure time-to-first-payroll as the shared metric, which gives sales and product the same scoreboard. If the promise truly cannot be met for a segment (multi-state, contractors), say so with data and propose a differentiated promise rather than letting sales discover it in the field. That is a strategy conversation, and the journey evidence is what earns the right to have it.

On the roadmap constraint: do not fight the funding model in week seven of a quarter. Instead:

• Identify the committed roadmap items that touch onboarding and bind the design work to them. Most roadmaps have an onboarding item; it is usually scoped as a technical migration or a UI refresh, and the design evidence can reframe its success criteria without changing its slot.
• Where no slot exists, run the cheap tests (copy, reversibility messaging, guided default) as experiments inside the existing release cadence. Experiments don't need roadmap slots; they need a metric and a week.

Longer term: the reason the map failed is that it had no entry point into the funding process. The durable fix is to make journey health a standing input to quarterly planning - one page, with the funnel and the three ticket clusters on it, presented every cycle. That is how design becomes infrastructure rather than an artifact in the lobby.