I keep a simple mantra front and center: Figma is not the source of truth. The customer is. In practice, that means the only thing that truly counts is what we ship, how it performs, and whether users come back for more. Mockups are hypotheses; production usage is evidence. When my teams adopt this lens, velocity improves, judgment sharpens, and quality rises where it matters most.
So what does design actually do in a software company? At its best, design builds leverage for the whole system—engineering, product, and marketing—by clarifying problems, raising the quality bar, and making complex decisions legible. The standard I hold is ancient and still essential: products must be useful, usable, and desirable — and above all, used. When we calibrate around “used,” debates about pixels give way to outcomes, and cross-functional partners feel the difference.
I often trace the roots of our craft back well beyond the digital era. The lineage from industrial design to software is real; constraints, ergonomics, affordances, and systems thinking didn’t start with screens. If you’ve ever mapped delight, performance, and reliability in a Kano Model, you’ve touched this lineage. The translation to software is simple: design the full journey, not just the interface—prioritize what improves time-to-value, reduces cognitive load, and earns habitual use.
One lesson I’ve learned the hard way: why design leaders who stop designing stop leading. I still sketch flows, write UX copy, and prototype when it unblocks the team or sets a decisive quality bar. The altitude changes constantly—one hour I’m in a strategic roadmap review, the next I’m in a critique or poking at a prototype. Great design leaders jump up and down in altitude to connect vision to details without becoming a bottleneck.
Over time, I’ve come to rely on four pillars every design manager must master: craft (raising taste and execution), product strategy (clarifying choices and trade-offs), people leadership (coaching, feedback, and hiring), and systems (processes, rituals, and design ops that scale). Neglect any one of these and either quality, speed, or team health will eventually falter.
Perfectionism is a double-edged sword. Over-indexing on quality can paralyze decision-making, but lowering the bar indiscriminately is worse. I’ve seen moments where relaxing standards to “go faster” actually cost the business—rework piled up, trust eroded, and customer value stalled. The answer is principled delegation: I define what “must be true” at each milestone, delegate ownership with clear guardrails, and reserve my veto power for moments where product integrity is genuinely at risk.
Measuring success as a design leader starts with outcomes vs output OKRs. I care about activation, retention, time-to-first-value, NPS verbatims tied to key journeys, and the operational metrics that earn the right to build the next thing. Design output is visible; design outcomes are durable. When trade-offs are needed, I optimize for the smallest shippable surface that still proves the core value proposition, then expand with data.
Scaling judgment is the multiplier. I build it through pattern matching—studying enduring product systems from companies like Airbnb, Amazon, Apple, Asana, Notion, Stripe, Nest, and others—to distinguish where polish compels usage versus where it’s ornamental. Strong opinions matter, but so does being easy to convince with new evidence. I encourage designers to articulate the pattern they’re invoking, why it fits the job-to-be-done, and how we’ll know it worked.
Operating cadence matters. My week is anchored around recruiting, crits, and staff meetings that actually make decisions. In critiques, I use the Do/Try/Consider framework to give actionable direction without micromanaging. On one-on-ones, the question isn’t “Should one-on-ones exist?” but “What are they for right now?”—coaching, performance, or clearing execution blockers. If a meeting doesn’t increase clarity or commitment, it gets redesigned or removed.
Execution-wise, I’ve taken inspiration from Rippling’s operating system—especially its emphasis on speed, precise ownership, and hard commitments. The lesson is timeless: go fast on the right things, make clear promises, and instrument your work so you can see reality quickly. When speed is paired with crisp decision rights and observable outcomes, momentum compounds rather than frays trust.
Hiring your first design leader? Look for someone who can set standards, scale judgment, and ship. They should be able to zoom from company narrative to interaction copy in a single afternoon, coach product trios, and build rituals that make taste and trade-offs explicit. Above all, they should have a point of view on where quality moves the business and where speed is the quality.
Here’s how my team’s approach differs from many: Figma is not the source of truth. We design in Figma, but we learn from production. We pair designers with engineering early, prototype in code when it reduces risk, and wire telemetry into every critical path. Product trios use discovery to validate “useful, usable, desirable — and used,” then commit to outcomes with clear, testable definitions of success. The result is faster iteration, fewer surprises, and experiences customers actually adopt.
The throughline is simple and demanding: design for reality, not for the board. Keep your standards where they create business value, scale judgment with explicit patterns, and instrument everything so learning never stops. When teams embrace that, the work gets better, customers feel it, and the roadmap starts to pull you forward.
Your team can generate a PRD, summarize an interview, and draft acceptance criteria in minutes. Yet the product still may not ship faster. Customer evidence remains scattered, decisions lose their rationale at handoffs, and nobody knows whether an AI-generated recommendation deserves to be trusted.
An AI-native product development workflow fixes that operating system. It connects evidence, decisions, delivery, and evaluation in one traceable learning loop. The goal is not to produce more documents. It is to shorten the path from a customer signal to a reliable product decision, then carry the result back into the next decision.
Change the unit of work from an artifact to a decision
AI-assisted teams use a model inside an existing process. They write the same documents, hold the same handoffs, and make the same decisions, only with faster drafting. That can save time, but it leaves the fundamental bottlenecks untouched.
An AI-native workflow reorganizes the process around decisions. Every meaningful unit of work should carry enough context for the next person or system to understand what is being decided, why it matters, and what evidence would change the decision.
Use a decision packet with five parts:
Decision: State the exact choice in front of the team. Replace broad assignments such as improve onboarding with a decision such as whether to change the first-session setup flow for a defined customer segment.
Evidence: Link the customer examples, research moments, usage data, and business constraints that support the problem. Preserve the original evidence rather than storing only an AI summary.
Assumptions: Separate what the team knows from what it believes. An assumption should be written so that new evidence can confirm or challenge it.
Success condition: Name the customer or business behavior expected to change. For an experiment, define the hypothesis and, where appropriate, the minimum detectable effect before exposure begins.
Decision state: Record the owner, status, unresolved questions, next test, and reason for the latest change.
The model can retrieve evidence, compress it, identify inconsistencies, draft alternatives, and check whether required fields are missing. A person still owns the interpretation, trade-offs, priority, and release decision. This boundary prevents polished language from being mistaken for product judgment.
Apply a simple test to every AI-generated artifact: what decision will this change? If the answer is unclear, the artifact is probably workflow noise. If the answer is clear, attach the artifact to the decision packet instead of allowing it to become another disconnected document.
Build an evidence spine before adding more automation
Most product workflows fragment evidence before a model ever sees it. Support tickets sit in one system, sales notes in another, interviews in folders, and behavioral data in an analytics platform. A prompt cannot recover relationships that the operating system never preserved.
Normalize incoming evidence while preserving its source identifier, relevant customer or segment context, and access permissions.
De-duplicate repeated signals and cluster related evidence without erasing meaningful differences between customers or use cases.
Retrieve a small set of representative examples for the decision being made. Do not dump the entire evidence store into the model context.
Write the approved decision, its assumptions, and its rationale into durable external state.
Return experiment results, release outcomes, and new qualitative feedback to the same evidence system.
Keep three forms of information distinct. The evidence store contains raw and normalized inputs. Working context contains only the material needed for the current task. The decision log contains approved conclusions, rejected alternatives, owners, and changes. Mixing all three creates stale prompts, contradictory instructions, and summaries that can no longer be audited.
A prioritization recommendation, for example, should link back to representative customer records and the relevant analytics view. A summary without those links is compression, not evidence. When somebody challenges the recommendation, the team should be able to inspect the underlying material without asking the model to reconstruct its reasoning from memory.
This is also where data governance belongs. Decide which systems the workflow may retrieve from, which fields require redaction, who can see sensitive records, and how model outputs will be retained before connecting those systems. Privacy-by-design, cybersecurity, and regulatory controls need to sit alongside the workflow, not appear as a review after customer information has already crossed an inappropriate boundary.
Run one closed loop from discovery to shipped learning
The product trio remains important in an AI-native workflow. Product, design, and engineering use automation to reach the evidence faster and explore more alternatives, while keeping explicit human gates around interpretation, feasibility, customer experience, and risk. Clear handoffs between context design, external memory, and orchestration make those responsibilities easier to see.
For each stage, name the AI job, the human gate, and the durable output. That turns a collection of AI tools into an operating workflow.
Stage
AI accelerates
Human gate
Durable output
Intake and triage
Normalize, de-duplicate, cluster, and retrieve representative customer signals.
Verify that a cluster reflects a real customer problem rather than repeated wording or a noisy channel.
An opportunity record linked to original evidence.
Discovery
Draft interview guides, summarize transcripts, extract entities, and tag moments of friction.
Interpret what the customer meant, identify contradictions, and decide which uncertainty deserves another conversation.
An evidence-backed problem narrative with open questions.
Opportunity sizing
Organize evidence against a driver tree and assemble available inputs about potential impact.
Choose the outcome, inspect data quality, expose assumptions, and make the prioritization trade-off.
A ranked opportunity with decision criteria and explicit assumptions.
Test desirability, usability, feasibility, strategic fit, and the cost of being wrong.
A solution hypothesis, acceptance criteria, and a test plan.
Planning and execution
Break an approved bet into sequenced work, surface dependencies, and check artifacts for missing requirements.
Set scope, choose rollout controls, confirm instrumentation, and approve release readiness.
An instrumented release plan connected to feature flags, CI/CD, and observability.
Iteration
Compare expected and actual outcomes, organize qualitative feedback, and surface anomalies for review.
Decide whether to scale, revise, stop, or collect more evidence.
An updated decision record returned to the evidence spine.
Exit criteria keep each stage honest. Discovery is not complete because the transcripts have been summarized. It is complete enough to move forward when the team can name the customer problem, the supporting evidence, and the uncertainty it intends to resolve next. Solution shaping is not complete because a PRD exists. It is complete when the hypothesis, constraints, acceptance criteria, test method, and required telemetry are clear enough for a responsible decision.
Plan measurement before release. If the team will use an A/B test, write the hypothesis and minimum detectable effect before looking at the result. If controlled experimentation is not appropriate, name the expected behavior change and the qualitative evidence that would support or challenge it. Feature flags provide controlled exposure, while observability helps the team understand why behavior changed rather than merely showing that it changed.
Engineer context, evaluations, and decision rights together
Reliability cannot be added as a final quality check. Every AI transformation can lose evidence, introduce unsupported language, or carry stale assumptions into the next stage. The workflow needs controls at the moment each failure can occur.
Give each task a context contract
One large prompt that tries to perform discovery, prioritization, specification, and planning will accumulate irrelevant material and conflicting instructions. Break the workflow into smaller tasks, each with a compact context contract:
Use a sub-agent when a task benefits from an isolated context or a separate review, such as checking a PRD against approved evidence. Do not add one merely to make the system look agentic. Every additional agent creates another handoff whose inputs, outputs, permissions, and failure behavior must be evaluated.
Build an evaluation harness before scaling the workflow
An evaluation should answer a repeatable question: does this workflow produce an acceptable result on representative work? A few impressive demonstrations do not tell you whether a prompt, retrieval change, or model update made the system more dependable.
Start with real task types your team already performs. Preserve representative inputs, the evidence that should be used, the requirements an acceptable output must satisfy, and known failure conditions. Then run those cases whenever you change the prompt, model, retrieval logic, tool permissions, or output schema.
Evaluate at least these dimensions:
Grounding: Can each important claim be traced to approved evidence?
Fidelity: Did the output preserve material differences, uncertainty, and constraints rather than flattening them into a convenient narrative?
Completeness: Are the fields required for the next decision present?
Decision usefulness: Does the output help a named owner make a specific choice?
Data handling: Did the workflow respect access, redaction, and retention rules?
Format and tool behavior: Did the model follow the schema and use only permitted systems or actions?
Documents generated, prompts executed, and summaries produced are activity measures. They can rise while product decisions become less reliable. Use four layers of measurement instead:
Learning flow: Time from a customer signal to an evidence-backed decision, time spent waiting at handoffs, and rework caused by missing context.
AI quality: Evaluation results by task, unsupported claims found during review, required fields missed, and human corrections before approval.
Customer outcome: The activation, adoption, retention, or other behavior named in the original hypothesis.
Delivery health: Deployment frequency, change failure rate, and the operational signals relevant to the release.
Keep decision rights visible beside those measures. The model may propose a priority, but the accountable product leader approves it. The model may draft a customer interpretation, but the product trio validates it against evidence. The model may prepare a release plan, but engineering owns operational readiness. Feature flags, access controls, and human approval are not signs that the workflow is insufficiently automated. They are what make greater automation responsible.
Log the decision, evidence references, model version, prompt or workflow version, retrieval configuration, evaluation result, and approving owner. Documenting decisions, model versions, and test artifacts makes a nuanced call auditable and gives the team a concrete starting point when quality changes.
Key takeaways: a 30/60/90-day rollout
Do not begin by automating the full product lifecycle. Start with one recurring decision, connect its evidence to its outcome, and prove that the loop can be operated reliably. A practical 30/60/90 sequence expands from the evidence foundation to selected workflows and then into planning and delivery.
Days 1-30: Map the evidence systems used for one recurring product decision. Define the decision packet, access rules, retrieval path, current human gates, and initial evaluation cases. Build the smallest retrieval-first pipeline that can preserve links from a recommendation back to original evidence.
Days 31-60: Pilot continuous discovery and PRD drafting. Keep approval manual, evaluate representative cases, record recurring corrections, and tighten the context contract. Do not expand until the team can identify why an output passed or failed.
Days 61-90: Extend the proven pattern to prioritization and experiment design. Connect approved outputs to planning, CI/CD, feature flags, and observability. Feed release outcomes and customer feedback back into the evidence spine.
By the end of the rollout, you should be able to trace an AI recommendation to customer evidence, reconstruct why a decision changed, detect a quality regression after a workflow update, and compare the expected outcome with what happened after release. If one of those paths is missing, fix it before adding another agent or automating another handoff.
Your next move can be small. Choose one product decision scheduled for this week. Put its evidence, assumptions, success condition, and state into a decision packet. Then follow that packet through discovery, delivery, and the first outcome review. That single trace will reveal where your workflow is genuinely AI-native and where faster drafting is only hiding an old bottleneck.
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.
“Continuous Discovery Habits” turns five this year, and I’m celebrating by reading the book together with you. Each month, I’m releasing an in-depth reading guide designed for empowered product teams and product trios—complete with the chapters we’ll read, a preview of the key concepts, short shareable videos, individual and team discussion prompts, team exercises you can run immediately, and additional reading to go deeper.
We’ll discuss each month’s reading in the comments, and we’ll gather quarterly for live calls. If you’re joining late, no problem—I’ll be monitoring comments throughout the year. Start with the current month or go back to January (https://www.producttalk.org/lets-read-continuous-discovery-habits-together-january-2026/). Jump in where it serves you best, ask for help, share what’s working, and connect with other readers any time.
If you want to participate, grab a copy of the book (https://amzn.to/3hGkNYT?ref=producttalk.org)—or dust off your old one—share the “Spread the Love” videos with your colleagues, set aside time to run the team exercises, and register for the community sessions. Let’s do this.
This Month’s Reading
Chapters: Chapter 3: Focusing on Outcomes Over Outputs
Estimated reading time: ~22 minutes
This chapter zeroes in on the critical difference between business outcomes and product outcomes—and why it matters which one your team is assigned; how to translate lagging business metrics into actionable product outcomes you can actually influence; why setting outcomes should be a two-way negotiation between leaders and product trios; when to start with a learning goal versus a performance goal; and five common anti-patterns that derail outcome-focused teams. Need a copy? Grab the book (https://amzn.to/3hGkNYT?ref=producttalk.org).
Share the Love with Friends and Colleagues
We learn best in community. I like to seed conversations across my org with short, high-signal content—especially when I’m shifting a culture from outputs to outcomes and sharpening OKRs. Use these short videos to bring peers into the conversation and invite them to read along:
“What’s an outcome?” (https://videos.producttalk.org/videos/ea9fdab71d1ee3c263/whats-an-outcome?ref=producttalk.org) — The real value of starting with an outcome. “Business outcomes vs. product outcomes” (https://videos.producttalk.org/videos/069fd5b5101ee2c78f/business-outcomes-vs-product-outcomes?ref=producttalk.org) — Why product teams need product outcomes, not business outcomes. “What’s the difference between OKRs and outcomes?” (https://videos.producttalk.org/videos/069fdab61919e4c38f/whats-the-difference-between-okrs-and-outcomes?ref=producttalk.org) — Any outcome can be represented as an OKR. “Understanding revenue model formulas” (https://videos.producttalk.org/videos/799fd5b5101ee2c4f0/understanding-revenue-model-formulas?ref=producttalk.org) — How to identify the business outcomes your company cares about. “Revisit your outcome every quarter” (https://videos.producttalk.org/videos/449fd5b4111ee0cfcd/revisit-your-outcome-every-quarter?ref=producttalk.org) — Don’t abandon your outcome, but do revisit how you measure it.
Reflect and Discuss What You Read
Reflection is the conversion rate optimizer for learning. When we pause to discuss what we’re reading, we retain more and apply it faster—especially in product discovery and product strategy work. This chapter challenges us to update our definition of success: away from features shipped and toward outcomes achieved. This month, I’m examining my own relationship with outcomes—where I’ve been rigorous, where I’ve drifted, and how I can help my teams strengthen day-to-day behaviors.
Individual Reflection
If your team isn’t working toward an outcome, look at the features or projects on your roadmap and ask: What impact are they supposed to have? If they succeed, what customer behavior or business result would change? If your team does have an outcome, consider whether it’s a business outcome, a product outcome, or a traction metric—and how that choice shapes your daily decisions and discovery cadence. Finally, think about the last time your team’s outcome changed: Was it a deliberate strategic shift, or did it feel like ping-ponging from one priority to the next?
Team Discussion
As a team, classify your current outcome: Is it a business outcome, a product outcome, or a traction metric? If it’s a business outcome, identify the leading customer behaviors that would signal momentum; if it’s a traction metric, broaden it to a product outcome that gives you more room to explore. Then, name which of the five anti-patterns (pursuing too many outcomes, ping-ponging, individual outcomes, outputs as outcomes, or tunnel vision) shows up for you and pick one concrete change. Finally, assess how outcomes are set: Are they handed down, or does your product trio co-create them? What would it take to make this a true two-way negotiation?
Put It Into Practice
Understanding the difference between business outcomes and product outcomes is table stakes. Translating one into the other is where product management leadership shows up. These exercises will help you connect company goals to customer behavior, avoid outcomes vs output OKRs traps, and increase your span of control over meaningful change.
Exercise: Map Your Revenue Model
Time: 30 minutes. Do this: Solo first, then share with your team. Start with this question: How does your company make money? Write out the formula for your revenue model. For example, a subscription business might be: Revenue = Number of Customers × Average Monthly Spend × Retention. Once you have the formula, identify each variable as a potential business outcome. Then, for each business outcome, brainstorm two to three product outcomes (customer behaviors or sentiments) that might be leading indicators. Which of these product outcomes is your team best positioned to influence?
Exercise: Audit Your Current Outcome
Time: 45 minutes. Do this: With your product trio. Take your team’s current outcome and run it through a quick diagnostic: Is it a business outcome, product outcome, or traction metric? If it’s a business outcome, what product outcomes might drive it? If it’s a traction metric, how might you broaden it to a product outcome? Is it a leading indicator or a lagging indicator? Can you measure progress weekly, or do you have to wait months? Is it within your team’s span of control? Based on your answers, draft a revised outcome that offers more actionable feedback while still connecting to business value, and prepare to discuss this with your product leader.
Go Deeper: Additional Reading
If you prefer an audio summary of this month’s reading, including the book chapter and the resources below, I’ve included an audio version at the end of this post for paid subscribers.
Related In-Depth Guide: Shifting from Outputs to Outcomes: Why It Matters and How to Get Started (https://www.producttalk.org/shifting-from-outputs-to-outcomes/).
Supplementary Reading: Empower Product Teams with Product Outcomes, Not Business Outcomes (https://www.producttalk.org/2020/05/product-outcomes/). Defining Product Outcomes: The 8 Most Common Mistakes You Should Avoid (https://www.producttalk.org/2022/12/defining-product-outcomes/). Understanding How Product Outcomes Connect to Revenue and Costs (https://www.producttalk.org/2023/04/connecting-product-outcomes-to-revenue-and-costs/). Product in Practice: Iterating to an Actionable Outcome at tails.com (https://www.producttalk.org/2020/08/actionable-outcomes/). Product in Practice: Iterating on Outcomes with Limited Data (https://www.producttalk.org/2023/12/iterating-on-outcomes-with-limited-data/). Measurable Outcomes – All Things Product with Teresa Torres and Petra Wille (https://www.producttalk.org/measurable-outcomes-all-things-product-podcast-with-teresa-torres-petra-wille/).
Other Voices: The Business Equation by Brett Bivens (https://venturedesktop.substack.com/p/the-business-equation?ref=producttalk.org). KPI Trees: How to Bridge the Gap Between Customer Behavior, Product Metrics, and Company Goals by Petra Wille and Shaun Russell (https://www.petra-wille.com/blog/kpi-trees-how-to-bridge-the-gap-between-customer-behavior-product-metrics-and-company-goals?ref=producttalk.org). Persistent Models vs. Point-In-Time Goals by John Cutler (https://cutlefish.substack.com/p/tbm-2553-persistent-models-vs-point?ref=producttalk.org). Is It Time to Ditch the Old SaaS Metrics? by Kyle Poyar (https://openviewpartners.com/blog/saas-metrics-plg/?ref=producttalk.org). How Engagement Metrics Can Be Misleading by Oleg Yakubenkov (https://gopractice.io/blog/how-engagement-metrics-can-be-misleading/?ref=producttalk.org). Subscription Churn Metrics and Benchmarks for Operators by Elena Verna (https://www.elenaverna.com/p/subscription-churn-benchmarks-and?ref=producttalk.org).
Related Courses: Business Fundamentals: Navigate Your Business Context with Confidence (https://learn.producttalk.org/course/business-fundamentals?utm_source=Product+Talk&utm_medium=cdh-book-club-february-2026).
Our Live Discussion Schedule
Our live discussion sessions are for paid subscribers and will not be recorded. Invitations will go out to Supporting Members and CDH Members (http://members.producttalk.org/?ref=producttalk.org) two weeks before each event—reserve time on your calendar now so you can participate fully and bring real examples from your team.
Wednesday, March 18, 2026: 9am–10am PDT and 4pm–5pm PDT. Tuesday, June 16, 2026: 9am–10am PDT and 4pm–5pm PDT. Thursday, September 17, 2026: 9am–10am PDT and 4pm–5pm PDT. Wednesday, December 16, 2026: 9am–10am PST and 4pm–5pm PST.
Audio Summary
Prefer to listen? I’ve included an audio summary—Stop Measuring Code Start Measuring Behavior—at the end of this post so you can review the main ideas on your commute or between meetings.
I’m excited to dive into outcomes with you this month. As a product leader, I’ve seen teams transform their product discovery, product roadmapping and sprint planning, and OKR quality when they anchor on clear product outcomes tied to business value. Let’s build that muscle together and make this a quarter where we stop measuring output and start driving outcomes.
Your roadmap can be coherent, the launch can go smoothly, and adoption can still stall. The usual gap is not a lack of effort. Product strategy, field discovery, technical validation, and post-launch adoption were treated as separate activities, so each team learned something that the others could not use.
You can close that gap by treating solutions engineering as part of the product learning system. The goal is not to give sales more technical coverage or product managers a larger queue of requests. It is to turn real customer conditions into testable product decisions, then follow those decisions until customers reach and repeat the intended outcome.
Key takeaways
Define adoption as an observable customer behavior before you approve features or plan a launch.
Ask solutions engineers to capture evidence in a consistent format, separating what happened from what the team thinks it means.
Treat demos and proofs of value as experiments with a hypothesis, baseline, value event, and decision rule.
Measure the entire path from promise to repeated value. A login, click, or feature visit is rarely sufficient evidence of adoption.
Route each adoption problem to the right response: positioning, enablement, onboarding, integration, product design, or core capability.
Carry launch learning into roadmap and operating reviews so that adoption changes product decisions instead of becoming a reporting exercise.
Write the adoption contract before debating the roadmap
Product strategy becomes operational only when it specifies whose behavior should change, why that change matters, and what evidence would show that the product created value. Without that translation, teams can agree on a strategic theme while holding incompatible ideas about what success means.
Write an adoption contract for every significant product bet. This is not a legal document or a long requirements package. It is a compact agreement among product, engineering, design, solutions engineering, sales, and customer success about the outcome being pursued.
Target user: Name the persona and operating context. A broad account segment is not enough when different people inside the account perform different jobs.
Starting condition: Describe the workflow, constraint, or workaround that exists before the change. This gives you a baseline against which the new experience can be judged.
Desired outcome: State the progress the customer wants, not the capability you intend to ship.
Value event: Identify the observable behavior showing that the user reached meaningful value. Opening a page may indicate exposure; completing the intended workflow is stronger evidence.
Repeat condition: Define what sustained use looks like at the natural cadence of the workflow. Daily activity is useful only when the job itself occurs daily.
Decision evidence: Agree on the metric, qualitative evidence, technical constraints, and guardrails that will determine whether to continue, change, or stop the bet.
Suppose a product automates part of an operations workflow. Increase feature adoption is too weak to guide a team. A more useful contract says that the operations manager can complete the target workflow, obtain the intended result, and return to it when the job recurs without relying on the old workaround. The team can now examine setup, permissions, integrations, comprehension, completion, and repetition as separate parts of the same outcome.
This contract also changes roadmap conversations. A feature request no longer competes on enthusiasm alone. You can ask which persona it serves, which blocked outcome it unlocks, what evidence supports the problem, and which customer behavior should change if the solution works. If those questions have no answers, the request needs more discovery before it needs an estimate.
Keep the contract stable enough to align the organization, but do not protect it from evidence. If customers repeatedly pursue a different outcome, struggle with an unanticipated dependency, or assign value to another part of the workflow, revise the contract explicitly. Silent reinterpretation is dangerous because every function can declare success against a different definition.
Turn solutions engineering into a field evidence system
A solutions engineer sees details that rarely survive a conventional feature request: the customer’s existing architecture, the sequence of the workflow, the people involved in approval, the point at which a demonstration loses credibility, and the difference between a stated objection and an actual blocker. That information can improve strategy, but only if the organization captures it in a form that product teams can compare and act on.
Do not send raw call notes into a backlog and call it discovery. Use a consistent field record containing:
The persona, account context, and job being attempted.
The customer’s desired outcome and current way of achieving it.
The specific moment where the current product or proposed solution created friction.
The relevant technical condition, such as an integration, data, permission, security, or scalability constraint.
The evidence observed: customer behavior, workflow review, demonstration response, deployment result, or instrumented product data.
The proposed interpretation and any plausible alternative explanation.
The next question or test that would reduce uncertainty.
Within that record, separate observation, interpretation, and request. They are not interchangeable.
Observation: The administrator could not complete configuration because a required permission was unavailable.
Interpretation: The permission model may not match how this persona operates.
Request: Add a new administrative role.
The observation is evidence. The interpretation is a hypothesis. The request is merely a candidate solution. Keeping them separate prevents the first proposed feature from becoming the definition of the problem.
Product leaders also need to protect this system from deal gravity. A commercially urgent request can be important without representing a widespread product problem. Conversely, a small implementation detail can reveal a structural barrier affecting an entire target persona. Evaluate field evidence with questions that make those differences visible:
Does the problem recur for the same persona, workflow, or environment?
Does it block the value event, or does it affect a peripheral preference?
Is the root cause a missing capability, product usability, configuration, integration, positioning, or customer process?
Does the problem appear in the strategic segment the product is designed to serve?
Can a smaller or reversible test distinguish competing explanations?
What roadmap decision would change if the hypothesis were confirmed?
The last question is a useful filter. If no plausible answer would change a decision, the team may be collecting interesting information rather than decision-grade evidence.
Bring the strongest records into the product trio’s learning cycle. Field evidence can then sharpen roadmaps, sprint planning, positioning, integration decisions, and stakeholder conversations. The solutions engineer contributes technical discovery and customer context. Product management synthesizes patterns and owns tradeoffs. Design examines behavior and workflow. Engineering tests feasibility and exposes architectural consequences. Sales contributes commercial context without converting urgency into automatic priority. Customer success adds evidence about repeated use after the initial deployment.
This arrangement does not require every customer conversation to become a committee meeting. It requires a common evidence format, clear decision ownership, and a route by which meaningful field learning reaches the people making product choices.
Run demos and proofs of value as product experiments
A polished demo can prove that a presenter understands the product. It does not prove that a customer can adopt it. Even a successful technical pilot can produce a false positive if the solutions engineer performed work that the target user cannot repeat, the environment was unusually controlled, or the team never defined what customer value would look like.
Design every proof around a falsifiable outcome hypothesis. A practical structure is:
For [persona] in [context], enabling [change] should produce [observable behavior] because [value mechanism]. The hypothesis is supported if [agreed evidence] meets [predefined decision rule] without violating [guardrail].
The brackets force useful decisions. You have to name the user, the operating condition, the expected behavior, and the reason the behavior represents value. You also have to decide what would count as failure before enthusiasm about the result changes the standard.
Build the proof plan around the following elements:
Baseline: Document how the customer handles the job now, including meaningful friction and dependencies.
Scope: State which workflow, persona, environment, and constraints the proof includes. Anything outside that boundary remains unvalidated.
Value event: Identify the customer action or result that demonstrates progress toward the desired outcome.
Instrumentation: Decide which product events and qualitative observations will show where users advance or stop.
Enablement: Record how much assistance the customer receives. Heavy expert intervention can validate technical feasibility while leaving self-service adoption unproven.
Decision rule: Define what evidence will justify progression, iteration, repositioning, or stopping.
Learning owner: Name the person responsible for translating the result into a product, go-to-market, or adoption decision.
A compact learning record can follow Insight – Hypothesis – Experiment – Metric. The sequence matters. A customer comment produces an insight, not a roadmap commitment. The insight leads to an explanation that can be tested. The test produces evidence against a metric or decision criterion.
Capture objections with the same discipline. An objection about missing functionality may actually reflect an unclear value proposition, concern about integration effort, lack of trust in the output, or a mismatch between the buyer and the eventual user. Ask what the customer is unable or unwilling to do because of the concern. That question moves the discussion from the requested feature to the blocked behavior.
At the end of a proof, classify what was learned:
Value validated: The target persona reached the intended outcome under representative conditions.
Need validated, capability missing: The problem matters, but the product cannot yet support the required workflow.
Capability works, adoption friction remains: The product can deliver value, but setup, comprehension, trust, or workflow design prevents the user from reaching it reliably.
Technical path blocked: An integration, architecture, data, permission, or operational constraint prevents deployment.
Positioning mismatch: The product can do what was promised, but the outcome is not important enough for the target persona or was framed in the wrong terms.
Evidence inconclusive: The test did not represent the intended user or environment, or the decision criteria were not measurable.
These outcomes lead to different work. A positioning mismatch belongs in messaging and discovery. Adoption friction may require onboarding or product design. A recurring technical blocker may deserve roadmap investment. An inconclusive test deserves a better test, not a success story.
Demos and early deployments become high-signal learning mechanisms when their evidence returns to product strategy instead of ending in the opportunity record. That closed loop is what allows solutions engineering to improve both customer execution and the underlying product.
Measure adoption as a path, then act at the break
Adoption is not a single metric. It is a sequence that begins with a credible promise and ends when the customer repeatedly receives value. Measuring only the end hides the reason users failed. Measuring only clicks overstates progress.
Map the path for the persona named in the adoption contract:
Promise understood: The user or buyer can connect the product to a relevant outcome.
Entry: The intended user begins setup or enters the target workflow.
Readiness: Required data, permissions, integrations, and configuration are in place.
Activation: The user reaches the first meaningful value event.
Repetition: The user returns when the underlying job recurs and reaches value again.
Expansion: Appropriate users, workflows, or capabilities are added because the initial value is credible.
Retention: The product remains part of the operating workflow because it continues to produce the desired outcome.
Instrument enough of this path to locate the break. For each event, retain the eligible persona or account, relevant product context, action attempted, result, and connection to the intended outcome. Always state the denominator. Activation among configured users answers a different question from activation among all purchased accounts.
Use metrics such as time-to-value, daily active usage, and feature adoption only when they match the product’s natural workflow. A monthly administrative task should not be judged by daily activity. A high feature-visit count does not establish value if users repeatedly enter the feature because they are confused. Pair behavioral data with the qualitative context collected during proofs, implementations, and customer conversations.
Observed pattern
Question to investigate
Likely response area
Interest is high, but eligible users do not begin
Is the value proposition relevant and credible to this persona?
Positioning, targeting, or enablement
Users begin, but readiness fails
Which data, permission, configuration, or integration dependency is blocking progress?
Onboarding, implementation, or platform capability
Users complete setup, but do not reach the value event
Does the workflow lead clearly to the promised outcome?
Product design, guidance, or core capability
Users activate, but do not return
Is the job recurring, and was the first outcome valuable enough to change behavior?
Discovery, workflow fit, trust, or value proposition
Adoption differs sharply by persona or context
Was the product designed and positioned for the segment that is actually succeeding?
Segmentation, strategy, or packaging
Usage is high, but retention or customer outcomes remain weak
Is activity measuring value, required effort, or repeated friction?
Metric design, product quality, or outcome alignment
Match the intervention to the break. Use onboarding checklists, empty-state prompts, in-app guides, and product tours when the user needs contextual direction. Do not use a tooltip to conceal a broken permission model, an unreliable integration, or a workflow that does not create enough value. Guidance can reduce comprehension friction; it cannot repair a missing capability.
When you test an intervention, define the intended behavior change and success criterion in advance. Segment the result by the persona and context in the adoption contract. An aggregate improvement can hide a deteriorating experience for the strategic user, while a neutral aggregate can hide a strong response in the segment the product is meant to serve.
The adoption contract and any evidence that challenges it.
Progress through the journey, segmented by the intended persona and context.
The strongest field observations, with interpretations kept separate.
The active hypotheses and experiments.
The product, positioning, enablement, integration, or onboarding decision each experiment may change.
The owner responsible for making that decision and returning the result to the group.
Use operating reviews and QBRs to evaluate outcomes, not to count shipped features or completed guides. Ask which hypothesis was confirmed, which constraint was removed, where customers still stop, and what the organization will do differently. If an experiment has no route to a decision, revise it or stop it.
For your next significant product bet, start before the launch plan. Write the adoption contract, ask a solutions engineer to challenge it with field conditions, and define the evidence that would change your mind. That small discipline gives every later conversation – roadmap, demo, onboarding, analytics, and QBR – the same customer outcome to pursue.
I just tuned into the latest conversation on the upcoming Product at Heart 2026, and it hit on the exact challenges product leaders are navigating right now: curating meaningful content in a world where AI moves faster than our agendas, designing formats that create real connection, and ensuring every minute earns its place. Listening to Petra Wille and Teresa Torres map out the speaker lineup, workshops, and structural shifts, I found myself nodding along—this is the kind of thoughtful curation we need if we want product teams and product leaders to walk away with practical value, not just inspiration.
Listen to this episode on: Spotify | Apple Podcasts
What stood out immediately is the bold move to a single-track conference for 2026. In an era of gen ai hype and endless breakouts, this choice signals clear intent: tighter curation, a shared experience, and less FOMO. The team isn’t carving out a separate AI track—and I love that decision. Their stance is simple and sensible: No AI track—AI will show up everywhere, but not as a siloed topic. The team sees it as part of the everyday toolkit. That mirrors how high-performing, empowered product teams actually work today—AI Strategy and AI workflows are part of the operating system, not a side show.
The keynote lineup is already compelling. Christian Idiodi (SVPG) brings storytelling that turns product principles into habits you can actually use on Monday. Elaine Kasket, cyber-psychologist, exploring digital afterlife and AI replicas, will push us to think more deeply about the human side of our systems. And Teresa Torres will be sharing what she’s learning about AI—exactly the kind of continuous discovery mindset we need as we integrate LLMs into product discovery and delivery.
I’m also thrilled to see roundtables become what they’re calling an “alternative track.” That’s a smart way to deepen learning without fragmenting attention. The best conference ROI I’ve had often comes from targeted small-group conversations—where product trios compare approaches, swap metrics frameworks, or challenge each other’s product strategy assumptions. It’s a design choice that rewards curiosity and builds communities of practice.
We also get a behind-the-scenes look at Teresa’s Maker Studio workshop, where participants will build personal AI workflows. That’s exactly the hands-on, practitioner-first approach teams need right now—less demo theater, more systems that stick. If your roadmap includes integrating LLMs into continuous discovery or augmenting your team’s decision velocity, this kind of guided practice is gold.
The broader workshop slate looks deep and balanced. Expect returning favorites and practical frameworks: Rich Mironov on the realities of product leadership in complex orgs; Büşra’s metrics workshop translating outcomes into action; and an overview of additional workshops from Rich Mironov, Büşra Coşkuner, Marcus Castenfors, and Özlem Yüce. From success metrics to toolkits for product managers, the content spans IC to product management leadership—ideal if you’re stepping into new roles or scaling empowered product teams.
One of the most exciting evolutions is the Product Leadership Event, now a 1.5-day retreat. The format blends talk sessions, mini-workshops, dinners, and small-group excursions (boat rides, improv, etc.), giving leaders time and space to exchange playbooks, stress-test decisions, and build real relationships. It’s capped at 60 attendees (all in product leadership roles) to keep it intimate and useful. As someone who believes in outcomes vs output OKRs and first principles decision making, I appreciate how this structure encourages depth over breadth—and real accountability among peers.
Here are the core takeaways I’m carrying into my own planning: single-track means tighter curation, so every talk has to earn its place. Roundtables are growing into an “alternative track,” offering more ways to engage beyond stage talks. Workshops go deep and meet you where you are—IC, manager, or executive. And the leadership retreat expands to maximize learning from peers, not just from the stage. If you care about product discovery, product strategy, and conference networking that leads to actual business impact, this program looks thoughtfully engineered.
If you’re planning your 2026 calendar—or just curious how conferences evolve alongside the craft—this is a thoughtful walkthrough of what to expect. Come say hi to Teresa and Petra—on stage, at a roundtable, or somewhere in the hallway conversations that make these events memorable.
For more context and resources mentioned, explore: Product at Heart, Arne Kittler, Mind the Product, Christian Idiodi of Silicon Valley Product Group, Elaine Kasket, House of Beautiful Business, The 7 Habits of Highly Effective People by Stephen Covey, Rich Mironov, Marty Cagan, Claude Code, Codex by OpenAI, Marcus Castenfors, Büşra Coşkuner and her Success Metrics: A Playbook for Product Managers, Özlem Yüce’s Essential Toolkit for Product Managers, Petra’s Product Leadership Wheel (PLwheel), and Netlight.
Follow Teresa Torres: https://ProductTalk.org
Follow Petra Wille: https://Petra-Wille.com
Full transcripts are only available for paid subscribers.
I’ve led product teams through countless discovery cycles, and nothing has accelerated our learning loops like AI. By weaving AI into our continuous discovery practice at HighLevel, I cut time-to-insight, reduce risk earlier, and keep our product strategy relentlessly focused on customer outcomes.
AI streamlines product discovery by accelerating research, prototyping, and validation, enabling teams to make faster, smarter, and user-driven decisions.
In the research phase, I use gen ai and LLMs for product managers to synthesize interviews, cluster themes, and surface unmet needs in minutes instead of days. Pairing those qualitative insights with behavioral signals in Amplitude analytics helps me spot high-intent cohorts and friction points at scale, so our problem framing is both human-centered and data-backed.
From there, I translate insights into crisp hypotheses and prioritize with the Kano Model and outcomes vs output OKRs. To keep experiments honest, I define a minimum detectable effect (MDE) up front and design A/B testing plans that reflect realistic traffic and seasonality, ensuring our decisions are statistically grounded rather than anecdotal.
Prototyping is where gen ai for product prototyping really shines. I spin up multiple UX flows, UI copy variants, and edge-case scenarios using prompt engineering, then iterate with rapid feedback from product trios. When needed, I mock in-app guides and product tours to validate onboarding concepts before we commit to code, preserving velocity without sacrificing quality.
For validation, I lean on a mix of lightweight experiments—fake-door tests, concierge pilots, and targeted A/B testing—augmented by in-product surveys via Pendo or Intercom. For AI-powered features, I apply eval-driven development to measure relevance, latency, and safety, so we can ship responsibly while maintaining the pace of learning.
This approach only works when the team is structured to move fast. Empowered product teams and product trios own discovery end-to-end, with clear guardrails around data governance, privacy-by-design, and AI risk management. That alignment lets us shift from opinions to evidence, and from output to outcomes, without friction.
If you’re getting started, pick one discovery loop to transform: automate research synthesis, prototype two to three variants with AI, and validate with a tightly scoped experiment. Instrument your analytics, track time-to-insight and time-to-prototype, and iterate your product roadmapping and sprint planning with what you learn. The payoff is immediate: faster cycles, stronger conviction, and a more user-driven path to product-led growth.
Buy-in isn’t a single meeting; it’s a designed journey. Over the years leading product strategy at HighLevel, I’ve learned that the fastest way to earn durable support is to reduce uncertainty, align on outcomes, and create visible momentum. Explore how to get buy-in from stakeholders with practical strategies, clear communication tips, and proven methods used by the best. Here’s the 7-step playbook my teams and I rely on to move from idea to aligned action.
Step 1 — Anchor on outcomes, not outputs. I start by writing a crisp problem statement, the target customer, and the measurable outcome tied to our North Star metric. I translate this into outcomes vs output OKRs so every stakeholder can see the difference between what we’ll ship and what we intend to change. This framing keeps discussions grounded in impact, not features.
Step 2 — Map stakeholders and incentives. Effective stakeholder management begins with a living map: economic buyers, executive sponsors, influencers, and operators. I capture each person’s goals, risks, and decision cadence. When I speak to Finance, I foreground cost and runway; with Sales, I emphasize pipeline and win rate; for Customer Success, I speak to retention and NPS. Meeting stakeholders where they are builds trust quickly.
Step 3 — Co-create early with the product trio. I pull the product trios (PM, Design, Engineering) into continuous discovery with GTM partners to validate assumptions and de-risk the solution. This is where empowered product teams shine—rapid discovery sprints, early prototypes, and clear learning objectives. Co-creating exposes blind spots early and transforms critics into champions.
Step 4 — Socialize a narrative, not a deck. Before any formal review, I circulate a short narrative memo that ties our product strategy to a clear value proposition, competitive differentiation, and go-to-market strategy. I include options and trade-offs so stakeholders feel invited to shape the path, not just stamp approval. Pre-wiring conversations ensure that the “meeting” is simply the last 10% of the decision.
Step 5 — Back the story with data and a viable plan. I combine retention analysis, funnel metrics, and customer evidence to demonstrate opportunity size and risk reduction. Then I outline a phased approach with product roadmapping and sprint planning, milestones, and success metrics. I highlight the smallest viable bet that proves value fast, along with contingency paths if we learn something unexpected.
Step 6 — Design the decision. I define the decision we need, by whom, and by when. The decision doc includes the problem, options, risks, mitigations, and the explicit ask. I schedule 1:1s to address concerns, then run a focused review with clear roles and time-boxed discussion. Clarity about the decision—and the criteria—prevents drift and protects timelines.
Step 7 — Sustain momentum post-approval. After the green light, I convert the plan into execution cadences: weekly demos, transparent dashboards, and QBRs vs OKRs check-ins to reinforce outcomes. We celebrate learning milestones, not just launches, and keep stakeholders informed with concise updates that tie progress to the original outcomes and value proposition. Momentum is the best antidote to second-guessing.
Clear communication and a repeatable process turn buy-in from a hurdle into a habit. When stakeholders see a compelling narrative, credible evidence, and a path to value, they don’t just approve—they advocate. Follow these seven steps and you’ll build alignment faster, ship smarter, and strengthen trust across the organization.
Your team probably doesn’t lack discovery techniques. It loses discovery when delivery becomes urgent. Customer contact clusters around planning, the team commits to a solution, the calendar fills, and assumptions quietly harden into backlog items. Everyone stays busy, but no one can point to the customer evidence behind the next decision.
Durable continuous discovery is an operating rhythm, not a research phase. The goal isn’t to conduct more interviews. It is to shorten the distance between customer reality and the decisions shaping your product. A weekly rhythm owned by a product trio can reduce rework, sharpen strategy, and keep discovery alive while delivery continues.
See your real discovery system before changing it
Adding a recurring customer interview to the calendar won’t fix a decision process built around handoffs. If ideas arrive from executives, become requirements in product, move to design, and reach engineering as implementation work, the interview is an extra activity attached to the side of the system. It isn’t part of how the team decides.
Start by making the existing system visible. Map what actually happened, including the awkward shortcuts and informal approvals. Do not draw the process described in a playbook.
Spend 60 minutes drawing how your team decides what to build. Show where ideas enter, who shapes them, who approves them, where customers appear, and how the team decides whether the result worked.
Compare your drawing with the drawings made by product, design, and engineering. Differences are evidence that the team does not share the same decision model.
Audit every product decision from last week in a 30-minute session. Include small decisions, not just roadmap commitments.
For each decision, record who made it, what information informed it, and whether the team had direct customer input or received a secondhand interpretation.
Mark the places where discovery and delivery reconnect. A production problem, adoption signal, support request, or implementation constraint can create a new discovery question; it should not disappear into a separate queue.
This process map and decision audit gives you a baseline without turning discovery into a maturity score. Look for the mechanism behind the misses. Perhaps customer input arrives after commitment. Perhaps the product manager is the only person who interprets it. Perhaps the team can describe the solution but not the opportunity it addresses.
Track a compact baseline: how recently the team had direct customer contact, which current decisions include direct input, where cross-functional decisions become handoffs, and which active solutions lack a named customer opportunity. Do not set targets yet. First identify where evidence stops influencing action.
If the process looks reasonable but the habit still collapses, inspect the six prerequisite mindsets: outcome-oriented, customer-centric, collaborative, visual, experimental, and continuous. Turn them into diagnostic questions:
Outcome-oriented: Can the team name the customer or business change it is trying to create, or only the feature it plans to ship?
Customer-centric: Does the team hear directly from customers, or mainly through sales, support, analytics, and stakeholder summaries?
Collaborative: Do product, design, and engineering make decisions together, or meet mainly to exchange work?
Visual: Is there one shared representation of the outcome, opportunities, solutions, and assumptions?
Experimental: Can the team name what could make the current idea fail?
Continuous: Does each learning activity lead to the next question, or does discovery end with a presentation?
Choose the weakest link as your first intervention. A team with output-based goals does not need a better interview script first; it needs an outcome that gives the interview a purpose. A team dominated by handoffs needs shared sensemaking, not another repository.
Install a weekly loop small enough to protect
A habit survives because its trigger, action, and output are clear. Put a recurring discovery block at a stable point in the team’s operating rhythm. Tie it to a current outcome and a live decision, not to a general ambition to understand users better.
Trigger: A protected calendar block recurs every week, including during active delivery.
Focus: The trio brings one current outcome, the decision in front of it, and the uncertainty preventing a confident choice.
Customer contact: The team has a direct customer touchpoint every week. That might be a customer interview, observation of a workflow, or a usability session connected to the current question.
Sensemaking: The trio separates what it observed from what it inferred.
Update: New evidence changes the opportunity solution tree or confirms why no change is warranted.
Commitment: The team names the next uncertainty and starts arranging the next customer contact.
A customer touchpoint is not any meeting attended by a customer. A sales demo, account review, or advisory session dominated by presentation may be valuable, but it does not automatically answer a discovery question. The useful test is whether the customer can reveal a real behavior, need, constraint, or reaction and whether the team can ask follow-up questions.
Prepare each touchpoint by completing this sentence: After this contact, the trio might decide whether… If you cannot finish it, the question is probably too broad. Starting with a decision also reduces the temptation to collect interesting comments that never affect the product.
During the interaction, capture concrete observations before interpretations. Afterward, answer five questions while the context is fresh:
What did the customer do, describe, or struggle to explain?
What interpretation is the team placing on that observation?
Which opportunity or assumption does it affect?
What decision changes, if any?
What remains uncertain enough to examine next?
The distinction between observation and interpretation matters. A customer abandoning a task is an observation. Assuming that price caused the abandonment is an interpretation. If the team records only the interpretation, an early guess can become institutional memory.
Recruiting is part of the habit, not administrative work that begins after an interview is requested. Give coordination to a named owner, maintain a rolling pool of relevant customers, and create simple paths for customer success and support to nominate people who recently experienced the problem. Start the next invitation before the current discovery cycle feels complete. Otherwise, every customer cancellation becomes a reason to skip the week.
When delivery pressure rises, protect the trigger and narrow the activity. Ask a smaller question, review a focused prototype, or examine one step in a workflow. Do not silently replace direct contact with an internal meeting and call the habit complete. If a customer cancels, use the protected time to recruit, refine the decision question, and reschedule. Preserve the rhythm without pretending the missing evidence exists.
Give the product trio ownership of decisions, not ceremonies
A product trio is not three people attending the same interview. It is product, design, and engineering sharing responsibility for understanding the opportunity and choosing how to address it. Attendance can rotate. Interpretation and decision-making cannot be delegated to one function and handed back as a deck.
Make the trio’s decision rights explicit at the start of an outcome. Record the outcome it owns, the decisions it can make autonomously, the constraints it must respect, what requires escalation, and where its evidence will remain visible. Without that contract, discovery may reveal a better direction while the roadmap continues unchanged because nobody knows who can act.
The responsibilities below are a practical starting point, not rigid job boundaries:
Product keeps the outcome, strategic context, customer segment, and pending decision visible.
Design helps the trio expose customer behavior, frame opportunities, and choose an appropriate way to learn.
Engineering surfaces feasibility, system behavior, data, and implementation assumptions before the solution becomes expensive to change.
The trio decides what the evidence means, which option remains viable, and what uncertainty deserves attention next.
Use a short shared debrief after customer contact. The format can remain simple:
Observation: What happened without interpretation?
Meaning: What plausible explanations fit the observation?
Decision: What will the trio change or preserve?
Unknown: What still blocks commitment?
This prevents the loudest interpretation from becoming the team’s conclusion. It also gives engineering a role before implementation and gives design a role beyond producing artifacts.
Leadership should ask for evidence of changed decisions, not proof that ceremonies occurred. Instead of asking how many interviews the team completed, ask which opportunity became clearer, which assumption weakened, what decision changed, and how the change connects to the outcome. Interview volume is easy to report and easy to game. Decision quality is harder to display, but it is the reason the habit exists.
Connect discovery evidence to strategy and delivery
A weekly customer conversation can still become theater if its evidence floats separately from strategy, roadmaps, and sprint planning. The opportunity solution tree provides a shared spine: the desired outcome sits at the top, customer opportunities sit beneath it, and candidate solutions connect to the opportunities they could address. That outcome-opportunity-solution structure keeps the team connected to why it is considering a particular feature.
Use the tree as a decision interface, not a workshop artifact:
Product strategy: Put the intended outcome at the top so the team can test whether its discovery work supports the strategic direction.
Roadmapping: Attach candidate solutions to named opportunities. Keep alternatives visible until evidence or a real constraint justifies commitment.
Sprint planning: Require each significant item to trace back to an opportunity and outcome. If it cannot, surface the mismatch before implementation.
Customer contact: Update the affected opportunity, solution, or assumption during the debrief. Do not wait for a separate documentation session.
Stakeholder communication: Show what changed in the tree, why it changed, and which decision follows. This is more useful than presenting a collection of customer quotations.
Keep a record of rejected options and the evidence or constraint behind each rejection. Otherwise, an old idea can return with a new label and consume another round of debate. The record should remain revisable: new customer behavior, technical capability, or strategic constraints can justify reopening a branch.
Measure whether evidence enters decisions
The safest discovery metric is not an isolated activity count. Measure the health of the loop:
Cadence: Did direct customer contact happen during the weekly rhythm?
Decision integration: Which current decision did that contact inform?
Shared ownership: Did the trio participate in sensemaking, even if every member did not attend the session?
Strategic traceability: Can a delivery item be traced to an opportunity and outcome?
Learning movement: Which belief, option, or assumption changed?
A team can conduct many interviews and learn very little if every conversation validates a solution already selected. Conversely, one focused interaction can be valuable when it exposes a faulty workflow assumption and changes a pending decision. Track cadence to protect the habit, but judge value by movement in the decision model.
Separate customer, model, and operational uncertainty in AI products
AI product teams face a specific discovery trap: an impressive model demonstration can make technical possibility look like customer demand. Keep different uncertainties separate so one kind of evidence does not answer a different question.
Customer uncertainty: What job is the person trying to complete? Where does the current workflow break? Under what conditions will the person trust, verify, correct, or reject an AI-assisted result?
Model uncertainty: Does the system produce acceptable behavior for the intended context? Which failures matter to the user, and how will the team evaluate them?
Operational uncertainty: Can the product obtain the required data and permissions? Where is human review needed? How will failures be detected, explained, and supported?
Customer contact can reveal workflow, language, trust conditions, and failure consequences. It cannot prove that the model behaves reliably. Model evaluations can reveal performance and failure patterns. They cannot prove that the workflow is valuable. Operational checks can establish feasibility and controls. They cannot prove adoption. Keep all of these linked to the same outcome while using the right evidence for each uncertainty.
On the opportunity solution tree, write opportunities in customer terms. “Use generative AI” is a solution direction, not an opportunity. “Reduce the effort required to turn a customer conversation into an accurate follow-up” describes a customer problem that could have AI and non-AI solutions. That distinction helps the trio discover value without becoming attached to a technology.
Fix the mechanism when the habit breaks
What you notice
Likely mechanism
What to change
The team talks to customers, but the roadmap never changes.
Sessions are disconnected from a live decision.
Write the decision before recruiting and record what changed immediately after the interaction.
Engineering joins only after discovery is complete.
The trio label is masking a handoff.
Include engineering in opportunity framing, assumption identification, and shared sensemaking. Session attendance can rotate.
Customer sessions repeatedly fall through.
Recruitment starts only after a question becomes urgent.
Maintain a rolling pool of relevant customers and assign coordination to a named owner.
The opportunity solution tree is stale.
The tree is treated as presentation material.
Update it during the debrief and remove or annotate branches that no longer have support.
Discovery pauses whenever delivery accelerates.
Discovery is scoped as a project rather than a continuous rhythm.
Protect the weekly trigger and narrow the question or method when capacity is tight.
Leadership keeps asking the team for certainty.
The team reports activities without showing their decision impact.
Show the outcome, changed opportunity or assumption, resulting decision, and remaining uncertainty.
Do not respond to a broken habit by adding more process everywhere. Match the intervention to the failure. A recruiting problem needs a pipeline. A decision-rights problem needs leadership alignment. A stale artifact needs an update trigger. A handoff problem needs shared sensemaking.
Key takeaways
Map the current decision system and audit last week’s decisions before adding a new discovery ceremony.
Anchor a direct customer touchpoint every week to a current outcome, decision, and uncertainty.
Let attendance vary when necessary, but keep interpretation and decisions jointly owned by the product trio.
Use the opportunity solution tree as the live connection between strategy, customer evidence, roadmap choices, and sprint work.
When delivery pressure rises, protect the trigger and shrink the activity instead of suspending the cadence.
For AI products, do not use customer enthusiasm as proof of model reliability or an evaluation result as proof of customer value.
Put the recurring customer touchpoint on the calendar, choose the outcome and decision it must inform, and name the product trio responsible for acting on what it learns. At the end of the next weekly cycle, do not ask whether the team “did discovery.” Ask what changed in the decision and what the team needs to learn next.
I’ve been systematically exploring how the product model shows up inside iconic companies. After studying “The Product Model at Spotify” and “The Product Model at Amazon,” I’m turning my lens to Google—specifically, how the product operating model, product culture, and product strategy manifest in practice and what we can pragmatically take back to our own organizations.
When I talk about the product model, I’m looking at the machinery that connects strategy to outcomes: empowered product teams, clear decision rights, tight product trios, continuous discovery, data-informed bets, and an operating cadence that enables learning at speed. My goal here is to unpack how those elements come together at Google and translate them into repeatable patterns you can adopt.
At a high level, I focus on how teams are empowered to solve problems rather than ship outputs, how outcomes vs output OKRs clarify what matters, and how experimentation (from rapid prototyping to A/B testing) de-risks decisions before they scale. I also examine how engineering and product partner to balance platform scalability with customer value, and how stakeholder management reinforces alignment without slowing teams down.
Why does this matter? Because the product model is a lever for resilience and speed. When product strategy is explicit and the operating model is built for learning, organizations multiply the impact of talented people. That’s how small, focused teams repeatedly deliver outsized results—even in complex, regulated, or high-scale environments like Google.
In the sections that follow, I’ll synthesize what I see as the core patterns behind Google’s approach and distill them into actionable guidance: how to structure product trios, how to run continuous discovery alongside delivery, how to set and calibrate OKRs for outcomes, and how to evolve your product culture so empowered product teams can do their best work. My aim is not to idolize a model, but to extract what’s portable and help you adapt it to your context.
Your launch is on schedule. Product is shipping, marketing has a campaign, sales has enablement, and customer success has an adoption plan. Yet the leadership review still gets stuck on a basic question: what customer outcome should all this activity produce?
If you cannot answer that question with observable evidence, you do not have a go-to-market system yet. You have coordinated output. Outcome-driven go-to-market execution connects the product promise to a change in customer behavior, then connects that behavior to a commercial result. It gives every function the same causal chain and enough evidence to decide what to change when the chain breaks.
Write the outcome contract before the launch plan
The usual go-to-market plan starts with deliverables: finish the landing page, train the sales team, publish the campaign, launch the product tour, and brief customer success. Those tasks matter, but completing them does not demonstrate that the market understood the value or that customers received it.
An outcome contract establishes what the cross-functional team is trying to make true. Start with a specific segment and ideal customer profile, because a result stated for everyone will be too vague to guide positioning, product decisions, or sales execution. The contract should also identify the customer situation that makes the offer relevant. Industry and company size alone rarely explain why a buyer needs to act.
Write the contract before functions turn the strategy into separate workstreams. It needs these elements:
Segment and situation: Identify who has the problem, what has changed in their environment, and who is explicitly outside the initial motion.
Customer outcome: State what becomes easier, faster, safer, or more valuable for that segment. Describe the change in the customer’s world, not the feature being delivered.
Value behavior: Name the observable action that indicates a user has begun receiving the promised value. This becomes the activation hypothesis, not merely another engagement event.
Commercial result: Choose the business result the motion is expected to influence, such as qualified progression, paid conversion, retention, or expansion. Add guardrails so that improving an early metric cannot conceal damage later in the journey.
Evidence window: Agree when the team expects each leading signal to become visible. Do not wait for a lagging revenue result to discover that the message or onboarding failed much earlier.
Decision owner: Identify who convenes the functions, resolves conflicting interpretations, and records the decision when the evidence is weak.
Failure condition: State what would cause the team to change the segment, promise, proof, onboarding, offer, or product instead of adding more activity.
A usable contract can fit into a single sentence: For [segment] facing [situation], this motion should produce [customer outcome]. We will see early evidence in [value behavior] and commercial evidence in [business result], without harming [guardrail]. If [required evidence] is absent by [decision point], [owner] will reopen [assumption or lever].
This is the practical difference between outcome and output OKRs. A completed product tour is an output. More target users reaching the value behavior with stronger downstream retention is an outcome. The tour earns continued investment only if it contributes to that outcome.
The contract also prevents each function from quietly optimizing for a different definition of success. Marketing can still manage audience and response metrics. Sales can still manage opportunity progression. Product can still manage activation. Customer success can still manage adoption and retention. The difference is that those measures now describe connected parts of the same customer journey.
Carry the buyer from a credible promise to acceptable proof
Positioning is not a launch slogan. It is the logic that helps a buyer recognize the problem, understand why the product is relevant, distinguish it from alternatives, and believe that choosing it is safe enough.
Build that logic before producing channel assets. A useful message architecture contains:
Situation: The trigger, constraint, or unmet job that makes action relevant now.
Promise: The customer outcome the product can credibly help create.
Points of parity: The capabilities buyers expect before they will consider the product a legitimate option.
Differentiation: The meaningful reason this approach is better suited to the target situation than the available alternatives.
Mechanism: How the product creates the promised outcome. This keeps the claim connected to product truth.
Proof: The evidence a buyer should accept at the current decision stage.
Risk response: How the motion addresses implementation, security, procurement, switching, and organizational concerns.
Next decision: The smallest credible commitment that advances the buyer without pretending the entire decision has already been made.
The core promise should remain stable, but its expression should change with context. Different segments, buying stages, and channels need different versions of the message. An advertisement may help a buyer recognize a problem. A landing page must establish relevance and differentiation. A sales conversation must diagnose the use case. An in-product guide must help the user experience value. Repeating identical copy in every context produces consistency of wording, not consistency of meaning.
Do not solve this by inventing a different promise for every role. Preserve the outcome and mechanism, then change the evidence. The user may need to see a workflow completed. The economic buyer may need quantified value. Security may need an approved control narrative. Procurement may need a clear scope, packaging model, and path to renewal. If those artifacts imply different product truths, the motion will lose credibility as stakeholders compare notes.
Use an asset test before anything enters the launch plan: This asset should move [audience] from [current belief] to [next belief or action]. I will observe that change through [leading signal], and I will validate it against [downstream outcome]. If the team cannot complete that sentence, the asset is a calendar commitment without a strategic job.
For complex accounts, design the proof of value as part of the offer rather than improvising it after a promising sales call. A proof of value should specify:
the business outcome and the baseline against which change will be judged;
the scoped use case, users, and workflow included in the evaluation;
the product behavior expected to indicate initial value;
the data, access, privacy, security, and governance constraints;
the stakeholders who must accept the evidence;
the instrumentation required to collect that evidence;
the criteria for expansion, redesign, or stopping; and
the commercial decision that follows a successful evaluation.
A proof of value is not a longer demo. It is a controlled way to test whether the promised outcome can survive contact with the customer’s environment. If the customer and seller cannot agree in advance on what counts as sufficient evidence, a successful pilot can still end in indecision.
Measure the causal chain, not a pile of channel metrics
A dashboard can contain accurate numbers and still be useless for go-to-market decisions. The test is whether the measures reveal where the customer journey is breaking and which lever the team should change.
Map the journey from targeted attention through paid expansion. For every stage, name the question, the evidence, and the likely response to a weak signal.
Journey stage
Decision question
Useful evidence
Response when weak
Targeted attention
Are relevant customers recognizing the problem?
Qualified response by segment and situation
Revisit targeting, problem framing, or channel context
Evaluation
Do buyers understand the promise and difference?
Use-case engagement, progression, and objection patterns
Clarify positioning, mechanism, or supporting proof
Commitment
Has enough buyer risk been removed?
Proof-of-value acceptance and security, procurement, or approval progress
Resolve the specific risk or make decision criteria explicit
Activation
Are users reaching initial value?
Activation behavior, time-to-value, and abandonment points
Fix access, onboarding, product guidance, or product friction
Durable use
Does the value behavior repeat?
Core behavior frequency and retention by relevant cohort
Test whether the activation event predicts lasting value
Expansion
Is value spreading or deepening?
Adoption breadth, additional use cases, and paid expansion
Revisit packaging, enablement, customer success, or the next use case
This chain makes leading and lagging measures work together. Revenue is essential, but it arrives too late and aggregates too many causes to diagnose execution by itself. Click-through rate arrives early, but it says little about whether customers receive value. Activation and retention connect the two, provided the chosen activation event represents a meaningful step toward the promised outcome.
That proviso matters. Teams often label a convenient event as activation because it is easy to instrument. Account creation, a login, or a page view may only show access. The stronger question is: what behavior would be unlikely unless the user had begun to receive the value described in the positioning?
Instrument identity and events across the relevant systems so that exposure can be followed through the funnel. A unified analytics journey from first touch to paid expansion needs product behavior, campaign exposure, CRM stage, account context, and commercial status to be reconcilable. Perfect attribution is not required to improve decisions, but incompatible definitions will create debates that no amount of dashboarding can settle.
Create a shared measurement dictionary for every outcome-critical event. Record what triggers the event, what does not, which user or account entity it belongs to, when it became reliable, and which decision it supports. If marketing, product, and sales use the word qualified or activated differently, fix the definition before interpreting the trend.
Experiments should test a link in the causal chain, not simply generate a winner. Before running an A/B test, write down:
the segment and journey stage being tested;
the customer belief or behavior expected to change;
the intervention, such as a message, product tour, in-app guide, onboarding flow, or offer;
the primary outcome metric and downstream guardrails;
the minimum detectable effect that would matter to the business;
the stopping and decision rules; and
the action the team will take for a positive, negative, or inconclusive result.
Setting the minimum detectable effect before reading the result protects the team from declaring a noisy change meaningful because the preferred variant appears slightly ahead. Guardrails protect against local optimization. If creative improves click-through but reduces downstream activation, it has made the funnel busier rather than better.
The pattern of movement often tells you where to look. Strong attention with weak qualified progression points toward targeting or positioning. Strong conversion with weak activation suggests an expectation, handoff, or onboarding problem. Strong activation with weak retention means the supposed aha moment may not represent durable value. Strong retention with weak expansion can indicate packaging, permissions, enablement, or use-case discovery friction. These are diagnostic hypotheses, not automatic verdicts; use qualitative evidence to identify the mechanism before changing the system.
Turn the launch into a decision loop that can scale
Outcome-driven execution needs a cadence that converts evidence into decisions. A status meeting asks whether the planned work shipped. A decision meeting asks what changed in the customer journey, what explains the change, and what the team will do next.
Use a weekly cross-functional review for the active motion. Keep the agenda anchored to the outcome contract:
Outcome and guardrail movement: Review the agreed measures, not a rotating collection of favorable metrics.
Segment and cohort variance: Check whether the aggregate hides a strong or weak response in the target group.
Current bottleneck: Identify the earliest important break in the causal chain. Later weaknesses may be consequences of that break.
Diagnosis: Decide whether the barrier is primarily belief, access, capability, risk, or commercial fit.
Next intervention: Choose the smallest change capable of testing the diagnosis.
Decision record: Capture the owner, expected signal, review point, and the assumption being tested.
Different evidence answers different questions. Analytics shows where behavior changes and how broadly. Customer conversations help explain motives and language. Field feedback reveals objections and decision friction. Controlled experiments provide stronger evidence that an intervention caused a change. None is sufficient alone, and a forceful anecdote should not automatically overrule a stable segment pattern.
Give each function responsibility for maintaining its link in the chain. Marketing maintains evidence about audience, problem recognition, and message response. Sales maintains evidence about diagnosis, objections, stakeholders, and commitment. Product maintains evidence about access, activation, and the ability to realize value. Customer success maintains evidence about adoption, durable outcomes, and expansion readiness. No function owns the entire customer outcome alone, but each must be able to explain its part without retreating into output metrics.
When the evidence points to a product constraint, the issue belongs in product prioritization and sprint planning. When it points to a credibility gap, another feature may be less valuable than better proof. Empowered product teams, product trios, and field insights from enterprise pilots keep those choices connected to the market without turning every objection into an unexamined roadmap request.
Use QBRs for the larger strategic questions: Is the segment still attractive? Does the product create a repeatable advantage? Are pricing and packaging aligned with received value? Should resources move between acquisition, activation, retention, and expansion? A quarterly review cannot replace the weekly learning loop, and the weekly loop should not repeatedly reopen strategy without material evidence.
Scale the motion only when its success is becoming repeatable rather than heroic. Look for:
a target segment that responds for a consistent reason;
a value proposition that survives across channels and buyer roles;
an activation behavior that has a credible relationship with retention;
a proof process with explicit evidence and decision criteria;
objections that are predictable enough to address through enablement or product changes;
instrumentation reliable enough to locate funnel breakdowns;
pricing and packaging that support the value customers are willing to buy; and
a playbook that another team can execute without recreating the strategy from memory.
A bespoke enterprise win can be valuable evidence, but it is not yet a repeatable motion. Before treating it as the model, separate what was essential from what depended on exceptional access, custom work, executive attention, or a uniquely motivated customer. Scale the elements that explain the outcome. Preserve the rest as a conscious exception or remove it from the standard motion.
If the bottleneck survives repeated tactical changes, stop expanding the activity around it. Reopen the underlying assumption. The segment may not feel the problem strongly enough, the promise may not be differentiated, the proof may not reduce the relevant risk, or the product may not deliver the claimed value. An outcome-driven system makes that uncomfortable conclusion visible early enough to act on it.
Key takeaways
Start with an outcome contract that links a target customer’s result to an observable value behavior and a commercial result.
Use a stable value proposition across the motion, but adapt the evidence and next decision to the segment, channel, stage, and buyer role.
Measure the full causal chain from targeted attention through activation, retention, and expansion; no single channel metric can represent go-to-market success.
Design experiments with a declared hypothesis, meaningful effect threshold, downstream guardrails, and decision rule before results arrive.
Run a weekly decision loop, reserve QBRs for strategic changes, and scale only after the motion is measurable, teachable, and repeatable.
At your next go-to-market review, put the causal chain on the first slide instead of the workstream tracker. Ask where the earliest important evidence breaks, name the assumption behind that break, and fund the smallest intervention that can test it. That is how a launch plan becomes a growth loop.
If product managers still open analyst tickets for routine funnel, activation, and retention questions, your analytics transformation has not reached self-service. Buying licenses and publishing dashboards may increase access, but access is not the same as decision autonomy.
You are not trying to turn every product manager into an analyst. You are creating a governed path from question to evidence to decision, while preserving analyst time for problems that require deeper investigation. That takes a shared measurement layer, curated entry points, clear ownership, and operating rituals that make data part of product work.
Start with the bottleneck, not the analytics platform
A self-service analytics transformation should begin with the service your teams experience today. Pick a common product question, such as which users complete activation, where a critical journey loses customers, or which cohorts retain. Ask a product manager to answer it from a standing start, then observe every dependency between the question and a decision.
Look for five distinct sources of friction:
Discovery friction: the product manager cannot find the relevant event, metric, or approved dashboard.
Definition friction: two reports use the same metric name but calculate it differently.
Construction friction: the data exists, but answering the question requires an analyst to build or join the view.
Trust friction: the product manager can create a chart but still needs someone to confirm that it is correct.
Decision friction: the chart answers what happened but does not connect the behavior to a product choice.
This diagnostic separates a tooling problem from a measurement or operating-model problem. Consolidating scattered tools into a unified analytics platform can reduce search and construction friction. It will not resolve inconsistent definitions, unclear ownership, or a culture in which every decision still needs analyst approval.
Establish a baseline before changing the stack. Track the elapsed time from a clearly stated question to decision-ready evidence, the mix of routine and investigative analyst requests, the frequency of conflicting metric definitions, and the product decisions that cite behavioral evidence. Avoid choosing a universal benchmark that your context cannot support. Measure your current state, separate question types, and set improvement targets from that baseline.
The intended end state is narrow enough to test. A product manager should be able to examine activation, funnel drop-off, and cohort retention without joining a reporting queue. An engineer should be able to see the behavioral signal after a release. An analyst should spend less time reproducing standard views and more time on questions whose ambiguity or complexity merits specialist work. When evidence is visible to the people making the decision, discovery and delivery can share the same facts.
Build a governed measurement layer before expanding access
Giving more people permission to query inconsistent data produces faster inconsistency. Self-service becomes trustworthy only when teams share a stable vocabulary for customer behavior and business outcomes.
Treat that vocabulary as a product. Events describe observable behavior; metrics encode an interpretation of that behavior. The distinction matters. A signup event may have a precise trigger, but an activation metric still needs a qualifying action, an eligible population, a time window, and explicit exclusions. If those choices live only inside one dashboard, the dashboard is carrying business logic that other teams cannot reliably reuse.
Use a standard instrumentation workflow for every new event or property:
Start with the decision. Record the question the team needs to answer and the action that could change because of the result.
Define the behavior. Specify the event trigger, required properties, allowed values, exclusions, and the naming convention it follows.
Assign accountability. Name the owner, identify the affected product flow, and record privacy and access requirements.
Implement consistently. Use the same instrumentation pattern and carry the change through the normal CI/CD path instead of relying on an undocumented one-off.
Validate before release. Compare the emitted payload with the tracking contract and check that required properties arrive with expected values.
Publish for reuse. Add the definition to the catalog and expose it through the appropriate curated report, rather than leaving users to discover raw events by trial and error.
This is the practical value of treating data requests like product requests: a team can ask for an event or property with a defined purpose, owner, and privacy classification, while a repeatable path takes it from instrumentation through CI/CD, documentation, and curated analytics.
Your catalog entry should answer the questions a future user will otherwise send to an analyst:
What behavior does this event represent, and what does it not represent?
Exactly when does it fire?
Which properties are required, and what do their values mean?
Which users, accounts, environments, or internal activities are excluded?
Who owns the definition and approves a semantic change?
What privacy classification and role-based access rules apply?
Which approved metrics and dashboards depend on it?
Is it active, deprecated, or scheduled for replacement?
Choose a naming convention that reveals intent, such as an object plus a past-tense action, and apply it consistently. The exact grammar matters less than eliminating synonymous events and ambiguous labels. Do not silently rename or repurpose an event after teams have built reports on it. Deprecate it explicitly, identify the replacement, and update dependent views so a semantic change does not masquerade as a change in customer behavior.
Governance should make the safe path easier, not turn every question into an approval request. Standard definitions, privacy-by-design, role-based access, named owners, and clearly labeled dashboards are the guardrails. Product teams should remain free to explore within them. That balance preserves both speed and trust.
Give non-technical teams a curated front door
A blank analytics canvas is not a self-service experience. It transfers the construction work to users without giving them the context needed to interpret the result. Start with a small set of approved views that answer recurring product questions, then let experienced users branch into deeper exploration.
For one critical product flow, publish three discoverable dashboards:
An activation dashboard that shows the eligible population, qualifying behavior, and relevant segments.
A journey dashboard that exposes conversion between meaningful steps and makes drop-off visible.
A retention dashboard that uses a documented cohort definition and return behavior.
Three well-governed dashboards are more useful than a large library nobody can navigate. Each one should state the question it answers, intended audience, metric definitions, default filters, exclusions, owner, and review status. If a chart is exploratory rather than authoritative, label it accordingly. Users should not have to infer whether they are looking at a decision-grade view or a working draft.
Build enablement around real decisions. Generic feature training teaches people where buttons live; it does not teach them which metric to trust. Use a current product question to show how to select a cohort, inspect a funnel, compare segments, and move from an observed pattern to the next investigation. Targeted onboarding, in-app guidance, and product tours can reinforce that path when users return to the platform.
Then hold a weekly readout for the teams using the flow. Ask what they learned, which decision changed, where a definition was unclear, and which missing property blocked the analysis. Starting with one end-to-end flow, three core dashboards, and weekly decision readouts gives you a controlled environment in which to repair the system before scaling it.
Watch the first few self-service attempts closely. If users repeatedly choose the wrong event, improve the label and catalog entry. If they can build a chart but cannot explain the denominator, curate the metric rather than adding more training. If sensitive properties are broadly visible, fix access design before inviting more users. Friction observed during onboarding is product feedback about the analytics experience.
Change ownership, decision rituals, and success measures
Self-service changes the division of work; it does not eliminate analysts or central governance. Product trios should define measurement needs while they shape a solution, not after engineering has finished it. The data function should own reusable semantics and quality mechanisms. Leaders should make evidence part of routine decisions instead of treating analytics as a separate reporting activity.
A workable ownership split looks like this:
Role
Primary ownership
Boundary
Product trio
Decision question, hypothesis, measurement plan, interpretation, and product action
Does not redefine shared metrics inside a local dashboard
Data and analytics
Event taxonomy, reusable metric definitions, validation patterns, and deeper investigation
Does not become the required builder for every routine chart
Engineering
Accurate instrumentation, implementation consistency, and release validation
Does not decide business meaning without product and data input
Platform and governance owners
Access, privacy controls, catalog standards, dashboard hygiene, and lifecycle management
Does not approve every permitted exploration
Product leaders
Decision rituals, outcome accountability, and protection of specialist capacity
Does not reward unsupported numbers simply because they arrive quickly
Carry measurement through the entire product lifecycle. During discovery, write the expected behavior and the evidence that would change the team’s view. During delivery, make instrumentation part of acceptance criteria. After release, inspect the same agreed signals instead of inventing success measures retrospectively. Before an A/B test, state the hypothesis and justify the minimum detectable effect so the team understands what result the experiment is designed to detect.
The weekly decision ritual can remain simple:
What product question did you answer?
Which governed event, metric, cohort, or dashboard supported the answer?
What decision changed, or what new uncertainty must be resolved?
What defect in instrumentation, definition, access, or documentation slowed you down?
This keeps dashboards connected to action and creates a visible backlog for the analytics product itself. It also prevents login counts from becoming the transformation’s main success measure. A person can log in frequently without reaching a trustworthy conclusion.
Measure the operating change instead:
Time from question to decision-ready evidence, segmented by question type.
Routine questions resolved by the product team without an analyst handoff.
Analyst capacity spent on recurring report construction versus deeper investigation.
Critical events and metrics with complete definitions, owners, and privacy classifications.
Duplicate dashboards, conflicting definitions, validation failures, and data-quality incidents.
Discovery, experiment, and post-release decisions that reference governed behavioral evidence.
Read these signals together. If platform usage rises but routine tickets remain unchanged, access improved while autonomy did not. If self-service rises while definition disputes and quality incidents increase, governance is lagging adoption. If tickets fall but teams cannot name decisions informed by data, people may have stopped asking rather than become self-sufficient.
Do not remove analyst support merely to make the ticket count look better. The intended shift is from repetitive construction to higher-leverage work: investigating ambiguous patterns, improving measurement quality, supporting sound experiment design, and helping teams interpret questions that exceed the safe limits of a standard dashboard.
Key takeaways
Define self-service as the ability to reach trustworthy, decision-ready evidence without a routine analyst handoff, not as access to an analytics tool.
Standardize event definitions, properties, ownership, privacy requirements, validation, and documentation before expanding access.
Begin with one critical flow and three curated views: activation, journey conversion, and retention.
Teach analytics through live product questions and reinforce it with weekly decision readouts.
Measure time-to-insight, ticket mix, governed coverage, quality failures, and decisions changed; logins alone cannot show autonomy.
Scale only after teams can move faster without creating conflicting metrics, unsafe access, or hidden analyst dependencies.
Choose one critical flow in your next planning cycle. Baseline its current question-to-decision path, define the tracking contract, publish the three governed views, and schedule the first weekly readout. Let that flow prove the operating model before you broaden the rollout. Self-service scales when each new team inherits a trusted path, not another blank workspace.
