Flowstate - Initiative scoping

The job

“We need to rebuild the platform.”

Five words. Said in a board meeting, a strategy offsite, or a Slack message from the CEO. And with those five words, an engineering organisation can lose eighteen months of its life.

Not because the platform doesn’t need rebuilding. Maybe it does. But because nobody defined what “rebuild the platform” actually means. What’s the first deliverable? What does success look like at month three versus month twelve? When would you know it’s time to stop — or that it’s not working?

The gap between strategy and execution is almost always a scoping problem. Leadership approves a big bet. Engineering interprets it as an open-ended programme. Six months in, nobody can articulate what’s been delivered or what’s left. Finance starts asking uncomfortable questions. Trust evaporates.

Initiative scoping is the discipline of turning large, ambiguous bets into bounded, measurable chunks of work that teams can actually deliver and the business can actually evaluate. It’s the difference between “rebuild the platform” and “migrate the payments service to the new architecture by March, reducing transaction failures from 2.3% to under 0.5%.”

The first is a prayer. The second is a plan.

Why it matters

Badly scoped initiatives are the single biggest source of wasted engineering investment. And they’re everywhere.

I’ve watched a Series C fintech spend fourteen months on a “platform modernisation” that produced no measurable business outcome. The engineers were working hard — shipping code, closing tickets, attending standups. But the initiative had no defined endpoint, no success criteria, and no mechanism for the business to evaluate whether the investment was paying off. When the CFO finally asked “what did we get for that $4M?”, nobody had a good answer.

Here’s what poor scoping actually costs you:

Scope creep becomes scope explosion. Without clear boundaries, initiatives absorb adjacent work like a black hole. “Rebuild the platform” becomes “rebuild the platform and also rewrite the API layer and while we’re at it let’s redo the auth system.” Each addition feels reasonable in isolation. In aggregate, you’ve tripled the scope and nobody made a conscious decision to do so.

You can’t course-correct. If your initiative is an eighteen-month monolith, you won’t know it’s failing until month twelve. By then, you’ve sunk millions and the sunk-cost fallacy kicks in. “We’ve come this far, we can’t stop now.” Yes you bloody well can. But only if you’ve structured the work so that stopping is a viable option.

Leadership loses confidence. When engineering says “it’ll take two years” and can’t show meaningful progress at month six, leadership starts to wonder if the team can handle the work. That’s not a capability problem — it’s a scoping problem. But it looks the same from the outside.

When scoping is done well, everything changes. Leadership can evaluate progress quarterly. Teams have clear goals and the satisfaction of actually finishing things. And if the strategic context shifts — if a competitor launches something that changes your priorities — you can stop at a natural boundary without throwing away everything you’ve built.

What good looks like

Mature organisations scope initiatives in six to twelve week chunks. Not because that’s a magic number, but because it’s long enough to deliver something meaningful and short enough to course-correct if the bet isn’t paying off.

Here’s what separates good scoping from bad:

Every chunk has a definition of done that a non-engineer can understand. Not “refactor the data layer” — that’s an engineering task, not a business outcome. Try “reduce report generation time from 45 seconds to under 5 seconds” or “enable customers to self-serve account changes without contacting support.” If your product manager or CFO can’t evaluate whether you’ve succeeded, you haven’t scoped it properly.

Each chunk delivers standalone value. This is the critical test. If you complete chunk one but never do chunk two, did the business get something useful? If the answer is no, your chunks are too tightly coupled. Restructure them so that each one is independently valuable, even if the full vision requires all of them.

The chunks are sequenced by risk, not by architecture. Bad scoping sequences work in the order that makes sense technically — build the foundation first, then the features on top. Good scoping tackles the riskiest assumption first. If the whole initiative depends on a new database performing at scale, prove that in chunk one, not chunk four.

There’s an explicit off-ramp. After each chunk, the business should be able to decide: continue, pivot, or stop. This isn’t a sign of weak commitment — it’s a sign of mature investment thinking. VCs don’t hand over Series B before seeing Series A results. Your engineering investments should work the same way.

The scope is written down and agreed. This sounds obvious, but I’ve seen initiatives where the engineering team, the product manager, and the executive sponsor all had different understandings of what was being built. Write it down. Get signatures if you need to. A scope that lives in someone’s head isn’t a scope — it’s a hallucination.

The approach

Step 1: Define the bet, not the solution

Start with the business problem, not the technical approach. “Our platform can’t handle 10x growth” is a bet. “Rewrite everything in Rust” is a solution (and probably the wrong one).

Frame it as: “We believe that [doing X] will result in [business outcome], and we’ll know it’s working when [measurable signal].”

For example: “We believe that migrating our core transaction processing to an event-driven architecture will reduce transaction failures from 2.3% to under 0.5% and enable us to handle 10x current volume, and we’ll know it’s working when we see failure rates drop in production.”

This framing does something crucial — it separates the strategic intent from the implementation. If someone finds a way to achieve the same outcome without the migration, brilliant. The bet is the outcome, not the approach.

Step 2: Identify the riskiest assumption

Every big initiative has an assumption that, if wrong, kills the whole thing. Find it. Name it. Test it first.

Common risky assumptions:

“The new architecture will perform better than the old one.” (Will it? Prove it.)
“We can migrate without downtime.” (Can you? Have you tested it?)
“The team has the skills to build this.” (Do they? Or are you hoping they’ll learn on the job?)
“Customers will adopt the new workflow.” (Will they? Have you asked them?)

Your first chunk of work should be designed to validate or invalidate the riskiest assumption. If the assumption is wrong, you want to know after six weeks and $200K, not after twelve months and $2M.

Step 3: Define MVBs (Minimum Viable Bets)

An MVB is the smallest unit of work that delivers a meaningful business outcome and tests a key assumption. Think of it as a startup’s MVP, but for an internal initiative.

For the platform migration example:

MVB 1 (weeks 1-8): Migrate the payments service to the new architecture. Measure: transaction failure rate below 0.5% on the new service, handling 2x current volume. This tests whether the new architecture actually performs better.
MVB 2 (weeks 9-16): Migrate the order processing service. Measure: end-to-end order completion time reduced by 40%. This tests whether the pattern scales to other services.
MVB 3 (weeks 17-24): Migrate the remaining core services. Measure: full platform handles 10x volume in load testing. This delivers the full strategic outcome.

Notice the structure. Each MVB is independently valuable. The business gets something after MVB 1, even if you never do MVB 2. And each one tests a different assumption, so you’re learning as you go.

Step 4: Size it honestly

This is where most scoping exercises fall apart. Engineers are optimists by nature. “That’ll take two weeks” usually means six.

Some rules of thumb:

If nobody on the team has done this before, double your estimate. Not because your team is slow, but because unknown unknowns are real.
Include the migration tax. If you’re replacing an existing system, you need to run both systems in parallel, migrate data, and handle edge cases. This is usually 30-50% of the total effort and almost always underestimated.
Account for operational overhead. Engineers don’t spend 100% of their time on initiative work. Between on-call, support escalations, code reviews, and the inevitable “quick fix” that takes three days, realistic utilisation is 60-70% for new initiative work. Plan accordingly.
Build in a buffer and be transparent about it. I’d rather tell leadership “this will take ten weeks, which includes a two-week buffer for unknowns” than tell them eight weeks and miss it. The first builds trust. The second destroys it.

Step 5: Get explicit sign-off

Before any work starts, get the initiative sponsor, the engineering lead, and the product owner to agree on:

What’s in scope (the specific MVBs and their success criteria)
What’s explicitly out of scope (equally important — write down what you’re not doing)
The decision points (after each MVB, who decides whether to continue?)
The investment (how many people, for how long, at what cost)

This isn’t bureaucracy. This is the conversation that prevents the “I thought we were getting X” moment six months later. Write it down. Put it somewhere everyone can find it.

The conversations

With leadership (“This is too big”)

The hardest scoping conversation is telling a senior leader that their initiative can’t be done in one go. Here’s how to do it without sounding like you can’t handle ambiguity:

Trust-building: “I completely agree this is the right strategic bet. Here’s how I’d structure it to give us the best shot at success. We break it into three phases, each delivering business value. After phase one, we’ll know if the approach works, and you’ll have something to show the board. If it’s not working, we’ll have spent $300K learning that, not $3M.”

Trust-eroding: “That’s going to take two years and forty engineers.” (Even if it’s true, leading with this makes you sound like you’re trying to kill the initiative.)

The trick is to reframe scoping as investment discipline, not engineering limitation. You’re not saying “we can’t do this.” You’re saying “here’s how to do this in a way that manages risk and gives you visibility.”

With your team

Trust-building: “Here’s what we’re delivering in the next eight weeks and exactly what success looks like. I’ve deliberately kept the scope tight so we can actually finish it and show results. If it goes well, there’s more work in the pipeline.”

Trust-eroding: “We need to rebuild the platform. I don’t know exactly what that means yet but let’s get started.” (Nothing kills team morale faster than open-ended work with no clear finish line.)

With product and design

Trust-building: “Let’s define the smallest thing we can ship that proves this works. I don’t want to build the full vision before we know the foundation is solid. What’s the critical user journey we need to get right?”

Trust-eroding: “Engineering needs to do a big technical initiative and we can’t take on product work for six months.” (This creates adversarial dynamics. Frame it as a shared bet with shared outcomes.)

Common failure modes

Scoping by architecture instead of by value. “Phase 1: build the new database layer. Phase 2: build the API. Phase 3: build the features.” This means you deliver zero business value until phase 3. If you get cut after phase 2, you have a database and an API that nobody uses. Scope by business outcome — each phase should deliver something a customer or stakeholder can see and value.

The “while we’re at it” trap. This is the most insidious scope creep pattern. “While we’re rebuilding the payments service, we should also fix the reconciliation bug and add support for the new payment provider and…” Each addition is small. Together, they double the timeline. Practice saying: “Great idea. Let’s put that in the backlog for the next chunk.”

Confusing effort with scope. “This is a big initiative” doesn’t mean it has to be a big scope. You can do big things in small increments. The Apollo programme didn’t start with a moon landing — it started with putting a person in orbit. Same ambition, radically different first scope.

No off-ramps. If your initiative has no natural stopping points, you’ve built a treadmill, not a project. You’ll run until someone gets tired enough to pull the plug, and that usually happens at the worst possible time.

Letting sunk cost drive decisions. “We’ve already spent six months on this” is not a reason to continue. The only question that matters is: “Given what we know now, would we start this initiative today?” If the answer is no, stop. Redirect the investment. The six months are gone regardless.

Scoping in isolation. If engineering scopes an initiative without product input, you’ll build the wrong thing. If product scopes it without engineering input, the estimates will be fiction. If neither of you talks to finance, you won’t know if you can afford it. Scoping is a team sport.

Getting started

If your organisation doesn’t have a scoping discipline, start with one initiative. Pick something that’s currently in flight and feels “too big.” Then:

This week: Write down what the initiative is actually trying to achieve in business terms. Not the technical approach — the business outcome. If you can’t articulate it in two sentences, that’s your first problem.

Next week: Break it into chunks that each deliver standalone value. For each chunk, write a one-paragraph scope with a measurable success criterion. Show it to the initiative sponsor and ask: “If we delivered just this first chunk and nothing else, would that be useful?”

This quarter: Run your first MVB. Treat it like a real experiment. Define success criteria upfront. Review the results at the end. Make an explicit decision about whether to continue.

You’ll probably get the scoping wrong the first time. That’s fine. The act of trying — of forcing the conversation about boundaries, success criteria, and off-ramps — is more valuable than getting it perfect. Within two or three cycles, you’ll have a muscle memory for breaking big bets into small ones.

The goal isn’t to avoid big ambitions. It’s to pursue them in a way that lets you learn, adjust, and prove value along the way. The organisations that ship the most impressive things aren’t the ones that plan the biggest initiatives. They’re the ones that scope the sharpest first bets.

Running Effective Planning Cycles — The quarterly rhythm that determines which initiatives make it into the plan.
Prioritisation & Trade-offs — How to decide which initiatives to invest in when you can’t do everything.
Scenario Planning — Stress-testing your initiative portfolio against different futures.