Business development ops trends for 2027 mostly repeat four old moves. Business development ops trends for 2027 mostly repeat four old moves
Image: Operations Process Control

Reviews

Part of Business development ops: the parts worth your attention

Business development ops trends for 2027 mostly repeat four old moves

Business development functions get redesigned every year in four familiar ways: what each move claims to fix, what it costs, and how to tell relabeling from change.

Revenue operations get rearranged on a roughly annual cycle. The territory map is redrawn, a role is split, the tool set is consolidated, or the compensation plan is rewritten. Each arrives described as a response to conditions.

This page is not a forecast. It is a way of reading the four moves you are most likely to be asked to implement. The same four keep coming back, and they are easier to judge when you know what each is for.

What to take away

  • Ask what the move is meant to fix before asking whether it is a good move. Most of these are reasonable answers to a specific problem and expensive answers to any other one.
  • Every one of them resets your history. After a territory redraw or a stage change, comparisons across the boundary are not available, and plans built on them are guesses.
  • The honest thing to say about a distant year is what you will do at a trigger, not what you predict. A commitment attached to an observable event survives being wrong.

Move one: redrawing territories or account coverage

What it claims to fix. Uneven workload, accounts nobody owns, or two people calling the same buyer.

Redraw: claims vs. real costs

What it claims to fix

Workload
Uneven workload
Ownership
Accounts nobody owns
Overlap
Two people calling same buyer

What it actually costs

Workload
Relationship history lost
Ownership
Quarter of learning accounts
Overlap
Decline attributed elsewhere

What it actually costs. Relationship history, which does not transfer with a record. It also produces a quarter in which everyone is learning accounts, and that quarter shows up in the numbers as a decline that gets attributed to something else.

How to tell whether it is working. Count accounts with no contact in the period, before and after. That is the problem a redraw is supposed to solve, and it is the only measure that will not be contaminated by the transition itself.

When it is the wrong answer. When the real problem is capacity. Redrawing lines does not create hours, and if the accounts per person exceed what the arithmetic supports, a new map produces the same neglect in a different shape.

Move two: splitting a role into specialists

What it claims to fix. People doing work below their value, or a skill that not everyone has.

Specialist split: claims vs. costs

What it claims to fix

Value
Work below their value
Skill
Skill not everyone has
Waiting
Faster specialist

What it actually costs

Value
A handoff added
Skill
Queue at the boundary
Waiting
Work sits at handoff

What it actually costs. A handoff, which is the most expensive thing you can add to an operating process. Every split creates a queue at the boundary and a place for work to sit, and the cost of that queue is rarely counted against the benefit of the specialization.

How to tell whether it is working. Measure the wait at the new boundary, not the productivity of the specialist. The specialist will look efficient by construction, because their queue does their waiting for them.

When it is the wrong answer. At low volume. A specialist needs enough flow to stay busy without becoming a bottleneck, and below that volume you have added a dependency and a delay. Counting handoffs before adding one is the discipline set out in operating processes.

Move three: consolidating the tool set

What it claims to fix. Data spread across systems, duplicate records, and reporting that requires exporting three things into a spreadsheet.

What it actually costs. A migration, which always takes longer than planned, and a period in which the historical data is either not available or not comparable. It also transfers ownership of your definitions to whoever configures the new system.

How to tell whether it is working. Whether people open it to do the work rather than to report on it. A system used only on Friday afternoons has not been adopted, whatever the login counts say.

When it is the wrong answer. When the problem is that nobody agreed what a field means. Consolidation moves inconsistent definitions into one place, where they become harder to see and easier to average together.

Move four: rewriting how people are paid

What it claims to fix. Behavior. Almost always behavior.

What it actually costs. A year, because the effects arrive on a delay and are entangled with everything else that happened. It also spends trust, which is not recoverable within the same year.

How to tell whether it is working. Write down, in advance, the specific behavior you expect to increase and the one you expect to decrease. Without that written before the change, any outcome will be read as confirmation.

When it is the wrong answer. When the behavior you dislike is a rational response to the process rather than to the incentive. If a step is skipped because it costs the seller time and returns them nothing, paying differently does not make the step worth doing. Adjusting a measure to change behavior runs directly into the effect named in Goodhart's law, and pay is the strongest version of it.

The test that applies to all four

Before agreeing to any of them, ask three things and write the answers down.

What is the observable that is supposed to change, and what is it now. Not a direction, a value. "Fewer uncovered accounts" is not testable; "accounts with no contact in ninety days, currently at some count" is.

What will break in the meantime, and for how long. Every one of these moves has a transition period in which the numbers are unreadable. Naming the length of that period in advance stops it being used as an excuse afterward.

What would tell us this was a mistake. If nobody can answer, the change will be judged by whether people got used to it, which everyone eventually does.

Why the same four keep returning

Each of these is a move that a leader can make. That is most of the explanation. The alternatives, such as fixing a step that people skip or agreeing a definition, are slower, less visible, and produce nothing to announce.

There is also a genuine cycle underneath. Specialization creates handoffs, handoffs create delay, delay produces a push to generalize, generalization creates uneven skill, and specialization returns. Nothing is wrong with either end of that cycle. What goes wrong is treating each swing as a discovery rather than as a known tradeoff with a known cost.

Reading someone else's account of one of these moves needs the same caution as any published result, since the ones written up are the ones that worked. The discipline for that is in operations case studies.

If you decide to make one of these moves, sequencing and communication are a separate skill, covered in change management. The underlying design questions about stages and coverage are in business development ops.

Organizational change is treated as a managed risk in the UK Health and Safety Executive's guidance on organizational change. It is worth reading because it comes from a domain where getting it wrong is not merely expensive.

Common questions

Is it possible to make one of these moves without losing the historical comparison?

Partly. Keep the old classification alongside the new one for two full periods and report both. It is duplicated effort for a few months and it is the only thing that lets you say anything about the effect afterward.

All four have been proposed at once. What do we do?

Sequence them and say why. Run together, they are uninterpretable: whatever happens will be credited to whichever one someone favored. Pick the one whose problem is best evidenced and hold the others.

What if the pressure to reorganize is coming from outside the team?

Then the useful contribution is the observable and the transition estimate, not resistance. A written expectation of what will change and how long the numbers will be unreadable is a service to whoever is making the call.

How far ahead can a revenue plan honestly commit?

About as far as your longest lead time on a decision that is hard to reverse, which is usually hiring. Beyond that, write triggers rather than dates and say plainly that the rest is a placeholder.

More in Reviews

Latest from Planning Desk