I hear the same refrain from product leadership peers everywhere: we’re overwhelmed. Shrinking headcount, constant AI disruption, economic uncertainty, and relentless context switching make it feel like we’re carrying two jobs—setting strategy while shielding our teams. I recently listened to an episode of All Things Product that zeroes in on what a real support system for product leaders looks like, and it resonated deeply with my day-to-day.
Want to listen to the conversation yourself? Find it on Spotify or Apple Podcasts.
Here’s the core tension I see (and felt early in my own leadership journey): product leaders tend to underinvest in themselves. We hold onto work because it feels faster, safer, or “just easier if I do it.” But that pattern quietly taxes strategy, slows learning, and caps team throughput. The hidden cost of “doing it all yourself” is real.
Early in my tenure leading product, I tried to keep every plate spinning—roadmap reviews, stakeholder prep, user research, executive updates—while protecting my team’s focus. I was busy and useful, but not maximally valuable. The turning point came when I started building a lightweight support stack: a few hours of executive assistant help each week, targeted research support for bet sizing, and a personal cadence with a leadership coach. The result wasn’t just more time; it was better time.
One provocative point that landed hard: product leaders rarely have executive assistants—and that’s a problem. If your calendar is your operating system, an EA is an extension of your leverage. Mine now handles scheduling, meeting hygiene, prep packets, and post-meeting artifacts. That shift moved me from “calendar triage” to “strategic curation.” It also reinforced a core principle: delegation is a leadership skill, not a weakness. When I delegate outcomes (not just tasks), my team learns, ownership grows, and we ship decisions faster.
Support for strategy work shouldn’t stop at the calendar. Research and data enable better bets. Lightweight research ops, access to product analytics, and brief synthesis sprints keep me anchored in evidence without drowning in artifacts. Paired with a strong community of practice, I get a steady stream of comparative patterns—how other leaders delegate, scope advisory boards, or run decision reviews—which short-circuits trial-and-error.
Coaches were framed as shortcuts for clarity, accountability, and skill-building—and I agree. A good coach compresses cycles, sharpens decision quality, and holds the mirror up when you drift into doer mode. Two quotes captured the mindset perfectly: “You are a pro athlete. It makes sense to think about how you scale your impact without adding more to your calendar.” — Petra Wille. “As you get busier, it becomes more important to focus on the value only you can bring.” — Teresa Torres.
There’s also a helpful nudge to let go of perfectionism: “80% done by someone else is 100% awesome.” — Dan Martell (quoted). In practice, that means I accept great drafts from others, then add the 10–20% only I can contribute—context, narrative, and the sharp edges of the decision.
What about AI? The conversation hits a practical middle ground I share: use AI where it compounds leverage—meeting summaries, research synthesis starters, doc outlines, and backlog triage. But keep humans where judgment, alignment, and context truly matter—strategy framing, stakeholder management, and the final decision-making loops. In other words, apply an AI Strategy that respects product leadership’s uniquely human work.
Key themes I took away: why product leaders struggle to scale themselves; the true cost of “doing it all yourself”; why not having executive assistants limits impact; delegation as a core leadership capability; how to identify and protect the work only you can uniquely do; using research and data to inform strategy; coaches as accelerators for clarity and accountability; communities of practice as a force multiplier; adopting a “professional athlete” mindset; when AI helps—and when humans still matter; and the liberating mantra that “80% done by someone else is 100% awesome.”
If you’re wondering where to begin, start small and practical. Audit your time: what work truly requires you? Experiment with small amounts of support (even a few hours a week). Delegate outcomes, not just tasks. Keep the hands-on work you love—but be intentional. Use peers, coaches, and communities to learn how others delegate. Don’t wait until burnout to build your support system.
Resources mentioned if you want to go deeper: Follow Teresa Torres: https://ProductTalk.org. Follow Petra Wille: https://Petra-Wille.com. Petra’s Coaching for Product Leaders: https://www.petra-wille.com/coaching-packages. Dan Martell’s book Buy Back Your Time: https://www.buybackyourtime.com.
I’m curious: what’s one outcome you’ll delegate this week, and what support would make it stick? Share your thoughts in the comments—your playbook might be exactly what another product leader needs right now.
Is hiring broken—or just badly designed? I’ve been sitting with that question after a recent conversation that crystallized what I see across product organizations: AI-fueled application overload, sprawling interview loops, and fuzzy criteria that invite groupthink at exactly the wrong moments. If you’ve ever watched a promising candidate stall out late in the process, you’re not alone. Listen to this episode on: Spotify | Apple Podcasts.
Here’s the reality I’m observing in the market: Layoffs and hiring freezes have flooded the funnel, while AI tools make it trivial to submit hundreds of applications. Companies are overwhelmed, so they respond by adding more interviews and more stakeholders, hoping more touchpoints equal better signal. In practice, that complexity often dilutes accountability and increases noise—especially for product management leadership roles where clarity, not consensus theater, determines success.
I’ve seen too many offers derailed by “one last step.” A candidate clears every structured interview, then a casual lunch or unframed panel suddenly becomes the deciding factor. The team isn’t briefed on what to evaluate, one lukewarm comment lands, and group dynamics cascade into a no-hire. That’s not rigor—it’s randomness masked as prudence.
Groupthink ≠ good hiring decisions. When everyone has veto power, risk-averse no-decisions become the default. Focus-group-style interviews create bias, not signal, and “culture fit” often becomes a proxy for stereotyping or personal preference. As product leaders, we’d never ship a feature based on vibes; we shouldn’t make high-stakes hiring calls that way either.
There’s a better way—and it mirrors how we run great product discovery. Define who you’re hiring before writing the job description. Set clear success metrics for the role. Assign each interviewer specific criteria to evaluate. Treat hiring like product discovery: intentional, structured, and evidence-based. In my teams, that looks like tight scorecards, interviewer calibration, and a decision owner who synthesizes evidence—not a popularity contest where the loudest voice wins.
Chemistry checks still matter, but only when we define what collaboration actually means for the role. Introversion, debate style, or lunch-table small talk are not performance indicators. I look for behaviors we value in empowered product teams—clarity of thinking, healthy dissent, co-creation under constraints—often via a real working session with the future product trio. Diverse teams outperform homogenous ones, even if not everyone “vibes,” so I optimize for complementary strengths over sameness.
If you’re a candidate, remember: When a process feels broken, it’s often not about you. Ask how you’re being evaluated to gauge process maturity; a thoughtful team will happily walk you through their rubric and what great looks like. For structure and support, I’ve seen “Who: The A Method for Hiring” help leaders clarify requirements; “Never Search Alone” and joining a Job Search Council (JSC) can give you peer accountability and sharper narratives. For current openings, I regularly point PMs to Scott Baldwin’s PM job postings on LinkedIn.
My challenge to fellow product leaders: Audit your hiring process the way you’d audit your roadmap. Where are decisions getting stuck? Where are you over-indexing on consensus and under-indexing on evidence? Tighten the criteria, streamline stakeholders, and instrument the funnel so you can learn and improve. The payoff is faster, fairer, more confident decisions—and teams that reflect the rigor we expect in product strategy and stakeholder management.
What’s one change you can make this week—reworking the scorecard, calibrating interviewers, or replacing an unstructured lunch with a real collaboration exercise? Small improvements compound. Let’s build hiring systems that are worthy of the talent we’re trying to attract.
Your AI support pilot can look successful while the service operation gets worse. The agent closes more conversations, but customers repeat themselves after escalation, risky cases receive plausible but incomplete answers, and human agents inherit a queue made almost entirely of exceptions.
If you own this transformation, your job is not to install an AI agent. It is to redesign how customer demand moves through knowledge, automation, human judgment, and product feedback. You also need to prove that a conversation marked resolved was actually resolved. That requires an operating model, not just a deployment plan.
Start with an operating thesis, not a deflection target
That gap matters. If you treat the program as a software rollout, the technology can reach production while ownership, escalation rules, quality controls, and performance expectations remain designed for a human-only queue. The result is automation sitting on top of an unchanged operation.
The interviews were drawn from Intercom customers or prospects and centered on Fin or similar products. They are useful directional evidence from teams close to this transition, but they are not a vendor-neutral census of every customer service organization. Your own demand, risk profile, knowledge quality, and channel mix should determine the design.
I would begin with a one-page transformation brief. Force the leadership team to complete these fields before discussing a broad rollout:
Customer promise: Which customer outcome will become faster, easier, or more reliable?
Eligible demand: Which intents, channels, languages, customer states, and account types may enter the AI workflow?
Decision boundary: What may the AI explain, recommend, decide, or execute? These are different levels of authority.
Human boundary: Which ambiguity, consequence, customer request, or system condition requires a human?
Business hypothesis: Which cost, capacity, service-level, or growth constraint should improve if the workflow succeeds?
Quality gates: Which measures must improve, and which failure measures must not regress?
Learning owner: Who converts failures into knowledge fixes, workflow changes, model evaluations, or product improvements?
Do not make deflection the customer promise. Deflection records the absence of a human interaction; it does not establish that the customer’s problem was solved. A better promise names the intended outcome, such as completing a defined action correctly or answering an eligible question from an approved source without avoidable repetition.
Scope automation using two dimensions: how repeatable the work is and what happens when the answer is wrong. A simple decision matrix prevents the team from treating every incoming conversation as equally automatable.
Work pattern
AI role
Human role
Release condition
Repeatable and low consequence
Resolve from approved knowledge or execute a reversible workflow
Review samples and handle defined exceptions
Correct resolution and reliable rollback are demonstrated
Repeatable and higher consequence
Retrieve, summarize, validate inputs, or draft
Approve the final answer or action
Authoritative sources, approval capture, and auditability are in place
Ambiguous and low consequence
Ask clarifying questions, categorize, and route
Resolve cases that remain ambiguous
The escalation reason and collected context are visible to the human
Ambiguous and higher consequence
Collect only the minimum safe context, then stop
Own judgment, communication, and action
Hard escalation rules have been tested and cannot be bypassed conversationally
Risk is contextual. The same intent may be routine for one account state and consequential for another. Eligibility therefore belongs in the workflow itself, using customer state, requested action, permissions, available knowledge, and tool health. It should not live only in a prompt that asks the model to be careful.
Redesign the full conversation, especially the human handoff
The unit of design should be one end-to-end customer intent. Do not stop at the AI response. Trace what happens from the first message through resolution, escalation, downstream action, and learning:
Define the intent and entry conditions. State what the customer is trying to accomplish and which signals make the conversation eligible.
Name the authoritative knowledge. Identify the policy, product data, account data, or workflow state required to answer correctly.
Specify permitted actions. Separate explaining a process, recommending an action, preparing an action, and executing it.
Design the handoff packet. Give the human the context needed to continue without interrogating the customer again.
Capture a failure reason. Every failed or escalated attempt should produce a category that can be assigned to an owner.
Close the learning loop. Route the failure to knowledge, conversation design, support operations, product, engineering, or governance.
The handoff is where many apparently successful deployments reveal their real cost. If the human receives only a transcript, the AI has transferred a conversation but not the work. The agent must reconstruct the goal, identify what the system already attempted, verify customer-provided facts, and decide whether any prior answer can be trusted.
A useful handoff contract should include:
The customer’s detected goal and the intent assigned to it.
The material facts the customer supplied, with no invented completion of missing fields.
The approved sources used to form the answer.
Any tools called, actions attempted, results returned, and side effects created.
The point of uncertainty or the exact escalation rule triggered.
The unresolved question or recommended next action for the human.
The relevant transcript, available for verification rather than presented as the only summary.
Test the handoff as a product experience. Give a human agent only the packet and the underlying conversation, then observe whether the case can continue without the customer repeating information. Track missing fields and unnecessary rework as workflow defects. Do not hide that effort inside average handle time.
Knowledge needs the same discipline. For each automated intent, name one canonical source, one owner, a review trigger, and a withdrawal path. If two approved pages disagree, the correct AI behavior is not to blend them into a smooth answer. It is to stop, disclose the limitation appropriately, and route the conflict to an owner.
The AI agent does not create knowledge debt, but it can expose and distribute that debt at much greater speed. A missing article, stale policy, ambiguous field, or inaccessible account state can produce thousands of superficially different conversations with the same root cause. Aggregate failures by root cause instead of editing individual answers forever.
Use a failure taxonomy that separates at least these problems: missing knowledge, stale knowledge, conflicting knowledge, retrieval failure, unsupported reasoning, policy-boundary failure, tool or integration failure, incorrect eligibility, poor conversation design, routing failure, and incomplete handoff. Each category should map to a named owner and a defined corrective action. Otherwise, quality review becomes a list of examples rather than an operating system for improvement.
Redesign jobs before you promise headcount savings
Workforce impact is real, but it is not uniform. Headcount or hiring changed in 27.71% of the 166 interviews, often through slower Tier 1 hiring, freezes, natural attrition, or reallocation. That is materially less common than workflow and responsibility changes. The safest conclusion is not that AI automatically removes a fixed percentage of support cost. It is that repetitive demand can shrink while new oversight, exception, knowledge, and optimization work grows.
Calculate net capacity rather than gross deflection. The practical equation is:
Net capacity released = human work correctly avoided – new review, exception, maintenance, and recovery work.
Count the whole system. Include time spent reviewing samples, investigating severe failures, maintaining knowledge, configuring workflows, testing releases, repairing integrations, managing escalations, and helping customers recover from wrong actions. Also separate capacity released from cash savings. A team may use capacity to absorb growth, improve response time, eliminate backlog, or take on higher-complexity work without reducing current payroll.
Role design should follow the new work, not the fashionable job titles. You may create an AI specialist, automation manager, or AI-agent owner, but the essential question is who owns each recurring decision:
Frontline specialists resolve nuanced cases, identify failure patterns, validate knowledge gaps, and contribute difficult conversations to evaluation sets.
Support managers manage the changing workload mix, coach exception handling, monitor capacity, and decide where human judgment adds value.
AI or automation owners configure behavior, maintain evaluations, control releases, monitor production, and coordinate rollback.
Quality owners define error severity, audit both automated and human resolutions, and make recurring failure visible.
Knowledge owners approve canonical content, resolve conflicts, and remove information that should no longer be used.
Product and engineering owners fix product defects, data gaps, and tool failures that support conversations repeatedly expose.
These are responsibilities, not necessarily separate positions. A smaller organization may combine them, but it should not leave them implicit. One person can hold several responsibilities; one critical responsibility cannot be owned by nobody.
Write decision rights alongside role descriptions. Specify who may expand eligible intents, approve a high-consequence workflow, publish knowledge, change a prompt or model, accept a known quality limitation, pause automation, and communicate a customer-impacting failure. An AI owner who is accountable for outcomes but cannot stop a release is not an owner.
Do not wait until automation is broadly deployed to explain this shift. Before changing staffing plans, show people the future queue, the new performance expectations, the skills they can build, and the paths available for redeployment. Vague assurances create uncertainty, while premature savings commitments force managers to defend a number before the operation has demonstrated sustainable quality.
Measure correct outcomes, not apparent automation
A conversation can be closed, contained, or deflected without being correct. That is why an automation dashboard cannot double as a transformation scorecard. I would make cost per correct resolution the economic anchor, then constrain it with customer-experience and severity guardrails.
Define correct resolution for every intent before launch. At minimum, it should mean that the customer received an accurate and complete answer or action, the applicable policy was followed, the workflow created no unintended side effect, and no avoidable human rescue or repeat contact occurred during an intent-appropriate observation period. The period may differ by intent; a question answered immediately and a downstream account action do not reveal failure on the same schedule.
Measure
Question it answers
Common trap
Eligible demand coverage
How much inbound demand falls inside a clearly approved scope?
Expanding eligibility merely to make automation look larger
AI attempt rate
How often did the AI engage eligible demand?
Counting an attempt as a successful outcome
Audited correct autonomous resolution
How often did sampled AI completions fully meet the intent definition without rescue?
Relying only on closure status or customer silence
Repeat or reopened contact
Did the customer return because the original issue remained unresolved?
Missing a repeat that arrives through another channel or wording
Handoff recovery
Can a human continue efficiently with accurate context?
Measuring routing speed while ignoring repeated questions and reconstruction work
Cost per correct resolution
What does a genuinely completed outcome cost across the whole system?
Excluding review, knowledge, tooling, maintenance, and recovery effort
Severity-weighted failure
How much customer or business consequence did errors create?
Allowing a high average accuracy to hide rare but serious failures
New-work burden
How much human effort did automation introduce?
Treating oversight and maintenance as free capacity
Keep the denominators explicit. Eligible demand coverage is eligible conversations divided by total inbound conversations. AI attempt rate uses eligible conversations as its denominator. Audited correct autonomous resolution should use reviewed AI-completed conversations, not every inbound contact. Mixing those denominators lets a team report a large percentage without showing how much demand was actually solved.
Audit with two sampling paths. Use a representative sample to estimate ordinary performance across intents, channels, languages, and customer states. Add targeted samples for high-consequence actions, new releases, known weak spots, tool failures, unusual escalations, and complaints. A purely random sample can miss rare failures that matter more than common harmless mistakes.
Define error severity before reviewers see the results. A wording issue, an incomplete answer, a wrong policy explanation, an unauthorized disclosure, and an incorrect account action should not contribute equally to one accuracy average. Severity should change the required response: monitor, correct knowledge, roll back a workflow, disable an action, or initiate the relevant incident process.
Maintain separate executive and operating views. The executive view should show eligible volume, audited correct resolution, customer outcome measures, cost per correct resolution, severe-failure trend, capacity released, and where that capacity went. The operating view should break performance down by intent, channel, language, customer state, workflow version, knowledge version, tool, failure category, and escalation reason.
Versioning is essential for diagnosis. Record the model, instructions, knowledge snapshot, workflow configuration, tool version, and eligibility rules associated with each resolved conversation. When several components change together, you may know performance moved without knowing why. Controlled rollouts or eligible-traffic holdouts can provide stronger evidence than a simple before-and-after comparison, especially when demand mix or seasonality is changing.
Set release thresholds before looking at a candidate’s results. The exact threshold should reflect the consequence of the intent and your current human baseline; there is no responsible universal number. The release decision should require sufficient audited quality, acceptable handoff recovery, no prohibited failure, functioning rollback, and an owner for every material defect that remains open.
Scale through evidence-gated stages
Do not scale on a calendar promise. Move when the workflow has produced enough evidence for its next level of authority. A useful sequence separates learning about the problem from granting the system permission to act.
Baseline the demand and draw the boundary
Start with the highest-volume and highest-consequence intents, but do not assume they belong in the same release. Build an inventory containing volume, current human effort, customer outcome, approved knowledge, data requirements, available actions, reversibility, failure consequence, escalation destination, and owner.
Create an evaluation set from real, appropriately handled historical conversations. Remove or protect sensitive data according to your controls. Include ordinary examples, ambiguous requests, missing information, policy conflicts, tool failures, customer requests for a human, and known edge cases. The gate for leaving this stage is not model quality. It is a testable definition of correct behavior and a clear boundary around what the AI must not do.
Run in observation or approval mode
Let the AI classify, retrieve, summarize, or draft while a human retains final authority. Compare its proposed outcome with the completed human outcome. Instrument the failure taxonomy, inspect whether the correct knowledge was available, and test the handoff packet with frontline agents.
Use this stage to repair the system around the model. Many failures will belong to missing content, conflicting policy, broken integrations, weak eligibility, or unclear product behavior. Prompt editing cannot fix an absent source of truth or an action the underlying system cannot perform reliably.
Grant controlled autonomy to bounded work
Begin with stable, low-consequence demand supported by authoritative knowledge and reversible workflows. Enforce eligibility outside the conversational instructions where possible. Keep hard escalation rules for uncertainty, missing data, customer preference, unavailable tools, policy conflicts, and prohibited actions.
Review production samples and targeted risk cases. Watch repeat contacts, human recovery work, severe errors, and changes in the composition of the human queue. A falling queue is not automatically good if the cases that remain take much longer or arrive with damaged customer trust.
Expand one meaningful dimension at a time
Add an intent, channel, language, customer state, or action only after defining how that dimension changes knowledge, evaluation, escalation, and consequence. Reusing a workflow in a new language is not just translation if policies, terminology, tone, or available support paths differ. Adding tool execution is not just a better answer; it grants the system operational authority.
Version each expansion and preserve rollback. If you need causal clarity, avoid changing the model, knowledge, tools, instructions, and eligibility rules in the same release. When simultaneous changes are unavoidable, label the release as a system change and evaluate the combined behavior rather than attributing the result to one component.
Institutionalize the operating model
Only after correct resolution and total workload remain durable should you change long-term staffing assumptions, performance management, budgets, or reporting lines. Update role charters, decision rights, quality routines, release governance, incident ownership, knowledge operations, and planning models together.
Give recurring AI failures a path into the product roadmap. If customers repeatedly ask because the interface is unclear, a workflow fails, or account state is hard to understand, automating the explanation may reduce service effort while preserving the root cause. The better product decision may be to remove the need for the conversation.
Key takeaways
Treat AI customer service as an operating-model transformation, because workflows and responsibilities change before most reporting structures do.
Automate bounded intents, not an undifferentiated share of tickets. Repeatability and consequence should determine the AI’s authority.
Design the human handoff as a product. A transcript without facts, actions, sources, uncertainty, and next steps transfers the queue but not the work.
Use audited correct resolution and cost per correct resolution as anchors. Attempts, closures, containment, and deflection are supporting events, not proof of value.
Calculate net capacity after review, maintenance, exception, and recovery work. Keep that separate from any claimed payroll saving.
Scale only when quality, severity, handoff, ownership, and rollback gates have been met for the next expansion.
Your next move can be small and consequential. Choose one recurring intent, complete the transformation brief, name its canonical knowledge owner, write the handoff contract, and define how you will audit correct resolution. If you cannot assign the knowledge, failure, and release decisions, do not automate the intent yet. Resolving that ownership gap is the first real step in the transformation.
You probably do not have an AI ideas problem. You have a conversion problem. Promising prototypes appear across the company, but few survive the distance between a convincing demo and a dependable customer or business outcome.
The way out is to stop treating AI transformation as a feature portfolio. Treat it as a redesign of how your organization senses problems, makes decisions, takes safe action, and learns from production. The practical unit of change is one closed loop with an accountable owner, trusted context, explicit guardrails, and measurable results.
Key takeaways: the transformation system in brief
Start with a bounded customer or employee workflow, not a company-wide AI program or a preferred model.
Define the outcome, quality threshold, action boundary, and fallback before choosing the implementation.
Build capabilities in dependency order: governed data, grounded context, constrained workflows, task-specific evaluations, and production operations.
Measure customer outcomes, AI behavior, delivery reliability, and organizational learning separately. No single metric can represent all four.
Centralize reusable controls and infrastructure, but keep problem selection and outcome ownership inside the domain team.
Increase autonomy only after the system can detect failure, escalate uncertainty, limit permissions, and recover safely.
Start with a transformation wedge, not a transformation program
A broad mandate such as make every team AI-first sounds ambitious but gives teams no useful decision rule. It encourages tool adoption, disconnected pilots, and activity metrics. A narrower mandate forces the hard questions into the open.
I call that narrower unit a transformation wedge: a bounded, repeatable moment where intelligence can remove meaningful friction, where the result can be observed, and where a safe fallback already exists. The wedge is small enough to govern but important enough to prove a new organizational capability.
Use these gates when selecting it:
Meaningful friction: A customer or employee is losing time, making avoidable errors, or failing to complete an important job.
Observable outcome: You can instrument the desired behavior rather than relying on opinions about output quality.
Available context: The system can reach sufficiently trusted information without placing sensitive data into an uncontrolled context.
Repeatable demand: The workflow occurs often enough to produce learning that the team can use.
Bounded consequence: The system can be constrained, reviewed, escalated, or reversed when confidence is inadequate.
Reusable learning: At least one capability – such as retrieval, evaluation, telemetry, or an integration – can support the next workflow.
This distinction changes the conversation. Add a support chatbot is an implementation idea. Reduce the time to an accurate support resolution while preserving policy adherence is a transformation wedge. The second framing leaves room to choose retrieval, workflow automation, agentic behavior, or a simpler interface based on evidence.
Write the outcome contract before selecting a model
For the selected wedge, create a short outcome contract. It should be understandable to product, engineering, design, operations, security, and the executive sponsor without translation.
User and moment: Who encounters the friction, and at what point in the workflow?
Current behavior: What happens without the AI intervention, and what baseline evidence is available?
Primary outcome: Which customer or business behavior should change?
Quality guardrails: Which failure measures must remain within an agreed boundary?
Trusted context: Which data may be used, who owns it, and which sensitive fields must be removed or protected?
Action boundary: May the system summarize, recommend, communicate, or execute? Name prohibited actions explicitly.
Fallback: What happens when evidence is missing, the model is uncertain, an integration fails, or a policy conflict appears?
Release evidence: Which offline evaluations, controlled experiments, and production signals will justify expansion?
Accountability: Who owns the outcome, the AI behavior, the data, and incident decisions?
In a support workflow, for example, the contract might pair a resolution outcome with accuracy and policy-adherence guardrails. A retrieval-first path can ground the response in approved knowledge, while a defined escalation route gives the system somewhere safe to send ambiguity. That combination of grounding, constrained action, evaluation, and escalation is much more consequential than the choice of chat interface.
Instrument the baseline and the intervention from the beginning. If telemetry arrives after launch, the team will be able to show that an AI feature shipped but not whether the targeted behavior improved.
Build the capability stack and the product loop together
Teams often start in the middle of the stack: they select a model, write prompts, and then discover that the data is unreliable, evaluation is subjective, or production failures have no owner. Model capability matters, but it cannot compensate for missing organizational capability.
Build the stack in dependency order:
Governed data: Identify approved data, access rules, sensitive fields, and accountable owners. Privacy-by-design belongs in the workflow definition, not in a review added before release.
Trusted context: When the task depends on company or customer knowledge, retrieve the relevant context from approved systems and control what enters the model’s context window. Define what the system should do when evidence is incomplete or conflicting.
Constrained workflow: Separate model judgment from deterministic operations. Give each integration an explicit purpose, permission boundary, failure path, and audit trail. Agentic AI should orchestrate only the actions the organization is prepared to observe and govern.
Task-specific evaluation: Build scenarios from the real workflow. Include expected cases, ambiguous inputs, missing context, policy conflicts, and known high-consequence failures. Define acceptance criteria before comparing prompts, models, or vendors.
Release and operations: Use feature flags, controlled rollout, production telemetry, threat detection, and incident management. Assign authority to pause or limit the system when behavior drifts.
This order is not a waterfall. Retrieval quality may expose a data problem, while an evaluation failure may expose a poorly defined policy. The point is to preserve the dependencies: autonomous action cannot become dependable before context, evaluation, permissions, and operations exist.
Use AI to expand options and evidence to make commitments
The capability stack changes day-to-day product work only when it is connected to discovery, design, delivery, and adoption. The useful pattern is to let AI accelerate reversible exploration while keeping consequential decisions anchored in evidence.
Discovery: Use AI to cluster interview notes, support tickets, and session transcripts. Then inspect the underlying material and pressure-test important themes with live customer conversations. A fluent summary is a hypothesis generator, not customer validation.
Design: Generate several storyboards, interaction flows, or guidance variants early. Refine promising options through the design system, accessibility requirements, and human review rather than treating the first plausible generation as finished design.
Delivery: Use AI to prepare hypotheses, test cases, and experiment materials. Keep success metrics and the minimum detectable effect explicit, and release variants through feature flags so that speed does not erase experimental discipline.
Adoption: Generate targeted in-app guidance, release it to controlled segments, and measure activation and retention alongside the immediate interaction. Shipping the intelligent behavior and helping users adopt it are parts of the same product decision.
Replace status review with a weekly learning review
Whether the accountable unit is called a product trio or something else, give it a weekly operating rhythm focused on verified learning. A useful agenda is:
Review the primary outcome and every guardrail, including meaningful segment differences.
Inspect evaluation failures and trace them to context, model behavior, policy, workflow design, or integration behavior.
Read the latest experiment evidence and distinguish a result from an interpretation.
Review reliability changes, incidents, near misses, and unresolved escalation paths.
Make an explicit decision to continue, change, limit, or stop the current approach, with an owner for the next piece of evidence.
Do not let this become a prompt-tuning meeting. Prompt changes are only one possible response. A retrieval defect, unclear product policy, missing event, weak handoff, or badly chosen outcome may be the actual constraint.
Use a metric chain instead of one AI success number
AI pilots look healthy when they are measured by output: drafts generated, tasks attempted, people trained, or features shipped. Those numbers can describe activity, but they do not establish customer value, dependable behavior, or organizational readiness.
A transformation scorecard needs separate layers because each answers a different management question:
Measurement layer
Question it answers
Useful measures
Customer and business outcome
Did the important behavior improve?
User activation, time-to-first-value, support resolution rate or time, retention
AI quality and safety
Is the intelligent behavior reliable enough for this workflow?
Can the team improve the system quickly without destabilizing it?
Deployment frequency, lead time, change failure rate, mean time to recovery
Organizational learning
Is the organization reaching better decisions faster?
Cycle time, experiment throughput, decision quality against predefined evidence
The metric names are not definitions. Make each operational for the selected workflow. Accuracy might mean correct support answers, successful tool completion, or correct classification; those are different tests. A hallucination rate needs a declared denominator and a rule for what counts as unsupported. Decision quality needs a rubric tied to the evidence available when the decision was made, not whether the result later happened to be favorable.
Connect the layers as a metric chain. In grounded support, retrieval and response evaluations establish whether the system can produce an accurate answer. Product telemetry shows whether the customer receives a useful resolution or an appropriate escalation. Resolution and retention measures show whether that behavior matters to the business. Delivery and learning measures show whether the organization can improve the loop repeatedly.
Interpret disagreement between the layers
The disagreements are often more informative than the headline result:
If offline evaluations improve but customer behavior does not, inspect workflow placement, user trust, adoption, and whether the evaluated task matches the real job.
If customer outcomes improve while policy adherence deteriorates, do not expand the rollout. The apparent win is being financed by unmanaged risk.
If deployment frequency rises while change failure rate or recovery time worsens, the team has increased release activity rather than adaptive capacity.
If cycle time falls but decisions are repeatedly reversed for missing evidence, the system is producing faster motion, not better learning.
If averages look healthy but a target segment fails, keep the rollout segmented until the failure mechanism is understood.
Use the right method for the question. Evaluations test whether AI behavior meets defined quality and safety criteria. A/B testing tests whether a product intervention changes user behavior; setting the hypothesis, success metric, and minimum detectable effect before reading results protects that inference. DORA metrics reveal the health of the delivery system. None is a substitute for the others. Connecting model, product, business, and delivery measures is what turns telemetry into an operating mechanism.
Centralize guardrails and distribute outcome ownership
Organizational design usually fails at one of two extremes. A central AI group becomes a queue that is distant from customer problems, or every team builds its own prompts, data paths, evaluations, and incident process. The useful split is to centralize scarce controls and reusable capabilities while distributing domain decisions.
Centralize the capabilities that should not be reinvented
Approved data-access and privacy patterns
Retrieval, context-management, and model-routing components
Evaluation tooling, baseline scenarios, and reporting conventions
Observability, auditability, feature-flag, and incident-response patterns
Prompt and workflow libraries with named owners and change history
Security, regulatory, and procurement requirements
Keep product judgment inside the domain
Choosing the customer or employee problem
Defining the outcome and acceptable trade-offs
Validating whether retrieved context represents the domain correctly
Designing the experience, fallback, and human handoff
Running controlled rollout and interpreting segment behavior
Deciding whether to continue, constrain, redesign, or stop the bet
This division preserves empowered product teams without turning governance into optional advice. The central capability owner defines the safe road; the domain team remains accountable for choosing the destination and proving that it is worth reaching.
Scale controls with the consequence of being wrong
Do not use one approval process for every workflow. A drafting assistant and an agent that changes customer records do not create the same exposure. Classify a workflow by what it can do and what happens when it fails.
Advisory output: A person reviews the draft, summary, or analysis before it affects another party. Evaluate usefulness and factual reliability, and make the reviewer accountable for the final decision.
User-facing recommendation: The output reaches a customer or employee directly. Add grounding, policy tests, clear escalation, monitored rollout, and an accessible non-AI path.
Action-taking workflow: The system invokes tools or changes state. Limit permissions, constrain eligible actions, preserve an audit trail, test integration failures, and provide a reliable stop or recovery path.
Sensitive or regulated workflow: Add the relevant privacy, security, legal, and compliance owners before data or actions enter the system. If an approved path does not exist, keep the workflow out of production until it does.
A human in the loop is not a complete control by itself. Name what the person must inspect, what evidence is visible, when escalation is mandatory, and whether the person has enough time and authority to intervene. Otherwise, the human becomes ceremonial approval around an automated decision.
Redesign roles around judgment, not tool usage
AI can accelerate exploration, synthesis, and test preparation. People still have to interpret customers, choose outcomes, set quality thresholds, resolve policy ambiguity, and accept accountability for consequences. Role design and hiring should reflect that boundary.
A product manager should be able to write the outcome contract, connect model behavior to user behavior, and make trade-offs visible.
A designer should be able to generate and interrogate alternatives, preserve accessibility, and design uncertainty and fallback states.
An engineer should be able to separate probabilistic behavior from deterministic operations and build evaluation, observability, permission, and recovery paths.
A leader should be able to fund reusable capability, challenge vanity metrics, and stop a persuasive demo that lacks production evidence.
Use communities of practice to spread prompt patterns, evaluation baselines, reusable workflows, and failure lessons. They work best as distribution networks for repeatable product and evaluation practices, not as committees that absorb accountability from the teams shipping the work.
At your next portfolio review, select one transformation wedge and require its outcome contract, metric chain, evaluation set, fallback, and named owners. Put it into the weekly learning rhythm before funding another disconnected pilot. Once the loop works in production, extract the reusable components and make the next team faster. That is the point at which AI stops being a collection of features and starts changing how the organization operates.
Capacity planning has always been a high-stakes exercise in customer service, and when you miss, the signal shows up fast in backlogs and SLAs. I’ve lived that pressure across multiple cycles, and 2026 will reward teams that plan differently.
AI fundamentally changes capacity planning because it changes the work. It resolves the bulk of your volume, speeds up execution, and elevates the complexity and value of what humans handle. The consequence is simple: planning models must evolve.
This is the final installment in my 2026 customer service planning series, and I’m focusing on the tension every leader feels right now—be ambitious about automation, but avoid the trap of understaffing if your assumptions don’t hold.
My goal is to share how AI changes the logic of capacity planning, what I’ve learned implementing these practices with my team and with customers, and the common traps to avoid.
Traditional planning rests on relatively stable assumptions: volume grows predictably, work types stay consistent, handle times don’t swing dramatically, and productivity improves slowly with better tools and training. In an AI-first model, none of that is guaranteed, and the fundamentals flip.
The mix of work changes as AI absorbs a growing share of simpler conversations, leaving humans with deeper, more time-consuming issues that demand human-to-human connection. Demand can actually increase when you remove friction, so AI can both resolve more and attract more volume. Human time splits differently as teammates solve customer problems and also review AI behavior, give feedback, improve content, and support system-level work. Performance becomes dynamic, not fixed—automation rate isn’t a one-time number; it can rise with care and fall with neglect.
If you plan for 2026 using a pre-AI model—assuming similar productivity, similar work mix, and a linear relationship between volume and headcount—you will underestimate what it now takes to run a high-performing support organization.
There are many metrics you can track, but the one to put at the center is automation rate (AI Agent involvement rate × AI Agent resolution rate). This single construct tells me what share of total volume AI actually resolves, how much work remains for humans, how much additional demand humans can absorb, and how ambitious I can be with headcount.
Early in the journey, I prioritize raising involvement—getting the AI involved in more conversations. Once involvement is high, I shift to resolution on the hardest remaining work, where each additional 1% of automation can represent several people’s worth of capacity.
In my 2026 plans, automation rate sits alongside projected inbound volume, average “output” per person for the more complex work that remains, and occupancy—how much time is allocated to customer-facing interactions versus operational and strategic work. Together, those inputs give a realistic picture of how many people you need and where they should spend their time.
First, plan boldly on automation, but match it with investment. I do not cap automation assumptions at 40–50% “because AI is new.” Many teams are already modeling 60%, 70%, even 80%+ for 2026—when they invest in AI ownership and content. The investment is non-negotiable: named ownership for AI performance (AI ops, knowledge management, conversation design), clear automation targets by work type (e.g., informational vs. personalized vs. actions vs. deep troubleshooting), realistic expectations for what’s easy to automate and what’s not, and a concrete plan to raise automation over time in monthly or quarterly steps rather than a single jump.
To decide where to invest first, I dig into the data. I start with the biggest volume drivers, separate content-led issues from those dependent on data or complex procedures, assume higher resolution potential for content-led topics once the knowledge base is in shape, and set more modest initial resolution expectations for system-dependent flows. Then I stair-step improvements as the systems, data contracts, and workflows mature.
In short, bold automation goals only work when paired with the team structure, content, and systems required to reach them—and the discipline to iterate.
Second, expect human “output” per person to go down. That’s a mindset shift. Historically, we assumed individual productivity would stay flat or tick up as tools improved. In an AI-first model, humans handle fewer conversations but more complex, cross-functional issues—and create more value despite lower case counts.
I model a lower “cases closed per person” than prior-year baselines, explicitly assume the remaining work is more complex and time-consuming, and redefine productivity to include system-level work like AI Agent improvements, content updates, and policy or workflow change management. I also report “capacity created” from automation alongside human outputs, so leadership sees the full picture.
Third, rethink occupancy: more time off the queues, on higher-value work. Traditional occupancy splits time between inbox and training, meetings, and breaks. Now there’s an expanding “out-of-inbox” portfolio that directly affects AI performance and overall capacity: reviewing AI-handled conversations, improving AI Agent triaging and handovers, contributing to content and procedures, feeding insights to product and engineering, and supporting system changes that reduce future volume.
I set lower inbox occupancy targets than before and make the rationale explicit. People aren’t working less—they’re working differently. In planning, I assume more time spent on improvement and system work, make it visible (for example, X% in inbox and Y% on AI and system improvement), and treat this as critical, not a “nice to have.” If you don’t proactively allocate it, it won’t happen—and your automation and performance targets will suffer.
Fourth, work with the finance team early, and treat your plan as a set of assumptions. Capacity planning with AI is a set of bets across automation rate, human output, demand growth, occupancy, and where surplus capacity (if any) goes. I bring finance in early, show that the plan is dynamic and directly tied to AI performance, and label every lever as an assumption with ranges.
I commit to a quarterly review cadence with finance to compare assumptions versus reality and adjust headcount, targets, and investment as needed. The risks are real: if automation grows slower than expected and you stop backfilling too early, you’ll be understaffed for months. Hiring and onboarding take time, so course-correcting late creates strain. If you do produce surplus capacity, have a clear strategy to reallocate those teammates to higher-value work—improving systems, feeding insights back to product, supporting new channels, and driving proactive CX—rather than defaulting to reductions.
I also set explicit guardrails—if automation rate misses by five points for two consecutive months, we pause planned reductions and revisit hiring gates. If it over-performs, we shift people into backlog eradication, content upgrades, or proactive outreach, so we bank compounding value.
To set your team up for success in 2026, anchor your plan on automation rate, be honest that humans will handle fewer but harder conversations, and protect time for system improvements. Partner early and often with finance, avoid shrinking too fast, and design a plan for surplus capacity so you’re never caught flat-footed.
If AI is going to handle the majority of your customer conversations, your plan has to be designed to help it do that well and to keep your team set up for meaningful, sustainable work. A 2026 plan built on adaptable assumptions—not fixed predictions—will hold up as your work, your systems, and your customers’ expectations continue to change.
If you’d like future editions like this, subscribe and stay close—I’ll keep sharing what’s working, what isn’t, and how to tune your customer support AI strategy in real time.
I’ve been closing the year with a deliberate reflection ritual for more than a decade, and this season I found fresh energy for it after listening to an insightful conversation with Teresa Torres and Petra Wille on All Things Product. Their approaches mirror the evolution many product leaders experience: moving from rigid annual goal-setting to values-led themes, longer time horizons, and a healthier respect for spaciousness. In my own practice, that shift has created better focus, less pressure, and far more meaningful outcomes.
Prefer to listen? You can find this episode here: Spotify | Apple Podcasts. I took notes with my team in mind and translated the discussion into a simple, values-driven framework that any product organization can adopt.
Why does annual reflection matter for product people? Because our work lives at the intersection of ambiguity, trade-offs, and time. If we only measure ourselves by shipped output or quarterly OKRs, we overlook the compounding value of learning, relationships, and judgement. I treat this ritual as a strategic reset: a chance to surface patterns, adjust expectations, and recommit to outcomes over output.
My own reflection habit started scrappy—paper notebooks, messy timelines, and even artful visualizations inspired by Dear Data by Giorgia Lupi & Stefanie Posavec. Like Petra, I’ve found that tactile, analog artifacts unlock insights I miss in a spreadsheet. Over time, I’ve kept the spirit and simplified the mechanics: a “what went well” review, a short list of hard lessons, and a handful of decisions that paid off—or didn’t.
The biggest evolution for me has been moving from rigid annual goals to values and themes. I still run OKRs, but I use them to track progress, not identity. The lens of process vs. outcome goals—reinforced by ideas from Atomic Habits—helped me set fewer, better commitments. For example, instead of “launch X by Y,” I’ll emphasize the cadence of customer discovery, the health of the product trio, and the quality of decisions made along the way.
One exercise that changed my practice is the “100 wishes” list. It’s powerful—and surprisingly difficult. Pushing past 30 or 40 wishes forces me to name latent interests and long-range intentions I rarely say out loud. Combined with decade-level themes, the list helps me balance ambition with patience. I don’t try to do it all next year; I use it to spotlight direction, not deadlines.
I also review patterns across years: Where did over-scheduling create hidden costs? When did I protect focus time and what did that unlock? Paul Graham’s Maker’s Schedule, Manager’s Schedule remains a useful calibration tool here. And when I feel the pull toward constant throughput, I revisit Stefan Sagmeister’s The Power of Time Off (TED Talk) to remind myself why strategically creating space often yields the most valuable ideas.
Of course, not every year follows plan—and that’s normal. Reflection helps me spot unrealistic expectations early and let them go. When setbacks hit, I’ll rewatch Dealing with Setbacks and re-ground in continuous discovery. The question isn’t “Did we do everything?” but “Did we learn fast, protect customer value, and make trade-offs aligned with our values?” That’s how empowered product teams compound impact.
My sharing philosophy has become more nuanced over time. Some reflections are public to invite dialogue and accountability; others stay private so I can process honestly. I’ve found it helpful to publish what I’m saying no to, capture a theme for the year ahead, and keep the rest for myself and my team. This balance preserves motivation while still contributing to the broader product management leadership community.
If you’re designing your own ritual, consider this lightweight flow: review wins and tough calls, write your “100 wishes,” extract a few values-based themes, then translate those into process goals for Q1. Revisit monthly, not just annually. If you like structured prompts, Chris Guillebeau’s How to Conduct Your Own Annual Review from The Art of Nonconformity offers a practical template you can adapt to your context.
For deeper dives and complementary ideas, I bookmarked these as part of my year-end reset: What I’m Saying No to This Year—And Why, Ask Teresa: My Leaders Still Want Roadmaps with Timelines—What Should I Do?, Scaling Impact: A Look at the Year Ahead (2022), Let’s Connect in 2025: A Look at the Year Ahead, The Interview Coach, and Petra’s own year-ahead reflections (here and her 2026 version). I also recommend revisiting the prior conversation on leadership and change: Role of Leadership in Transformations.
I’d love to hear how you approach your end-of-year reflection. What questions bring you the most clarity? Which practices help you set an intentional, values-driven path for the next year? Share your process—I’m always looking to learn from other product creators and leaders.
When I push our organization to adopt the product operating model, I’m emphasizing a foundational shift—from “shipping roadmaps of features (output)” to solving real customer and business problems, measured by “business results (outcomes)”. That’s the difference between activity and impact, and it’s the only way to build durable value at scale.
This change inevitably reaches beyond the product organization. It reshapes how company stakeholders in Sales, Marketing, Customer Success, Finance, Legal, Security, and Operations engage with product teams, and it reframes what they expect from us. Instead of asking, “When will feature X ship?” they learn to ask, “How will we move the outcome that matters?”
In practice, the product operating model is a contract: product teams commit to outcomes, and stakeholders commit to partnership. That partnership means we co-own the problem, align on evidence, and share accountability for results. The reward is clarity—everyone sees how their work ladders to strategy and why the sequence of work makes sense.
Here’s how I align stakeholders around this model. First, I ground everything in outcomes vs output OKRs. We replace feature roadmaps with a clear strategy, prioritized problems, and measurable objectives. Our product roadmapping and sprint planning then serve the objectives—not the other way around—so capacity is allocated to the highest-leverage bets.
Second, I build empowered product teams around product trios (product, design, engineering). We practice continuous discovery with stakeholders: we share opportunity trees, test riskiest assumptions early, and bring partners into research when it informs go-to-market strategy, pricing, or enablement. This keeps us honest and avoids late-stage surprises.
Third, I establish operating rhythms that make outcomes visible. Monthly stakeholder reviews focus on progress toward objectives and what we’re learning—not status theater. Quarterly, we connect OKRs to business performance so leaders can see the throughline from discovery and delivery to pipeline, retention, or margin. If priorities shift, we renegotiate objectives explicitly.
Fourth, I define metrics that stakeholders trust. We use a balanced set of leading indicators (activation, engagement, cycle time) and lagging indicators (revenue, retention, unit economics). We socialize definitions early so no one debates the scoreboard mid-game. The result: faster decisions and less “data whiplash.”
Fifth, I invest in change management. Moving from outputs to outcomes can feel threatening if your success has historically been measured by launch volume or roadmap commitments. I address this head-on with training, transparent comms, and clear decision rights. The message is simple: outcomes create more autonomy for empowered product teams and more predictability for stakeholders.
At HighLevel, this approach has been especially powerful when cross-functional dependencies are high. For example, when we set an objective to improve user activation for a new CRM integration, we didn’t promise a bundle of features. We committed to a measurable lift in activation and a shorter time-to-value, co-owned with Customer Success and Marketing. That alignment unlocked smarter experiments, tighter enablement, and a more credible launch narrative.
The anti-patterns are predictable: treating OKRs as a renaming of the roadmap, equating discovery with indecision, or isolating product decisions from go-to-market strategy. The cure is equally consistent: bring stakeholders into discovery, attach every bet to an objective, and show progress with evidence—not just demos.
Ultimately, the product operating model is a leadership choice. It asks us to trade certainty theater for learning velocity, and feature checklists for business impact. When stakeholders see that shift pay off—in faster cycles, clearer priorities, and results that matter—support for the model moves from compliance to conviction.
Your AI agent is resolving enough conversations that queue volume is no longer a useful blueprint for organizing the team. Yet your org chart still assumes that every customer outcome belongs to a human agent. The result is a dangerous ownership gap: everyone can recognize a poor AI interaction, but no one is clearly responsible for the content, behavior, action, or handoff that caused it.
The decision in front of you is not simply which jobs AI will remove. It is which responsibilities become more important, who should own them now, and when that work deserves a dedicated role. You can answer those questions before adding headcount.
The unit of work has shifted from tickets to systems
A human-owned ticket usually has a visible assignee, a queue, and a closed state. An AI conversation can fail much earlier in the system. The policy may be stale. The right knowledge may exist but be difficult to retrieve. The response may be accurate but confusing. A backend action may fail. A handoff may reach a person without the context needed to continue.
If you classify all of those outcomes as generic AI accuracy problems, the team will spend its time rewriting prompts while structural defects remain untouched. Diagnosis has to begin with the layer that failed.
Knowledge: Did the system have an accurate, current, and unambiguous basis for answering?
Conversation: Did it communicate clearly, follow policy, and recognize when it should stop or escalate?
Action: Could it complete the requested task safely and confirm the result?
Operations: Could the organization detect the failure, assign it, correct it, and verify that the correction worked?
Start with a simple accountability rule: every layer needs one named owner. Several people can contribute, but shared contribution is not shared accountability. If nobody has the authority to prioritize a correction and see it through, performance will drift between support, product, engineering, and content teams.
Assign four ownership roles before opening four requisitions
I would not begin by hiring four specialists. I would begin by assigning four explicit responsibilities to people who already understand the customers, policies, tools, and failure modes. A dedicated job becomes necessary when the work is continuous, consequential, and repeatedly displaced by the owner’s primary role.
AI operations lead: owns performance and improvement
The AI operations lead is accountable for day-to-day performance. This person maintains the quality view, classifies recurring failure modes, prioritizes corrections, and coordinates changes across support, product, data, content, and engineering.
This is not a meeting coordinator or a person who manually edits every weak response. The role needs enough operating authority to decide which problems deserve attention and enough analytical depth to separate isolated bad conversations from systemic patterns. Support operations is often a strong internal starting point because the function already understands workflows, tooling, routing, and capacity.
The first useful deliverable is an AI performance register. For each recurring issue, record the affected customer intent, observed outcome, failure layer, accountable owner, proposed change, validation method, and current status. That register becomes the shared backlog for the AI support system.
A good decision boundary is equally important: the operations lead prioritizes what must improve, while the relevant domain owner decides how to change knowledge, conversation behavior, or automation. Otherwise, one person becomes a bottleneck for every adjustment.
Knowledge manager: owns what the AI is allowed to know
The knowledge manager owns the material that grounds customer answers: help content, internal procedures, macros, snippets, policy explanations, and the relationships between them. The job is not merely publishing more documentation. It is making sure the AI has one dependable answer for each supported question.
Conflicting content is often more damaging than missing content because the system can produce a plausible answer from the wrong instruction. Every important knowledge item should therefore have a clear owner, audience, scope, status, and review trigger. Product or policy changes should update the source of truth before teams try to compensate through prompt wording.
The first useful deliverable is a knowledge inventory organized by customer intent. Mark where content is missing, duplicated, contradictory, overly broad, or dependent on information the AI cannot reliably access. This turns an abstract content audit into a prioritized quality backlog.
Measure this role by whether knowledge-related failures become easier to prevent and diagnose. Page count is an output. Dependable answers are the outcome.
Conversation designer: owns how the AI behaves
The conversation designer defines how the AI communicates and how an interaction progresses. That includes tone, question sequencing, explanation structure, confirmation language, boundaries, escalation triggers, and the context passed to a human agent.
This role is broader than polishing wording. A response can be factually correct and still produce a poor outcome because it is too confident, asks for information in the wrong order, buries a constraint, or continues after the situation calls for human judgment. Conversation design turns brand, policy, and customer-experience expectations into observable behavior.
The first useful deliverable is an interaction specification for each important intent. It should define the customer’s likely goal, information required, acceptable response structure, prohibited claims, escalation conditions, action confirmation, and handoff payload. That specification gives QA something concrete to evaluate and gives the automation specialist a stable flow to implement.
Content design, UX writing, and support enablement are natural backgrounds for this work. The essential skill is not clever phrasing. It is recognizing how small language and sequencing choices affect comprehension, trust, and completion.
Support automation specialist: owns safe execution
The automation specialist connects customer intent to business systems. This person builds and maintains the workflows that let an AI agent retrieve account-specific information, update a record, initiate an approved process, or complete another backend task.
This is the role that moves AI support from answering to resolving. It also introduces a different class of risk. A weak answer can be corrected in conversation; a wrongly executed refund, cancellation, permission change, or account update can create financial loss, access problems, or corrupted state. Begin with reversible, bounded actions. Enforce identity, authorization, business rules, and transaction limits outside the language model, and preserve a human path when the system cannot establish that an action is safe.
The first useful deliverable is an action catalog. For each action, document the eligible intent, required inputs, source system, authorization rule, success response, known failure states, recovery path, and human fallback. Do not enable an action merely because the model can call it.
Support engineering, systems administration, solutions engineering, and tooling operations can all supply the necessary background. The role must be able to work with product and engineering without waiting for those teams to own every support-specific workflow.
Organize around human support, AI support, and optimization
Resolve complex, sensitive, ambiguous, and exception-driven customer needs
What requires judgment? What should be escalated? What are people learning that the system does not yet know?
AI Support
Own automated knowledge, behavior, actions, and continuous performance improvement
Where does the AI succeed or fail? What change will improve the outcome? Who can safely approve that change?
Support Operations and Optimization
Provide tooling, analytics, enablement, QA, workflow design, and capacity planning
Can performance be measured? Can failures be routed to an owner? How should human capacity change as automation coverage changes?
The reporting lines can vary. The interfaces cannot. Before debating where each role sits, write down how work crosses the boundaries.
Human Support to AI Support: Frontline agents provide structured evidence about missing knowledge, failed automation, confusing language, and escalation gaps. A collection of anecdotes is not enough; feedback needs an intent and a failure category.
AI Support to Human Support: A handoff carries the customer’s goal, relevant context, questions already asked, actions attempted, confirmed results, and remaining uncertainty. The customer should not have to reconstruct the conversation.
Operations to both: Operations supplies the measurement, workflow, tools, and change process needed to turn observed failures into verified improvements.
Product and engineering partnership: Support owns the customer problem and operating priority. Product and engineering own changes that affect the core product, shared platform, security boundary, or technical architecture.
Make decision rights explicit as well. Name who can publish source knowledge, change conversational behavior, enable or disable an action, alter handoff rules, accept residual risk, and declare a correction ready. Without these boundaries, teams either move recklessly or wait for broad consensus on routine changes.
Transition the current team without hiring ahead of the work
Most organizations do not need a separate AI department on the first day. They need visible ownership. Distributing the responsibilities across existing people lets you prove where the workload and leverage actually sit before converting responsibilities into job titles.
Map recent failures to ownership layers. Classify each meaningful problem as knowledge, conversation, action, or operations. If the team cannot classify it, that ambiguity is itself an operations problem.
Put a person’s name beside every layer. Avoid team names such as Support Ops or Product. A team cannot make a decision; an accountable owner can.
Give each owner an artifact and decision boundary. Use a performance register, knowledge inventory, interaction specification, and action catalog so that the role produces something inspectable.
Run the work on a fixed operating cadence. Review outcomes, inspect representative conversations, assign root causes, prioritize changes, and check whether previous corrections held.
Formalize the role when borrowed capacity stops working. A dedicated hire is justified when the responsibility is continuous, affects important outcomes, and repeatedly loses priority to the owner’s original job.
The existing support functions should evolve at the same time:
Frontline agents spend less time repeating known answers and more time resolving exceptions, preserving trust in difficult moments, and supplying structured feedback about system weaknesses.
Enablement teaches agents how to receive AI handoffs, identify failure layers, use AI-generated context critically, and submit feedback that another owner can act on.
Quality assurance expands beyond grading agent conversations. It evaluates the end-to-end customer outcome, including AI behavior, action results, escalation decisions, and continuity after handoff.
Workforce management plans for automation coverage and the type of work reaching people, not only gross inbound volume. Lower human volume can still demand substantial capacity when the remaining cases are more complex.
Support leadership becomes a player-coach responsibility. The leader must understand performance data and system behavior well enough to guide priorities while helping people move into unfamiliar work.
Do not treat the move as a title-renaming exercise. A knowledge manager without publishing authority, an operations lead without a performance view, or an automation specialist without access to technical partners will reproduce the old model under new labels.
This transition can also create credible internal career paths. Analytical support-operations talent can grow into AI operations. Content and enablement specialists can move toward knowledge or conversation design. Technically inclined support staff can develop into automation. Frontline experts with strong policy judgment can contribute to knowledge governance, QA, and escalation design. The best candidate is often the person who already understands where customer intent and company systems fail to meet.
Run AI support as a product, not a side project
An AI support system changes whenever its knowledge, instructions, workflows, integrations, policies, or underlying product changes. It therefore needs a product-like operating loop: observe an outcome, diagnose the responsible layer, change the right artifact, validate the result, and watch for regression.
The scorecard should distinguish customer outcomes from automation activity. An impressive volume metric can hide poor resolution, unnecessary handoffs, or actions that appear successful but do not complete in the business system.
Resolution quality: Did the customer achieve the intended outcome, rather than merely receive a response?
Handoff quality: Was escalation appropriate, correctly routed, and supplied with enough context for a person to continue?
Action reliability: Did the requested action complete, produce the expected state, and recover safely when it failed?
Knowledge health: Which failures came from missing, stale, conflicting, or poorly scoped information?
Customer signals: Do repeat contacts, corrections, abandonment, or explicit dissatisfaction indicate that an apparently completed interaction did not work?
Coverage: Which customer intents are eligible for automation, and which remain deliberately human-owned?
Human workload: What volume, complexity, and urgency reach agents after automation and handoffs?
Segment these measures by customer intent. A single aggregate can conceal a reliable password-reset flow beside a weak billing or cancellation flow. Intent-level views also make ownership clearer: you can connect a measurable outcome to the knowledge, conversation specification, action workflow, and escalation rule behind it.
During an operating review, resist the urge to solve every failure by changing the prompt. First classify the root cause. Correct the source material when the knowledge is wrong. Change the interaction specification when the behavior is wrong. Repair the workflow when an action is wrong. Improve instrumentation or accountability when the organization cannot tell what happened.
The leader’s job is to keep that loop moving. AI support needs someone who can move between customer experience, operational data, content, and technical constraints. Pure people management is insufficient, but so is pure systems administration. The effective leader coaches the people while actively shaping the system they operate.
Key takeaways
Organize AI support around four accountable layers: operations, knowledge, conversation, and action.
Assign the responsibilities before creating dedicated positions; hire when continuous ownership can no longer fit beside an existing role.
Connect Human Support, AI Support, and Support Operations through explicit handoffs, feedback contracts, and decision rights.
Evolve enablement, QA, workforce management, and leadership around system outcomes rather than ticket throughput.
Measure resolution, action reliability, handoff quality, and knowledge health by customer intent, then fix the layer that actually failed.
Your first move should be small but explicit. Pull recent AI failures, classify each one into the four ownership layers, and put a person’s name beside every layer. Then publish what each owner may change and how the team will verify that a correction worked.
Do that before requesting a new organization chart. Once the work is visible, you will know which responsibilities can remain distributed and which have become real jobs. More importantly, your customers will no longer depend on an AI system that everybody observes but nobody owns.
Setbacks are the tax we pay for doing meaningful product work. As a VP of Product Management, I’ve learned that what separates resilient teams from the rest isn’t a lack of failures—it’s how we metabolize them. This episode of All Things Product with Teresa Torres and Petra Wille is a powerful reminder that recovery, reflection, and rigorous product discovery are as essential as speed and execution.
Listen to this episode on: Spotify https://open.spotify.com/episode/10LYRya7boYJBHTYBnE79E?ref=producttalk.org | Apple Podcasts https://podcasts.apple.com/kh/podcast/dealing-with-setbacks/id1794203808?i=1000737190520&ref=producttalk.org
What struck me most is how Teresa shares a deeply personal story about her long recovery from an injury—and how that journey mirrors the nonlinear reality of product development. In product, just like in healing, progress is rarely a straight line. We have surges, stalls, and moments that feel like reversals. Yet with the right mindset and rituals, we still move forward.
Professionally, we all face moments when your product fails to move a single KPI, when a launch falls flat, or when you just feel stuck. I’ve been there—in quarterly reviews, post-launch standups, and board prep. The instinct is to sprint straight into solutions. The wiser move is to respond with curiosity, emotional honesty, and resilience, then re-engage our discovery habits with intention.
If you’re a PM, designer, or researcher, consider this an invitation to rebalance. Recovery and reflection are just as important as velocity and success. That’s not soft talk—it’s how empowered product teams build durable performance without burning out.
On the emotional reality of setbacks, I’ve learned to normalize naming the loss. We put immense pressure on ourselves, and it’s okay (and necessary) to grieve product failures. When we acknowledge the disappointment, we regain the ability to observe clearly—and to learn.
Leaders play a crucial role here. I create space for teams to recover before jumping into post-mortems. We don’t whiteboard over feelings; we schedule time for decompression, then conduct a crisp, blameless review. That sequencing transforms the quality of insights and strengthens psychological safety.
Another lesson that resonates is the danger of tying performance too tightly to outcomes. Outcomes matter, but they are lagging indicators influenced by many externalities. I evaluate performance on behaviors: clarity of problem framing, rigor in discovery, quality of decision-making, and stakeholder alignment. This aligns with outcomes vs output OKRs and keeps us focused on controllable excellence.
How do we build resilience? Continuous discovery builds resilience by normalizing failure. When we test assumptions routinely with customers and data, we turn large, risky bets into a series of small, learnable steps. Teams recover faster because failure becomes feedback—frequent, cheap, and informative.
For perspective, I often use the 10–10–10 framework (from Decisive by Chip & Dan Heath). I ask: How will this setback feel in 10 minutes, 10 months, and 10 years? The answers de-escalate urgency, expand our time horizon, and produce better, calmer decisions.
Here are the key takeaways I’m carrying forward. Setbacks are not just inevitable—they’re part of doing meaningful product work. Giving teams time and space to process failure builds long-term resilience. Mourning losses is just as important as celebrating wins.
Healthy discovery cultures embrace reflection, psychological safety, and emotional honesty. And most importantly, staying consistent with discovery habits helps teams recover faster and learn more deeply.
Notable moments that stood out for me include: [00:02:00] Teresa shares the story of her injury and what it’s taught her about patience and setbacks. The parallel to product cadence is both humbling and motivating.
[00:10:00] Petra talks about a team whose carefully planned launch didn’t move a single KPI. I’ve led similar debriefs; when we anchor on customer insight gaps rather than blame, the next iteration improves dramatically.
[00:20:00] Discussion on allowing space for grief and frustration after failure. In my teams, we time-box “emotional processing” before we enter analysis mode—it humanizes the work and sharpens the learning.
[00:30:00] Why organizations must decouple performance reviews from short-term outcomes. I align evaluations to strategy execution quality, hypothesis discipline, and cross-functional collaboration.
[00:40:00] How continuous discovery can help teams normalize—and even learn to appreciate—setbacks. When discovery is weekly, momentum becomes self-healing.
If you want to dig deeper, here are useful links from the episode. Follow Teresa Torres: https://ProductTalk.org
Follow Petra Wille: https://Petra-Wille.com
Mentioned in the episode: Decisive by Chip & Dan Heath — The 10–10–10 framework for perspective in decision-making https://heathbrothers.com/books/decisive/?ref=producttalk.org
Teresa Torres’ Continuous Discovery Habits — Building resilience through ongoing discovery practices. https://www.amazon.com/Continuous-Discovery-Habits-Discover-Products/dp/1736633309?dchild=1&keywords=continuous+discovery+habits&qid=1621385051&sr=8-2&linkCode=sl1&tag=teresatorres-20&linkId=34bc439ac78da06e1398f7bf069b219e&language=en_US&ref_=as_li_ss_tl&ref=producttalk.org
Join the Conversation: Have thoughts on this episode? Leave a comment below. I’d love to hear how you create space for recovery while sustaining product velocity.
Full Transcript: Full transcripts are only available for paid subscribers.
I’ve spent my career building products and teams that I intend to steward for the long haul, and I’m drawn to founders who treat company-building as a craft you can practice forever. In this analysis, I break down a journey that crystallizes what it takes: going from a teenage wholesale hustle to an API-first healthcare clearinghouse, and in the process, learning why execution isn’t a moat, why venture capital is “going pro,” and how “eating glass” can become a durable advantage.
Here’s the arc that anchored my thinking: a founder who, at 16, turned $2,500 into a wholesale empire; later bootstrapped a wildly profitable auto-parts business; then sold it to tackle “the most complicated problem” he’d ever encountered: business-to-business transaction exchange. He spent years building EDI infrastructure, threw away the entire codebase eight times, and found extraordinary traction in healthcare. The company recently raised a $70M Series B co-led by Stripe and Addition. The throughline is a consistent, high-agency approach to product management and go-to-market strategy, guided by first principles decision making.
The first customer is often the trickiest—not because demand doesn’t exist, but because the product’s value proposition, points of parity, and competitive differentiation are still coalescing. I push teams to do founder-led GTM early, speak in the user’s language, and orchestrate high-signal conversations that expose real switching costs. That’s how we avoid mistaking polite interest for product-market fit.
Bootstrapping forces rigor, but it also means being “constrained by capital.” There’s a ceiling to the speed at which you can iterate, validate, and scale. Venture capital, in the right context, is like “going pro”: you trade a bit of optionality for time, talent density, and a faster feedback loop. I often see confusion between ownership vs. control; structurally, you can design for alignment while still moving with the urgency a competitive market demands.
One theme I return to with my own teams: execution is never actually a moat. Processes can be copied. Culture can be mimicked superficially. What can’t be easily replicated is the willingness to do the unglamorous, compounding work—what the founder here called “eating glass.” It’s the daily discipline of simplifying the system, instrumenting the edge cases, and standing up operational excellence that compounds into true competitive differentiation.
When product-market fit hits in enterprise infrastructure, it can feel like “the snake swallowing a deer.” Capacity, process, and architecture are stretched to their limits all at once. I’ve experienced the same pattern: everything slows down so the organization can re-architect for scale. The trick is to make those constraints visible—measure service levels, queuing, and error budgets like you would in a production system—so you’re not flying blind.
Some of the strongest product-management instincts I’ve seen borrow from discount retail and Toyota. From discount retail, we learn to obsess over unit economics, operational throughput, and ruthless simplification. From the Toyota production system, we adopt Kanban / TPS (Toyota), continuous improvement, and respect for constraints. In software terms, this becomes fast deployment frequency, small batch sizes, and defect prevention at the source—because “All software is a cascade of miracles.”
Scaling decision-making is where most teams stall. I favor clear ownership, lightweight written narratives, and a bias for first principles decision making over committee compromise. That structure lets high-agency individuals move quickly while keeping cross-functional stakeholders aligned on outcomes vs output OKRs. It’s how you build empowered product teams without sacrificing focus.
Hiring is where philosophy becomes practice. I resonate with the onboarding mantra “everything’s your fault now”—not as blame, but as an invitation to own outcomes end to end. I look for high-agency people who demonstrate systems thinking and the capacity to simplify. Manager hiring should lag role clarity; bring in managers when coordination overhead is the limiting factor, not when it merely feels uncomfortable.
Longevity comes from founder-approach fit as much as product-market fit. Build a company you don’t want to leave by aligning operating cadence, decision rights, and cultural norms with how you actually work best. Maintain conviction in unconventional practice when the evidence supports it, while remembering that “Reality has a surprising amount of detail.” The more I zoom in on the real work—interfaces, edge cases, workflows—the more the right design emerges.
In healthcare EDI, that realism matters. HIPAA overview (HHS) sets the compliance baseline. Payer integrations with Aetna, Blue Cross Blue Shield, and Cigna demand reliability and deep domain fidelity. Cloud and back-office ecosystems—from AWS and NetSuite to Slack, Microsoft Teams, Zapier, and Clay—shape the surrounding workflow. Lessons from Amazon, Target, Walmart, and Costco inform operational rigor; supply chain analogies from Ford Motor Company and GM clarify interface contracts. Porter’s five forces helps frame market structure; perspectives from Jeff Bezos and Peter Thiel sharpen strategic posture.
If you’re building for the long run, here’s the blueprint I use with product leaders: validate painfully specific jobs-to-be-done before you scale; prefer founder-led GTM until messaging closes the intent-to-adoption gap; instrument throughput and quality like a production system; invest in people who treat ambiguity as a chance to lead; and don’t confuse speed with hurry. When the “snake swallowing a deer” moment arrives, re-architect deliberately, protect your margins, and let operational excellence carry you from product discovery to durable product-led growth.
References and resources: Aetna: https://www.aetna.com/, Amazon: https://www.amazon.com/, AWS: https://aws.amazon.com/, Blue Cross Blue Shield: https://www.bcbs.com/, Change Healthcare: https://www.changehealthcare.com/, Cigna: https://www.cigna.com/, Clay: https://www.clay.com/, Costco: https://www.costco.com/, Ford Motor Company: https://www.ford.com/, GM: https://www.gm.com/, HIPAA overview (HHS): https://www.hhs.gov/hipaa/index.html, Jeff Bezos: https://x.com/JeffBezos, Kanban / TPS (Toyota): https://global.toyota/en/company/vision-and-philosophy/production-system, Microsoft Teams: https://www.microsoft.com/microsoft-teams, NetSuite: https://www.netsuite.com/, O’Reilly Auto Parts: https://www.oreillyauto.com/, Peter Thiel: https://x.com/peterthiel, Porter’s five forces: https://www.isc.hbs.edu/strategy/pages/the-five-forces.aspx, “Reality has a surprising amount of detail”: https://johnsalvatier.org/blog/2017/reality-has-a-surprising-amount-of-detail, Slack: https://slack.com/, Stedi: https://www.stedi.com/, Summit Racing: https://www.summitracing.com/, Target: https://www.target.com/, Walmart: https://www.walmart.com/, Zapier: https://zapier.com/
Heading to ProductCon San Francisco 2025? I approach conference travel the same way I approach product strategy: optimize for outcomes, reduce friction, and invest in high-signal experiences. Here’s the playbook I use to choose the right hotel, find memorable meals, and make the most of every hour in the city.
For lodging, I prioritize walkability, safety, and quiet rooms so I can focus during sessions and recover at night. If you want to be steps from most venues and meetups, SoMa and the Yerba Buena corridor are ideal. InterContinental San Francisco, W San Francisco, and The Clancy (Autograph Collection) are reliable, business-friendly picks with strong Wi‑Fi and ample lobby space for impromptu one‑on‑ones. If you prefer classic energy and transit access, Union Square hotels like Hotel Nikko and The Westin St. Francis work well. For waterfront views and a calmer vibe, Hyatt Regency Embarcadero puts you by the Ferry Building with easy BART and Muni access.
My booking checklist is simple: reserve early, target a high floor away from elevators, and request early check‑in or late checkout around your session schedule. Loyalty programs often unlock better rates and quiet‑room preferences. If you need heads‑down time between talks, ask about day‑use meeting rooms or find a corner of the lobby with stable bandwidth. I also pack a compact power strip and a long USB‑C cable—two small upgrades that routinely save a day.
Coffee is the fuel of great product conversations. Near SoMa, I rotate between Blue Bottle (Mint Plaza), Sightglass (7th Street), and Philz (Front Street) for pre‑session caffeine and quick stand‑ups. If I’m on the Embarcadero side, the Ferry Building’s roasters are perfect for early starts, and morning lines move faster than you’d expect if you arrive just after opening.
For efficient lunches, I favor fast‑casual spots that can handle volume without sacrificing quality. Mixt, Souvla, Sweetgreen, Super Duper Burgers, and The Grove are dependable within a short walk of most downtown venues. When I need a higher‑signal lunch with a partner or prospect, I book a table slightly off the main corridor to avoid the rush—think Mourad for elevated Moroccan in SoMa or Boulevard along the Embarcadero for a polished, quiet conversation.
Dinner is where the best networking often happens, so I plan for atmosphere, acoustics, and a menu that works for mixed dietary needs. Kokkari Estiatorio (FiDi) excels for executive dinners. Liholiho Yacht Club is a creative, memorable choice for cross‑functional teams. Waterbar or Angler near the waterfront pair great food with views that impress visiting colleagues. For something more casual but still conversation‑friendly, Nopa or Sorella deliver consistently.
When it’s time for drinks, I think in terms of groups and goals. For panoramic views and small group catch‑ups, The View Lounge (Marriott Marquis) is a classic. For wine‑forward conversations with a quiet ambiance, Press Club near Yerba Buena works well. If you’re hosting a more energetic crew, Charmaine’s (SF Proper Hotel), Dirty Habit (Hotel Zelos), or 25 Lusk offer space, good music, and reliable service. For craft cocktails, Pacific Cocktail Haven and ABV are standouts if you don’t mind a short ride.
Transit and timing matter. From SFO or OAK, BART is often the fastest, most predictable route downtown; rideshare is convenient late at night. I walk whenever possible, but I time routes along well‑lit, busier streets and avoid sprinting between neighborhoods tight on time. Microclimates are real—bring layers, comfortable shoes, and a compact umbrella. I schedule 15‑minute buffers around key sessions to handle inevitable friend‑of‑a‑friend introductions.
If you need a professional setting for a quick working session, many hotels will extend lobby seating to guests and their visitors. For dedicated space, day passes at coworking operators like Industrious, CANOPY, or Regus are worth it when you’ve got a client briefing or board prep. For a more casual backdrop, Sightglass and Blue Bottle locations typically have reliable Wi‑Fi and just enough outlets if you arrive off‑peak.
Finally, a word on intent: I set a simple goal for each day—one meaningful connection, one surprising insight, and one concrete action to bring back to my team. ProductCon San Francisco 2025 is a catalyst if you design your experience with the same rigor you apply to your roadmap. If you spot me in a session or at a nearby cafe, say hello—I’m always up for trading notes on product strategy, pricing experiments, and what’s working in the field right now.
Quick note: restaurants and hours can change quickly—make reservations where possible and double‑check opening times the week of the event.
You have rewritten the roadmap as OKRs, asked teams to focus on outcomes, and changed the titles in the quarterly review. Yet feature requests still arrive as commitments, teams still need approval to change a solution, and leaders still celebrate launches more than customer behavior. The language changed. The operating model did not.
An outcome-driven product operating model changes who owns the problem, what leaders fund, how teams make decisions, and what evidence can alter the plan. If you are leading that transition, the practical test is simple: can each product team name the behavior it is trying to change, its current baseline, the business result that behavior should influence, its guardrails, and the decisions it can make without escalation?
Start with an outcome contract, not an outcome slogan
An outcome-driven model needs more than an outcome-shaped sentence. It needs a clear contract between leadership and the team.
Leadership defines the strategic direction, the customer or business result that matters, the constraints, and the boundaries of acceptable risk. The team owns discovery, solution choice, sequencing, and the experiments used to find a viable path. This division protects strategic alignment without turning leaders into backlog managers.
Describes the behavior or result that should change
More new accounts complete the first-value action
Metric
Measures that change
Activation rate or time-to-first-value
Target
Defines the desired movement and time horizon
The agreed improvement from the recorded baseline
Bet
States a possible way to create the outcome
Guided setup for the highest-friction step
Output
Names what the team may build or change
An in-app guide or revised onboarding flow
Keeping these elements separate matters. If the objective says “launch onboarding v2,” the solution has already been chosen. Discovery can only validate the predetermined answer. If it says “improve activation,” but there is no segment, baseline, causal explanation, or guardrail, the team has freedom without usable direction.
A strong outcome contract fits on one page and contains:
Target customer and problem: who is affected, where the friction appears, and why resolving it matters now.
Primary outcome: the single behavior or business result the team is expected to influence.
Baseline and target: the current measurement, desired movement, and decision horizon. If the baseline is unavailable, measurement is the first task rather than an assumption hidden in the plan.
Causal chain: the proposed connection from product change to customer behavior to business value.
Leading indicators: signals such as completion of a core action or time-to-first-value that can reveal movement before the lagging result is available.
Guardrails: measures that must not deteriorate, such as support demand, reliability, performance, satisfaction, privacy, or risk.
Constraints: non-negotiable regulatory, security, platform, brand, cost, or commercial boundaries.
Decision rights: what the team can decide, what requires consultation, and what requires leadership approval.
Evidence standard: what would justify continuing, changing, scaling, or stopping the bet.
The causal chain is the part most teams skip. “Build a dashboard to improve retention” jumps directly from output to business result. Ask what the customer will do differently because the dashboard exists, why that behavior should affect retention, and which signal would appear first. If no credible behavior connects the feature to the result, the feature is not yet a defensible bet.
Do not make the outcome so broad that no team can influence it. Company revenue, total churn, and overall customer satisfaction are often shared results shaped by pricing, sales, service, market conditions, and multiple product experiences. A team needs a customer behavior or operating result close enough to its work to guide daily choices, while still having a clear connection to the larger business outcome.
This is also why outputs should not disappear from planning. Teams still need delivery plans, quality standards, dependencies, and technical milestones. The mistake is treating those items as proof of value. Outputs tell you what changed in the product. Outcomes tell you whether that change mattered.
Give durable teams a problem and real decision rights
You cannot hold a team accountable for an outcome while reserving every meaningful decision for someone else. Outcome ownership without authority is delegated blame.
A durable team should own a customer problem or value area long enough to build context, observe behavior, test alternatives, and learn from the result. A stable product, design, and engineering partnership reduces the handoffs that appear when temporary project teams move from specification to design to implementation.
Durability does not mean a team owns the same feature forever. It means the team retains responsibility for an outcome space even as its solution changes. An activation team might work on guidance, setup defaults, education, performance, or removing a step entirely. The outcome provides continuity; the outputs remain flexible.
Make decision rights explicit at each level:
Executive leadership: chooses the strategic outcomes, sets material constraints, allocates investment across the portfolio, and resolves conflicts that cross organizational boundaries.
Product leadership: translates strategy into outcome spaces, defines evidence and review standards, protects coherent team boundaries, and makes portfolio trade-offs visible.
Product teams: investigate opportunities, choose solution hypotheses, decide how to test them, sequence delivery, and recommend whether a bet should continue.
Functional leaders: establish engineering, design, data, security, and product-management standards while developing the craft and capability of their people.
Stakeholders: contribute customer context, commercial needs, risks, deadlines, and operational knowledge. Their requests are important evidence, but they do not silently become roadmap commitments.
The wording of the boundary matters. “The team is empowered unless a senior stakeholder disagrees” is not a decision rule. Specify which constraints are binding, who can override a team decision, what evidence an override requires, and who decides which existing commitment will move as a result.
When a feature request arrives, use a short intake sequence:
Restate the request as a customer problem, business risk, or desired behavior change.
Identify the affected segment, current evidence, urgency, and consequence of doing nothing.
Compare it with the outcomes already assigned to the team.
If it fits, add it as an opportunity or solution hypothesis rather than an automatic commitment.
If it displaces an existing priority, ask the portfolio owner to make that trade-off explicitly and record what is being delayed.
This prevents the common pattern in which every request is individually reasonable but the combined roadmap is strategically incoherent.
Do not force enabling work into a fictional revenue claim. State the operational capability it must improve, the downstream product outcomes it enables, and the risk of postponing it. That gives platform and infrastructure investments a testable rationale without pretending every technical change has a direct, isolated effect on growth.
Manage a portfolio of bets instead of a feature queue
A feature roadmap creates the appearance of certainty too early. It commits the organization to solutions before the most important assumptions have been tested. An outcome-driven roadmap still communicates direction and sequencing, but it treats solutions as bets that can earn more investment through evidence.
Each roadmap item should answer four different questions:
Why this problem? The customer pain, strategic relevance, business consequence, and reason it deserves attention now.
What should change? The target behavior or result, baseline, leading indicators, and guardrails.
How might it change? The current solution hypothesis and the causal assumptions behind it.
What happens next? The evidence being gathered and the next continue, change, scale, or stop decision.
This format changes the roadmap conversation. Stakeholders can challenge the importance of the problem, the logic of the bet, or the quality of the evidence without treating a proposed feature as an irreversible promise.
Use a lightweight bet brief before substantial delivery begins. It should include:
The outcome contract and the strategic objective it supports.
The customer opportunity and evidence that the problem is real.
The causal chain from proposed change to behavior to business result.
The expected reach, frequency of exposure, and direction of behavior change.
The solution hypothesis and the riskiest assumptions within it.
Confidence, effort, dependencies, privacy implications, data requirements, and technical complexity.
The instrumentation, experiment, rollout, and guardrail plan.
The evidence that would change the decision.
A one-page impact brief is usually enough. If a team cannot express the logic concisely, expanding the document will not repair the missing understanding.
Prioritization frameworks can help compare bets, but they should expose judgment rather than replace it. Reach, impact, confidence, and effort are useful because they force assumptions into view. Cost of delay helps when timing matters. Neither method turns uncertain inputs into objective truth.
Pressure-test the inputs before trusting the score:
Is reach based on actual eligible users or the entire customer base?
Does “impact” refer to a behavior that can be measured, or merely to stakeholder enthusiasm?
Is confidence supported by behavioral evidence, customer discovery, prior experiments, or only opinion?
Does effort include instrumentation, rollout, migration, enablement, support, and dependencies?
Would the bet still rank highly if its most optimistic assumption were reduced?
The portfolio also needs balance. Some bets improve customer behavior directly. Others reduce material risk, strengthen a platform capability, or create the measurement needed to pursue later outcomes responsibly. Make those categories explicit so foundational work is not forced to compete through exaggerated short-term impact claims.
Set stopping conditions before enthusiasm and sunk cost distort the decision. A stopping condition might be failure to observe the necessary leading behavior, inability to reach the intended segment, unacceptable movement in a guardrail, or evidence that the customer problem is less important than assumed. Stopping a weak bet is not a delivery failure. Continuing it without a credible causal path is.
Make evidence change plans, funding, and reviews
The model becomes real only when evidence can change what the organization does. If every bet continues regardless of results, experimentation is theater. If quarterly reviews still focus on release counts, teams will optimize for releases.
Connect discovery, delivery, and measurement
Discovery is not a phase that ends when development begins. It is the work of reducing uncertainty throughout the bet. The useful sequence is:
Record the baseline. Confirm that the primary outcome and leading indicators can be measured for the relevant segment.
Map the causal chain. Identify the customer behavior that must change before the business result can move.
Test the riskiest assumption. Learn whether the problem, proposed value, usability, feasibility, or business logic is most uncertain.
Ship the smallest meaningful change. Reduce the scope needed to create observable behavior, not merely the number of tickets in the release.
Monitor leading and guardrail signals. Leading indicators may appear within days, while durable or lagging outcomes can require weeks to assess.
Write the learning memo. Record what happened, what remains uncertain, and whether the evidence supports continuing, changing, scaling, or stopping.
Instrumentation belongs in the bet, not in a cleanup backlog after launch. Define event names, eligibility rules, segments, exposure, dashboards, and metric ownership before the change reaches customers. Otherwise, the team may ship on time and still be unable to answer whether the intended behavior occurred.
Match the evidence method to the decision
Use an A/B test when you need causal confidence and can create valid comparison groups. Set the minimum detectable effect before the test so the team knows whether the available population and duration can detect a change large enough to matter. A test that cannot resolve the decision is activity, not useful evidence.
Not every change can be randomized. Sequential rollouts, pre-post comparisons, cohort analysis, and synthetic controls can still inform a decision, but their limitations should remain visible. Seasonality, selection effects, concurrent launches, and changes in traffic can produce movement that the product change did not cause. Label the conclusion with the strength of the evidence rather than presenting every dashboard shift as proof.
Also distinguish a negative result from an inconclusive one. A well-powered test that shows the necessary behavior did not change challenges the hypothesis. A test with weak exposure, broken instrumentation, or insufficient sensitivity says much less. The next decision should reflect that difference.
Replace status rituals with decision rituals
Each operating cadence should answer a distinct question:
Strategy reviews: Are the chosen outcomes still the right expression of the strategy, given current customer and business evidence?
Team reviews: What did the team learn about the problem, causal chain, solution, and metrics, and what will it test next?
Portfolio reviews: Which bets deserve more investment, which need to change, and which should stop?
Quarterly business reviews: What customer and business results changed, what was learned, and how should allocation change? Releases provide context, not the score.
A useful review page shows the baseline, current value, target, leading indicators, guardrails, confidence level, latest learning, and next decision. A release list without those fields is a delivery update, even if the slide is labeled “outcomes.”
Incentives must support the same behavior. Teams should be accountable for the quality of their discovery, the integrity of measurement, the speed with which they resolve material uncertainty, and the decisions they make from evidence. Treating every missed outcome as individual failure encourages conservative targets, favorable metric selection, and reluctance to stop weak bets. Outcomes are influenced, not manufactured on command.
Introduce the model through a real decision
A company-wide reorganization is not the safest starting point. Begin with an important product area where the current feature plan contains meaningful uncertainty and leadership is willing to let evidence change the solution.
Select one outcome and record its baseline, causal chain, leading indicators, and guardrails.
Assign it to a durable product trio with written decision boundaries.
Convert the planned initiative into a bet brief with assumptions and stopping conditions.
Change the existing team and portfolio reviews so they require evidence and an explicit decision.
At the end of the planning cycle, inspect where decisions still stalled: unclear strategy, missing data, dependency conflicts, weak skills, incentive mismatch, or executive overrides.
Repair those operating constraints before expanding the model to more teams.
Treat the operating model itself as a product. Its users are the teams and leaders making decisions. Its outcomes are clearer ownership, lower decision latency, stronger learning, and better allocation of effort. Changing an org chart without changing those behaviors is just another output.
Key takeaways for your next planning cycle
An outcome must name an observable change, not disguise a feature as an OKR.
Pair every outcome with a baseline, causal chain, leading indicators, guardrails, constraints, and an evidence standard.
Give durable teams authority over discovery and solution choices within explicit strategic and risk boundaries.
Manage solutions as bets that can earn, lose, or redirect investment as evidence changes.
Keep enabling work visible by naming the capability it improves, the outcomes it unlocks, and the risk of delay.
Review customer behavior, business movement, learning, and next decisions. Do not use delivery activity as a substitute for impact.
At your next roadmap review, take the most expensive planned initiative and rewrite it as an outcome contract and bet brief. If the room cannot agree on the target behavior, baseline, causal link, decision owner, and evidence that would stop the work, the initiative is not ready for a larger commitment. Resolve that uncertainty before adding more scope.
