From the August 26th, 2026, edition of How Teams Work
Almost every conversation with a new client starts the same way.
Most teams come in knowing what they want. What they don't always know is whether their processes are mature enough to get them there.
And most importantly, the processes underneath those goals have more gaps than they realize.
What's usually missing is an honest assessment of how mature their processes actually are before deciding what to build on top of them.
We started to notice the pattern across different industries, different team sizes, different tools.
The problem wasn't that teams were setting the wrong goals. It was that they were skipping the stages that determine whether those goals are actually achievable and paying for it later when an automation breaks, or their AI tool produces garbage outputs, or the team quietly goes back to doing things their own way.
So we built a framework to help teams see where they actually are before deciding where to go next. We call it FORM.
FORM is a maturity model that gives teams a clear picture of where their processes currently stand and whether they are mature enough to scale.
It applies to any process, whether that's how you capture and qualify leads, how deals move through your pipeline, or how you onboard and retain customers. When developing a process within your organization, you should follow these four steps:
The stages are sequential. Each one requires the stage before it. You can't operationalize something that isn't built. You can't refine a process nobody is actually using. And you can't safely scale something that hasn't been proven.
A team can be at different stages for different processes at the same time. That's normal. What matters is knowing where you actually are before deciding what to scale next.
Putting this into practice
A team came to us recently with a clear ask.
They wanted to automatically reply to inbound leads with AI, route them based on enrichment data, and run them through automated sequences.
The goal made complete sense. It's exactly the kind of thing that makes a team more effective.
It's also a Multiply-stage ask.
The question isn't whether they should get there. They should. The question is whether they had the processes in place to support it.
So we walked through FORM together, starting at the beginning.
Foundation
Most teams assume they have this covered. And in most cases, they have some sort of foundation built.
But Foundation isn't just about having something built. It means the process is defined, documented, and capable of running.
For this team, the basics were in place, but the details weren't. Lead source tagging was inconsistent, so attribution data couldn't be trusted, which meant leads were being enrolled in the wrong sequences and the team had no reliable way to know where their best prospects were actually coming from.
The scoring model existed but hadn't been validated against any real outcomes.
The routing logic worked most of the time, but edge cases were being handled manually by whoever noticed them first.
That's not a Foundation. That's a starting point that was never finished.
A process doesn't have to be perfect to move forward, but it does need to be defined clearly enough that the team can work it consistently. Until that's true, everything built on top of it is built on assumptions.
This is by far the most underinvested stage we see.
Teams spend real money building a foundation. They run some initial training. And then they expect adoption to follow.
Most of the time, it doesn't.
The team clicks around in the new system for a few weeks, hits some friction, and quietly drifts back to how they were working before.
Operationalize is where the system becomes how the team actually works, not just how it was designed to work. That means training that goes beyond a one-time kickoff. Office hours, ongoing enablement, and a regular cadence of reviews that keep the process visible and on track.
It also means going back into the system as the team starts using it, reducing friction where it exists, and adjusting the system when the process has evolved.
The goal is a team that works faster and more effectively inside the system, not around it through email threads and spreadsheets.
For this team, leads were being captured, but reps weren't consistently working them. There was no regular rhythm for reviewing lead quality. A lead scoring model existed, but nobody was using it as it was intended.
This stage matters beyond adoption. A process the team isn't consistently using can't generate data worth analyzing. And without that data, Refine has nothing to work with.
Operationalize fixes problems you can see. Refine fixes problems the data and your team's feedback reveal.
By the time you're here, the team is working in the system consistently. Now you can actually look at what's happening and ask whether it's working the way you thought it would. Not based on gut feel or what leadership assumed when they built it, but based on what the numbers are actually showing.
This is where assumptions get proven or disproven. And that distinction matters more than most teams realize. A scoring model that was built on assumptions looks fine until the data tells you otherwise. A routing rule that made sense six months ago might not reflect how the team is actually structured today. Refine is where you find out.
For this team, the scoring model started getting validated against real outcomes. They could see which lead sources were converting and which weren't. The assumptions that were baked into the model at Foundation were finally being tested against reality.
Skipping this stage doesn't just mean missing out on optimization. It means going into Multiply with unproven assumptions. And scaling unproven assumptions is expensive.
This is where the work pays off. But only if the stages before it were done properly.
Multiply is about scaling a process that is stable, proven, and repeatable.
That can mean robust automation, dynamic routing, integrated tooling, or AI. The common thread is that none of it works reliably until the process underneath it has been defined, adopted, and validated.
For this team, leads were being enriched with data from tools like Clay, combined with what already existed in their CRM, giving the routing logic and the AI agent handling automated replies a complete picture to work from.
The automated responses and sequences were built around real data, actual industries, actual sources, and actual marketing touchpoints that had been refined over time.
This is what the team originally asked for. The difference is that the process underneath it had been proven before they tried to scale it.
The original ask, AI auto-reply, automated sequences, wasn't wrong. It was just early.
The team wasn't missing a foundation. They had one. What they were missing was proof that it worked.
Skipping Operationalize and Refine doesn't get you to Multiply faster. It means building automation on top of unproven assumptions. And when those assumptions turn out to be wrong, you end up spending a lot of money adjusting and rebuilding things you already paid to scale.
This is the pattern we see more than any other. The ambition is right. The instinct to scale is right.
But until the process has been adopted by the team and validated by the data, Multiply is just expensive guesses with frequent misses.
Before you decide what to automate, what to hand to AI, or what to scale, run it through FORM first.
Is the process defined and documented clearly enough that everyone works it the same way? Is the team actually using it consistently? Does the data show that it's working the way it was designed to?
If the answer to any of those is no, you're not in Multiply yet. That's not a failure. It just means there's still work to do before scaling makes sense. And doing that work first is how you actually get where you're trying to go.
If you're working through any of this, I’d be happy to talk it through.
Want to get the "How Teams Work" newsletter sent to your inbox? Subscribe Now.