HealthEdge • Three Products, One Deadline

I didn't have the regulatory background to solve this by reading policy faster than anyone else. What I could do was make the whole problem visible. I needed to dust off a trusty format from my UX toolbox: build a service blueprint.

A service blueprint borrows its structure from theater. Imagine a stage, where everything on it is what the audience sees, and apply that to a member's journey over a year in healthcare. The member's actual experience is all on stage: moving through enrollment, an assessment, a claim, a hospital stay, an appeal. Supporting that member experience is backstage: the plans, the benefits, the systems, the staff, the handoffs, the data, all the machinery that has to work correctly and invisibly to hold the performance together. Nobody in the audience needs to know how the scenes get blocked. They just need the play to work.

I used a similar format and process to what I'd built for Wellframe's service blueprint: map a member's path through a full calendar year on one of these plans, then map everything running behind it to support that path. This time, what was running behind the line belonged to three separate HealthEdge products, each with its own users, its own front end, its own database, its own APIs, configured differently for every plan. They were built to work together but never pressure tested at this level of complexity, or this level of regulatory risk. They each needed to know their lines and get the data choreography right too.

Luckily I wasn't voluntold alone. I partnered with Jennifer V., HealthEdge's in-house regulatory expert, for the entire project. She grounded every question I didn't know enough to ask correctly. The process and the format for how we ran it were mine, carried over from Wellframe. The regulatory judgment was hers. We interviewed as a team.

“

He and I partnered on a Special Needs Plan (SNP) Service Blueprint that allowed our clients to visually trace a member's journey through a complicated series of interactions with their health plan. His leadership pushed our org's SMEs to work cross-functionally and collaboratively and broke down silos to inform product roadmap initiatives.

When I start a project with a knowledge gap, I need a delicate balance: enough authority over my own craft and the direction of the sessions, while deferring to the actual experts for their knowledge of the space. Posturing unearned knowledge in front of people who know the space better than I do doesn't work; they see through it fast, and it makes them guarded instead of open. Staying honestly curious, asking open-ended questions, and letting them be the authority, is what got them to tell me how things currently worked and where there might be gaps. Each SME really only knew their own piece, their own product's slice of it. Figuring out what was missing, wrong, or needed fixing didn't happen in any single interview. It came later, once everything was laid out side by side.

Getting three separate product lines, with three different leadership teams, to the same table wasn't smooth. None of this was something they were measured on, and every hour spent on it was an hour taken from projects they were actually accountable for. Getting people to engage at all, without feeling like I was there to expose gaps in their own knowledge, was the biggest point of friction. Objections were plentiful. Some didn't like the idea of sharing their thinking with a design director from a different business unit. Some seemed afraid I would expose a gap in what they were offering. A few tried to slow the project down because they hadn't been looped in, couldn't find the time, or didn't like what the early findings were starting to show. A surprise to me: there was less shared foundation across the SMEs, even within the same business unit, than you'd expect. My approach stayed the same every time: take the objection, find a solution backed by data, move forward. Repeat as many times as it took. It was a lot of hand holding.

Open the working version of this blueprint and you can still see it: sticky notes flagging questions nobody had answered yet, red flags on gaps between systems that took weeks just to get everyone to even agree were gaps. A related piece of it, mapping a similar population, is annotated in someone's own handwriting: "This is a disjointed process." Nobody hands you a clean diagram on day one.

The findings surfaced obvious risk areas: places where systems, teams, or configurations weren't aligned with what the regulation actually required, and the biggest single gap was that the three products simply didn't talk to each other, with no standardized configuration between business units. The blueprint showed exactly where those gaps were and what best practices existed to reduce the risk. It wasn't a playbook. Closing any specific gap was still its own separate effort.

Six weeks after we started, the first full draft went back to leadership. The six weeks weren't the mapping itself; they were spent getting people to actually sit down together and work through objections.

When that first draft came back, Alyssa Alsheimer, SVP Marketing and Engagement, told leadership it was some of the best work she'd seen.

“

When customers started asking about revised CMS and HIDE/FIDE requirements, Andy built a cross-company research initiative from scratch because nobody had mapped what it meant for our customers.

The blueprint never shipped anything itself, but it is live at four customers today; other teams are responsible for the implementation work. By December, the market it was built around was clearly real, not theoretical, and at scale: one customer running 16 group structure codes, another with 18 care-management rules and 6 data rules covering utilization management and risk notification, a third with authorization routing live between two internal systems.

Our CPO took that and built out the market-sizing on the opportunity. That's what got dual-eligible populations named as one of HealthEdge's own long-term strategic bets; leadership hadn't staked that out ahead of time. The same work led to the services line HealthEdge is now evaluating, implementation and enablement support for any health plan trying to get compliant on HIDE, FIDE, and other dual-eligible plan requirements. And it opened a sales pipeline. I built the sales collateral myself: slides the team could put in front of a prospect and make a case with.

Then something happened that I didn't set out to build. Once people saw what the first blueprint could do, some of them asked for the same treatment somewhere else. They'd already spotted a gap of their own. In May 2025, that request turned into a related blueprint covering LTSS, a different but adjacent regulatory category, and I personally ran a one-day workshop built on those findings with the leadership of one of HealthEdge's largest customers. That work went straight into their own product roadmap, built by their own embedded development team, to close gaps the workshop surfaced.

I didn't know what HIDE or FIDE stood for in February. By March I'd shown leadership a script nobody else had been able to write. By May I was running workshops off the back of it with one of the company's biggest customers.

The audience never saw any of it. That was the point. The show went on.