Every scaling company hits the same inflection point: the systems that got you here – won’t get you there. When Uber had expanded to hundreds of cities, the company faced an operational and communication nightmare that threatened to choke its exponential growth. Product teams in San Francisco were building features in isolation, while the city’s operation teams felt blindsided by launches. Roadmaps remained invisible and critical feedback disappeared into what frustrated teams called “a black hole.” This wasn’t a failure of talent or ambition—it was the predictable consequence of scaling without operational infrastructure.
Blake Samic was invited to Uber to address this growing business problem and did something considered counterintuitive at the time: he built ProductOps from scratch by hiring internally; embedding the function fully, rather than coordinating remotely and limiting problem-solving areas clearly. Within twelve months, the function achieved what he calls “product-market fit inside the company”—both product teams and operations leaders became enthusiastic advocates. By the time he left, that team of 50+ professionals was orchestrating over 200 beta tests and product launches annually across 10,000+ cities.
The pattern repeats across companies starting to scale. Outcomes of implementing ProductOps splits dramatically: some blame the function for adding bureaucracy and failing to simplify, while others achieve measurably superior efficiency. The difference hasn’t been the concept—it has been the execution. Creating great products requires more than skilled Product Managers collaborating with developers. It requires operational infrastructure: the documented playbooks that prevent each launch from becoming a unique coordination event, the data pipelines that make insights accessible without manual archaeology and the communication protocols that scale beyond hallway conversations.
This two-part guide distills Uber’s implementation playbook into actionable phases anyone can adapt for their organisation. Part 1 covers the foundational stages that determine whether ProductOps becomes your scaling advantage or an expensive mistake: recognising when you actually need it, conducting the research that defines scope correctly, hiring your first team members strategically and testing the embedded model that either builds credibility or confirms skeptics’ worst fears.
These aren’t theoretical suggestions —they’re tested frameworks that Blake made while navigating a messy reality of organisational politics, budget constraints and skeptical stakeholders. Supported by further research I’ve conducted, the insights apply whether you’re a 50-person startup anticipating growth or a 500-person company already drowning in coordination overhead. Let’s examine how Uber’s ProductOps went from zero to essential in eight critical phases.
Phase 1: When Coordination Becomes Chaos
Uber’s ProductOps origin story begins with a structural fracture that most scaling companies will recognise. As the company expanded toward 100 cities, each operating like an independent startup with its own P&L, the elegance of early proximity shattered. Feedback from drivers in emerging markets about broken fundamentals never reached the teams optimizing for Silicon Valley’s perfect conditions. The communication architecture that worked brilliantly when everyone shared the same building became a liability at global scale.
This wasn’t incompetence in leadership. It was the mathematical certainty of information degradation across expanding networks without infrastructure to support that expansion.
Four Diagnostic Signals Beyond “We’re Getting Bigger”
Most companies wait too long to implement ProductOps because they’re looking for the wrong signal. Company size alone doesn’t trigger the need—operational breakdown patterns do. Your organisation likely needs ProductOps if you’re experiencing:
Multi-team fragmentation: Product teams operating in parallel create competing priorities, duplicated work and misalignment that informal coordination can no longer resolve.
Portfolio complexity: Multiple revenue streams or service offerings lacking standardised processes create operational chaos regardless of team count.
Infrastructure lag: Rapid growth where expansion velocity exceeds the ability to build supporting systems—bandwidth constraints that hiring more product managers won’t solve.
Decision paralysis: Frequent bottlenecks where teams struggle to make decisions because information doesn’t flow to the right people at the right time.
Documenting Your Business Case
Blake Samic didn’t walk into a confused Uber — he walked into documented pain. For an executive looking to build a business case for ProductOps, convincing the peers requires the same evidence-based foundation.
What one needs to do is to start identifying where information flow fractures between product, operations and go-to-market functions. By quantifying the costs: missed launch windows, support volume from preventable issues, duplicated analysis work across teams. By interviewing stakeholders to capture specific coordination breakdowns rather than general frustrations.
The organisations that successfully implement ProductOps start by acknowledging that operational degradation isn’t failure—it’s predictable physics. The question isn’t whether you’ll hit these breaking points during growth. The question is whether you’ll build infrastructure before or after they constrain your velocity.
Phase 2: Do Your Research & Define Scope
The Slow-Motion Investigation That Saves Years
Blake Samic’s first months at Uber looked deceptively unproductive. While stakeholders wondered when he’d start “doing ProductOps,” he was conducting what amounted to organisational ethnography—detailed interviews with product management, operations leaders, customer support and marketing teams. He wasn’t searching for best practices from other companies. He was mapping the specific fractures in Uber’s internal nervous system, distinguishing between genuine process gaps and communication breakdowns that better meetings could solve.
This deliberate pace contradicts most executives’ instincts when they hire for a new function; the pressure to show immediate value pushes teams toward visible activity. All that can be put down in a report and measured for impact – implementing cool tools and launching new programs. Blake resisted this entirely. His boss eventually asked, “Are we going to ramp this up soon?”
The Dangerous Seduction of Sophistication
Sarah Marshall inherited a cautionary tale that every ProductOps founder should memorize. A previous team at her company had built an automated OKR tracking system that made work demonstrably worse—two-thirds of the effort went toward making information findable rather than capturing actual progress. The output quality fell below what teams achieved with basic spreadsheets. Her solution violated conventional wisdom: she removed the automation entirely.
This failure pattern reveals the trap to be avoided by early ProductOps functions. Organisations naturally assume that operational problems require operational complexities, where the solutions are elaborate. Reality inverts this logic. Early ProductOps credibility comes from subtracting friction, not adding infrastructure. Start with the simplest intervention that delivers measurable value, then build toward emerging gaps rather than anticipated ones.
Three Pillars, Not Thirty Responsibilities
Blake’s team eventually crystallised their scope into three specific pillars: surfacing global business insights, ensuring products worked beyond US markets and coordinating cross-functional launches. Notice what’s absent—no mention of tool management, no process optimization, no stakeholder reporting. This restraint wasn’t modesty; it was strategic clarity.
Best takeaway here is to follow suit — crafting a charter document needs similar specificity. Define 2-3 focus areas that address documented pain points, then explicitly state what ProductOps won’t handle. The boundaries matter as much as the scope, such examples like —ProductOps doesn’t replace product manager coaching, doesn’t dictate development methodologies, doesn’t become an approval bottleneck. Clarity about constraints prevents the function from becoming an organisational dumping ground for every coordination problem leadership doesn’t want to solve.
Phase 3: Hire Your First Team Members
The Internal Talent Hypothesis
Blake Samic made an almost counterintuitive hiring decision that would define Uber’s ProductOps trajectory: he recruited almost exclusively from inside the company. Not from product management—from city operations teams scattered across global markets. He wanted people who’d lived the consequences of poor coordination, who understood how products actually performed in São Paulo versus San Francisco, who carried operational frustrations from launches that blindsided their teams.
This wasn’t sentiment. It was strategic credibility-building. When someone who ran Uber’s Mexico City operations tells a product team their feature won’t work in emerging markets, that carries weight that no external consultant can manufacture. These weren’t junior coordinators either—Blake targeted senior operators with consulting or banking backgrounds who could think strategically while understanding ground-level realities. For organizations pioneering the function internally, the credibility advantage of insider knowledge outweighs the fresh perspective external candidates provide.
The Trap No One Warns You About
When one decides to search for external skillsets, the hiring paradox will sabotage candidate search. ProductOps person is as good as their ability to pinpoint the business problems and do something about it. ProductOps work experience in itself means almost nothing in 2025. Chen Siedner articulates the problem precisely—there’s still no standard format for what ProductOps managers actually do. One company’s ProductOps professional spent five years building data dashboards and analytics infrastructure. Another spent five years coordinating product launches and managing stakeholder communication. Same title, completely different skill sets.
This ambiguity creates a dangerous hiring scenario. You post a job seeking “3+ years ProductOps experience,” receive applications from people with that exact credential, and discover during interviews that their daily work bore no resemblance to the problems you need solved.
Hiring for Problems, Not Pedigrees
The solution requires reversing the hiring logic. Starting with the 2-3 pillars defined in Phase 2, understanding the specific operational challenges within each pillar will define the skillset needed. Helping to find people who’ve solved those exact problems regardless of their title.
Blake’s emphasis on senior hires with a co-founder mentality makes even more sense through this lens. Since the first hire will define what ProductOps means in the organization, the team will need someone with enough experience to create the format rather than follow one. The credential that matters isn’t previous job titles—it’s demonstrated ability to build operational infrastructure in ambiguous environments where the playbook doesn’t exist yet.
Phase 4: Test the Embedded Model
The Part-Time Illusion
Uber’s first attempt at ProductOps integration followed conventional wisdom: designate someone from operations to dial into product team meetings weekly, share the ground-level perspective, then return to their regular job. This model possessed superficial logic—why pull someone entirely from their role when they could serve dual functions? The experiment failed completely. Weekly check-ins carried no decision-making weight. By the time the ProductOps representative understood enough context to contribute meaningfully, the team had already committed to a direction.
Blake’s solution inverted the equation: fully embedding the functionality into the Product team itself, close to the decision-making process. ProductOps people sat physically with product teams, attended every standup, participated in daily decisions. They brought domain expertise so specific that one person focused exclusively on understanding how Mexico City’s valet culture required different product thinking than Mumbai’s street-hailing patterns.
Daily Standups: Where Real Problems Surface
Gerisha Nadaraju’s transition from Business Operations to embedded ProductOps revealed something Blake’s structural explanation missed: the mechanism that makes embedding powerful isn’t proximity—it’s rhythm. Strategic roles provide macro visibility of how teams coordinate on large initiatives, but that bird’s-eye perspective creates distance from daily operational friction. Participating in daily standups exposes micro-level challenges that never escalate to weekly status meetings.
This direct access advantage enables seamless improvements—small, timely tweaks that prevent problems from requiring formal process solutions. When you hear someone in standup say “we’d love to test this but need a data scientist,” you can immediately offer the initiative to a team that has analytical capacity. That opportunity doesn’t appear if ProductOps only attends weekly syncs, because by then the team has either abandoned the experiment or waited weeks for centralised resources.
Start Where Complexity Concentrates
The first embedding placement doesn’t just determine ProductOps credibility—it defines what ProductOps means to every team watching the experiment. Choose wrong, and the organization concludes ProductOps is an expensive coordination theater. Choose right, and teams start requesting their own embedded support before you’ve finished the pilot.
The selection criteria isn’t about company size or maturity—it’s about finding product teams where operational friction visibly prevents execution. The teams that know exactly what they should ship but can’t because feedback arrives fragmented across twelve channels; launches require manually coordinating eight stakeholders who each discover the plan at different times; or every market rollout becomes a unique coordination event that consumes three weeks of calendar Tetris. These aren’t large-company problems—a 30-person startup launching across three customer segments experiences identical friction.
Starting with 1-2 placements where little reductions of operational drag will produce unmistakable velocity gains. Giving the embedded people outcome direction rather than process mandates, will help to crystallise the role after 3-6 months based on what actually moved the constraint. The teams experiencing the most pain will tell you exactly what ProductOps should do.
The 20% time Blake mandated for “building ProductOps as a function” prevents a critical failure mode—getting so absorbed in one team’s problems that you never establish reusable infrastructure for the broader organization.
Conclusion: The Infrastructure That Scales
From Zero to Product-Market Fit in Twelve Months
Uber’s ProductOps journey from nonexistent to essential was achieved in a single year, something that most organisations stretch across three. The velocity came from executing these four phases with disciplined focus: documenting operational breakdown before proposing solutions, defining three specific pillars instead of solving everything, hiring senior internal talent who understood ground-level realities and embedding fully rather than coordinating remotely.
The pattern that emerges reveals why some organisations transform ProductOps into competitive advantage while others abandon it as bureaucratic overhead. Success requires resisting the impulse to immediately implement sophisticated tools and elaborate processes. Blake spent months researching before hiring anyone. His first hires received broad direction rather than rigid playbooks. Early programs started with 20% time allocations before warranting dedicated staff. Sarah Marshall’s cautionary tale about over-automation reinforces this principle—credibility comes from subtracting friction, not adding infrastructure.
What Part 2 Covers
These foundational phases determine whether ProductOps gains organizational legitimacy or confirms skeptics’ worst predictions. Part 2 examines how Uber scaled from initial credibility to 50+ people managing the success of 200+ annual launches: achieving internal product-market fit, scaling the embedded model strategically, introducing central programs without creating bureaucracy and measuring impact for continued executive support. The companies that crack ProductOps implementation aren’t working harder—they’re working systematically, building operational infrastructure before growth forces reactive crisis management.