Design Outcomes Weekly reflections on the real-time work of supporting a design org.
One Journey Map, Three Tracks

One Journey Map, Three Tracks

Why this matters

How a simple onboarding journey map became three planning tracks right before annual planning.

One Journey Map, Three Tracks How a deliberately simple onboarding journey map for group practices became three planning tracks a few weeks before annual planning. How a simple onboarding journey map became three planning tracks right before annual planning. Build the journey map from the people who onboard customers by hand, mark friction in one color, then split findings into tracks by purpose (packaging, scale, time to value) so each can be prioritized on its own.

How a deliberately simple onboarding journey map for group practices became three planning tracks a few weeks before annual planning.

A design lead on our team finalized a journey map this week for group practices getting onboarded, and the first thing he said about it was that it isn’t a true journey map. He kept it simple on purpose. It came out of a handful of calls with sales, customer success, and the onboarding specialists who walk new practices through setup by hand, run with a partner from the onboarding side who’s been in every one of those calls. That sourcing is the first move worth stealing. The people who onboard customers manually already know where the product falls short, because they’re the ones filling the gap.

The structure is a managed path, where practices get a specialist and hands-on training, and a set of self-serve paths where they don’t. Everything in red is friction: a place where setup becomes a problem for the specialist or for the practice on its own. It’s a pretty big list under that column, and it’s platform-wide. Nothing about it is scoped to the squad that made it, which is what makes it useful to everyone else.

A journey map earns its keep by what it feeds. This one fed 3 planning tracks a month before annual planning.

He was clear that squads won’t get much from the overall journey. They’ll get the bucketed issues, not a feature list. The value is in the split he made downstream. The map now feeds 3 tracks, each with a different purpose. A packaging question, which belongs to the people who shape the offer. A scalability question, which is about the systems holding up as practices grow. And a time-to-value question, which is about onboarding and setup: cutting the days between starting an account and seeing a first client, including getting teammates in, intake documents built, clients added, locations, calendar settings, service codes, and rates per clinician.

Splitting the findings that way means each track can be prioritized on its own terms. Packaging questions go to the people who own the offer. Scalability goes to the platform conversation. Time to value becomes a near-term lever, mostly in-product guidance and cleaner setup workflows, that doesn’t have to wait on the other two. And it landed a few weeks before annual planning, which is the tactic. A map that arrives after the roadmap is set is a nice artifact. A map that arrives before it is an argument.

The last thing I’ll credit him for is restraint. It would have been easy to make this a polished, end-to-end journey with personas and emotion curves. He made a working document with a red column and 3 exits, and it’s already shaping the asks going into planning.

Filed under TB Toolbox — Frameworks you can steal.