Tag: empowered product teams

  • New Year, New Product Habits: AI Workflows, Coaching Culture, and Community in 2026

    New Year, New Product Habits: AI Workflows, Coaching Culture, and Community in 2026

    Happy New Year! I’m kicking off 2026 with a behind-the-scenes look at what’s changing in my product practice, the experiments I’m running with my teams at HighLevel, and the trends I’m most energized by—especially around continuous discovery, AI workflows, and building stronger coaching cultures.

    If you want to listen to the conversation that sparked many of these reflections, you can find it here: Spotify | Apple Podcasts.

    Why Teresa sunset the live deep-dive cohorts—and how on-demand and the new Discovery Habits Toolbox better support real behavior change. This pivot resonated with my own experience: some skills, especially discovery habits, only stick when they’re reinforced in the flow of real product work, not just in a time-boxed cohort. In my org, we’re leaning into on-demand learning paired with manager coaching to drive durable behavior change.

    What leaders actually need to coach interviewing, assumption testing, and core discovery habits inside their orgs. I’ve found that empowered product teams thrive when leaders have lightweight coaching tools, practical prompts, and clear expectations for product trios. This is less about one-off training and more about building communities of practice where deliberate practice and feedback loops become routine.

    Why training is shifting toward ongoing, leader-supported learning (and how AI will accelerate the shift). AI Strategy isn’t just about tools—it’s about learning systems. For LLMs for product managers to create leverage, we need eval-driven development, privacy-by-design, and clear guardrails. I’m building AI workflows that enable managers to review interviews, spot anti-patterns, and nudge teams toward better decisions—without replacing critical thinking.

    Teresa’s move into paid subscriptions and why AI content doesn’t fit the classic “design once, run for years” course model. I see the same reality in my content roadmap: the half-life of AI guidance is short. That pushes us toward subscription models, tighter feedback loops, and a more adaptive go-to-market strategy for education products.

    A sneak peek into the AI tools Teresa is building for discovery work—from interview coaching to near-ready interview snapshot generation. I’m particularly excited by tooling that scaffolds better interviews, sharpens assumption testing, and speeds up synthesis without skipping the human judgment step. These capabilities map directly to where I want my teams investing time: spending less energy on admin and more on learning from customers.

    Petra’s plans for the year: community building with Product at Heart, a new product leadership email course, her Product Leadership Wheel, and workshops launching in Cairo. As someone who believes in conferences as high-quality “energy wells,” I’m inspired by how these programs create momentum for leaders who are upgrading their coaching muscles.

    The role of conferences and retreats in staying grounded, inspired, and connected. I treat these gatherings as strategic resets—spaces to test ideas, confront blind spots, and deepen my network for future collaboration. The best outcomes often come from serendipitous hallway conversations and hands-on sessions where you can pressure test frameworks with peers.

    How Teresa is staying on top of academic research (and why “synthetic users” aren’t ready for prime time). I agree: while synthetic data can be useful for scaffolding, it’s not a substitute for direct customer contact. Combine academic rigor with real-world interviewing and strong data governance—especially when operating under General Data Protection Regulation (GDPR).

    The shared challenge of evaluating vendors and conference speakers making questionable AI claims. My heuristic: ask for clear problem statements, reproducible evaluations, grounded benchmarks, and a path to safe deployment. If a pitch can’t show measurable uplift or ignores compliance, it’s not ready for empowered product teams.

    Key takeaways I’m carrying into 2026: delivery models matter; leaders need coaching tools, not just training; AI is reshaping how we teach and learn; experimentation is the theme of 2026; and community still energizes. That’s the blueprint I’m using to strengthen continuous discovery, refine our AI workflows, and sustain high standards in product management leadership.

    What about you? How are you integrating AI workflows into your discovery practice, and what coaching tools are helping your managers reinforce the right habits? Share your approach—I’d love to learn what’s working in your context.

    Resources & Links:

    Follow Teresa Torres: https://ProductTalk.org

    Follow Petra Wille: https://Petra-Wille.com

    Teresa’s website: Product Talk

    General Data Protection Regulation (GDPR)

    Product Talk Academy

    Deliberate Practice – ATP episode where Teresa talked about the ending live cohorts for Deep Dive classes

    Teresa’s Discovery Habits Toolbox program

    Petra’s A 52-Week Transformation Journey

    Teresa’s Product Talk subscriptions (AI workflows + discovery content)

    Claude Code

    The Interview Coach by Teresa

    Product at Heart Conference (Hamburg)

    Petra’s Coaching Packages

    Petra’s Ways We Can Work Together

    Petra’s Product Leadership Wheel (PLwheel)

    Petra’s Product Manager (PMwheel)

    Prdkt+ MENA Product Summit 2026

    World Beautiful Business Forum by House of Beautiful Business

    Melissa Suzuno

    Vistaly (Teresa’s integration partner for some upcoming AI tools)

    Teresa’s Just Now Possible podcast

    Inspired by this post on Product Talk.

    Book a consult png image
  • 11 Product Management Shifts Redefining 2026: Actionable Signals from Top Leaders

    11 Product Management Shifts Redefining 2026: Actionable Signals from Top Leaders

    2026 is closer than it feels, and the signals are already clear. I’ve been synthesizing what I’m seeing across empowered product teams, boards, and cross-functional partners into a practical view of what matters next. A sharp look at product management trends for 2026. Not guesses, but signals from top product leaders shaping how PMs will actually work next.

    In this analysis, I distill eleven shifts that are changing the craft—from outcomes vs output OKRs and continuous discovery to stronger product strategy and tighter product roadmapping and sprint planning. The throughline is simple: prioritize customer value, ship with focus, and measure what moves the business. These aren’t headline trends; they’re working patterns I’m seeing across high-performing organizations.

    AI is no longer a side project—it’s part of the product manager’s core toolkit. Agentic AI, LLMs for product managers, and trustworthy AI workflows are accelerating discovery, sharpening problem framing, and enabling faster iteration. The best teams pair this with disciplined evaluation and experimentation, so insight compounds without sacrificing safety, privacy, or product quality.

    Execution is getting crisper through product trios and stronger stakeholder management. When design, product, and engineering co-own discovery and delivery, teams reduce handoffs and increase clarity. That alignment translates into better prioritization, fewer context-switches, and a roadmap that reflects real trade-offs—not wish lists.

    On growth, product-led growth remains a durable engine when it’s anchored in a compelling value proposition and instrumented end-to-end. Clear activation moments, in-app guides, and thoughtful product tours outperform brute-force acquisition. When we connect these motions back to product strategy and the roadmap, we create a repeatable loop that compounds adoption and retention.

    Governance and trust are now table stakes. Privacy-by-design, data governance, and a pragmatic approach to regulatory compliance protect both users and velocity. Teams that build these practices into their operating model move faster because they avoid late-stage rework and maintain stakeholder confidence.

    If you’re leading a product org—or aspiring to—this is your field guide to 2026. I’ll unpack where these shifts are strongest, how to apply them in your context, and the pitfalls to avoid. The aim is to give you clear language, concrete practices, and a sharper edge as you shape what your team builds next.

    Inspired by this post on Product School.

    Book a consult png image
  • 7 Proven Steps to Win Stakeholder Buy-In with Clarity, Data, and Lasting Trust

    7 Proven Steps to Win Stakeholder Buy-In with Clarity, Data, and Lasting Trust

    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.

    Inspired by this post on Product School.

    Book a consult png image
  • How to Build a Continuous Discovery Habit That Survives Delivery

    How to Build a Continuous Discovery Habit That Survives Delivery

    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.

    1. 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.
    2. 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.
    3. Audit every product decision from last week in a 30-minute session. Include small decisions, not just roadmap commitments.
    4. For each decision, record who made it, what information informed it, and whether the team had direct customer input or received a secondhand interpretation.
    5. 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:

    1. What did the customer do, describe, or struggle to explain?
    2. What interpretation is the team placing on that observation?
    3. Which opportunity or assumption does it affect?
    4. What decision changes, if any?
    5. 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 noticeLikely mechanismWhat 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.

    References

  • AI Transformation Is an Operating Model, Not a Feature Roadmap

    AI Transformation Is an Operating Model, Not a Feature Roadmap

    You probably do not have an AI ideas problem. You have a conversion problem. Promising prototypes appear across the company, but few survive the distance between a convincing demo and a dependable customer or business outcome.

    The way out is to stop treating AI transformation as a feature portfolio. Treat it as a redesign of how your organization senses problems, makes decisions, takes safe action, and learns from production. The practical unit of change is one closed loop with an accountable owner, trusted context, explicit guardrails, and measurable results.

    Key takeaways: the transformation system in brief

    • Start with a bounded customer or employee workflow, not a company-wide AI program or a preferred model.
    • Define the outcome, quality threshold, action boundary, and fallback before choosing the implementation.
    • Build capabilities in dependency order: governed data, grounded context, constrained workflows, task-specific evaluations, and production operations.
    • Measure customer outcomes, AI behavior, delivery reliability, and organizational learning separately. No single metric can represent all four.
    • Centralize reusable controls and infrastructure, but keep problem selection and outcome ownership inside the domain team.
    • Increase autonomy only after the system can detect failure, escalate uncertainty, limit permissions, and recover safely.

    Start with a transformation wedge, not a transformation program

    A broad mandate such as make every team AI-first sounds ambitious but gives teams no useful decision rule. It encourages tool adoption, disconnected pilots, and activity metrics. A narrower mandate forces the hard questions into the open.

    I call that narrower unit a transformation wedge: a bounded, repeatable moment where intelligence can remove meaningful friction, where the result can be observed, and where a safe fallback already exists. The wedge is small enough to govern but important enough to prove a new organizational capability.

    Use these gates when selecting it:

    1. Meaningful friction: A customer or employee is losing time, making avoidable errors, or failing to complete an important job.
    2. Observable outcome: You can instrument the desired behavior rather than relying on opinions about output quality.
    3. Available context: The system can reach sufficiently trusted information without placing sensitive data into an uncontrolled context.
    4. Repeatable demand: The workflow occurs often enough to produce learning that the team can use.
    5. Bounded consequence: The system can be constrained, reviewed, escalated, or reversed when confidence is inadequate.
    6. Reusable learning: At least one capability – such as retrieval, evaluation, telemetry, or an integration – can support the next workflow.

    This distinction changes the conversation. Add a support chatbot is an implementation idea. Reduce the time to an accurate support resolution while preserving policy adherence is a transformation wedge. The second framing leaves room to choose retrieval, workflow automation, agentic behavior, or a simpler interface based on evidence.

    Write the outcome contract before selecting a model

    For the selected wedge, create a short outcome contract. It should be understandable to product, engineering, design, operations, security, and the executive sponsor without translation.

    • User and moment: Who encounters the friction, and at what point in the workflow?
    • Current behavior: What happens without the AI intervention, and what baseline evidence is available?
    • Primary outcome: Which customer or business behavior should change?
    • Quality guardrails: Which failure measures must remain within an agreed boundary?
    • Trusted context: Which data may be used, who owns it, and which sensitive fields must be removed or protected?
    • Action boundary: May the system summarize, recommend, communicate, or execute? Name prohibited actions explicitly.
    • Fallback: What happens when evidence is missing, the model is uncertain, an integration fails, or a policy conflict appears?
    • Release evidence: Which offline evaluations, controlled experiments, and production signals will justify expansion?
    • Accountability: Who owns the outcome, the AI behavior, the data, and incident decisions?

    In a support workflow, for example, the contract might pair a resolution outcome with accuracy and policy-adherence guardrails. A retrieval-first path can ground the response in approved knowledge, while a defined escalation route gives the system somewhere safe to send ambiguity. That combination of grounding, constrained action, evaluation, and escalation is much more consequential than the choice of chat interface.

    Instrument the baseline and the intervention from the beginning. If telemetry arrives after launch, the team will be able to show that an AI feature shipped but not whether the targeted behavior improved.

    Build the capability stack and the product loop together

    Teams often start in the middle of the stack: they select a model, write prompts, and then discover that the data is unreliable, evaluation is subjective, or production failures have no owner. Model capability matters, but it cannot compensate for missing organizational capability.

    Build the stack in dependency order:

    1. Governed data: Identify approved data, access rules, sensitive fields, and accountable owners. Privacy-by-design belongs in the workflow definition, not in a review added before release.
    2. Trusted context: When the task depends on company or customer knowledge, retrieve the relevant context from approved systems and control what enters the model’s context window. Define what the system should do when evidence is incomplete or conflicting.
    3. Constrained workflow: Separate model judgment from deterministic operations. Give each integration an explicit purpose, permission boundary, failure path, and audit trail. Agentic AI should orchestrate only the actions the organization is prepared to observe and govern.
    4. Task-specific evaluation: Build scenarios from the real workflow. Include expected cases, ambiguous inputs, missing context, policy conflicts, and known high-consequence failures. Define acceptance criteria before comparing prompts, models, or vendors.
    5. Release and operations: Use feature flags, controlled rollout, production telemetry, threat detection, and incident management. Assign authority to pause or limit the system when behavior drifts.

    This order is not a waterfall. Retrieval quality may expose a data problem, while an evaluation failure may expose a poorly defined policy. The point is to preserve the dependencies: autonomous action cannot become dependable before context, evaluation, permissions, and operations exist.

    Use AI to expand options and evidence to make commitments

    The capability stack changes day-to-day product work only when it is connected to discovery, design, delivery, and adoption. The useful pattern is to let AI accelerate reversible exploration while keeping consequential decisions anchored in evidence.

    • Discovery: Use AI to cluster interview notes, support tickets, and session transcripts. Then inspect the underlying material and pressure-test important themes with live customer conversations. A fluent summary is a hypothesis generator, not customer validation.
    • Design: Generate several storyboards, interaction flows, or guidance variants early. Refine promising options through the design system, accessibility requirements, and human review rather than treating the first plausible generation as finished design.
    • Delivery: Use AI to prepare hypotheses, test cases, and experiment materials. Keep success metrics and the minimum detectable effect explicit, and release variants through feature flags so that speed does not erase experimental discipline.
    • Adoption: Generate targeted in-app guidance, release it to controlled segments, and measure activation and retention alongside the immediate interaction. Shipping the intelligent behavior and helping users adopt it are parts of the same product decision.

    This combination can create a tighter discovery, design, delivery, and learning loop without pretending that model output replaces research, statistical judgment, design standards, or customer evidence.

    Replace status review with a weekly learning review

    Whether the accountable unit is called a product trio or something else, give it a weekly operating rhythm focused on verified learning. A useful agenda is:

    1. Review the primary outcome and every guardrail, including meaningful segment differences.
    2. Inspect evaluation failures and trace them to context, model behavior, policy, workflow design, or integration behavior.
    3. Read the latest experiment evidence and distinguish a result from an interpretation.
    4. Review reliability changes, incidents, near misses, and unresolved escalation paths.
    5. Make an explicit decision to continue, change, limit, or stop the current approach, with an owner for the next piece of evidence.

    Do not let this become a prompt-tuning meeting. Prompt changes are only one possible response. A retrieval defect, unclear product policy, missing event, weak handoff, or badly chosen outcome may be the actual constraint.

    Use a metric chain instead of one AI success number

    AI pilots look healthy when they are measured by output: drafts generated, tasks attempted, people trained, or features shipped. Those numbers can describe activity, but they do not establish customer value, dependable behavior, or organizational readiness.

    A transformation scorecard needs separate layers because each answers a different management question:

    Measurement layerQuestion it answersUseful measures
    Customer and business outcomeDid the important behavior improve?User activation, time-to-first-value, support resolution rate or time, retention
    AI quality and safetyIs the intelligent behavior reliable enough for this workflow?Task accuracy, hallucination rate, policy adherence, correct escalation
    Delivery reliabilityCan the team improve the system quickly without destabilizing it?Deployment frequency, lead time, change failure rate, mean time to recovery
    Organizational learningIs the organization reaching better decisions faster?Cycle time, experiment throughput, decision quality against predefined evidence

    The metric names are not definitions. Make each operational for the selected workflow. Accuracy might mean correct support answers, successful tool completion, or correct classification; those are different tests. A hallucination rate needs a declared denominator and a rule for what counts as unsupported. Decision quality needs a rubric tied to the evidence available when the decision was made, not whether the result later happened to be favorable.

    Connect the layers as a metric chain. In grounded support, retrieval and response evaluations establish whether the system can produce an accurate answer. Product telemetry shows whether the customer receives a useful resolution or an appropriate escalation. Resolution and retention measures show whether that behavior matters to the business. Delivery and learning measures show whether the organization can improve the loop repeatedly.

    Interpret disagreement between the layers

    The disagreements are often more informative than the headline result:

    • If offline evaluations improve but customer behavior does not, inspect workflow placement, user trust, adoption, and whether the evaluated task matches the real job.
    • If customer outcomes improve while policy adherence deteriorates, do not expand the rollout. The apparent win is being financed by unmanaged risk.
    • If deployment frequency rises while change failure rate or recovery time worsens, the team has increased release activity rather than adaptive capacity.
    • If cycle time falls but decisions are repeatedly reversed for missing evidence, the system is producing faster motion, not better learning.
    • If averages look healthy but a target segment fails, keep the rollout segmented until the failure mechanism is understood.

    Use the right method for the question. Evaluations test whether AI behavior meets defined quality and safety criteria. A/B testing tests whether a product intervention changes user behavior; setting the hypothesis, success metric, and minimum detectable effect before reading results protects that inference. DORA metrics reveal the health of the delivery system. None is a substitute for the others. Connecting model, product, business, and delivery measures is what turns telemetry into an operating mechanism.

    Centralize guardrails and distribute outcome ownership

    Organizational design usually fails at one of two extremes. A central AI group becomes a queue that is distant from customer problems, or every team builds its own prompts, data paths, evaluations, and incident process. The useful split is to centralize scarce controls and reusable capabilities while distributing domain decisions.

    Centralize the capabilities that should not be reinvented

    • Approved data-access and privacy patterns
    • Retrieval, context-management, and model-routing components
    • Evaluation tooling, baseline scenarios, and reporting conventions
    • Observability, auditability, feature-flag, and incident-response patterns
    • Prompt and workflow libraries with named owners and change history
    • Security, regulatory, and procurement requirements

    Keep product judgment inside the domain

    • Choosing the customer or employee problem
    • Defining the outcome and acceptable trade-offs
    • Validating whether retrieved context represents the domain correctly
    • Designing the experience, fallback, and human handoff
    • Running controlled rollout and interpreting segment behavior
    • Deciding whether to continue, constrain, redesign, or stop the bet

    This division preserves empowered product teams without turning governance into optional advice. The central capability owner defines the safe road; the domain team remains accountable for choosing the destination and proving that it is worth reaching.

    Scale controls with the consequence of being wrong

    Do not use one approval process for every workflow. A drafting assistant and an agent that changes customer records do not create the same exposure. Classify a workflow by what it can do and what happens when it fails.

    • Advisory output: A person reviews the draft, summary, or analysis before it affects another party. Evaluate usefulness and factual reliability, and make the reviewer accountable for the final decision.
    • User-facing recommendation: The output reaches a customer or employee directly. Add grounding, policy tests, clear escalation, monitored rollout, and an accessible non-AI path.
    • Action-taking workflow: The system invokes tools or changes state. Limit permissions, constrain eligible actions, preserve an audit trail, test integration failures, and provide a reliable stop or recovery path.
    • Sensitive or regulated workflow: Add the relevant privacy, security, legal, and compliance owners before data or actions enter the system. If an approved path does not exist, keep the workflow out of production until it does.

    A human in the loop is not a complete control by itself. Name what the person must inspect, what evidence is visible, when escalation is mandatory, and whether the person has enough time and authority to intervene. Otherwise, the human becomes ceremonial approval around an automated decision.

    Redesign roles around judgment, not tool usage

    AI can accelerate exploration, synthesis, and test preparation. People still have to interpret customers, choose outcomes, set quality thresholds, resolve policy ambiguity, and accept accountability for consequences. Role design and hiring should reflect that boundary.

    • A product manager should be able to write the outcome contract, connect model behavior to user behavior, and make trade-offs visible.
    • A designer should be able to generate and interrogate alternatives, preserve accessibility, and design uncertainty and fallback states.
    • An engineer should be able to separate probabilistic behavior from deterministic operations and build evaluation, observability, permission, and recovery paths.
    • A leader should be able to fund reusable capability, challenge vanity metrics, and stop a persuasive demo that lacks production evidence.

    Use communities of practice to spread prompt patterns, evaluation baselines, reusable workflows, and failure lessons. They work best as distribution networks for repeatable product and evaluation practices, not as committees that absorb accountability from the teams shipping the work.

    At your next portfolio review, select one transformation wedge and require its outcome contract, metric chain, evaluation set, fallback, and named owners. Put it into the weekly learning rhythm before funding another disconnected pilot. Once the loop works in production, extract the reusable components and make the next team faster. That is the point at which AI stops being a collection of features and starts changing how the organization operates.

    References

  • Enterprise Go-To-Market That Wins: How Product Marketing Supercharges Analytics Adoption

    Enterprise Go-To-Market That Wins: How Product Marketing Supercharges Analytics Adoption

    In my role leading product management at HighLevel, I’ve learned that enterprise go-to-market lives or dies by the strength of the partnership between product and product marketing. When we operate as one team, we turn complex capabilities into clear outcomes that resonate with buyers and drive adoption at scale.

    I’m especially energized by the archetype of a product marketing manager at a leading analytics platform—someone “focusing on go-to-market solutions for enterprise customers.” That mandate requires rigor across product positioning, value proposition design, competitive differentiation, and sales enablement, all while aligning deeply with engineering and customer success. In practice, it means translating signal from a unified analytics platform into narratives and plays that close deals and expand accounts.

    Day-to-day, I partner with product marketing to validate messaging through continuous discovery and data. We use Amplitude analytics to instrument activation, engagement, and retention analysis—then feed those insights into product-led growth motions like in-app guides and product tours. A/B testing grounded in a clear minimum detectable effect (MDE) helps us separate noise from impact, while points of parity and true differentiation shape the story sellers can confidently carry into enterprise conversations.

    This is also where outcomes vs output OKRs keep us honest. Rather than celebrating launches, we anchor on measurable behavior change: faster time-to-value, higher user activation, deeper feature adoption, and multi-threaded stakeholder engagement. Product trios provide the operating rhythm, and stakeholder management ensures sales, marketing, and success move in lockstep with the roadmap and GTM calendar.

    If you’re building an enterprise GTM motion, start by tightening your value proposition to the top three pains your best-fit accounts actually feel, validate with real usage data, and then enable your field teams with crisp, data-backed talk tracks. With the right PM–PMM alignment and analytics foundation, your go-to-market strategy becomes a compounding advantage—not just a launch plan.

    Inspired by this post on Amplitude – Perspectives.

    Book a consult png image
  • Inside Google’s Product Model: Hard-Won Lessons to Build Empowered, Outcome-Driven Teams

    Inside Google’s Product Model: Hard-Won Lessons to Build Empowered, Outcome-Driven Teams

    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.

    Inspired by this post on SVPG.

    Book a consult png image

  • 2026 Support Capacity Playbook: Bold AI Automation, Smarter Staffing, Zero‑Surprise SLAs

    Capacity planning has always been a high-stakes exercise in customer service, and when you miss, the signal shows up fast in backlogs and SLAs. I’ve lived that pressure across multiple cycles, and 2026 will reward teams that plan differently. AI fundamentally changes capacity planning because it changes the work. It resolves the bulk of your volume, speeds up execution, and elevates the complexity and value of what humans handle. The consequence is simple: planning models must evolve. This is the final installment in my 2026 customer service planning series, and I’m focusing on the tension every leader feels right now—be ambitious about automation, but avoid the trap of understaffing if your assumptions don’t hold. My goal is to share how AI changes the logic of capacity planning, what I’ve learned implementing these practices with my team and with customers, and the common traps to avoid. Traditional planning rests on relatively stable assumptions: volume grows predictably, work types stay consistent, handle times don’t swing dramatically, and productivity improves slowly with better tools and training. In an AI-first model, none of that is guaranteed, and the fundamentals flip. The mix of work changes as AI absorbs a growing share of simpler conversations, leaving humans with deeper, more time-consuming issues that demand human-to-human connection. Demand can actually increase when you remove friction, so AI can both resolve more and attract more volume. Human time splits differently as teammates solve customer problems and also review AI behavior, give feedback, improve content, and support system-level work. Performance becomes dynamic, not fixed—automation rate isn’t a one-time number; it can rise with care and fall with neglect. If you plan for 2026 using a pre-AI model—assuming similar productivity, similar work mix, and a linear relationship between volume and headcount—you will underestimate what it now takes to run a high-performing support organization. There are many metrics you can track, but the one to put at the center is automation rate (AI Agent involvement rate × AI Agent resolution rate). This single construct tells me what share of total volume AI actually resolves, how much work remains for humans, how much additional demand humans can absorb, and how ambitious I can be with headcount. Early in the journey, I prioritize raising involvement—getting the AI involved in more conversations. Once involvement is high, I shift to resolution on the hardest remaining work, where each additional 1% of automation can represent several people’s worth of capacity. In my 2026 plans, automation rate sits alongside projected inbound volume, average “output” per person for the more complex work that remains, and occupancy—how much time is allocated to customer-facing interactions versus operational and strategic work. Together, those inputs give a realistic picture of how many people you need and where they should spend their time. First, plan boldly on automation, but match it with investment. I do not cap automation assumptions at 40–50% “because AI is new.” Many teams are already modeling 60%, 70%, even 80%+ for 2026—when they invest in AI ownership and content. The investment is non-negotiable: named ownership for AI performance (AI ops, knowledge management, conversation design), clear automation targets by work type (e.g., informational vs. personalized vs. actions vs. deep troubleshooting), realistic expectations for what’s easy to automate and what’s not, and a concrete plan to raise automation over time in monthly or quarterly steps rather than a single jump. To decide where to invest first, I dig into the data. I start with the biggest volume drivers, separate content-led issues from those dependent on data or complex procedures, assume higher resolution potential for content-led topics once the knowledge base is in shape, and set more modest initial resolution expectations for system-dependent flows. Then I stair-step improvements as the systems, data contracts, and workflows mature. In short, bold automation goals only work when paired with the team structure, content, and systems required to reach them—and the discipline to iterate. Second, expect human “output” per person to go down. That’s a mindset shift. Historically, we assumed individual productivity would stay flat or tick up as tools improved. In an AI-first model, humans handle fewer conversations but more complex, cross-functional issues—and create more value despite lower case counts. I model a lower “cases closed per person” than prior-year baselines, explicitly assume the remaining work is more complex and time-consuming, and redefine productivity to include system-level work like AI Agent improvements, content updates, and policy or workflow change management. I also report “capacity created” from automation alongside human outputs, so leadership sees the full picture. Third, rethink occupancy: more time off the queues, on higher-value work. Traditional occupancy splits time between inbox and training, meetings, and breaks. Now there’s an expanding “out-of-inbox” portfolio that directly affects AI performance and overall capacity: reviewing AI-handled conversations, improving AI Agent triaging and handovers, contributing to content and procedures, feeding insights to product and engineering, and supporting system changes that reduce future volume. I set lower inbox occupancy targets than before and make the rationale explicit. People aren’t working less—they’re working differently. In planning, I assume more time spent on improvement and system work, make it visible (for example, X% in inbox and Y% on AI and system improvement), and treat this as critical, not a “nice to have.” If you don’t proactively allocate it, it won’t happen—and your automation and performance targets will suffer. Fourth, work with the finance team early, and treat your plan as a set of assumptions. Capacity planning with AI is a set of bets across automation rate, human output, demand growth, occupancy, and where surplus capacity (if any) goes. I bring finance in early, show that the plan is dynamic and directly tied to AI performance, and label every lever as an assumption with ranges. I commit to a quarterly review cadence with finance to compare assumptions versus reality and adjust headcount, targets, and investment as needed. The risks are real: if automation grows slower than expected and you stop backfilling too early, you’ll be understaffed for months. Hiring and onboarding take time, so course-correcting late creates strain. If you do produce surplus capacity, have a clear strategy to reallocate those teammates to higher-value work—improving systems, feeding insights back to product, supporting new channels, and driving proactive CX—rather than defaulting to reductions. I also set explicit guardrails—if automation rate misses by five points for two consecutive months, we pause planned reductions and revisit hiring gates. If it over-performs, we shift people into backlog eradication, content upgrades, or proactive outreach, so we bank compounding value. To set your team up for success in 2026, anchor your plan on automation rate, be honest that humans will handle fewer but harder conversations, and protect time for system improvements. Partner early and often with finance, avoid shrinking too fast, and design a plan for surplus capacity so you’re never caught flat-footed. If AI is going to handle the majority of your customer conversations, your plan has to be designed to help it do that well and to keep your team set up for meaningful, sustainable work. A 2026 plan built on adaptable assumptions—not fixed predictions—will hold up as your work, your systems, and your customers’ expectations continue to change. If you’d like future editions like this, subscribe and stay close—I’ll keep sharing what’s working, what isn’t, and how to tune your customer support AI strategy in real time.

    Inspired by this post on The Intercom Blog.

    Book a consult png image
  • Year-End Reflection for Product Leaders: Values, Themes, and the 100‑Wishes Reset

    Year-End Reflection for Product Leaders: Values, Themes, and the 100‑Wishes Reset

    I’ve been closing the year with a deliberate reflection ritual for more than a decade, and this season I found fresh energy for it after listening to an insightful conversation with Teresa Torres and Petra Wille on All Things Product. Their approaches mirror the evolution many product leaders experience: moving from rigid annual goal-setting to values-led themes, longer time horizons, and a healthier respect for spaciousness. In my own practice, that shift has created better focus, less pressure, and far more meaningful outcomes.

    Prefer to listen? You can find this episode here: Spotify | Apple Podcasts. I took notes with my team in mind and translated the discussion into a simple, values-driven framework that any product organization can adopt.

    Why does annual reflection matter for product people? Because our work lives at the intersection of ambiguity, trade-offs, and time. If we only measure ourselves by shipped output or quarterly OKRs, we overlook the compounding value of learning, relationships, and judgement. I treat this ritual as a strategic reset: a chance to surface patterns, adjust expectations, and recommit to outcomes over output.

    My own reflection habit started scrappy—paper notebooks, messy timelines, and even artful visualizations inspired by Dear Data by Giorgia Lupi & Stefanie Posavec. Like Petra, I’ve found that tactile, analog artifacts unlock insights I miss in a spreadsheet. Over time, I’ve kept the spirit and simplified the mechanics: a “what went well” review, a short list of hard lessons, and a handful of decisions that paid off—or didn’t.

    The biggest evolution for me has been moving from rigid annual goals to values and themes. I still run OKRs, but I use them to track progress, not identity. The lens of process vs. outcome goals—reinforced by ideas from Atomic Habits—helped me set fewer, better commitments. For example, instead of “launch X by Y,” I’ll emphasize the cadence of customer discovery, the health of the product trio, and the quality of decisions made along the way.

    One exercise that changed my practice is the “100 wishes” list. It’s powerful—and surprisingly difficult. Pushing past 30 or 40 wishes forces me to name latent interests and long-range intentions I rarely say out loud. Combined with decade-level themes, the list helps me balance ambition with patience. I don’t try to do it all next year; I use it to spotlight direction, not deadlines.

    I also review patterns across years: Where did over-scheduling create hidden costs? When did I protect focus time and what did that unlock? Paul Graham’s Maker’s Schedule, Manager’s Schedule remains a useful calibration tool here. And when I feel the pull toward constant throughput, I revisit Stefan Sagmeister’s The Power of Time Off (TED Talk) to remind myself why strategically creating space often yields the most valuable ideas.

    Of course, not every year follows plan—and that’s normal. Reflection helps me spot unrealistic expectations early and let them go. When setbacks hit, I’ll rewatch Dealing with Setbacks and re-ground in continuous discovery. The question isn’t “Did we do everything?” but “Did we learn fast, protect customer value, and make trade-offs aligned with our values?” That’s how empowered product teams compound impact.

    My sharing philosophy has become more nuanced over time. Some reflections are public to invite dialogue and accountability; others stay private so I can process honestly. I’ve found it helpful to publish what I’m saying no to, capture a theme for the year ahead, and keep the rest for myself and my team. This balance preserves motivation while still contributing to the broader product management leadership community.

    If you’re designing your own ritual, consider this lightweight flow: review wins and tough calls, write your “100 wishes,” extract a few values-based themes, then translate those into process goals for Q1. Revisit monthly, not just annually. If you like structured prompts, Chris Guillebeau’s How to Conduct Your Own Annual Review from The Art of Nonconformity offers a practical template you can adapt to your context.

    For deeper dives and complementary ideas, I bookmarked these as part of my year-end reset: What I’m Saying No to This Year—And Why, Ask Teresa: My Leaders Still Want Roadmaps with Timelines—What Should I Do?, Scaling Impact: A Look at the Year Ahead (2022), Let’s Connect in 2025: A Look at the Year Ahead, The Interview Coach, and Petra’s own year-ahead reflections (here and her 2026 version). I also recommend revisiting the prior conversation on leadership and change: Role of Leadership in Transformations.

    I’d love to hear how you approach your end-of-year reflection. What questions bring you the most clarity? Which practices help you set an intentional, values-driven path for the next year? Share your process—I’m always looking to learn from other product creators and leaders.

    Inspired by this post on Product Talk.

    Book a consult png image
  • AI in Product Design: My Proven Playbook, Real Use Cases, and the Tools That Win Faster

    AI in Product Design: My Proven Playbook, Real Use Cases, and the Tools That Win Faster

    In product design, AI has shifted from novelty to non-negotiable. I’ve watched teams accelerate discovery, compress prototyping cycles, and turn ambiguous ideas into validated experiences faster than ever—without sacrificing quality or customer trust.

    AI in product design has quickly moved from new to necessary. Here are the AI product design tools and approaches you need to stay relevant in this decade.

    From my vantage point leading product teams, “necessary” means AI is woven throughout the product lifecycle—discovery, prioritization, prototyping, validation, and iteration—not bolted on. The goal isn’t to chase hype; it’s to build durable advantage with clear AI Strategy, disciplined execution, and measurable outcomes.

    First, anchor the work in strategy. Tie every AI initiative to a specific customer problem and value proposition, then express that linkage with outcomes vs output OKRs. This keeps teams focused on real impact and avoids feature-chasing. It also sharpens product positioning and clarifies where AI can deliver competitive differentiation versus simple points of parity.

    Second, upgrade discovery. I rely on AI workflows to synthesize interviews, cluster themes, and surface insights at scale. A retrieval-first pipeline—grounding models in our own data—improves factuality and reduces hallucinations. Combine this with strong data governance and privacy-by-design so insights are trustworthy and compliant from day one.

    Third, make quality measurable. Adopt eval-driven development: define evaluation sets and acceptance thresholds that reflect real user tasks before you ship. Pair that with A/B testing and minimum detectable effect (MDE) discipline, so you learn quickly and confidently. Add safety guardrails (red-teaming prompts, content filters, and bias checks) to manage AI risk without slowing the pace.

    Fourth, enable empowered product teams. Product trios (PM, design, engineering) should co-create prompts, prototypes, and evaluation criteria. Give designers and PMs practical tools—LLMs for product managers, structured prompt templates, and reusable components—so AI-augmented work becomes the default, not a special project.

    Where does AI shine in product design today? Concept exploration and market scans, turning fuzzy opportunity spaces into crisp problem statements. Rapid wireframes and interaction ideas, using gen ai for product prototyping to explore multiple design directions in minutes. UX writing that adapts tone and reduces friction across onboarding, tooltip design, and microcopy.

    It also excels at guided experiences. I’ve seen strong lifts in user activation when we pair in-app guides and product tours with context-aware suggestions. For support and education use cases, a retrieval-grounded assistant can deflect tickets, shorten time-to-value, and reinforce the product’s value proposition at the exact moment a user needs help.

    Voice is another frontier. A well-scoped voice AI agent can accelerate complex workflows (think data entry or multi-step configurations) when hands-free is faster or more intuitive. Just be intentional about when agentic AI adds net value versus when a simple UI tweak would do.

    On the tooling side, my AI product toolbox is pragmatic and modular. For analytics and learning loops, Amplitude analytics and Pendo help quantify behavior changes and retention analysis. For in-product engagement and feedback routing, Intercom and HubSpot integrate cleanly with LLM-driven tagging and summarization. For ideation and automation, I use a ChatGPT connector and Claude Code for quick scripts, data wrangling, and prompt experiments. The constant: a retrieval-first pipeline that grounds models in approved knowledge and maintains context window management at scale.

    Risk management is built in, not bolted on. Set clear AI risk management policies, catalog model and data dependencies, and document decisions. Align with regulatory compliance requirements early, and keep an audit trail of prompts, datasets, and eval results. That’s how you move fast without breaking trust.

    If you’re getting started, begin small: pick one high-friction workflow, add a retrieval-grounded copilot, and measure the lift. Use the results to inform product roadmapping and sprint planning, then scale to adjacent use cases. With disciplined discovery, sharp evaluation, and the right tooling, AI becomes a force multiplier for product teams and a clear win for customers.

    Inspired by this post on Product School.

    Book a consult png image
  • Inside the Engine Room: How I Drive Scalable Analytics APIs, Reliability, and Performance

    Inside the Engine Room: How I Drive Scalable Analytics APIs, Reliability, and Performance

    I build and scale analytics platforms with a product mindset, and the work starts with the "middleware and compute systems that power analytics at scale." In platforms like Amplitude analytics and other unified analytics platform architectures, that foundation is what makes everything else possible.

    Day to day, I oversee the "APIs behind charts, cohorts, and metrics—driving performance, reliability, and platform scalability." When those APIs are fast and resilient, every product team—from growth to customer success—can trust the insights they use to ship, learn, and iterate.

    From an engineering leadership standpoint, I partner closely with SRE to define SLOs and error budgets, wire CI/CD pipelines for safe deploys, and track DORA metrics so we improve speed without compromising quality. This combination reduces incident management toil and shortens MTTR while keeping data freshness and query latency within strict thresholds.

    From a product management leadership lens, the goal is clarity: crisp APIs, predictable contracts, and transparent stakeholder management across data, engineering, and GTM teams. That alignment empowers product teams with reliable cohorts and metrics, accelerates experimentation, and de-risks roadmaps.

    If you’re scaling analytics, invest first in the platform layer: middleware and compute, schema governance, caching strategies, and cost-aware compute. Do that well, and the visible experience—charts, cohorts, and metrics—feels effortless, even as you grow to serve billions of events with confidence.

    Inspired by this post on Amplitude – Best Practices.

    Book a consult png image
  • Long-Horizon Company Building: How to Operate for Decades

    Long-Horizon Company Building: How to Operate for Decades

    You are looking at a roadmap full of credible near-term work, yet none of it seems likely to change your company’s position. The team is busy, customers are asking for improvements, and every investment has a reasonable explanation. What is missing is a clear connection between today’s choices and the company you want to become.

    Long-horizon company building solves that problem only when it changes how you allocate capital, sequence capabilities, learn from customers, and stop work. A 25-year ambition is not permission to wait longer for results. It is a decision filter that helps you distinguish compounding investments from activity that merely fills the next planning cycle.

    Choose a problem that becomes more defensible with time

    Not every company should play a decades-long game. Time does not rescue weak demand, an undifferentiated product, or a market whose underlying problem is disappearing. A long horizon is useful when the work required to serve customers creates assets that become more valuable as they accumulate.

    Before you commit to a long-horizon strategy, test the problem against a few concrete conditions:

    • The pain is structural. Customers are constrained by an enduring workflow, infrastructure dependency, procurement model, or service failure. The opportunity does not depend entirely on a temporary technology cycle.
    • Frustration and switching costs are both high. Switching costs alone protect incumbents. Frustration alone can produce shallow demand for a convenient feature. When customers are dissatisfied but cannot change easily, a substantially better end-to-end experience can open a durable market.
    • The solution requires cumulative capability. Reliability knowledge, operational data, installation expertise, distribution, hardware, service operations, or customer trust should improve with continued use. If a new entrant can reproduce your advantage quickly, waiting longer will not make the business stronger.
    • The first product creates credible adjacencies. Expansion should follow the same customer, capability base, or service promise. A list of unrelated markets is not a platform strategy.
    • The customer outcome can support the business model. The way you charge should reinforce the result customers buy, rather than reward complexity they would prefer to avoid.

    The sharpest test is simple: explain why the company should be structurally better after years of serving customers. Your answer must identify a mechanism. More telemetry may improve diagnosis. More deployments may reduce installation risk. Deeper workflow integration may increase the value of adjacent services. Trust may lower the friction of adopting the next product. Merely having more customers or more features is not enough.

    A useful thesis takes this shape: for a specific customer, a costly problem will persist because of a structural constraint; repeatedly building a named capability will improve a defensible advantage; controlling certain interfaces is necessary to deliver the promise; and observable evidence will tell you when the thesis is weakening.

    If you cannot complete that logic without relying on market size, ambition, or executive conviction, you do not yet have a long-horizon strategy. You have a long-range hope.

    Convert a 25-year belief into present-day decisions

    A decades-long horizon should not produce a decades-long roadmap. The farther out you look, the less credible feature-level precision becomes. Preserve the direction while making the route explicitly revisable.

    Separate your strategy into three layers:

    • Enduring commitments: the customer you serve, the problem you believe will remain important, the experience you intend to make possible, and the principles you will not trade away casually.
    • Revisable hypotheses: the product architecture, distribution motion, ownership boundary, pricing model, and capability sequence that currently appear most likely to deliver the promise.
    • Disposable work: features, prototypes, internal systems, campaigns, and implementation choices. These deserve no protection beyond the evidence they produce.

    This separation prevents two common errors. The first is strategic thrashing: changing the destination whenever a current bet disappoints. The second is strategic stubbornness: defending a failed implementation because it has been wrapped in the language of mission.

    Meter provides a useful example of the distinction. The company maintained its commitment to a full-stack networking service while spending more than four years in early research and development. It also discarded about a year of operating-system work. The durable thesis survived; a costly implementation did not. That is what conviction looks like when it remains accountable to learning.

    At each planning cycle, require every major initiative to answer four questions: Which lasting capability will this build? What customer evidence should it produce? What finding would cause you to reshape or stop it? What are you deliberately declining so the investment receives enough attention?

    The stop condition matters most. Without one, patient capital quietly becomes protected capital. Teams learn to explain delays instead of testing assumptions. Write the condition while enthusiasm is high, before sunk costs and personal identity enter the decision.

    Key takeaways

    • Use a long horizon to define durable commitments, not detailed forecasts.
    • Fund work that compounds a named capability or reduces a consequential uncertainty.
    • Protect the customer problem and company promise, not the current implementation.
    • Give every major bet observable evidence and an explicit stop condition.
    • Treat abandoned work as a valid strategic outcome when it prevents a larger misallocation.

    Own only the stack required to keep the promise

    Vertical integration is neither inherently bold nor inherently wasteful. It is justified when a layer you do not control repeatedly prevents you from delivering the outcome customers believe they purchased.

    Start with the promise, not the architecture. Map the complete path from customer intent to customer outcome:

    • How the customer evaluates and buys the product
    • How the product is installed, configured, and activated
    • Which interfaces determine performance and reliability
    • What telemetry reveals failure before or after the customer notices
    • How support diagnoses and resolves a problem
    • Which service commitment makes the outcome commercially credible

    Mark every point where an external dependency can break the promise. Then ask whether tighter integration would materially improve the experience and whether the capability will compound across customers or future products. Own a layer when both answers are strong. Keep partnering when the dependency is replaceable, the layer is genuinely commodity-like, or internal ownership would add cost without improving the customer outcome.

    This prevents full-stack ambition from turning into organizational vanity. Building hardware, software, installation operations, support tooling, and service delivery at once creates many ways to fail. The burden of proof belongs with the added ownership. Each new layer should remove a specific failure mode, improve a measurable part of the promise, or unlock a strategically important product that would otherwise remain impossible.

    Physical-product teams should also treat geography as part of the operating design. When design, manufacturing, and iteration depend on one another, physical proximity can compress feedback loops. Meter used Shenzhen in this way during its development. The general lesson is not that every hardware company needs the same location. It is that organizational geography should follow the bottleneck: put the people making interdependent decisions close enough to learn at the speed the product requires.

    The business model belongs in the same analysis. If customers want an outcome but must assemble vendors, equipment, installation, and support themselves, packaging the complete experience as a service can reduce complexity and clarify accountability. Service commitments then become part of the product, not language added after the product is built. The company earns recurring revenue by continuing to deliver the outcome, which aligns incentives more closely than a transaction that ends when equipment changes hands.

    Distribution should reinforce learning during the early stages. A direct sales motion gives product and commercial leaders access to the buyer’s language, objections, procurement constraints, implementation concerns, and definition of value. That access is especially important when you are trying to establish seller-market fit: the ability to identify the right buyer, explain the value consistently, navigate the buying process, and deliver what was sold.

    Before adding channel distance, verify that target buyers recognize the same problem, objections fall into understandable patterns, sales commitments survive the implementation handoff, and the economics support the promised service. A channel can scale a repeatable motion. It cannot repair one that the company does not yet understand.

    Replace planning theater with a customer-learning system

    Removing OKRs does not create focus. It removes one alignment mechanism. If you do not replace it with a visible decision system, priorities will depend on executive proximity, persuasive storytelling, and whichever escalation arrived most recently.

    A lightweight operating system still needs a few explicit artifacts:

    • A strategic narrative: the customer problem, the long-horizon thesis, the current constraint, and the choices the company is making because of them.
    • A primary customer-value measure: evidence that the promised outcome is actually occurring, not merely that work shipped.
    • Guardrails: reliability, service, economics, or trust conditions that must not deteriorate while the primary outcome improves.
    • An unhappy-customer ledger: a shared record of broken promises, stuck use cases, escalations, and gaps between what was sold and what was delivered.
    • A decision log: the assumption behind each consequential choice, the evidence available at the time, the owner, and the condition for revisiting it.

    The unhappy-customer ledger is often more useful than another aggregate dashboard. A satisfaction score compresses many experiences into one number. An escalation exposes the precise boundary where your product, service, sales process, or ownership model failed.

    For every serious case, capture the customer’s intended outcome, the point at which progress stopped, the expectation that was violated, the immediate resolution, and the systemic change required. Classify that change as product, operations, sales, support, or ownership-boundary work. Then look for recurring failure modes across cases.

    Do not let this become a larger support queue. Closing the individual ticket is necessary, but the strategic value comes from removing the class of failure. If customers repeatedly struggle during installation, the answer may be a better workflow, different telemetry, a narrower promise, or ownership of an interface that has been treated as someone else’s problem.

    This system also clarifies empowerment. A product team should know the outcome it owns, the constraints it must respect, the decisions it can make independently, and the conditions that require escalation. Empowerment without a clear outcome produces local optimization. Authority without proximity to customer evidence produces slow, brittle decisions.

    The same clarity applies to performance problems. A company cannot preserve a long horizon while allowing unresolved role or behavior gaps to consume the team’s attention. Define the gap, the expected standard, the support available, the decision owner, and the process for reaching a fair conclusion. Move quickly toward clarity, while still following the appropriate people process. Delayed ambiguity is not patience.

    Make patience accountable in your next strategy review

    Long-horizon work will contain periods when visible output understates real progress. Research, infrastructure, reliability, manufacturing, and operational design may need to mature before customers see the complete benefit. The leadership challenge is to distinguish that legitimate incubation from drift.

    Patience is working when the core customer thesis remains supported, important uncertainties are being resolved, a reusable capability is getting stronger, and customer failures are becoming better understood or less frequent. The dates may move, but the quality of evidence improves.

    Drift looks different. Milestones move without producing new knowledge. Teams defend work by describing its difficulty or the effort already invested. The same customer failures return without a systemic response. Adjacent products receive attention before the original promise is dependable. Leadership keeps adding resources because it has not defined what would justify stopping.

    Review the portfolio by decision, not by project status. Continue work that compounds a necessary capability. Reshape work when the thesis remains sound but the current method is failing. Stop work whose original assumption no longer holds. Keep adjacent opportunities separate until the core business has earned the capacity to pursue them.

    You can run the review with the following sequence:

    1. Write the customer promise in language a buyer would recognize.
    2. Name the structural reason the problem should remain worth solving.
    3. Identify the capability that should become more valuable as the company learns.
    4. Map the interfaces, operations, and commercial dependencies that can break the promise.
    5. Examine recent unhappy-customer cases for repeated failure modes.
    6. For every major investment, write the evidence expected and the condition that would cause a change of course.
    7. Remove work that neither improves the current promise nor builds a required future capability.
    8. Assign the next consequential decision to a named owner with access to the relevant customer evidence.

    Do not leave that review with a more elaborate long-range deck. Leave with fewer bets, clearer ownership, explicit learning goals, and at least one piece of work you are prepared to stop.

    At your next planning meeting, ask which current investment will make the company structurally better at solving its chosen problem. If nobody can name the capability, the evidence, and the customer promise it serves, pause the work before time turns activity into strategy by accident.

    References

    • Shivam.Consulting Blog — Playing the 25-Year Game: Rethinking Networking, Ditching OKRs, and Owning the Full Stack