Most product discussions revolve around features. What ships next, what moves metrics, what users ask for. It's a reasonable frame — features are visible, debatable, and easy to track on a roadmap.
But in every company I've worked in, the real leverage hasn't been at the feature level. It's been structural. The bottlenecks that actually slow teams down are rarely about what to build. They're about how decisions get made, how ownership is distributed, and how trade-offs get resolved when engineering, design, and commercial teams want different things.
Product as operating model
At Omnipresent, hypergrowth exposed this clearly. We went from 50 to 500 people in under two years, and the friction that accumulated wasn't primarily a UI problem. It was a configuration problem. What was configurable by business teams? What required an engineer? What could be delegated to a customer, and what had to live inside the system?
Those decisions compound. A feature can be rewritten in a sprint. A structural decision embeds itself into how an organisation thinks, hires, and scales. The schema-driven form engine we built wasn't valuable because it was technically elegant — it was valuable because it moved a class of decisions out of the engineering queue entirely, and let regional teams own their own workflows.
The shape of the system matters more than the surface.
What this means in practice
Product, understood this way, is less about backlog management and more about systems design operating across org structure, incentives, and information flow. It asks different questions: not just what should we build, but what should the system make easy, what should it make hard, and who should be able to change it without asking permission.
This is the part that gets harder to see as teams grow. In a five-person company, the product IS the operating model — everyone feels the shape of every decision. At 200 people, the model has calcified into process, and the product has become a symptom of how the org is structured rather than a deliberate design.
The job of product, then, is to keep the system legible. To make the structural decisions visible before they harden, and to build the kind of configurability that lets the organisation change faster than its own tooling.
What AI changes
The same logic applies — and accelerates — when the execution layer is agentic. When Claude Code or Cowork can implement a workflow in hours rather than a sprint, the constraint shifts further upstream. The question is no longer just what to build, but what the system should be allowed to decide on its own, what it should surface for human judgement, and how you design the handoff between the two.
That's a product problem. It always was. AI just makes the structural decisions arrive faster, and the cost of getting them wrong harder to unwind.