Over the years I've come to believe that most engagement trouble starts before a single line of code is written. It starts when a team is unsure which game they're actually playing. There are two distinct operating modes, both completely honorable, and the failures I've seen rarely come from picking the wrong one. They come from running one mode with the reflexes of the other.

The two modes#

Consulting mode is about delivering what was scoped. The customer is the person who hired you. "Done" means the work shipped against the agreement. You typically hand off at launch, scope is effectively the contract, and quality means the spec was met. The risk you carry is delivery risk: can you build the agreed thing, on time, at the agreed quality. You advise, and the client decides.

Product mode is about learning what to build next. The customer is the end user, not the person funding the work. "Done" means real usage validated the bet. You keep operating and iterating long after launch, so scope becomes "whatever ships fastest so we can learn something." Quality means users keep coming back. The risk is doubled: delivery risk plus market risk, because you can build the thing flawlessly and still discover nobody wants it. You co-decide, and you have a stake in the outcome.

The most common failure#

The single most frequent mistake I see is running a product engagement with consulting muscle memory. The team scopes a backlog, burns it down, hits the date, and ships something polished that never finds an audience. Everyone did their job by the consulting definition of success, and the product still failed. The reflexes were wrong for the mode.

What actually changes between modes#

When you move from one mode to the other, a surprising amount shifts:

• How decisions get made moves from "client decides" to "we co-decide."
• How success is measured moves from delivered scope to validated behavior.
• How long you stay engaged stretches from launch to ongoing operation.
• The commercial structure changes, because a stake in the outcome is not the same as a fee for delivery.
• Day-one instrumentation becomes non-negotiable; you cannot learn from usage you never measured.
• Planning style shifts from backlog burn-down to hypothesis-driven iteration.

What does not change#

It's worth being equally clear about what stays constant. Your values don't change. Your quality bar doesn't drop. Transparency with whoever you're working with remains absolute, and you still treat clients as partners rather than ticket queues. Mode is about how you operate, not about who you are.

Who owns the call#

A simple rule keeps decision-making honest across both modes: the person closest to the consequences owns the final call. In consulting mode that's usually the client, because they live with the result. In product mode the rights are shared, because you share the outcome. Naming this explicitly prevents the slow drift where decisions quietly default to whoever talks loudest.

A five-question diagnostic#

When I'm unsure which mode an engagement is really in, I ask:

1. Do we have a stake beyond the cash, something tied to the outcome?
2. Will we still be involved twelve months from now?
3. Are we expected to have an opinion on what to build, or only on how to build it?
4. Is success measured by validated user behavior or by delivered scope?
5. Are we operating what we ship, or handing it off?

Mostly "what to build," "still here in a year," "validated behavior" answers mean product mode. The opposite cluster means consulting mode.

Watching for drift#

Even when you start in the right mode, drift creeps in. The warning signs are subtle:

• Demos quietly turn into status updates.
• Scope decisions default to the founder instead of the user.
• The team stops talking about users at all.
• Nobody mentions the transition or operating plan anymore.

Any one of these tells me a product engagement is sliding back into consulting habits.

Mode awareness, not mode purity#

The goal isn't to be a pure product shop or a pure consultancy. The goal is awareness. Know which mode you're in, name it out loud, and name it again the moment it changes. A team that can say "we just shifted into product mode, so let's start instrumenting and forming hypotheses" will outperform a team that never noticed the ground moving under them.