A lot of teams assume moving faster means hiring more developers or adopting the latest framework. But in our experience, the biggest drag on development speed is usually upstream. It’s how decisions get made, the way priorities are set, and whether there’s alignment (or misalignment) across teams.
In heavily regulated industries like healthcare, the instinct is often to add more process when things slow down: more documentation, signoffs, and checkpoints. It makes sense on the surface, but what’s frequently missing is a shared way of working.
We saw this firsthand when one of our clients expanded their offerings into the healthcare services space. When we came on board, teams had been missing deadlines, cross-team alignment was breaking down, and a new product initiative was stalling. Here’s how we helped them navigate change to overhaul a waterfall process and increase speed.
The waterfall problem: More documentation, less speed
The most entrenched issue was waterfall culture. Before any coding could begin, product managers were producing lengthy, detailed product requirements documents (PRDs) that tried to anticipate every decision upfront. In regulated industries, there’s real cultural pressure to have everything documented and approved before moving. But those detailed docs become obsolete almost immediately, and they tend to become political artifacts. They’re things teams negotiate over rather than build from.
When we embedded with this client, we broke that pattern deliberately. Rather than exhaustive PRDs, we kept requirements lightweight and iterated. A brief requirement went to the design lead and technical lead first. This allowed them to poke holes and surface unknowns before a developer touched anything.
This was a political change as much as an operational one. Convincing stakeholders to adopt a lighter-touch approach required earning trust fast. To do this, we shipped early and visibly, and this success helped create buy-in around the process changes.
Start by getting the right people in the room
Before writing a single line of code, we typically run a design sprint) with our clients. The first goal is alignment: We identify the actual decision makers, clarifying who has the final call, and establish an executive sponsor. This clarity helps prevent political friction that can derail cross-team initiatives later.
With this client, there were multiple senior product managers overseeing their own roadmaps with little cross-team coordination. We met with the executive team and asked direct questions about who ultimately owned decisions. This helped us understand the management layers above where the work happened, so we knew who could help us move things forward.
From there, we facilitated a problem statement exercise). The goal was deceptively simple: define who has the problem, what the problem really is, and why it matters. We kept refining it until the group landed on something they could rally around.
That statement lived at the top of every FigJam board for the duration of the project. Whenever a new request surfaced, we’d ask: Does this address the problem we agreed to solve? It gave everyone a principled basis for saying no.
Make the big picture visible
One exercise that consistently generates cross-organizational buy-in is mapping the entire critical path, including every touchpoint, product team, and dependency, on a single board.
With this client, we mapped the entire operating picture: every product, every team, every place the new work would borrow resources or touch existing systems. Invisible interdependencies became suddenly obvious. PMs who’d been quietly absorbing off-roadmap requests suddenly had evidence to escalate.
Change management is part of the work
Transitioning away from waterfall in a regulated industry isn’t just a process problem; it’s a change management problem. The documentation, approval chains, and signoffs exist for many reasons. The goal isn’t to abandon rigor; it’s to be rigorous about the right things at the right time.
As an outside consulting team, we have a structural advantage. We’re not protecting our careers inside the organization. We can push back on scope, name the political dynamics slowing things down, and advocate for PMs getting squeezed between competing priorities. These are conversations internal teams often can’t have. We used that position deliberately with this client.
What we leave behind
We closed out this engagement by establishing a lightweight cross-team coordination structure. It was an as-needed touchpoint where all teams with a stake in a shared initiative could surface blockers, get decisions made, and flag dependencies before they became problems. It gave individual PMs a direct line to executive attention rather than things stalling at the manager level. While we modeled less process overall, we also left behind some techniques like this to help clear blocks as needed.
The goal of any engagement isn’t just to ship code. It’s to model a way of working that teams carry forward long after we’ve handed things off.
Ready to help your team move faster? Let’s design and develop great products while leveling up your team.
