I keep a simple mantra front and center: Figma is not the source of truth. The customer is. In practice, that means the only thing that truly counts is what we ship, how it performs, and whether users come back for more. Mockups are hypotheses; production usage is evidence. When my teams adopt this lens, velocity improves, judgment sharpens, and quality rises where it matters most.
So what does design actually do in a software company? At its best, design builds leverage for the whole system—engineering, product, and marketing—by clarifying problems, raising the quality bar, and making complex decisions legible. The standard I hold is ancient and still essential: products must be useful, usable, and desirable — and above all, used. When we calibrate around “used,” debates about pixels give way to outcomes, and cross-functional partners feel the difference.
I often trace the roots of our craft back well beyond the digital era. The lineage from industrial design to software is real; constraints, ergonomics, affordances, and systems thinking didn’t start with screens. If you’ve ever mapped delight, performance, and reliability in a Kano Model, you’ve touched this lineage. The translation to software is simple: design the full journey, not just the interface—prioritize what improves time-to-value, reduces cognitive load, and earns habitual use.
One lesson I’ve learned the hard way: why design leaders who stop designing stop leading. I still sketch flows, write UX copy, and prototype when it unblocks the team or sets a decisive quality bar. The altitude changes constantly—one hour I’m in a strategic roadmap review, the next I’m in a critique or poking at a prototype. Great design leaders jump up and down in altitude to connect vision to details without becoming a bottleneck.
Over time, I’ve come to rely on four pillars every design manager must master: craft (raising taste and execution), product strategy (clarifying choices and trade-offs), people leadership (coaching, feedback, and hiring), and systems (processes, rituals, and design ops that scale). Neglect any one of these and either quality, speed, or team health will eventually falter.
Perfectionism is a double-edged sword. Over-indexing on quality can paralyze decision-making, but lowering the bar indiscriminately is worse. I’ve seen moments where relaxing standards to “go faster” actually cost the business—rework piled up, trust eroded, and customer value stalled. The answer is principled delegation: I define what “must be true” at each milestone, delegate ownership with clear guardrails, and reserve my veto power for moments where product integrity is genuinely at risk.
Measuring success as a design leader starts with outcomes vs output OKRs. I care about activation, retention, time-to-first-value, NPS verbatims tied to key journeys, and the operational metrics that earn the right to build the next thing. Design output is visible; design outcomes are durable. When trade-offs are needed, I optimize for the smallest shippable surface that still proves the core value proposition, then expand with data.
Scaling judgment is the multiplier. I build it through pattern matching—studying enduring product systems from companies like Airbnb, Amazon, Apple, Asana, Notion, Stripe, Nest, and others—to distinguish where polish compels usage versus where it’s ornamental. Strong opinions matter, but so does being easy to convince with new evidence. I encourage designers to articulate the pattern they’re invoking, why it fits the job-to-be-done, and how we’ll know it worked.
Operating cadence matters. My week is anchored around recruiting, crits, and staff meetings that actually make decisions. In critiques, I use the Do/Try/Consider framework to give actionable direction without micromanaging. On one-on-ones, the question isn’t “Should one-on-ones exist?” but “What are they for right now?”—coaching, performance, or clearing execution blockers. If a meeting doesn’t increase clarity or commitment, it gets redesigned or removed.
Execution-wise, I’ve taken inspiration from Rippling’s operating system—especially its emphasis on speed, precise ownership, and hard commitments. The lesson is timeless: go fast on the right things, make clear promises, and instrument your work so you can see reality quickly. When speed is paired with crisp decision rights and observable outcomes, momentum compounds rather than frays trust.
Hiring your first design leader? Look for someone who can set standards, scale judgment, and ship. They should be able to zoom from company narrative to interaction copy in a single afternoon, coach product trios, and build rituals that make taste and trade-offs explicit. Above all, they should have a point of view on where quality moves the business and where speed is the quality.
Here’s how my team’s approach differs from many: Figma is not the source of truth. We design in Figma, but we learn from production. We pair designers with engineering early, prototype in code when it reduces risk, and wire telemetry into every critical path. Product trios use discovery to validate “useful, usable, desirable — and used,” then commit to outcomes with clear, testable definitions of success. The result is faster iteration, fewer surprises, and experiences customers actually adopt.
The throughline is simple and demanding: design for reality, not for the board. Keep your standards where they create business value, scale judgment with explicit patterns, and instrument everything so learning never stops. When teams embrace that, the work gets better, customers feel it, and the roadmap starts to pull you forward.
The most valuable lesson I’ve learned leading product organizations is that portfolio choices make or break outcomes. In an era of infinite requests and finite teams, the question isn’t what we could build—it’s what we must build next. That’s why I’m codifying a pragmatic, AI-driven playbook to optimize the product portfolio while staying true to outcomes, not output.
AI-powered product portfolio optimization is here. Explore strategies and tools helping product leaders manage complexity and boost ROI.
My starting point is a data backbone that connects strategy to reality. I aggregate product usage, revenue by segment, cost-to-serve, retention cohorts, and support signals into a unified analytics platform, then layer a retrieval-first pipeline so LLMs can reason over clean context. Instrumentation matters: Amplitude analytics, Pendo, and in-app guides provide the behavioral and activation signals that make prioritization measurable.
From there, I translate strategy into an objective decision system. I express outcomes vs output OKRs, align initiatives to value proposition and competitive differentiation, and classify opportunities with the Kano Model. LLMs for product managers help cluster voice-of-customer at scale; with thoughtful prompt engineering and AI workflows, I can map themes to jobs-to-be-done, quantify demand, and de-duplicate asks across stakeholders.
Execution hinges on evidence. I run A/B testing with a clear minimum detectable effect (MDE), pair it with eval-driven development for AI features, and ship through CI/CD while tracking DORA metrics. This closes the loop between product roadmapping and sprint planning and real-world performance—activation, retention analysis, and Web Vitals inform the next set of portfolio bets.
Trust is a feature, so governance is built-in. Privacy-by-design, data governance, and AI risk management guide how we store, prompt, and evaluate models. I apply guardrails to sensitive workflows and define success metrics that balance short-term ROI with long-term resilience and regulatory compliance.
The operating model matters as much as the models themselves. Product trios and empowered product teams run continuous discovery, pressure-test assumptions in QBRs vs OKRs, and make trade-offs visible. Stakeholder management becomes easier when the portfolio narrative is anchored in transparent scenarios and shared metrics.
If you’re getting started, here’s my flow: unify data, define outcomes, segment opportunities, simulate scenarios, and test fast. Use LLMs to synthesize signals you’d never humanly read, then make one focused bet per team that moves a measurable KPI. Rinse, learn, and reallocate—portfolio optimization is a living system, not an annual meeting.
Ultimately, the promise of this new playbook is simple: less noise, sharper focus, and compounding ROI. By pairing AI Strategy with disciplined product management leadership, we can manage complexity with clarity—and consistently build what matters most.
Your team has more plausible work than capacity. Sales has a customer commitment, support sees recurring friction, engineering sees reliability debt, and executives want a differentiator. Every item can be defended. That is exactly why ranking features is the wrong first move.
An outcome-led system changes what earns priority. You first decide which customer behavior, product condition, or business result needs to change. Then you compare opportunities and solution bets by how credibly they can cause that change. The roadmap becomes a record of choices, evidence, and trade-offs rather than a queue controlled by the loudest request.
Prioritize the change before you prioritize the work
An output is something the team delivers. An outcome is an observable change the team intends to cause. Launching an onboarding flow is an output. Increasing the share of new customers who complete setup successfully is an outcome. The distinction matters because a team can deliver the first without achieving the second.
A usable outcome needs more than a metric name. It should identify who is affected, what behavior or condition should change, why that change matters, how it will be observed, and which guardrails must remain healthy. If you cannot describe how the world should be different after the work succeeds, the item is not ready to compete for priority.
Use an outcome card before accepting solution proposals:
Decision context: the strategic problem that makes a choice necessary.
Target population: the customer segment, user role, or workflow affected.
Current state: the observed behavior, baseline signal, or product condition.
Desired movement: the direction of change and, when the evidence supports it, a meaningful target.
Strategic connection: how the change supports growth, retention, trust, efficiency, or another declared priority.
Guardrails: the signals that must not be harmed while the primary outcome improves.
Review trigger: the evidence or constraint change that would cause leadership to reconsider the outcome.
Do not invent a precise target when no baseline exists. The first commitment may need to be instrumentation, observation, or a small test that establishes the current state. False precision makes an outcome look settled while hiding the most important uncertainty.
The following layers prevent strategy, outcomes, opportunities, bets, and outputs from collapsing into one roadmap item:
Layer
Decision question
Illustrative setup example
Strategic intent
Why does this area matter?
Make first use dependable for new customers.
Outcome
What observable change should occur?
Increase the share of new administrators who finish setup without support.
Opportunity
What unmet need or obstacle prevents that change?
Administrators cannot tell which permissions are required.
Bet
What intervention might address the opportunity?
Test guided permission configuration.
Output
What would the team actually deliver?
Release the validated setup change.
This separation gives you several places to change course. If the bet fails but the opportunity remains important, try another solution. If evidence shows the opportunity was misdiagnosed, investigate another obstacle. If the outcome no longer supports strategy, stop the entire branch. Without these layers, leaders often preserve a feature commitment long after its original reasoning has failed.
A company-level result such as revenue can be valid, but it may be too distant for a product team to manage directly. Connect it to customer behavior and product signals the team can influence. Pair each primary signal with a guardrail: setup completion with setup errors, faster resolution with customer-reported quality, or increased usage with reliability. A metric can improve through the wrong mechanism, so success needs a boundary as well as a direction.
Translate strategy into a decision boundary teams can use
Outcome-led leadership does not mean selecting a metric and disappearing. Leadership owns the strategic context, the outcome boundary, the investment constraints, and the conflicts that individual teams cannot resolve. The team needs room to investigate opportunities, compare solutions, and stop weak bets without asking permission at every step.
Training teams in discovery while leaders continue to manage through feature requests, static roadmaps, and approval gates teaches the organization that customer evidence is secondary. Teams may perform interviews and experiments, but they will still optimize for getting a predetermined feature approved and shipped.
A clear outcome statement can act as a decision boundary:
For [target segment] in [specific situation], improve [behavior or product condition], observed through [primary signal], because [strategic reason], while protecting [guardrails]. Explore opportunities within [scope and constraints] without assuming [requested solution].
The last clause is important. A feature hidden inside an outcome statement is still a feature mandate. Improve adoption of the new dashboard assumes the dashboard is the answer. Help account owners notice and act on performance risks leaves room to discover whether a dashboard, alert, workflow change, or no new interface is the better intervention.
Build a driver tree when the connection between strategy and team behavior is unclear:
Place the business result at the top.
Identify customer behaviors or product conditions that may contribute to it.
Attach observable product signals to those drivers.
Map the customer opportunities that could change each driver.
Mark every unproven connection as an assumption, not a fact.
The tree is not proof of causality. It is a visible model of the current reasoning. That visibility helps teams choose what to validate and helps leaders see where a confident roadmap rests on a weak connection.
Before assigning an outcome, leadership should answer four practical questions:
Why does this outcome deserve investment ahead of the alternatives?
Which constraints are fixed, and which are merely preferences?
Which decisions can the team make without another approval?
What evidence would cause leadership to change the outcome or its investment?
A team cannot genuinely own an outcome when every solution needs executive approval, critical dependencies remain unresolved, or performance is judged only by shipping. That arrangement gives the team accountability without authority. The leadership task is to remove those contradictions before asking the team to move a metric.
Prioritize opportunities with evidence, then shape the portfolio
Use an eligibility gate before a ranking formula
I prefer a gate before a rank. It prevents a polished request with a confident sponsor from competing against a well-understood opportunity merely because both have feature names and effort estimates.
A candidate should become eligible for prioritization only when its decision brief covers:
Outcome relevance: the specific outcome it could affect.
Target evidence: the segment, situation, and observed problem behind it.
Mechanism: the reason this intervention might change the outcome.
Measurement: the primary signal, guardrails, and method of learning.
Critical assumption: the belief most likely to invalidate the bet.
Constraint fit: the technical, operational, and sequencing limits that matter.
Opportunity cost: the work, learning, or outcome investment that would be displaced.
Reversibility: the cost of changing course if the assumption proves wrong.
If a candidate cannot name its outcome or target population, return it to intake. That does not mean it lacks value. It means the organization does not yet have enough information to compare it honestly.
Scoring models can help expose disagreement, but arithmetic should not make weak evidence look objective. Record the reasoning behind each score. Ask which uncertain input has the greatest effect on the ranking. If a small change to that input reverses the decision, investigate the assumption before committing substantial capacity.
Compare opportunities before comparing solutions. Several feature requests may be different guesses about the same customer obstacle. Combining them at the opportunity level can reveal a smaller or more effective intervention. Conversely, two similar-looking features may serve different segments and outcomes, which means one score should not flatten them into a false equivalence.
Use the Kano Model to balance protection, improvement, and exploration
Outcome relevance tells you why an opportunity matters. The Kano Model adds a customer-expectation lens by separating capabilities into must-haves, satisfiers, and delighters.
Must-haves protect the baseline. When they are missing or broken, trust and satisfaction suffer even if the product has innovative features.
Satisfiers create more value as their performance improves. Compare the expected incremental outcome movement with the effort and risk required.
Delighters create unexpected value and differentiation. Treat them as hypotheses worth testing, not as compensation for a broken baseline.
Run the classification by segment and context. A capability can be essential for an advanced customer and irrelevant to a new user. Ask how the target customer would feel if the capability existed and how that same customer would feel if it did not. Pairing these functional and dysfunctional questions is more informative than collecting positive reactions to a proposed feature in isolation.
Do not translate the categories into equal allocations. The right portfolio depends on product maturity, strategic intent, and the condition of the core experience. Make the allocation explicit instead: which investments protect required value, which improve an outcome customers already care about, and which explore future differentiation?
Revisit the classification after meaningful releases or market changes. A delighter can become an expected baseline, so yesterday’s differentiator may no longer justify the same investment. Usage, experiments, interviews, retention patterns, and support evidence should update the portfolio rather than merely confirm the original roadmap.
Run leadership reviews that force choices, not status reports
An outcome-led roadmap can still become output-led in the review meeting. If leaders ask only about delivery dates, scope, and percentage complete, teams will optimize for those signals. Separate the conversations that answer different questions:
Outcome review: Is the customer behavior or product condition moving, for which segment, and with what guardrail effects?
Discovery review: What changed in the team’s understanding of the opportunity, mechanism, or critical assumption?
Commitment review: Which bet should start, continue, change, or stop, and what does that choice displace?
These conversations can share a meeting, but they should not share one vague status label. On track can mean delivery is proceeding to plan while the underlying evidence is weakening. Healthy delivery and healthy product reasoning are different states.
Use a compact review board with the outcome and segment, current signal relative to baseline, strongest new evidence, largest unresolved assumption, active bet, decision required, and displaced work. Feature completion belongs in the delivery portion of the review. It should not stand in for evidence that the outcome is becoming more likely.
Leaders should repeatedly ask:
What did the team learn that it did not believe before?
Which evidence supports or weakens the proposed mechanism?
Is the outcome still right even if the current solution is wrong?
What is the smallest next commitment that resolves the most consequential uncertainty?
What will stop or move if this work receives priority?
Does the team need a decision, a constraint removed, or simply space to continue?
Set decision conditions before attachment to a solution grows. Continue a bet when the evidence strengthens its mechanism. Change the bet when the outcome and opportunity remain valid but the solution does not. Move to another opportunity when the original problem is weaker than expected. Reconsider the outcome when its strategic premise or target segment changes. Stopping a bet is not abandoning outcome ownership; it is one of the ways outcome ownership becomes real.
Stakeholder requests need the same discipline. Translate each requested feature into an intake record that identifies the affected customer, the situation, the observed problem, the evidence, the desired behavior change, the timing constraint, and any alternatives already tried. A request earns evaluation, not an automatic roadmap position.
A useful escalation rule is simple: anyone asking to add committed work must identify what should leave, or explain which outcome or constraint has changed. This turns hidden priority overrides into visible strategy decisions. Seniority may change who has decision rights, but it should not erase opportunity cost.
Before changing the entire organization, use a pilot team to surface decision bottlenecks, incentive conflicts, stakeholder friction, and policy barriers. Track where the team still needs feature approval, where evidence loses to hierarchy, and where another function is rewarded for behavior that undermines the outcome. Those blockers are leadership work. Scaling the workflow without resolving them only distributes the same conflict more widely.
Key takeaways for your next prioritization review
Prioritize an observable customer, product, or business change before ranking proposed outputs.
Give each outcome a target population, baseline signal, strategic connection, guardrails, and review trigger.
Separate outcomes, opportunities, solution bets, and outputs so a failed solution does not preserve itself as a permanent commitment.
Use an evidence gate before scoring, and expose the assumption that could reverse the ranking.
Balance Kano must-haves, satisfiers, and delighters deliberately instead of treating every request as the same kind of value.
Make leadership reviews decide what starts, changes, stops, or gets displaced.
Convert stakeholder urgency into evidence, constraints, and explicit opportunity cost.
At your next roadmap review, take the highest-ranked feature and rewrite it as an outcome statement. Require competing bets to name their evidence, critical assumption, guardrails, and displaced work. If the team cannot do that yet, commit to resolving the uncertainty rather than pretending the feature is ready.
At the following review, ask what changed in the customer signal or the team’s belief before asking what shipped. That question reveals whether your operating system actually rewards outcomes or merely uses outcome language around a feature queue.
