The Week Everything Launched Simultaneously
In the spring of my second year as Product Head at UpGrowth, we launched three product updates in a single week. Not a planned, coordinated release. Three separate product teams, operating on three separate roadmaps, converging on the same week through a combination of deadline pressure, miscommunication, and the kind of optimism that accumulates in organizations where nobody wants to be the person who says "we should probably push this."
By Wednesday afternoon, we had a critical bug in the growth platform affecting approximately 8,000 daily active users. A UX change in the CRM product that had invalidated a workflow used by our enterprise clients, generating five urgent support escalations by lunchtime. And a new monetization feature in the analytics product that was working correctly but whose pricing logic had been implemented in a way that conflicted with an existing discount scheme for three of our largest accounts.
I spent that week entirely in crisis mode. Engineering teams triaging bugs, account managers on calls with enterprise clients, me in back-to-back conversations trying to understand what had broken and what needed priority, while also managing a leadership team that was stressed, a CEO who was asking reasonable questions I didn't have good answers to, and an engineering organization that was feeling the consequences of moving faster than the system could absorb.
The bugs got fixed. The enterprise clients stayed. The pricing conflict was resolved. Nobody quit. It wasn't a catastrophe.
But sitting in my car at 11pm on Friday, trying to decompress, I had a sharp and uncomfortable realization: I had built the conditions for this week to happen. Not through any single bad decision, but through a series of good-sounding decisions that, in aggregate, had created an organization that was optimizing for shipping velocity without adequate coordination infrastructure. The week I had just survived was not bad luck. It was the predictable output of a system I was responsible for designing.
"The worst week I had as Product Head was the one that taught me the most. Not because I learned from failure in a comforting way. But because I couldn't blame anything external. The system was mine. The failure was mine."
This story is about what I built before that week, what I rebuilt after it, and what I learned about decision coherence — the organizational capability that determines whether a growing product organization generates coordinated value or expensive chaos.
Scale is Not Just Numbers
When people talk about "scale" in product organizations, they usually mean user numbers or revenue. UpGrowth was scaling on those dimensions. But the scale that I was dealing with was organizational — the complexity that comes from coordinating many people across many products toward shared goals, when the people, products, and goals are all evolving simultaneously.
At its core, organizational scale creates a decision-making problem. In a small team of 5–8 people, decisions happen fast. Everyone knows what everyone else is doing. Context is shared implicitly. Coordination is nearly free. As teams grow, coordination costs rise. At 15–20 people, explicit communication structures become necessary. At 40–50 people, you need something more systematic — processes, rituals, documentation, organizational structure that distributes decision-making authority while maintaining coherence.
UpGrowth, when I joined as Product Head, had approximately 50 people in the product and technology organization. It had been growing quickly and the organizational infrastructure for that size — the decision-making frameworks, the communication patterns, the coordination mechanisms — hadn't kept pace with headcount growth. The team was operating like a 20-person startup with 50-person complexity.
What UpGrowth Did
UpGrowth was a growth-focused technology company operating across multiple product lines that served B2B clients with marketing, analytics, and CRM tools. The product portfolio included:
- Growth Platform: The core product — campaign management and marketing automation for performance marketing teams
- Analytics Suite: Attribution, funnel analysis, and reporting tools for digital marketers
- CRM Integration Layer: Middleware connecting marketing data to client CRM systems
- Monetization Intelligence: A newer product line helping clients optimize revenue generation from their existing user base
Each product line had its own engineering team (8–12 people), a product manager, and dedicated design resources. The four teams shared infrastructure but operated with a high degree of independence. This independence had been an intentional choice — enabling each team to move fast without dependency on others — but it had created exactly the coordination failure that manifested in that bad spring week.
What I Inherited
My first 60 days at UpGrowth were spent understanding the organization before trying to change it. This was a conscious discipline that I had developed from earlier product experiences — the cost of misdiagnosing an organizational problem is at least as high as the cost of misdiagnosing a product problem.
The Good
The engineering talent was strong. I was consistently impressed by the technical depth of the engineers across all four product lines. The product managers were energetic and clearly committed to their products. The design team had a developed visual language and was producing polished work. Customer satisfaction, as measured by NPS and retention, was solid — the products were genuinely useful to clients.
The Problems
The problems were structural, not talent-related:
No shared prioritization framework. Each product team set its own priorities through an informal process that combined client requests, sales pressure, and product manager judgment. There was no mechanism for the organization to say "across all four products, these are the three most important things we're working on this quarter."
Disconnected roadmaps. The four product roadmaps were maintained independently and shared across teams infrequently. Teams often discovered mid-execution that two products were building adjacent features, or that a backend service change in one product would break assumptions in another. The three-launch-in-one-week scenario that produced the crisis was a direct consequence of disconnected roadmaps.
Unclear ownership at the intersection. When a problem or opportunity sat at the boundary of two product lines — which happened frequently, because the products were tightly integrated for clients — ownership was ambiguous. This created either duplication (two teams building similar things without coordination) or gaps (both teams assuming the other was handling it). Both were expensive.
Measurement inconsistency. Each product team measured its success differently. Growth Platform measured by active campaigns and campaign success rates. Analytics Suite measured by dashboard sessions and report exports. CRM Integration measured by integration uptime and data sync success rates. Monetization Intelligence was still figuring out its metrics. There were no company-level product metrics that could give leadership a coherent view of product health.
Sales-driven reactive prioritization. Approximately 40% of engineering time across the organization was being consumed by client-specific feature requests — things that individual clients had asked for, that sales had committed to, that hadn't been evaluated against the broader product strategy. This wasn't wrong in principle — client feedback is valuable — but the process for evaluating and incorporating it was absent, leading to reactive one-off builds that didn't compound into strategic product strength.
The Decision Coherence Problem
I want to spend time on what I mean by "decision coherence," because it's the conceptual center of everything I did at UpGrowth, and it's a concept that I don't think is articulated clearly enough in most product management thinking.
Decision coherence is the degree to which individual decisions, made across different people and teams over time, accumulate into a consistent and strategically sound direction. A highly coherent organization makes many decisions that compound productively — each decision builds on and reinforces others, creating clear momentum. An incoherent organization makes many decisions that partially cancel each other out, creating noise, churn, and confusion about where the organization is actually going.
The Components of Coherence
Decision coherence has three components:
Strategic clarity: Does everyone in the organization understand what the organization is trying to achieve? Not just the mission statement, but the specific bets being made — which user segments, which product capabilities, which business outcomes — for this specific period of time.
Decision authority mapping: Does everyone know who is authorized to make which decisions, and at what scope? Incoherence often comes from decisions being made at the wrong level — too centralized (everything needs CEO approval, creating bottlenecks) or too decentralized (teams making decisions with organization-wide consequences without sufficient coordination).
Information flow: Do the people making decisions have the information they need? Coherent decisions require complete information. When decisions are made on partial information — because the relevant context is in another team, another system, or another person's head — they are systematically biased toward local optimization at the expense of global coherence.
At UpGrowth when I arrived, all three components were weak. Strategic clarity was low — the company had a direction but not a specific articulation of bets and tradeoffs for the year. Decision authority was uncharted — nobody had formally defined what product decisions required cross-functional approval and what were within each team's authority. Information flow was fragmented — the tools and rituals for sharing context across teams were inadequate for the organization's size.
Coherence is not about centralized control. It is about distributed decision-making within a shared framework. The goal is to enable every person in the organization to make good local decisions that add up to a good global outcome — without needing approval for every choice.
When Everything is Priority One
The symptom that most visibly manifested the coherence problem was priority inflation. In a system without clear cross-team prioritization, every request becomes urgent. Client X needs feature Y by end of month. Sales committed to client Z that we'd have capability W by next quarter. Engineering is blocked on infrastructure unless they upgrade the database — and that affects all four products. A competitor has released a feature that clients are asking about.
Everything is urgent. Nothing is prioritized. The team is busy constantly and productive intermittently.
The True Cost of Priority Inflation
Priority inflation has costs that are easy to undercount:
| Cost Type | Description | Frequency |
|---|---|---|
| Context-switching cost | Each priority switch costs 30–60 min of engineer re-orientation | Multiple times daily |
| Quality degradation | Rushed work produces more bugs, requiring more future rework | Continuous |
| Strategic drift | Reactive work crowds out proactive strategic investment | Cumulative |
| Team morale | Constant priority shifting creates a sense of chaos and futility | Continuous |
| External trust | Missed commitments damage client and partner relationships | Episodic |
The team I inherited was experiencing all five cost types simultaneously. The engineers were working hard. They were not, in aggregate, making the strategic progress the business needed. The gap between effort and output was the unmeasured cost of priority inflation.
The Uncomfortable Conversation
Fixing priority inflation requires an uncomfortable organizational conversation: saying no to some things so that the yes to others is meaningful. This is easy to prescribe and hard to do, because the things you're saying no to are usually someone's priority — a client need, a sales commitment, a leadership aspiration.
I had this conversation with the CEO and the sales and commercial leadership in my third month at UpGrowth. The substance of the conversation was: we need to stop saying yes to everything and start making deliberate, explicit tradeoffs about what we commit to. This will feel worse in the short term — some clients will be disappointed, some sales conversations will be harder. But the alternative is an engineering organization that is perpetually behind, perpetually stressed, and perpetually producing below its capability because it cannot maintain the focus required to do its best work.
The reception was mixed. The CEO understood and agreed. The commercial team was concerned about client impact. We agreed on a structured process for evaluating new commitments — a lightweight but explicit gate that would apply to any request that required more than a day of engineering time and hadn't been planned in the quarterly roadmap.
Building the PM Operating System
After the diagnosis and the uncomfortable conversations, the work began. I call what I built the "PM Operating System" — the collection of processes, tools, rituals, and frameworks that define how product decisions get made and communicated across the organization.
A well-designed PM OS has a specific property: it should make good decisions easier to make and bad decisions harder to make, without requiring significant overhead. If the OS requires enormous effort to operate, teams will route around it. The best operating systems are lightweight enough to be sustained but structural enough to change behavior.
Component 1: The Strategic Brief (Quarterly)
Each quarter, I wrote a Strategic Brief — a 3-page document that articulated three things:
The Situation: What is the current state of each product line, the market, and our competitive position? What changed last quarter? What are the key risks and opportunities entering this quarter?
The Bets: Given the situation, what are we betting on this quarter? What capabilities are we investing in, and why? What are we explicitly not investing in, and why? This is the hardest section to write honestly, because saying "we're not investing in X" requires standing behind that choice when X inevitably becomes the topic of someone's urgent request.
The Coordination Points: Where are the known dependencies between product lines this quarter? What decisions will require cross-team alignment? Who owns those decisions, and what process will govern them?
The Strategic Brief was shared with the entire product and technology organization on the first Monday of each quarter. It was also shared with the CEO and commercial leadership. Every important product decision made during the quarter was referenced back to it — "this is consistent with the Q3 bets" or "this is outside the Q3 scope and needs to go through the change process."
Component 2: The Roadmap Sync (Bi-Weekly)
I instituted a bi-weekly cross-team roadmap review — 60 minutes with all four product managers and representatives from engineering and design. The agenda was standardized:
- 15 min: What shipped in the last two weeks across all teams
- 15 min: What's planned for the next two weeks across all teams
- 15 min: Cross-team dependencies and coordination needs
- 15 min: Incoming requests and change requests (go/defer/no decision)
The roadmap sync did several things simultaneously: it created shared visibility (no team could launch something that affected another team without the other team knowing in advance), it surfaced coordination needs early (before they became crises), and it created a recurring space for the "go/defer/no" decisions on new requests.
Component 3: The Decision Log
I started maintaining a shared Decision Log — a running record of significant product decisions, with the date, the decision, the rationale, the alternatives considered, and who made the call. This document was not a bureaucratic formality. It served three practical purposes:
First, it created accountability. When a decision turned out to be wrong, we could review the log to understand what information we had at the time, whether the reasoning was sound, and what we'd do differently with the same information. This is different from looking at a bad outcome and asking "why did we make that stupid decision?" — which creates defensive behavior — versus asking "given what we knew, was the reasoning sound?" — which creates learning behavior.
Second, it reduced redundant debate. When the same question came up again (which it always does), we could refer to the log to find what had been decided before and why. If the context hadn't changed, we could move forward without relitigating. If the context had changed, we could acknowledge that explicitly.
Third, it created onboarding clarity. New team members could read the decision log to understand the reasoning behind the current state of the product — not just what decisions had been made, but why.
How I Structured the Team
Organizational structure is a product decision. The way you organize people determines the information flows, the decision authority, and ultimately the products that get built. Most organizations don't treat structure this deliberately — they inherit it or iterate on it incrementally without explicit strategic intent. I tried to design it.
The Starting Structure Problem
The structure I inherited was pure product-line alignment: four product teams, each with a PM-engineering-design unit, each reporting to me. This structure optimized for product-line velocity — each team could move fast within their domain. It did not optimize for cross-product coherence or for addressing market opportunities that didn't fit neatly within a single product line.
The most pressing strategic opportunity when I joined — enterprise client expansion — required capabilities across all four product lines working together in a coordinated way. The existing structure made this coordination almost impossible without significant overhead.
The Revised Structure
I introduced a matrix element to the product organization: in addition to the product-line teams, I created two cross-functional "capability teams" that operated across product lines:
Platform Integrity Team: A small team (3 engineers, 1 PM) responsible for shared infrastructure, API contracts between product lines, and the technical coherence of the integrated product suite. This team didn't ship user-facing features — it maintained the foundations that other teams built on. Before this team existed, infrastructure decisions were made independently by each product team, creating the technical debt and dependency failures that caused the bad spring week.
Enterprise Experience Team: A cross-functional team (2 engineers, 1 PM, 1 designer) dedicated to the enterprise client experience — the workflows, dashboards, and integration capabilities that enterprise clients needed across all four products. This team "borrowed" from the product-line engineering teams for deep feature work but owned the enterprise experience layer end-to-end.
This restructure was not universally loved. Product-line PMs felt some loss of control as cross-cutting capabilities moved into shared teams. The Platform Integrity team was initially seen as a bottleneck rather than an enabler. It took a quarter for the trust and working patterns to develop to the point where the structure was generating value rather than friction.
The Decision Authority Map
Alongside the structural change, I created an explicit Decision Authority Map — a document that specified, for every significant category of product decision, who had the authority to make it and what the escalation path was if consensus couldn't be reached:
| Decision Category | Primary Authority | Consultation Required | Escalation |
|---|---|---|---|
| Feature scope within product line | Product Line PM | Engineering lead | Me |
| Cross-product feature dependencies | Affected PMs jointly | Platform Integrity team | Me |
| Pricing changes for existing tiers | Me + Commercial lead | CEO | CEO |
| New product line initiation | CEO | Me, Commercial lead | Board |
| Enterprise client commitments >30 days work | Me + Commercial lead | Relevant PM + Eng lead | CEO |
| Technical architecture changes | Engineering leads collectively | Affected PMs | Me |
The Decision Authority Map was imperfect and required ongoing refinement. But having an explicit document that everyone could reference when a decision came up — instead of a fog of implied authority and political navigation — significantly reduced the time and energy spent on decision-making process rather than decision content.
The OKR Failure and Recovery
At some point in my first year, I decided that UpGrowth needed OKRs. Objectives and Key Results is a goal-setting framework with a good track record at organizations that implement it well. I had seen it work well in previous contexts. I introduced it at UpGrowth with what I thought was appropriate care.
The first OKR cycle was, in the honest assessment, a partial failure. Not a complete disaster — we set goals, we tracked progress, we reviewed them. But the OKRs didn't generate the organizational energy and focus that I had expected. Post-cycle review revealed why:
What Went Wrong with OKRs at UpGrowth
Too many objectives: Each product team set its own OKRs independently. After aggregation, we had 11 objectives and 34 key results across the organization. This is not OKRs — this is a project tracker with aspirational language. Genuine OKRs require ruthless constraint: 3–5 objectives maximum, each with 2–3 key results. Eleven objectives means no objectives.
Vanity metrics as key results: Several key results were metrics that could be gamed without actually achieving the underlying objective. "Increase feature release frequency" as a key result for an objective of "improve product quality" creates exactly the wrong incentive — teams ship more, ship faster, and produce lower quality in the process. A metric that can be improved without improving the thing you care about is a vanity metric.
No consequence architecture: At the end of the cycle, nothing happened based on OKR achievement. No recognition for teams that hit their goals. No post-mortem for teams that missed. The OKRs existed in a vacuum, disconnected from the organizational reward and accountability systems. Metrics without consequences are noise.
Quarterly cycles were too short: For a product organization working on capabilities that took 6–9 months to develop and validate, quarterly OKRs created artificial checkpoints that encouraged short-term thinking. Teams optimized for measurable quarterly outcomes rather than strategically important annual progress.
The Recovery
After the failed first cycle, I reset. The revised OKR framework at UpGrowth had four changes:
Annual company-level OKRs + quarterly team-level goals. The company set 3 objectives at an annual level — the things that mattered most over a 12-month horizon. Each team then set quarterly goals that were explicitly linked to one or more annual objectives. This created a hierarchy that connected daily work to long-term direction without requiring quarterly redefinition of strategic intent.
Outcome-only key results. Any proposed key result that was an activity (ship X features, conduct Y user interviews) was rejected in favor of outcomes (reduce user-reported errors by 40%, increase trial-to-paid conversion by 15%). This shift was more difficult than it sounds — outcome metrics are harder to define and harder to influence than activity metrics — but it created genuine accountability for results rather than effort.
Monthly progress reviews with learning dialogue. Monthly reviews that asked "are we on track, and if not, why not?" — creating early intervention capability rather than end-of-quarter surprises. The tone of these reviews was diagnostic, not judgmental: the question was "what are we learning?" not "who is failing?"
Annual retrospective with real consequence. At the end of the annual OKR cycle, we ran a structured retrospective that informed the next cycle's goal-setting, team structure decisions, and resource allocation. OKR outcomes mattered for real decisions — this gave the framework organizational weight it had previously lacked.
OKRs are not a management tool. They are an alignment tool. The difference matters enormously. Alignment tools work when everyone genuinely understands and believes in the goals. Management tools work when compliance is enforced. OKRs implemented as management tools produce the worst of both.
Growth Platform Architecture
The Growth Platform was UpGrowth's core product and the one I spent the most time on strategically. Understanding it deeply, and making the right architectural bets, was central to the company's long-term competitive position.
The Core Problem the Growth Platform Solved
Digital marketing teams at mid-to-large companies operate with a proliferation of tools: ad platforms (Google, Meta, LinkedIn, programmatic), attribution tools, CRM systems, analytics dashboards, email marketing platforms, push notification systems. Each tool generates data. None of them talk to each other cleanly. The marketing team's daily reality is toggling between tabs, exporting CSVs, manually reconciling numbers that don't match, and trying to synthesize a coherent picture of campaign performance across platforms.
The Growth Platform's promise was to unify this picture — to be the central layer that connected the data streams from all these tools and gave marketing teams a single, coherent view of their growth programs. The value proposition was real. The execution challenge was significant.
The Architecture Decisions That Mattered
During my tenure, three architectural decisions defined the Growth Platform's trajectory:
Decision 1: Event-based data model. We moved from a batch-report-based data model (nightly or weekly data pulls from ad platforms) to an event-based model (real-time event streams where supported, hourly updates where not). This significantly increased infrastructure complexity and cost. It was worth it because the batch model had been the primary source of client complaints about data freshness — clients couldn't trust dashboards that were 24 hours stale for making real-time budget decisions.
Decision 2: API-first integration architecture. Rather than building point-to-point integrations with specific platforms (an increasingly untenable approach as the number of relevant platforms expanded), we built a standardized integration API that could accept event data in a normalized format. New platform integrations became a matter of writing an adapter to the normalized format, rather than building a new point-to-point integration from scratch. This reduced the time to integrate a new platform from 6–8 weeks to 2–3 weeks.
Decision 3: Deferred the AI/ML capability. There was significant organizational pressure — from sales, from the CEO, from the market — to add AI-powered insights and recommendations to the platform. "Your competitors are doing it." "Clients are asking for it." "It's a market expectation now."
I chose to defer it. Not because AI/ML wasn't valuable — it clearly was. But because the data foundation for AI/ML to produce useful results wasn't solid yet. AI models that train on messy, incomplete, or improperly attributed data produce confidently wrong recommendations — which is worse than no recommendations. We needed the data architecture to be reliable before we could build intelligence on top of it.
This decision generated internal friction. It was the right call. When we eventually launched AI-powered features 12 months later, they were built on a data foundation that made them meaningfully accurate. The trust they generated with clients was directly attributable to that foundation investment.
Monetisation at Scale
UpGrowth had a monetization challenge that was interesting in its specific shape: the product was valuable but its pricing model wasn't capturing that value effectively. Clients were paying flat monthly fees that bore limited relationship to how much value they were extracting from the platform.
The Value Capture Gap
The flat-fee model created several problems:
High-usage clients — companies running large marketing programs through the platform — were effectively subsidized by low-usage clients. The margin on high-usage accounts was lower than it should have been because infrastructure costs scaled with usage while revenue didn't. Conversely, low-usage clients were paying for capabilities they weren't using, which made them feel the product was expensive relative to their specific value extraction.
The flat-fee model also made expansion revenue (revenue growth from existing clients) difficult to achieve. If a client doubled their marketing program size and ran twice as many campaigns through the platform, they paid the same fee. There was no mechanism for UpGrowth to capture a share of the growth it was enabling.
The Pricing Redesign
I led a six-month pricing redesign project that moved UpGrowth from a flat-fee model to a hybrid model combining a base platform fee with usage-based pricing on two dimensions:
Data volume: A per-event fee on data processed above a threshold, reflecting the actual infrastructure cost of high-volume clients while keeping the base fee accessible for smaller clients.
Campaign value: A percentage of managed media spend above a threshold — aligning UpGrowth's revenue with the value it was creating for clients running large programs.
The redesign required significant commercial and technical work: building usage metering infrastructure, redesigning the billing system, creating migration paths for existing clients, and developing the sales playbook for the transition.
The client transition was the most delicate part. Moving existing clients from predictable flat fees to variable pricing creates anxiety even when the new model is more favorable for most clients. We handled this through a 6-month parallel period — clients could see their projected spend under the new model before it went live, and those for whom the new model would mean significantly higher costs were given customized transition pricing that phased in the increase over time.
The outcome: revenue per client for high-usage accounts increased by an average of 34%. Churn in the six months post-migration was below historical baseline — a strong signal that clients understood and accepted the value argument for the new pricing. The total revenue impact was significant.
The Engineering Relationship
The relationship between product and engineering is the most important relationship in a product organization, and the most frequently mismanaged. I want to describe how I thought about and worked to build this relationship at UpGrowth, because it was central to everything that worked.
The Adversarial Default
Product-engineering relationships have a tendency toward a dysfunctional adversarial dynamic. Product says: "Engineering is too slow, they push back on everything, they don't understand the user." Engineering says: "Product doesn't understand technical complexity, they change priorities constantly, they don't plan enough." Both sides are partially right. The dynamic is toxic.
The root cause, in my experience, is usually a structural one: product and engineering are measured on different things, which creates different incentives, which creates different behaviors, which looks like personality conflict but is actually incentive misalignment.
What I Did at UpGrowth
The specific practices I implemented to build a healthier product-engineering relationship:
Engineers in the room for discovery. When talking to clients or users about problems and opportunities, I brought engineers into those conversations. Not to take notes — to hear directly from users what was valuable and what was broken. Engineers who hear users' frustration firsthand are more motivated to fix the problem and more invested in the solution direction. They also catch technical implications early that might change the product framing.
No surprises, ever. The commitment I made to engineering leads: you will never be surprised by a priority change without prior conversation. If I needed to change the roadmap based on a new client need or a market development, I talked to the engineering lead before the decision was final, not after. This created trust that the roadmap wasn't going to shift arbitrarily.
Tech debt as a first-class citizen. I allocated 20% of engineering capacity in every sprint to technical debt, platform improvements, and infrastructure work — the things that engineering cared about and that product managers often deprioritize because they don't directly produce new user-facing features. The reliability and velocity improvements from this investment were real and measurable, and they generated significant goodwill from the engineering organization.
Public recognition of engineering judgment. When engineers flagged a technical concern about a product direction and turned out to be right, I made a point of acknowledging that publicly — in team reviews, in retrospectives, in one-on-ones with the CEO. Engineering judgment deserves the same organizational respect as product judgment. Creating that parity through deliberate recognition changed the cultural dynamic.
The best product and engineering partnerships I've seen are characterized by shared ownership of outcomes, not separation of responsibilities. When engineers care about the user experience and product managers care about the technical foundation, the product is better. Engineering this shared ownership is the product leader's job.
Leadership in Ambiguity
Running a 50-person product organization across four product lines, in a company that was itself evolving its strategy and competitive position, meant operating in persistent ambiguity. The market was moving. The competitive landscape was shifting. The company's own strategic clarity varied with the business cycle. My job was to provide organizational direction when that direction was genuinely uncertain — not to pretend certainty I didn't have, and not to be paralyzed by the uncertainty.
What Leadership in Ambiguity Requires
I've thought a lot about what distinguishes leaders who navigate ambiguity well from those who don't. The distinguishing factors aren't what I expected:
Comfort with provisional decisions. In ambiguous situations, the choice is usually between making a provisional decision (with acknowledged uncertainty, clear reversibility conditions) and making no decision at all. The latter is almost always worse, because organizations default to the status quo in the absence of direction, and the status quo is rarely the right answer when circumstances are changing. Making good provisional decisions requires being genuinely comfortable saying "this is our best current judgment, here's what would change it."
Faster loops on reality-checking. Ambiguity is resolved by data. When the direction is uncertain, the highest-value activity is usually to design a quick test or observation that will reduce uncertainty before committing to a course of action. The leaders who navigate ambiguity best are the ones who identify the fastest path to reducing uncertainty, not the ones who tolerate the uncertainty longest.
The courage to name the ambiguity. A significant leadership failure mode is pretending to have clarity that doesn't exist — communicating false certainty to create organizational confidence, and then adjusting when reality diverges from the false picture. This erodes trust more than honest ambiguity acknowledgment ever does. Teams can handle uncertainty; they can't handle surprise discovery that their leader was never certain about something they were told was certain.
Maintaining principles in the absence of answers. When the specific direction is uncertain, principles can guide decisions. At UpGrowth, I tried to maintain three explicit principles that served as decision criteria when specific direction was unclear: "Optimize for the user experience before optimizing for the business metric." "Make the decision that keeps the most future options open." "Default to transparency, internally and externally." These principles weren't always the right answer, but they were consistent guides that prevented unprincipled expedience.
The Team That Grew Me More Than I Grew Them
I want to write something honest about the people at UpGrowth, because the narrative of product leadership can become overly focused on the leader's frameworks and decisions in a way that obscures where the real work happens: in the product managers, engineers, and designers who execute every day.
What I Learned From the Product Managers
I managed four PMs at UpGrowth, each at a different career stage and with a different set of strengths. Managing them well — understanding what each one needed to develop, where they were ready to be stretched, what kind of feedback they could hear and process productively — was harder than any of the strategic problems I was working on, and more important.
The PM I struggled with most was one who was technically excellent and had excellent relationships with her engineering team, but who consistently avoided difficult conversations with stakeholders. She would agree to timelines she knew were unrealistic rather than have the uncomfortable conversation upfront. She would let ambiguous requirements go into development rather than force the difficult specification conversation that would slow things down momentarily.
The feedback I gave her, repeatedly and with different framings, was: the short-term discomfort of a hard conversation is always less expensive than the downstream cost of the problem the conversation would have prevented. But I also had to examine my own role — had I created an environment where difficult conversations were appropriately rewarded? Were there signals that consensus-seeking was safer than truth-telling? The most useful feedback from this PM was indirect: her behavior was partially a reflection of the organizational norms I had created.
The Engineer Who Changed How I Think About Feedback
One of the senior engineers on the Growth Platform team had a practice that I've since adopted myself: he wrote weekly notes — not meeting notes, not documentation, but personal reflections on what he had worked on, what had been hard, what he had learned, and what he was worried about. He shared these with me and a few senior colleagues.
These notes were incredibly valuable. They surfaced problems and risks that weren't making it into formal channels. They showed me how he was thinking about his work — the mental models he was using, the assumptions he was making. They gave me a basis for much richer feedback than I could give based on output metrics alone.
I started writing similar notes myself and sharing them with my direct reports. The effect on communication quality in the team was significant. Written reflection creates a depth of thought that real-time conversation rarely achieves. And sharing that reflection — making it visible, making it vulnerable — creates a norm of intellectual honesty that transforms the quality of team dialogue.
The leaders who develop the best teams are usually the ones who are most deliberately developing themselves, and who make that development visible to their teams. Learning isn't just individual — it's cultural. When a leader models learning behavior, they create permission for everyone in the organization to learn publicly rather than privately.
Results: 12 Months of Clarity
I want to be careful here, because I think product leaders often take too much individual credit for organizational outcomes. The results at UpGrowth were produced by a team of 50+ people, most of whom were doing excellent work before I arrived and continued doing excellent work within and beyond the frameworks I introduced.
With that caveat: here is what the data showed 12 months after I implemented the organizational changes described in this story:
Revenue Per Client
The combination of the pricing model redesign and the enterprise experience investment drove a 62% increase in average revenue per client over 12 months. Net Revenue Retention — the measure of whether existing clients are spending more or less than they were 12 months ago — improved from 89% to 118%. Above 100% NRR means existing clients alone are growing the business, regardless of new client acquisition.
Engineering Quality and Velocity
Critical production bugs (bugs causing client-visible service disruption) decreased 45% over the year, driven by the Platform Integrity team, the tech debt investment, and improved pre-launch coordination. Somewhat counterintuitively, feature delivery velocity also increased 28% — the improvement in coordination quality and the reduction in context-switching from better prioritization freed engineering capacity that had previously been consumed by firefighting and rework.
Team Engagement
The company-wide engagement survey showed improvement across all measured dimensions for the product and technology organization. The most significant improvements were in "clarity of priorities" (+0.8 points) and "confidence in leadership direction" (+0.6 points) — exactly the dimensions that the organizational work had been designed to address.
The Metric I Didn't Have
The one metric I wish I had measured more rigorously: client perception of product coherence. Clients interacted with multiple UpGrowth products, and the quality of their end-to-end experience depended on how well those products worked together. I tracked this informally through client feedback and support escalation patterns, but I didn't have a formal measure. If I were doing it again, I'd invest more in designing that measure upfront.
What Scale Taught Me About Simplicity
The most counterintuitive thing I learned at UpGrowth — the insight that most surprised me and that I apply most consistently now — is that the answer to organizational complexity is not more sophisticated organizational management. It is simplicity.
This sounds paradoxical. A 50-person organization is complex. Surely it requires complex management? But the complexity of the organization is precisely why the management approach must be simple. When management systems are complex, people spend energy navigating the management system rather than doing the work. Simple systems, clearly communicated and consistently applied, scale better than sophisticated ones.
The Simplicity Principles I Ended With
Fewer objectives, clearly held. Three annual objectives, known by everyone in the organization, are infinitely more valuable than eleven quarterly objectives tracked in a spreadsheet that most people have stopped looking at.
Default to communication over documentation. Documentation is a complement to communication, not a substitute for it. The most important context transfer happens in conversation — in rituals, reviews, and genuine dialogue. Documentation preserves the artifacts of those conversations for future reference. Optimizing for the documentation at the expense of the conversation is a common error in scaling organizations.
The job of leadership is removing obstacles, not making decisions. In a mature product organization, most decisions should be made by the people closest to the work — product managers, engineering leads, designers. The job of the product leader is to ensure those people have the context, authority, and psychological safety to make good decisions, and to remove the organizational obstacles that prevent them from doing so. When I was spending my time making product decisions rather than enabling others to make them, I was failing as a leader.
What you choose not to build matters as much as what you choose to build. The organizations that maintain strategic coherence over time are the ones that are disciplined about what they don't do. Every "yes" has an opportunity cost. The job of prioritization isn't ranking things — it's choosing what to stop doing so that what remains gets done excellently.
Running a 50-person organization taught me that the measure of leadership isn't how many decisions you make. It's how well the organization makes decisions without you. If things break when I'm out, I've created dependency. If things run well, I've built a system. Building the system is the job.
I left UpGrowth with a deep respect for the difficulty of organizational product leadership and a specific set of practices that I've refined in every engagement since. The frameworks in this story are not theoretical — they came from two years of iteration in a real organization, with real people, producing real consequences when they were right or wrong.
That's the only kind of learning that sticks.