Most product leaders inherit a team, a process, and an operating model. They optimize what exists. The harder assignment is building the product organization from scratch inside a company that has been shipping products without one.
I have done this three times. Each time, the company had engineering, sales, and operations. Each time, the company shipped products to customers. Each time, there was no product management function, no product operating model, and no structured way to decide what to build next. The product decisions were made by the loudest voice, the most senior engineer, or the most recent customer complaint.
The pattern that follows is not a theory. It is a field-tested operating model built across a $74M global construction technology company (100+ countries), a $125M enterprise IoT subsidiary of a $44B parent, and a $600M manufacturer serving Fortune 500 accounts across 23 industries.
What do you build first?
Not the team. The operating model.
The most common mistake I see new product leaders make is hiring before they have defined how the organization will make decisions. They staff up, then discover the company has no product roadmap governance, no intake process for feature requests, no framework for investment prioritization, and no shared language for discussing tradeoffs.
Build the decision-making framework first. Who has input. Who has veto. How priorities are ranked. How tradeoffs are communicated. What the cadence looks like: weekly, monthly, quarterly. What artifacts the organization produces and who consumes them. This operating model is the product the product leader ships to the rest of the company. It must work before the team scales.
How do you sequence the team build?
In a company with no product function, the first hire is not a product manager. The first hire depends on which capability gap is causing the most downstream damage.
At one company, the highest-damage gap was UX. The products worked, but the setup experience took 60 minutes per unit. Field operators were frustrated. Support costs were climbing. The first hire was a UX design lead who established a human-centered design system. Time-to-value dropped 68%. Support call volume followed.
At another company, the gap was customer intelligence. The company had no structured understanding of its own users across 23 industries. The first investment was field research: 41 enterprise customer audits, 96,000+ miles annually, cross-industry pattern mapping. That intelligence layer drove every subsequent product investment decision.
The sequence is: diagnose the highest-damage gap, hire for that capability, prove the value, then expand. Not the reverse.
What functions belong inside the product organization?
In a mature product org, five functions interact daily: Product Management, UX Design, Business Intelligence, Product Operations, and Go-to-Market. In a startup or turnaround, you build these over time. The order matters.
Product Management is the core. Strategy, roadmap, prioritization, customer requirements, competitive intelligence. This exists from day one, even if it is just the product leader doing the work personally.
UX Design is the first expansion. In B2B companies selling to field operators, factory workers, and technical users, the UX gap is almost always the largest drag on adoption, retention, and support cost. A design system established early creates compounding returns.
Business Intelligence is the second expansion. You cannot make data-driven product decisions if no one owns the data. BI builds the dashboards, defines the metrics, and creates the feedback loop between product usage and product investment.
Product Operations is the third expansion. Process documentation, tooling, release management, cross-functional coordination. Ops becomes essential when the team exceeds 10 people or the product ships to more than 5 markets. Before that, the product leader handles it.
Go-to-Market is the fourth. Pricing, packaging, launch coordination, sales enablement. In some organizations this lives in marketing. In product-led organizations, it belongs in or adjacent to the product org because pricing and packaging are product decisions, not marketing decisions.
I have founded three of these five functions from scratch at a single company. UX Design (including a named design system), Business Intelligence, and Product Operations. The product operating model I built remains in place years after my departure. That is the test of an org build: does it survive the builder?
How do you operate globally?
Shipping products to 100+ countries adds three layers of complexity: regulatory compliance, localization, and cross-cultural team coordination.
Regulatory compliance is a product requirement, not a legal afterthought. FCC, CE, UKCA, CCC, ITAR, CMMC, HIPAA, GDPR, CCPA. Each market has constraints that affect what the product can do, what data it can collect, where that data can be stored, and how the product is certified. Compliance must be embedded in the product development process, not applied after the product is designed.
Localization is not translation. It is product adaptation. 14 market groups. 40+ product variants. The same physical product configured differently for different regulatory environments, measurement standards, and operational practices. A localization program requires a structured charter that defines what varies by market and what stays constant globally.
Cross-cultural coordination is a leadership skill, not a process. I have led teams across the US, India, China, Germany, Romania, France, Philippines, and Australia. The lesson is not “use Slack” or “overlap hours.” It is: every culture has a different relationship with authority, disagreement, and deadlines. A German engineering team pushes back directly. An Indian development team signals concern through silence. A Japanese headquarters makes decisions through consensus that takes longer than Western product cycles expect. The product leader’s job is to build a communication cadence that respects these differences while maintaining shared accountability for outcomes.
What does the product operating model look like after 12 months?
If the build is working, after 12 months the organization has:
A roadmap governance process that leadership trusts. A prioritization framework that engineering respects. A design system that new products inherit. A metrics layer that connects product usage to business outcomes. A release cadence that customers and internal stakeholders can predict. A team that can operate without the product leader in the room.
That last point is the one that matters most. The product operating model must outlast the person who built it. If it depends on a single leader’s presence to function, it is not an operating model. It is a personality.
Build the model. Build the team. Build the cadence. Then build the products.