Building and Operating Your Revenue Machine

Many change initiatives fail quietly because they are designed as massive, one-time deployments. A new CRM workflow. A new qualification framework. A new operating cadence. Leadership rolls it out and expects immediate adoption. In reality, they’ve just dumped a massive amount of new work in flight onto the system.

Buyer behavior shifts. Team composition changes. New channels appear. If the operating model is static while the environment is dynamic, the friction just builds up. The pattern I see repeatedly is this: organizations treat operating model change as a project to complete, rather than managing their actual lead time and capacity.

“In parallel to building the product, you need to build the organization that is building the product.”

For revenue teams, that means building better decision rights, managing dependencies, and establishing better adaptation habits, not only better plans.

“People don’t really like being inflicted change upon. They like to be part of the process.”

Adoption is not communication. Teams are far more likely to sustain behavior change when they help shape it.

“If people fail, then that’s a failure of the system.”

When execution is inconsistent, start with system design before blaming individuals. Usually there is a policy, interface, incentive, or workload issue hiding under the symptoms.

If you lead sales, marketing, RevOps, or product marketing, here is a pragmatic pattern to avoid the theater:

1. Pick one business-critical outcome (for example: forecast reliability, or cycle time to qualified pipeline).
2. Map the current system that produces this outcome across functions to visualize the dependencies.
3. Run small experiments in the operating model, rigorously limiting work in progress.
4. Review both business outcomes and adoption signals.
5. Keep what works, adapt what does not, and repeat.

Watch the full conversation here: In the Spotlight - with Yuval Yeret

If this topic resonates, these pieces go deeper:

• AI isn’t the problem - your operating system is
• When Traction Becomes Friction

A few other questions that often come up in conversations about applying continuous learning/adaptation to the revenue/GTM machine

Is this mainly relevant for large enterprises?

Not necessarily. The pattern appears in scaleups, mid-market firms, and enterprise contexts. The size changes; the operating-system dynamics are similar. At the extreme, even soloists like me have to run the revenue machine in parallel to evolving it.

Should RevOps lead this alone?

RevOps is central, but not sufficient alone. Durable change needs shared ownership across sales leadership, marketing, product marketing, and supporting functions. That’s one of the key insights - change participants need to feel and show up as players, not pawns, if you want the change to stick and to really serve the needs of the organization.

How fast should we expect results?

Well, this is an interesting one. On one hand participatory evolutionary change might seem slower because you have to involve more people, and plan for iteration rather than one big bang. On the other hand, the right plan could leverage this iterative incremental nature to show quick progress and value along the way.

Ideally you can front load value, seeing much faster results, and even trim the tail - skipping some aspects of the change that you initially planned for but are realizing aren’t needed after trying some things out.

Moving from agile theater to real business agility takes more than a framework — it takes a deliberate operating model shift. Explore Business Agility advisory or let’s talk.