The Illusion of Control: Process as a Reflex for Product Operations
Default operational behaviors to stop doing now
When process becomes a reflex, it's time to ask: is this helping?
In complex systems, people crave certainty. Work—especially product management work—has a tendency to become quite ambiguous. Outcomes are murky, collaboration gets messy, and decisions feel political. When this becomes uncomfortable and seemingly unmanageable, we instinctively reach for tools and templates. The process becomes the safety net. Frameworks become the fallback. We want anything that helps us control our situation.
The practice of Product Operations is meant to reduce this kind of chaos in product organizations. It offers structure, repeatability, and shared understanding. But in practice, it’s easy for operations to shift from enabler to over-corrector. We begin codifying edge cases, solving ambiguity with bureaucracy, and confusing visibility with clarity.
Over time, especially in teams without experienced Product Operations, I’ve seen the same patterns repeat. These are common responses to complexity. They aren’t bad practices, but they’re often overused and applied in the wrong situations. They offer the comfort of order but at the expense of outcomes.
Here are five common defaults I deliberately choose not to follow—and what I recommend when supporting product organizations at product-enabled companies.
1. The Intake Form
When a team struggles with requests coming from all directions, often the first instinct is to create an intake form. It’s an understandable move. Intake forms suggest fairness, structure, and transparency. They offer the illusion that the work can be cleanly captured, sorted, and triaged.
In reality, intake forms often become disconnected from the relationships they’re supposed to support. They are treated as transactional: submitted into a system, often with no follow-up, and quickly sidelined in favor of back-channel requests. Ultimately, intake forms turn product managers into order-takers.
What I recommend:
Don’t start with the form. Start with the relationships. Build shared expectations with your partners about how and when to bring problems to the product team. Establish regular touchpoints. Create forums for conversation, not just submission. Spend your time building trust and accountability through conversation, not form submission. Intake can be replaced with clearer team charters, service boundaries, and intentional partner rituals. When trust is present, people rarely need a form to ask for help.
2. The Quarterly Planning Box
Quarterly planning is one of the most institutionalized rituals in cross-functional work. In many departments, quarterly boundaries are useful. But for product development, they’re often arbitrary.
Work rarely fits neatly into 13-week increments. The push to conform to quarterly boxes leads to artificial scoping, rushed deliverables, and delayed initiatives that could have started sooner—simply because they didn’t “fit” in the current quarter. Teams feel pressure to deliver anything by the end of the quarter to meet output measurements, and strategic priorities get shaped around calendar constraints instead of customer or business needs.
What I recommend:
Plan based on intent and complexity. Let the quarter be a boundary for communication, not a container for execution. Use your roadmap to tell the story of your priorities and decisions regardless of timing. Let strategy lead. The calendar can follow. To do this, begin with the work and then overlay the quarterly structure. This approach allows planning to serve the strategy, rather than dictate it.
3. The Pursuit of Transparency
Many organizations invest heavily in visibility—dashboards, trackers, status updates, and real-time roadmaps designed to surface everything to everyone. The goal is noble: reduce surprises and improve cross-functional awareness.
But visibility is not the same as clarity. Transparency without a clear narrative leads to information overload. Stakeholders may have access to everything but still walk away unsure of what’s happening or why decisions were made.
What I recommend:
Don’t just show data; tell the story. Make your artifacts smaller, simpler, and annotated with insight. Explain what decisions have been made, what tradeoffs were involved, and where you're watching for risk. Visibility should reduce confusion, not just satisfy curiosity.
4. The Impulse to Codify
Process is an essential part of scaling, but the temptation to codify everything can get out of control. Teams create a documented flow for every exception and respond to friction with a new template, rule, or meeting.
This instinct is well-intentioned. But over time, it creates rigidity. The organization begins to optimize for process compliance rather than adaptability. People feel constrained, and operational debt accumulates. Teams wind up spending more time maintaining work systems than solving problems.
What I recommend:
Pause before formalizing a process. Ask: Is this a recurring problem? Have we tried solving it manually more than once? Could this be addressed through clearer ownership or communication instead? Often, the right response is to clarify the work, not to create a new workflow. If not, resist the urge to systematize. Some aspects of product work—especially cross-functional collaboration—require human judgment more than process enforcement.
5. Mistaking Operational Fluency for Product Skill
One of the more subtle and persistent issues I see is the assumption that strong operational fluency equates to strong product management. A product manager who runs meetings efficiently, manages the roadmap with precision, and easily navigates new tools is often viewed as “effective.” For example, there’s a tendency to equate knowledge of Agile frameworks with good product management.
While operational capabilities can certainly support product success, they are not the core of the role. A PM can be excellent at execution and still struggle with customer insight, trade-off decisions, or strategic alignment.
What I recommend:
Protect product managers’ time and attention so they can focus on customer insight, decision-making, and alignment. Create operational scaffolding to support them without expecting every PM to also be an expert in process, tooling, and internal governance. Build a Product Ops team to help enable critical thinking, customer-centricity, and cross-functional alignment as well as provide access to strong operational tools and support.
Defaults Worth Keeping
Not all defaults are problematic. Some common practices exist because they address real, repeatable needs. I rarely challenge the following, though I tailor them carefully to each organization:
Create structured moments for alignment.
Planning rituals, decision reviews, and cross-functional syncs offer critical opportunities to create shared understanding. These rituals don’t need to be overly formal, but they should be intentional.
Document decisions, not just plans.
Good roadmaps are more than prioritized lists. They capture why certain paths were chosen, what trade-offs were made, and where uncertainty remains. Decision logs often serve a team far more than timelines.
Invest in enablement.
Playbooks, onboarding, and templates can be powerful when designed to teach thinking frameworks, not just tasks. The goal isn’t to automate behavior but to accelerate good judgment.
Process is not the enemy. But when it becomes the default response to uncertainty, it loses its value.
Product Operations exists to support clarity, alignment, and adaptability. Sometimes that means introducing structure. Sometimes it means clearing it away. The goal is never to control the work; it’s to make the work better.