Category: Product Management Leadership

  • From Amplitude Adoption to Customer Value: A Leadership Model

    From Amplitude Adoption to Customer Value: A Leadership Model

    If your team can show what customers clicked but cannot explain what changed in their business, you do not have customer value evidence. You have usage evidence. That distinction becomes expensive when a renewal, expansion, or roadmap decision depends on a credible outcome.

    The fix is not another dashboard. You need an operating model that connects product behavior to workflow change, business outcomes, and a decision the customer is prepared to make. Customer value leadership is the discipline that keeps that chain intact.

    Customer value is a chain, not an adoption metric

    Amplitude has both a Head of Strategic Customer Success and a regional Head of Value for Asia Pacific and Japan. Job titles do not reveal the full operating model, but the distinction is useful. Helping a customer succeed with a product and proving the value of that success are related responsibilities, not identical ones.

    Customer success can coordinate adoption, remove account-level obstacles, and maintain the relationship. Product can build the capability and instrument its use. Analytics can show what happened inside the product. Value leadership must connect those contributions to an outcome that matters outside the dashboard.

    Use this chain when you evaluate a value claim: product capability leads to user behavior; behavior changes a workflow; the workflow affects an operational or business outcome; the outcome changes a decision. A broken link cannot be repaired by adding more detail to the links you already have.

    • Usage means an event occurred. A user opened, configured, created, or completed something.
    • Adoption means the intended users incorporated the behavior into a recurring workflow.
    • Outcome means something measurable changed in that workflow or in the operation around it.
    • Value means the outcome matters enough to affect a customer decision, such as continuing, expanding, standardizing, or changing direction.

    These working definitions prevent a common category error. A rising event count can be evidence of usage, but it does not automatically establish adoption. Adoption can be real without improving the intended outcome. Even a verified outcome may have limited value if the customer does not consider it material.

    This is why product analytics is necessary but insufficient. It is closest to the behavior layer. The business outcome may live in an implementation record, CRM, support system, finance system, operational database, or the customer’s own system of record. Your value model has to cross those boundaries without pretending that a convenient proxy is the result itself.

    Write the value contract before you instrument the dashboard

    A value contract is a testable agreement about what should change, for whom, why the product should contribute, how the change will be measured, and what decision will follow. It is not a legal contract or a sales promise. It is the shared measurement brief for product, customer success, data teams, and the customer sponsor.

    Write the hypothesis in this form: If the specified users complete the intended workflow through the product capability, the named business outcome should move in the expected direction because of the stated mechanism. The result will be judged in the named system of record, for the defined population and time window, against an agreed baseline or comparison. The named decision owner will use the result to make a specific decision.

    A practical value contract should contain:

    • Outcome owner: the customer stakeholder who cares about the result and has authority to act on it.
    • Outcome: the operational or business condition expected to change, including its unit of measurement.
    • Population: the users, accounts, workflows, or transactions included in the claim.
    • Mechanism: the reason the product behavior should produce the outcome rather than merely accompany it.
    • Behavioral signal: the observable action showing that the capability entered the intended workflow.
    • Baseline or comparison: the prior state, untreated group, alternative workflow, or other reference needed to interpret movement.
    • System of record: the place from which the outcome value will be taken.
    • Measurement window: the period in which the behavior and outcome can reasonably be connected.
    • Evidence boundary: what the available data can establish and what will remain an assumption.
    • Decision: what the customer or your product team will do if the result is confirmed, rejected, or inconclusive.

    Consider a hypothetical onboarding capability. A weak claim is: guided setup improves activation. A testable contract is: when newly assigned administrators complete configuration through guided setup, elapsed time from access to the first completed workflow should decline because fewer manual handoffs are required. Product analytics will establish the configuration path, implementation records will establish elapsed time, and the customer sponsor will determine whether the change is material to the rollout decision.

    The second version gives every participant something concrete to verify. It also exposes missing data before anyone builds an executive narrative around an attractive chart.

    Value layerQuestion to answerEvidence to inspect
    CapabilityWhat product intervention was available and correctly configured?Release, entitlement, and configuration records
    BehaviorDid the intended users perform the intended action?Events, paths, account identity, and cohort membership
    WorkflowDid the way work was completed actually change?Completion states, handoffs, errors, and process records
    OutcomeDid the relevant operational or business measure move?The agreed customer or company system of record
    DecisionWas the movement material enough to change what happens next?A documented decision from the accountable stakeholder

    Instrumentation should follow the same contract. Define the event, account and user identity rules, qualifying population, required properties, exclusions, data owner, and expected data freshness. Then identify the external outcome record and the join needed to connect it to product behavior. If identity cannot be reconciled across those systems, say so before presenting an account-level value claim.

    Match the strength of the claim to the strength of the evidence

    Customer value work loses credibility when the language becomes stronger than the measurement. A dashboard can establish that behavior occurred. It cannot, by itself, eliminate changes in customer staffing, process, demand, pricing, seasonality, implementation support, or other competing explanations.

    Use an evidence ladder and label every material claim:

    • Observed: the target behavior or outcome was measured. Safe language is that users performed the action or that the metric changed.
    • Associated: the behavior and outcome moved together in the relevant population. Safe language is that the two were associated; alternative explanations remain.
    • Contributed: behavioral data, outcome data, the proposed mechanism, and customer context support the product as a meaningful contributor. The evidence is stronger than correlation but does not isolate the product as the sole cause.
    • Causal: an experiment or credible comparison isolates the intervention sufficiently for a causal statement within the tested population and conditions.

    This classification is not academic caution. It determines what you can responsibly tell a customer, put into a business case, use in a case study, or feed into a product investment decision. Saying that evidence supports a contribution is more credible than claiming causation the design cannot prove.

    Prepare a compact evidence packet for each important value claim. Include the contract, the population and exclusions, the baseline or comparison, the product behavior, the outcome record, relevant customer context, plausible rival explanations, the evidence label, and the decision at stake. Keep raw observations separate from customer-supplied values and internal assumptions.

    This separation matters especially in financial models. An estimated labor value, assumed conversion effect, or projected risk reduction may be useful for planning, but it is still an assumption until the customer accepts the input and the outcome is observed. Marking the boundary does not weaken the case. It lets the decision-maker see which part is measured, which part is supplied, and which part is inferred.

    Three checks catch most overstatements:

    • Counterfactual check: what would probably have happened without the product behavior?
    • Segment check: does the result hold for the target population, or is an aggregate hiding materially different groups?
    • Mechanism check: can you explain how the behavior produced the outcome, and does the available evidence support that path?

    If you cannot answer a check, downgrade the claim and record what evidence would raise confidence. That creates a measurement backlog with a purpose, instead of a growing collection of dashboards nobody can use to make a decision.

    Give the value leader decision rights and a review mechanism

    A Head of Value cannot succeed as a ceremonial translator who is invited after product, sales, and customer success have already chosen their metrics. The role needs authority over the quality of value claims while leaving functional ownership where it belongs.

    I would give customer value leadership responsibility for:

    • maintaining the shared definitions of usage, adoption, outcome, value, and evidence confidence;
    • requiring a value contract before a strategic claim is instrumented or commercialized;
    • rejecting claims whose wording exceeds the available evidence;
    • convening product, data, customer success, sales, and customer stakeholders when the evidence chain crosses their boundaries;
    • turning repeated account-level evidence into portfolio learning for positioning, onboarding, and roadmap decisions; and
    • making unresolved assumptions, data gaps, and ownership gaps visible to leadership.

    I would not make the value leader the owner of every customer outcome. Product still owns the capability and its intended mechanism. Data owners remain accountable for measurement integrity. Customer success owns the adoption plan and account context. Sales owns the commercial hypothesis it introduces. The customer sponsor decides whether the outcome is material in that customer’s business.

    The value leader owns the standard connecting those responsibilities. That includes the right to say that a claim is not ready.

    Replace status-heavy value meetings with decision reviews. Require the value contract and evidence packet in advance. During the review, ask:

    • Which customer decision is this evidence meant to inform?
    • What changed in product behavior, and among exactly which users or accounts?
    • What changed in the workflow or business outcome?
    • Does the proposed mechanism still hold, or did implementation reveal a different one?
    • Which competing explanations remain plausible?
    • What confidence label does the evidence support?
    • What will product, customer success, or the customer do differently as a result?

    A review is complete only when it produces a decision, a revised claim, or a named evidence gap with an owner. A polished presentation without one of those outputs is reporting, not value management.

    Keep account truth separate from portfolio truth. Evidence from a strategic account can guide that account’s success plan. It should influence the core product only when you can explain why the underlying need or mechanism generalizes to a relevant segment. Repeated value contracts make that comparison possible because teams stop describing every customer outcome in incompatible language.

    If you use regional value leaders, make the boundary between global consistency and local adaptation explicit. Definitions, evidence labels, and claim standards should remain comparable. Customer workflows, stakeholder language, implementation conditions, and the decisions that establish materiality may require local context. Without that boundary, central teams either erase useful differences or regional teams produce claims that cannot be compared.

    Key takeaways

    • Amplitude behavior data can establish what users did; customer value leadership connects that behavior to workflow changes, business outcomes, and decisions.
    • Define usage, adoption, outcome, and value separately so an engagement metric is not mistaken for business impact.
    • Create a value contract before building the dashboard. Name the population, mechanism, baseline, system of record, evidence boundary, and decision owner.
    • Label claims as observed, associated, contributed, or causal, and use language that matches the evidence.
    • Give the value leader authority over claim quality, cross-functional evidence standards, and portfolio learning without transferring every functional responsibility into the role.
    • Run value reviews around pending decisions, not presentation updates.

    Choose a strategic account with a live renewal, expansion, rollout, or workflow decision. Draft its value contract with product, customer success, data owners, and the customer sponsor. Then audit the chain from capability to behavior, outcome, and decision. The first missing link tells you where leadership is needed; another adoption chart will not.

    References

  • Competing on Experience: A Retail Banking Product Strategy

    Competing on Experience: A Retail Banking Product Strategy

    A rate promotion can win a comparison. It cannot, by itself, make a customer trust your bank as the place where their financial life should run. If you are deciding where retail banking growth should come from, separate the offer that gets attention from the experience that earns the primary relationship.

    That distinction changes the roadmap. The competitive front is moving beyond rate and toward experience. The practical question is not whether user experience matters. It is which moments change customer behavior, which failures weaken trust, and how you improve those moments without compromising security, compliance, or financial value.

    Experience is the banking system, not the app’s finish

    Retail banking experience is often reduced to interface quality: fewer taps, cleaner screens, faster navigation, and more polished personalization. Those things matter, but they are only the visible layer.

    The real experience is the customer’s ability to achieve a financial outcome and remain confident about what happened. It includes product rules, identity checks, transaction processing, status messages, notifications, support handoffs, fraud controls, and back-office resolution. A payment blocked in the app, explained by a contact-centre agent, and resolved by an operations team is one customer experience, even if three departments own it.

    This is why experience-led competition is not a choice between price and design. An uncompetitive product cannot be rescued by a delightful interface. A confusing or unreliable experience can still destroy the value of a good rate. Product value earns consideration; the surrounding experience determines whether customers can understand, access, and continue using that value.

    A useful experience test asks whether a customer can:

    • Complete the intended job safely, without avoidable repetition or channel switching.
    • Understand the current status, including pending, failed, restricted, or completed states.
    • See what will happen next, what action is required, and who owns the next step.
    • Resume the journey without re-entering information the bank already has.
    • Get an appropriate human handoff when self-service is no longer the right path.
    • Recover from an exception with the same clarity as the happy path.

    If your roadmap mainly improves navigation while these underlying conditions remain broken, you are decorating operational friction. The more durable advantage comes from building a system that can detect a failing journey, explain why it is failing, change it safely, and measure whether customer and business outcomes improved.

    Compete where uncertainty and consequence meet

    Customers do not experience your organizational chart. They arrive with an intent: open an account, move money, understand a balance, protect a card, resolve a problem, or make a financial decision. Map the experience around those intents rather than around pages, features, or departmental ownership.

    The highest-leverage moments tend to combine uncertainty with consequence. A cosmetic inconsistency may be annoying. An unexplained transfer status can make a customer unsure whether to wait, retry, contact support, or move money another way. That uncertainty creates repeat actions, operational work, and avoidable risk.

    Customer momentQuestion the experience must answerSignals of failureUseful measures
    Opening and funding an accountIs my account ready, and what must I do next?Repeated verification, unexplained waiting, abandonment, or an opened but unfunded accountVerified-and-funded completion, time between milestones, repeat attempts, and assisted contacts
    Moving moneyDid the payment or transfer go where I expected?Duplicate submissions, repeated status checks, reversals, or support contactsFirst-attempt completion, repeated actions, status comprehension, and exception resolution
    Understanding activityWhat happened to my money, and is action required?Ambiguous labels, repeated transaction views, unnecessary disputes, or channel switchingSelf-resolution, help-seeking behavior, dispute initiation, and successful next action
    Handling an exceptionAm I protected, who owns this, and when will I hear more?Multiple handoffs, repeated explanations, contradictory status, or unresolved follow-upResolution completion, handoffs, repeat contacts, status visibility, and recurrence
    Considering another productIs this relevant to my need, and do I understand the commitment?Generic offers, confused eligibility, abandonment after disclosure, or acceptance without meaningful useEligible journey completion, comprehension signals, post-acceptance use, and complaints

    Use this map to choose investments. Do not start with the most visited screen or the loudest internal request. Start with a customer moment where failure has a meaningful consequence and where the bank has enough evidence and control to improve the outcome.

    You also need to distinguish necessary friction from accidental friction. Identity verification, security challenges, disclosures, and eligibility checks may be essential. The product problem is not simply to remove them. It is to remove ambiguity, redundant work, dead ends, and unexplained waiting while preserving the control itself.

    That distinction prevents a common mistake: treating completion speed as the only definition of good experience. A slightly longer journey can be better if it improves understanding or prevents a harmful error. A shorter journey can be worse if customers complete it without knowing what they agreed to. Optimize for a safe, understood outcome rather than minimum interaction at any cost.

    Measure behavior, not a vague experience score

    A single experience score is attractive because it makes portfolio reporting easy. It is weak as a product-management instrument. The average can improve while an important customer group gets stuck, and it rarely identifies what a team should change next.

    Build a measurement hierarchy for each priority journey instead:

    1. Customer outcome: Did the customer complete the intended financial job and understand its result?
    2. Journey quality: How many retries, backtracks, unexplained waits, handoffs, help requests, and channel switches occurred?
    3. Trust and risk guardrails: Did errors, complaints, disputes, fraud exposure, accessibility failures, or regulatory incidents change?
    4. Business effect: Did the improvement lead to appropriate activation, ongoing use, retention, relationship growth, or lower avoidable service demand?

    This order matters. If a redesigned onboarding step gets more clicks but does not produce more ready-to-use accounts, the local conversion is not the outcome. If contact volume falls while abandonment rises, the experience did not improve; customers may simply have stopped asking for help. If a faster transfer flow increases mistaken submissions or disputes, speed came at the expense of safety.

    Do not mistake activity for customer value

    Several familiar digital metrics are ambiguous in banking:

    • More logins can indicate engagement, but they can also indicate anxiety about an unresolved transaction.
    • Longer sessions can reflect exploration, but they can also mean that information is hard to find.
    • Higher self-service can indicate convenience, but only if customers complete the job rather than abandon it before contacting the bank.
    • Faster completion is useful only when comprehension, accuracy, security, and accessibility remain intact.
    • Feature adoption matters only when the feature helps customers reach an outcome and supports a legitimate business result.
    • Overall satisfaction can reveal direction, but an aggregate score usually cannot diagnose a specific broken journey.

    Read these measures in context. Pair activity with state, intent, and downstream behavior. A customer who repeatedly checks a pending payment belongs to a different behavioral pattern from one who regularly reviews a completed monthly statement, even if both produce the same page-view event.

    Segment by the journey conditions that change the experience

    An average funnel can hide the problem you need to solve. Break the journey down by factors such as entry channel, new versus established relationship, first attempt versus repeat attempt, product held, authentication path, assisted versus unassisted completion, and exception type. Use customer attributes only when their use is lawful, necessary, governed, and appropriate for the decision.

    For each segment, look for a behavioral chain: the change you made, the immediate behavior it should influence, the customer outcome that should follow, and the business effect you expect. Name a guardrail beside that chain. This turns an experience idea into a testable product hypothesis rather than an aesthetic preference.

    Build a product operating system for experience improvement

    Experience-led competition depends on the speed and quality of organizational learning. A bank will not create that capability through a collection of isolated redesign projects. You need a repeatable path from customer problem to evidence, intervention, safe release, and measured outcome.

    1. Choose one consequential customer moment. Use complaints, service reasons, journey abandonment, operational exceptions, and business performance to locate a problem. Write down why this moment matters to the customer and the bank.
    2. Define an outcome contract. State the job the customer must complete, the status they must understand, and the controls that cannot be weakened. Include required disclosures, security conditions, accessibility needs, and the fallback path when digital completion is inappropriate.
    3. Draw the service blueprint. Map the visible steps together with decision rules, systems, queues, messages, handoffs, and manual operations. Mark ownership at every transition. This exposes failures that a screen-by-screen journey map cannot show.
    4. Instrument the journey safely. Create stable events for meaningful states such as journey started, verification submitted, status displayed, action completed, help requested, assisted handoff, and case resolved. Do not place account balances, credentials, free-form customer text, or unnecessary personally identifiable information in analytics events. Apply your institution’s privacy, security, retention, and regulatory controls before collection.
    5. Combine behavioral and operational evidence. Funnels and journey paths show where behavior changes. Support reasons, complaints, accessibility feedback, and operational exceptions help explain why. Review them together so the team does not optimize a digital metric while moving the problem into another channel.
    6. Prioritize by consequence and evidence. Consider customer harm or inconvenience, business effect, strength of evidence, frequency, controllability, dependencies, and implementation risk. Avoid a false-precision scoring formula when the underlying evidence is weak.
    7. Test within explicit guardrails. A/B testing can help evaluate navigation, explanation, sequencing, prompts, or other reversible presentation choices. Do not use experimentation to weaken security, vary legal entitlements, obscure fees or rates, bypass required disclosures, or produce unfair treatment. Obtain the necessary risk, compliance, legal, and accessibility review, release through controlled exposure where appropriate, and prepare a rollback path.
    8. Review the full outcome after release. Check the customer outcome, journey diagnostics, risk guardrails, and business effect. Then inspect important segments for uneven results. A local lift is not a win if the end-to-end journey, a vulnerable segment, or an operational queue deteriorates.

    Treat service recovery as a product surface

    Many roadmaps stop at the moment an automated journey fails. The customer experience does not. Recovery should be designed with the same care as onboarding or payments.

    A useful recovery design preserves context across channels, gives the customer a stable case or transaction status, identifies the next owner, explains what the customer needs to do, and closes the loop when the case changes. It should also distinguish between a person who needs reassurance, one who must provide information, and one who requires immediate specialist help.

    Measure the journey from the original intent through resolution. A digital team should not claim success because a customer left the app if the customer then had to repeat the story to multiple agents. Equally, a support contact is not automatically a failure; for a consequential or complex situation, a timely and informed human intervention may be the right product outcome.

    Fund the capabilities that improve multiple journeys

    Portfolio reviews tend to favor visible features because they are easy to present. Experience advantage often depends on less visible foundations: a consistent status model, reusable identity and permission services, cross-channel case context, notification preferences, governed event definitions, experimentation controls, and reliable links between digital behavior and operational resolution.

    These capabilities should not become open-ended platform programs. Tie each one to a priority customer journey, prove that it improves an outcome, and then reuse it. That creates compounding value without asking the organization to fund infrastructure on faith.

    Product leadership also needs clear decision rights. Product owns the intended customer and business outcome. Operations owns the viability of manual paths and queues. Service teams contribute failure reasons and recovery evidence. Data owners govern definitions and access. Risk, compliance, legal, security, and accessibility partners define constraints and review consequential changes. Shared ownership should clarify the decision, not create a committee in which nobody is accountable.

    Key takeaways

    • A competitive rate or fee can attract attention, but the end-to-end experience determines whether customers can realize that value and keep using the relationship.
    • Manage journeys around customer intent, including operational handoffs and recovery, rather than optimizing isolated screens or departmental metrics.
    • Prioritize moments where uncertainty has a meaningful customer or business consequence.
    • Measure customer outcomes, journey quality, trust and risk guardrails, and business effects as a connected hierarchy.
    • Do not treat logins, session time, self-service, feature adoption, or a single satisfaction score as proof of value without behavioral context.
    • Use experimentation for reversible experience choices within explicit legal, security, accessibility, fairness, and compliance constraints.
    • Invest in reusable journey capabilities only when a priority customer outcome gives them a concrete reason to exist.

    At your next roadmap review, ask every retail banking initiative to name the customer moment, observable behavior, end outcome, business effect, and non-negotiable guardrail. If it cannot, it is not yet an experience strategy. Start with the journey that creates both customer uncertainty and operational work, repair that system end to end, and use what you learn to improve the next one.

    References

  • Operating Lessons from Plaid’s COO for Scaling Through Change

    Operating Lessons from Plaid’s COO for Scaling Through Change

    Scaling an operating organization is not simply a matter of adding process. It requires leaders to decide where the company needs control, where teams need discretion, and how much capacity must remain available for opportunities that cannot be predicted.

    First Round’s conversation with Plaid COO Eric Sager offers a useful operating model for making those choices. His experience at Plaid, following leadership roles at Bluevine and Square, connects organizational resilience, customer ownership, executive leverage, and employee onboarding into one coherent discipline.

    Key takeaways for operating leaders

    • Preserve capacity for unexpected, strategically important work instead of scheduling every team to its theoretical limit.
    • Give each customer relationship one accountable owner, supported by specialists who can enter when their expertise is needed.
    • Evaluate speed alongside risk and cost; faster execution is not automatically the better business decision.
    • Measure an executive’s impact partly by whether the organization can function without constant executive intervention.
    • Use direct contact with new employees to test how onboarding and culture are experienced, not merely how they were designed.

    Operating slack is a strategic resource

    Sager argues against running an organization at 100% capacity. First Round reports that retaining flexibility helped Plaid respond to opportunities involving OpenAI, Perplexity, and Replit. The broader lesson is not that teams should operate without discipline. It is that a plan consuming every available hour leaves no room for high-value work that appears after planning is complete.

    This is especially relevant to product and go-to-market leaders. A team optimized entirely for utilization can look efficient while becoming slow to respond. Spare capacity acts like an option: the company incurs a visible short-term cost in exchange for the ability to pursue an important customer, solve an urgent problem, or adapt to a market shift.

    The practical challenge is protecting that slack from becoming unowned time. Leaders still need clear priorities and decision rights. Capacity should be available for defined classes of work, such as strategic deals, urgent customer risks, or emerging product opportunities, with explicit authority over who can redirect it.

    Customer ownership should remain simple as expertise grows

    As a company scales, generalist roles often give way to specialized customer segments and expert functions. That specialization can improve the quality of advice while making the customer’s experience fragmented. Plaid’s reported answer is a quarterback model: one person owns the full relationship while specialists remain available to contribute.

    The distinction between accountability and expertise matters. Specialists may understand a product, industry, or technical issue more deeply, but the customer should not have to coordinate the internal organization. A single owner maintains context, aligns the contributors, and remains responsible for the overall outcome.

    This model also exposes weak handoffs. When ownership is shared ambiguously, teams can complete their individual tasks while the customer’s larger problem remains unresolved. A named quarterback makes escalation clearer without requiring that person to solve every issue personally.

    Speed, risk, and cost belong in the same decision

    The source describes Sager treating speed, risk, and cost as a three-way trade-off. This is a more useful framing than a blanket instruction to move faster. Accelerating work may require more people, introduce operational exposure, or reduce the time available to validate a consequential choice.

    A sound operating review therefore asks what the company gains by acting sooner, what can go wrong, and what additional resources acceleration requires. Reversible decisions can often move quickly because errors are easier to correct. Decisions with material customer, regulatory, or organizational consequences may justify a slower path. The objective is not maximum speed; it is an appropriate speed for the consequences involved.

    That discipline becomes more important during turbulence. According to First Round, Sager helped lead Plaid through the pandemic, the collapse of its planned Visa acquisition, a fintech downturn, and the AI boom. The source also says Plaid remained focused after the Visa transaction fell through and later raised at nearly three times the price. These are reported outcomes, but the transferable insight is the importance of separating a changed circumstance from a changed mission.

    An effective COO reduces organizational dependency

    Sager’s view that strong COOs deliberately make themselves obsolete challenges the image of the executive as permanent chief problem-solver. If routine decisions repeatedly rise to the same leader, the organization may be borrowing that person’s judgment without developing its own.

    Reducing dependency does not make the role irrelevant. It shifts executive attention toward the ecosystem, the business, and the team – the three areas First Round says shape Sager’s working week. The COO can then concentrate on cross-functional constraints, leadership quality, and new operating problems instead of repeatedly compensating for missing ownership.

    A useful test is whether teams have the context, authority, and mechanisms to proceed when the executive is unavailable. Delegation without context produces guesswork; context without authority produces escalation. Both must travel together.

    Cold-calling new hires turns onboarding into evidence

    One of Sager’s more unusual practices is personally cold-calling brand-new employees. The source does not provide enough detail to judge the full method or its results, but the practice points to a valuable principle: senior leaders need unfiltered signals from people experiencing the organization for the first time.

    New hires notice unclear language, missing context, and mismatches between stated culture and everyday behavior. Direct outreach can reveal whether onboarding is creating confidence or merely completing administrative steps. It can also make leadership more tangible, although leaders should avoid turning the conversation into a test in which employees feel pressured to give reassuring answers.

    The forward-looking opportunity is to connect those conversations to operating improvement. When recurring confusion becomes visible, leadership can clarify ownership, revise onboarding, or remove unnecessary process. That is how a personal executive habit becomes a scalable management system.

    Book a consult png image
  • From Customer Signals to Reliable Product Operations

    From Customer Signals to Reliable Product Operations

    Customer signals become operationally useful only when a team knows what each signal can establish, how quickly it requires action, and who owns the next decision. A support complaint, a workflow metric, and a detailed customer story may describe the same experience, but they do not carry the same context or call for the same response.

    The two source articles illuminate opposite ends of this system. The incident-management article shows how customer impact should trigger rapid containment, while the product-discovery article explains why early evidence usually needs enrichment before it supports a durable product commitment. Together, they suggest a product operations model that separates detection, diagnosis, recovery, and learning without disconnecting them.

    Key takeaways

    • Signals should be classified by purpose: some reveal that customers are being harmed, while others help explain why.
    • The cost of waiting should determine response speed, but urgency should not turn an incomplete signal into false certainty.
    • Support, behavioral data, operational telemetry, rollout monitoring, and customer interviews contribute different forms of evidence.
    • Strong product operations preserve signal provenance, route it to a clear owner, and define the next evidence-building or recovery action.
    • Incident learning and continuous discovery should feed the same organizational memory so recurring friction becomes easier to recognize and address.

    One customer signal can serve several operational jobs

    The phrase “customer signal” often collapses several distinct concepts. A signal can detect a change, indicate its scale, describe a particular experience, test an explanation, or evaluate a proposed solution. Confusion arises when an input collected for one of these jobs is treated as if it can perform all of them.

    The incident playbook reports that Support, including automated support capabilities, may identify a pattern in customer conversations before a technical dashboard exposes it. It also describes heartbeat metrics that track whether customers can complete core workflows, rather than merely whether underlying systems remain online. In that setting, tickets and outcome metrics act as detection mechanisms: they establish that the experience may be unhealthy and that investigation should begin.

    The evidence-focused article assigns a different role to many of the same inputs. It characterizes support tickets, app-store reviews, sales notes, and behavioral analytics as useful prompts for discovery but weak foundations for deciding what to build on their own. These sources can expose repetition or friction, yet they may omit the sequence, motivation, constraints, and tradeoffs behind the observed behavior.

    These positions are complementary. A compressed support report can be strong enough to initiate triage without being rich enough to define a roadmap solution. Likewise, a behavioral change can justify investigation without proving its cause. Product operations should therefore attach an explicit purpose to each signal: detect, size, explain, validate, or monitor. That label prevents teams from asking an input to support a conclusion it cannot carry.

    Response speed and evidence depth belong on different clocks

    Customer signals create two fundamentally different decision conditions. When customers are actively unable to complete an important task, delay expands the harm. When a team is considering a durable product investment, premature certainty can consume capacity and institutionalize the wrong interpretation.

    The incident article argues that a declared incident should become the responsible team’s immediate priority. Its reported process converges customer reports, product alarms, and engineer rollout monitoring on a rapid assessment of customer impact. It also reports that engineers monitor changes through production and that a rollback can land in a little under two minutes. In this context, a safe rollback does not require a complete causal theory; it is a reversible containment decision intended to reduce exposure while investigation continues.

    The discovery article describes a more deliberate progression through a “Ladder of Evidence.” Repeated low-context signals justify moving upward toward recent, story-based customer accounts. Those accounts reconstruct what the customer was trying to do, what happened, and what constraints shaped the experience. The purpose is not to delay action indefinitely, but to avoid turning frequency into an unsupported solution.

    A useful synthesis is to separate the action threshold from the belief threshold. Teams can act quickly when an intervention is reversible and the cost of waiting is high. They should demand richer evidence when a choice is difficult to reverse, consumes substantial capacity, or assumes a specific explanation for customer behavior. Fast containment and careful learning are therefore not competing philosophies; they govern different commitments.

    A routed signal system turns inputs into decisions

    Preserve provenance before interpreting the signal

    Every captured signal should retain enough context to show where it came from, which customer workflow it concerns, when it occurred, and whether it is an observation or an interpretation. This is a general operating practice rather than a fact reported by either source, but it follows directly from their shared concern with signal quality. A ticket summary, a metric anomaly, and an interview account should remain distinguishable after entering a common repository.

    Preserving provenance also makes limitations visible. A Sales note may reflect the priorities of a commercial conversation. A dashboard records selected events but not necessarily customer intent. A story-based interview offers depth about a specific experience but does not by itself establish prevalence. None of these limitations makes the source unusable; each defines the questions it can responsibly answer.

    Correlate without treating evidence as a vote

    The discovery article presents triangulation across quantitative data, organizational observations, and qualitative customer insight. It cautions, in effect, against treating three inputs as interchangeable ballots. Convergence can strengthen an explanation, contradiction can expose segmentation or missing context, and silence in one channel can reveal an instrumentation or access gap.

    The incident article supplies an operational version of the same principle. Customer conversations, heartbeat metrics, ordinary alarms, and rollout monitoring offer separate views of product health. A support pattern may establish visible pain, while a workflow metric helps assess scope and timing. Combining them produces a more useful impact picture than either channel can produce alone.

    Route the signal to an explicit next action

    A signal repository becomes a backlog graveyard if collection is not paired with routing. The next action might be incident triage, instrumentation review, identification of affected customers, a story-based interview, solution evaluation, or continued monitoring. The choice should reflect what is already known and which uncertainty most constrains the next decision.

    This routing step is where product operations adds leverage. It connects customer-facing teams, product trios, engineering owners, and decision-makers without pretending that every input deserves a feature request. It also creates a traceable path from the original observation to the investigation, intervention, and later result.

    Ownership and cadence close the signal-to-learning loop

    Signals move faster when ownership is defined before pressure arrives. The incident article reports distinct responsibilities for a technical lead, an incident commander when escalation is needed, a business lead for customer-facing coordination, and a resolution owner for follow-up work. The benefit is not hierarchy for its own sake; it is reduced ambiguity while customers are affected.

    Discovery needs comparable clarity. The evidence article places responsibility on product teams to distinguish observations from interpretations, match the research method to the question, and improve interview quality without discouraging customer contact. Product operations can support that discipline by making evidence strength visible and ensuring that recurring signals receive either an investigation owner or an explicit decision not to pursue them.

    The two workflows should ultimately reconnect. An incident can generate product questions about confusing recovery paths, missing safeguards, or poorly observed workflows. Discovery can reveal customer-critical actions that deserve heartbeat metrics or stronger operational readiness. Post-incident follow-ups, recurring signal reviews, customer research, and roadmap discussions should contribute to a shared record rather than separate departmental archives.

    The next stage of mature product operations is therefore not simply collecting more feedback or adding more dashboards. It is designing a system in which the weakest signal can trigger appropriate attention, stronger evidence can refine the explanation, and clear ownership can carry learning into safer product and operational choices.

    References

  • The Hidden Leadership Skills Product Managers Need Before the Title Change

    The Hidden Leadership Skills Product Managers Need Before the Title Change

    Every product manager eventually confronts the same uncomfortable paradox: Every product manager wants to move into leadership — but nobody wants to hire a leader without leadership experience. I have seen this pattern across product teams at every stage of maturity, and I have felt how frustrating it can be for strong individual contributors who are ready for more responsibility but are still waiting for a formal title change.

    The mistake I see many product managers make is assuming that leadership begins only after promotion. In practice, product management leadership starts much earlier. It begins when we understand what our organization actually expects from its leaders, then deliberately practice those behaviors in the role we already have.

    That first step sounds simple, but it is often skipped. Before I can grow as a leader, I need to know what leadership means in my specific context. Some companies define it through leadership principles, values, management training, or competency models. Others leave it implicit, which means I need to study who gets promoted, ask recently promoted leaders what changed, and observe which behaviors earn trust from executives and peers.

    General frameworks can help. Petra’s Product Leadership Wheel – A Framework for Defining and Growing Product Leadership at Scale, Korn Ferry’s competencies, Gallup, and Amazon’s Leadership Principles all provide useful language. But the most important version is the one inside my own organization. Leadership is not abstract; it is contextual, cultural, and operational.

    One leadership muscle I believe every product manager must build early is the ability to say no with evidence and clarity. Saying no is easy. Saying no well is the skill. The goal is not to become a gatekeeper, reject ideas reflexively, or hide behind process. The goal is to make the reasoning so clear that stakeholders can almost reach the “no” themselves.

    This is where stakeholder management becomes a serious product management leadership capability. When we explain why a request does not align with the strategy, customer evidence, business outcome, or current opportunity space, we are not simply declining work. We are teaching the organization how decisions get made. Over time, that clarity reduces thrash, builds trust, and raises the quality of future conversations.

    The second foundational skill is directional clarity. I think of directional clarity as the ability to help a team understand where we are going, why it matters, and how today’s decisions connect to a larger outcome. It is the crux of leadership because teams do not need leaders merely to assign tasks. They need leaders to reduce ambiguity without pretending certainty exists.

    For an individual contributor, the practical path is incremental. I can start by creating clarity for the current sprint. Then I can extend that clarity across two sprints. Then a quarter. As my product leadership grows, my planning horizon expands from the immediate work to broader customer outcomes, product strategy, and organizational tradeoffs.

    Podcast cover for Episode 67, Stepping Into Leadership, showing abstract connected nodes beside All Things Product text with Teresa and Petra.
    Stepping Into Leadership sets a calm, thoughtful tone with connected-node artwork and bold purple typography for an All Things Product podcast episode with Teresa and Petra.

    This shift can feel strange because the work becomes less concrete over time. Early in a product career, clarity often looks like a prioritized backlog or a crisp sprint goal. Later, clarity looks more like a strategic narrative, a set of outcome-based priorities, and a decision framework that helps teams navigate uncertainty. Getting less concrete over time is a feature, not a bug.

    Tools like the Decision Stack, the Now-Next-Later roadmap, and the Opportunity Solution Tree are useful because they help us communicate at different abstraction levels. The Decision Stack connects company strategy to product decisions. The Now-Next-Later roadmap gives teams a healthier way to plan under uncertainty. The Opportunity Solution Tree helps us connect customer needs, business outcomes, and solution bets without collapsing discovery into feature delivery.

    I also like the metaphor of Powers of Ten because product leadership requires constant movement between levels of abstraction. One moment, I may need to discuss a specific customer pain point. The next, I may need to connect that pain point to a quarterly outcome, a market shift, or a broader product strategy. Strong product leaders know how to zoom in and out without losing the thread.

    The most encouraging lesson is that I do not need a large scope to practice. Even on a team with a narrow mandate, the product manager usually has more business context than anyone else. I can use that context to explain the why behind the work, not just the what. I can connect sprint planning to customer value. I can connect customer value to product strategy. I can connect product strategy to business outcomes.

    That habit compounds. The product manager who consistently creates clarity, communicates tradeoffs, and says no with evidence begins to operate like a leader before anyone changes their title. This is how the IC to manager transition becomes less of a leap and more of a visible progression.

    For me, the practical takeaway is clear: leadership is not something I wait to be granted. It is something I practice in increasingly larger circles of responsibility. I start with my team, my sprint, and my immediate stakeholders. Then I expand toward quarters, outcomes, strategy, and organizational alignment.

    If we want to grow into product management leadership, we need to stop treating leadership experience as something that only appears after promotion. The work is already available to us. We can study our organization’s definition of leadership, practice saying no well, build directional clarity, and use product roadmapping and discovery tools to communicate at the right level of abstraction. That is how we earn trust before the title arrives.

    Inspired by this post on Product Talk.

    Book a consult png image
  • Supercharge Product Discovery: A Practical July Guide to Better Team Ideation

    Supercharge Product Discovery: A Practical July Guide to Better Team Ideation

    Continuous Discovery Habits turned five this year, and I see that milestone as a useful reminder: great product teams do not discover customer value through occasional workshops. We build the habit of discovery through repeated practice, structured reflection, and honest conversations about what we are learning.

    This month, I am focusing on Chapter 8: Supercharged Ideation. For product leaders, product trios, and empowered product teams, this chapter is especially practical because it challenges one of the most persistent myths in product discovery: that traditional brainstorming is the best path to better ideas.

    In my own product management work, I have seen teams move too quickly from opportunity to solution. We often identify a real customer problem, feel the pressure to show momentum, and then rally around the first plausible idea. The problem is not that the first idea is always bad. The problem is that our first idea is rarely our best idea.

    This Month’s Reading

    Chapters:

    • Chapter 8: Supercharged Ideation

    Estimated reading time: ~18 minutes

    This chapter introduces several ideas that matter deeply for product discovery, prioritization, and product strategy:

    • Why quantity of ideas leads to quality – your first idea is rarely your best idea
    • The four reasons traditional brainstorming doesn’t work (and what to do instead)
    • How to generate 15-20 ideas for a single opportunity without getting stuck
    • Why individuals outperform groups at ideation – and how to get the best of both
    • Using dot-voting to whittle ideas down to three for a compare-and-contrast decision

    I find the compare-and-contrast framing particularly important. Too many product decisions are framed as whether or not decisions: should we build this, should we not build this, is this feature good, is this feature bad? A stronger product discovery process forces us to compare multiple viable paths before we commit.

    Why Supercharged Ideation Matters

    Supercharged ideation is not about being louder, more creative on command, or filling a whiteboard with random concepts. It is about creating enough solution diversity that the team can make a more informed choice. That distinction matters because product teams are not rewarded for having ideas; we are rewarded for solving customer problems in ways that support business outcomes.

    Traditional brainstorming often feels productive because everyone is in the same room and ideas are moving quickly. But group dynamics can quietly narrow the range of thinking. Senior voices carry more weight, early suggestions anchor the conversation, and quieter team members may never share the insight that could reshape the direction.

    The individual-then-share approach gives each person space to think before the group converges. I have found this especially useful with cross-functional product trios because design, engineering, and product often see different constraints and possibilities. When each discipline ideates independently first, the team gets a richer set of options.

    Reflect and Discuss What You Read

    When we reflect and discuss what we read, we absorb more of the material. It helps us put what we learn into practice. Don’t skip this step.

    This chapter challenges how most of us think about ideation. We’ve all been taught that brainstorming is the answer, but research tells a different story. This month, I am examining my own relationship with idea generation and where I may be falling into common traps.

    Individual Reflection

    1. Think about the last time your team generated ideas for a solution. Did you generate multiple ideas for one opportunity, or did you generate one idea per opportunity? What was the outcome?
    2. When you ideate, where do you get stuck? Is it after the first few obvious ideas? Do you struggle with wild ideas that feel unrealistic? Or do you find it hard to avoid jumping into evaluation mode too early?
    3. Be honest: Do you have a favorite idea right now that you’re pushing for? What assumptions are you making about why it’s the best option? Are you falling in love with your idea before testing it?

    That third question is the one I would push every product manager to answer honestly. Attachment to an idea can feel like conviction, but conviction without evidence can become a liability. Continuous discovery gives us a healthier path: generate multiple options, expose assumptions, and test before we over-invest.

    Team Discussion

    1. Walk through your team’s typical ideation process. Does it look more like traditional brainstorming (everyone sharing ideas out loud) or more like the individual-then-share approach the chapter recommends? What’s working and what isn’t?
    2. Pick one opportunity from your current tree. As a team, can you generate 15-20 ideas for how to address it? If you get stuck before reaching 15, use the chapter’s techniques: look at analogous products, consider extreme users, or think about wild ideas.
    3. Discuss: When you evaluate ideas as a team, do you tend to set up “whether or not” decisions (Is this idea good?) or “compare and contrast” decisions (Which of these ideas looks best?)? How might you shift to more compare-and-contrast decisions?

    Put It Into Practice

    The best way to learn supercharged ideation is to practice it with your team. These exercises help turn the concepts into a working product discovery habit rather than a theory we agree with but never operationalize.

    Book cover of Continuous Discovery Habits by Teresa Torres, shown at an angle for a July 2026 CDH Book Club reading guide
    A featured image of Teresa Torres' Continuous Discovery Habits, inviting Product Talk readers to join the July 2026 CDH Book Club and explore better product discovery practices together.

    Exercise: Generate 15-20 Ideas for One Opportunity

    Time: 45-60 minutes
    Do this: With your product trio (and consider inviting other team members for more diversity)

    Choose a target opportunity from your opportunity solution tree. Set a timer and go through this process:

    1. Individual ideation (5 minutes): Everyone generates ideas on their own. Aim for at least 7-10 ideas each. Write them down on sticky notes or in a shared doc.
    2. Share round one (15 minutes): Take turns sharing your ideas. No evaluation yet – just share and ask clarifying questions if needed.
    3. Individual ideation round two (5 minutes): Generate more ideas individually. The first round should have sparked new thinking. Push yourself to consider analogous products, extreme users, or wild ideas.
    4. Share round two (15 minutes): Share your new ideas with the group.
    5. Review and refine (10 minutes): Count your ideas. Did you reach 15-20? If not, do another quick round. Then, review the list together and remove any ideas that don’t actually address the target opportunity.

    After the exercise, I would ask the team to pause before evaluating the ideas. What did we learn? Were the later ideas more creative than the earlier ones? How did hearing others’ ideas spark new thinking? Those questions help the team understand not only which ideas emerged, but how the quality of thinking changed through the process.

    Exercise: Practice Dot-Voting

    Time: 20 minutes
    Do this: With your product trio

    Using the 15-20 ideas generated in the previous exercise, I would use dot-voting to narrow the field to three ideas:

    1. Set the criteria: Remind everyone that you’re voting based on how well each idea addresses the target opportunity – not on feasibility, not on how “cool” it is.
    2. Vote (5 minutes): Give each person three votes. You can put all three on one idea, split them across three ideas, or any combination.
    3. Review the results (10 minutes): Which ideas got the most votes? If it’s clear that three ideas stand out, you’re done. If several ideas have similar vote counts, take a few minutes for people to advocate for their top picks, then vote again.
    4. Check alignment (5 minutes): Once you have your top three, do a quick poll: Is everyone excited about at least one of these ideas? Does each idea have a strong advocate on the team?

    Save these three ideas – you’ll use them for assumption testing in Chapter 9.

    The discipline here is subtle but powerful. Dot-voting is not a popularity contest when it is used well. It is a lightweight mechanism for helping a product trio move from an overwhelming idea set to a manageable comparison set, while preserving enough variation to support real learning.

    Go Deeper: Additional Reading

    For teams that want to go deeper on product discovery, team creativity, and structured ideation, I would keep the following resources close. They are useful companions for product managers, designers, engineers, and leaders who want to build stronger discovery habits.

    Supplementary Reading

    • Stop Brainstorming and Generate Better Ideas
    • That’s Not Brainstorming
    • How to Turn Bad Ideas Into Good Ideas
    • Product in Practice: Getting Engineers Involved in Brainstorming

    Other Voices

    • On the Quest for Originality, Recombine the Familiar by Adam Alter
    • Creativity Is Not an Accident by Scott Berkun
    • A Data-Driven Approach to Group Creativity by Bastian Bergmann and Joe Schaeppi

    Live Discussion Schedule

    For teams following the July 2026 reading cadence, the live discussion schedule is:

    • Thursday, September 17, 2026: 9am-10am PDT and 4pm-5pm PDT
    • Wednesday, December 16, 2026: 9am-10am PST and 4pm-5pm PST

    My Product Leadership Takeaway

    My biggest takeaway from Chapter 8 is that better ideation requires both independence and collaboration. We need independent thinking to expand the solution space, and we need collaborative discussion to clarify, combine, and compare ideas. When we skip either side, the quality of our product decisions suffers.

    For me, this is where continuous discovery becomes a leadership practice, not just a team ritual. Leaders have to create the conditions where teams are not punished for exploring multiple options, questioning favorite ideas, or slowing down long enough to test assumptions. That is how product discovery becomes more than a process. It becomes a product culture.

    If I were applying this immediately with a product trio, I would choose one opportunity from the current opportunity solution tree, generate 15-20 ideas, dot-vote down to three, and carry those three into assumption testing. That simple sequence can turn a vague conversation about creativity into a concrete product management habit.

    Inspired by this post on Product Talk.

    Book a consult png image
  • Durable Product and Platform Leadership Beyond the Launch

    Durable Product and Platform Leadership Beyond the Launch

    A successful product can create momentum, but durable leadership determines whether that momentum becomes an enduring company or platform. The distinction is especially important for infrastructure businesses, where trust, scalability, and operating discipline must keep pace with adoption.

    Taken together, the two source articles suggest a practical leadership test: can an organization preserve customer value while strengthening the strategy, governance, and systems surrounding the product?

    Product strength can conceal organizational weakness

    Why Great Products Can Still Fail argues that product excellence is necessary but insufficient for company health. A compelling product may temporarily mask unclear strategy, weak accountability, poor tradeoffs, or an operating culture that values output more than outcomes. Adoption and market opportunity do not automatically prove that the organization can make sound decisions as it grows.

    This changes the leadership question. The issue is not simply whether teams can ship something customers value, but whether the company can repeatedly direct talent and capital toward the right problems. Product discovery, stakeholder management, roadmapping, and sprint planning become parts of a governance system: they connect customer evidence to decisions and expose assumptions before those assumptions harden into costly commitments.

    The article also emphasizes ethical decision-making and corporate governance. That perspective broadens product leadership beyond roadmap ownership. Leaders remain responsible for the organizational conditions under which a successful product is developed, sold, and extended.

    Durable platforms reduce uncertainty at every stage

    The Supabase article approaches durability through a developer-platform case study. It reports that Supabase started with an open-source PostgreSQL proposition intended to combine rapid application development with an architecture developers would not have to abandon as their needs became more serious. In that account, the platform’s value rests on fast setup, predictable building blocks, reliable documentation, sensible defaults, and a credible path to scale.

    Those qualities reveal a broader platform principle: durability is not the same as having the largest feature set. A durable platform lowers uncertainty. It helps customers understand what they are adopting, begin using it without unnecessary friction, and remain confident that early speed will not create an architectural trap later.

    The source attributes part of that confidence to Supabase’s alignment with PostgreSQL and its open-source approach. Community trust and commercial growth are presented as mutually reinforcing rather than competing motions. This complements the governance argument from the first article: trust is created when a company’s operating choices support the product promise, not merely when its marketing states that promise.

    Leadership durability comes from connected operating loops

    The Supabase account reports that founder Paul Copplestone’s earlier startup experiences contributed to an emphasis on finding product-market fit before blitzscaling and on separating fundraising from building. It also describes the company as operating with a constraint mindset even after raising capital. Read alongside the warning that strong products can disguise structural problems, the lesson is that available resources should not be mistaken for validated demand or organizational readiness.

    Positioning forms another operating loop. According to the Supabase article, a tagline change preceded the project reaching the top position on Hacker News and was treated as an early product-market-fit signal. The useful interpretation is not that wording alone establishes fit. It is that positioning can test whether the market recognizes the job a product performs. When the message and the customer problem align, feedback becomes clearer and acquisition friction may fall.

    Measurement must then distinguish genuine contribution from inherited momentum. The source reports that Supabase designed sales compensation around incremental uplift over a control group. In a product-led business, that approach asks whether sales created conversion or expansion beyond what self-service adoption would probably have generated. It places evidence above activity and limits the temptation to claim credit for demand already produced by the product.

    Organizational learning completes the system. The article describes a fully distributed, asynchronous team with near-zero attrition and connects its scaling philosophy to kaizen, or continuous improvement. Because these are claims from a single company-focused account rather than independently verified comparisons, they should be treated as reported characteristics. Their leadership relevance is still clear: asynchronous execution depends on strong writing and explicit ownership, while continuous improvement requires teams to identify and remove recurring friction.

    AI readiness should amplify a durable foundation

    The Supabase article reports three AI-related waves involving pgvector, Bolt and Lovable, and Claude Code. It presents these developments as successive ways in which retrieval, rapid application creation, and AI-native development workflows increased the relevance of an existing backend platform.

    The sequence matters because it separates readiness from trend chasing. The reported AI opportunities could compound platform value because the underlying customer need already existed: developers wanted to build quickly on a backend they could trust. AI changed workflows and urgency, but it did not replace the platform’s core value proposition.

    For leadership teams, this implies a disciplined filter for emerging technology. A new capability deserves investment when it strengthens an established customer job, improves the platform’s trusted primitives, or opens a coherent path for existing users. Technology excitement alone cannot resolve weak positioning, unclear ownership, or an unproven operating model.

    Key takeaways

    • Treat product success as evidence, not immunity. Adoption does not eliminate the need for governance, ethical judgment, and explicit accountability.
    • Design platforms around customer confidence. Fast onboarding, dependable primitives, clear documentation, and a credible scaling path matter together.
    • Preserve constraints after capital or demand arrives. Resources should follow validated customer value rather than substitute for it.
    • Measure incremental impact. Product-led and sales-led motions need a method for separating created lift from revenue that would have occurred anyway.
    • Use AI to extend a durable value proposition. Emerging workflows are most useful when they compound an existing platform advantage.

    Durable leadership is ultimately visible in what happens after early success: whether the organization converts attention into learning, learning into disciplined choices, and those choices into a platform customers can continue to trust.

    References

  • AI Product Leadership: Faster Learning, Safer Systems

    AI Product Leadership: Faster Learning, Safer Systems

    AI-enabled product leadership is not primarily a contest to automate more work. The stronger opportunity is to shorten learning loops while improving the quality, traceability, and safety of product decisions.

    Across the five source articles, a common operating model emerges: begin with bounded problems, connect AI to real customer evidence, define quality through domain expertise, and make safeguards proportional to the consequences of failure. This model applies both to internal product workflows and to customer-facing AI systems.

    Move from an AI tool stack to an evidence system

    The article on essential tools for product managers presents AI as a working layer across product intelligence, research, analytics, roadmapping, design, prioritization, and delivery. Its most useful implication is that tool selection should begin with the decision a team needs to improve, not with the number of AI features available.

    A feedback summarizer, behavioral analytics platform, prototyping assistant, and requirements generator can each save time. Their strategic value appears when their outputs are connected: qualitative feedback helps explain observed behavior, behavioral evidence tests assumptions raised in interviews, and both inform prioritization. The product manager still has to reconcile customer pain, business outcomes, engineering effort, differentiation, and stakeholder expectations.

    The practical guide to finding AI use cases reaches the same conclusion from a different direction. It recommends starting with a concrete item from everyday work, testing how AI might help, and studying the gap between the desired result and the output. It specifically proposes a 15-minute daily practice and treats an initially poor result as evidence about instructions, context, constraints, or model capability.

    Together, these perspectives suggest two complementary levels of adoption. At the individual level, task-first experimentation builds judgment about what AI can do. At the team level, connected evidence workflows turn that judgment into a repeatable product operating system. Buying tools without the first creates shallow adoption; isolated personal experiments without the second produce scattered efficiency rather than organizational learning.

    Use AI to deepen discovery, not to create distance from customers

    The 2026 roadmap article frames roadmaps as portfolios of experiments involving products, learning methods, teaching models, and choices about what to stop doing. It argues that AI can reduce tedious discovery work and provide feedback on demanding skills, including interviewing, assumption testing, and opportunity mapping. At the same time, it warns against substituting agents or dashboards for human curiosity and direct customer contact.

    That tension supplies an important boundary for AI-enabled discovery. Models can organize notes, identify recurring themes, critique an interview guide, expose possible confirmation bias, or compare evidence across sources. They cannot independently determine whether the team asked the right customers, understood the social context, or interpreted ambiguous language correctly. Those remain product and research judgments.

    The safety-first consent coach described in the Override Labs article illustrates why context matters. According to that account, the nonprofit examined 2,000 Reddit posts per subreddit to validate demand and understand how vulnerable questions were expressed. The discovery material included uncertainty, shame, peer pressure, and the possibility that someone might be seeking permission rather than reflection. A conventional feature request or decontextualized summary could have obscured those conditions.

    The cross-team review reinforces this point through other domains. It reports that former teachers at eSpark created evaluation rubrics based on how educators assess student work and enriched educational content with domain-specific metadata when generic embeddings produced weak matches. It also describes how local-government knowledge at Zencity changed the interpretation of sentiment, and how incident-response experience informed Incident.io’s investigation architecture. Across these examples, AI increased the importance of domain expertise because people still had to define what relevance, quality, and failure meant.

    Let the consequence of failure determine the product architecture

    Not every AI-assisted task needs the same controls. A weak draft of an internal stakeholder update can be reviewed and corrected cheaply. A response that could be interpreted as permission in a consent-related situation has a fundamentally different risk profile. Responsible product development begins by distinguishing those cases before selecting architecture or interaction patterns.

    The Override Labs account offers the clearest high-stakes pattern. The team reportedly defined a "South star" around the worst outcome: a teenager using the product response as a green light for harmful action. The product therefore avoids giving a green-flag verdict. It runs deterministic risk classification before calling Claude, adjusts responses by risk tier, and uses a structure that validates, reflects, and invites further reflection. A licensed therapist contributed to the evaluation rubric, while positive masculinity coaches helped shape the tone.

    The underlying principle is broader than that implementation. A generative model should operate inside a product-defined safety system rather than becoming the safety system. Product leaders can translate that principle into four design questions: what outcome must never be encouraged, which decisions require deterministic handling, when should generation be constrained or withheld, and which domain experts are qualified to judge the response?

    The review of AI product teams adds another trust boundary: deciding when a system should admit that it does not know. This is both a model-quality issue and a product behavior. Teams need to specify what insufficient evidence looks like, what the interface communicates in that state, and whether the user should retry, provide more context, consult a person, or stop the workflow.

    This risk-based approach avoids two unhelpful extremes. Applying high-stakes controls to every low-consequence drafting task can make experimentation needlessly heavy. Treating sensitive decisions like ordinary content generation can leave critical failure modes to probabilistic behavior. The appropriate control set follows the plausible harm, reversibility, affected population, and user’s ability to detect an error.

    Make evaluation, privacy, and leadership part of delivery

    The production-team review describes evaluation as an evolving operational capability rather than a final test. It reports that Stack Overflow ran about 50 experiments across five pods in three months, produced four versions of an AI-powered search product, and ultimately stopped that effort. Arize began building its Alyx agent before established agent frameworks were available, while eSpark’s former teachers learned to write evaluation code with LLM assistance. These are source-reported examples, not independently verified benchmarks, but they demonstrate how structured learning can support both shipping and stopping decisions.

    Evaluation should therefore start when the use case is defined. Early rubrics can be simple: representative tasks, expected properties, unacceptable outputs, and a review process. As the product matures, teams can add risk tiers, regression sets, production observations, and explicit release criteria. The goal is not to claim that a model is universally good; it is to establish whether a particular system performs acceptably within a bounded workflow.

    Privacy belongs in the same product definition. The consent-coach article reports that the service uses no accounts, cookies, or cross-session tracking. That choice limits conventional retention analytics, but it also supports the trust required for a sensitive interaction. It shows that less data can be a deliberate product feature when identification or surveillance would discourage honest use.

    Leadership determines whether these practices persist. The roadmap article argues that training alone does not change an organization when leaders continue to reward old behaviors. Its proposed learning model combines on-demand material, AI-generated feedback, coaching resources, and human support. The practical-use-case article similarly recommends peer demonstrations and structured practice. Both suggest that AI readiness is a management system: teams need permission to experiment, shared examples, quality standards, and leaders who reinforce evidence-based behavior.

    Key takeaways

    • Start with a bounded task and a defined outcome; use repeated practice to learn where AI adds leverage and where it fails.
    • Connect research, feedback, behavioral data, prioritization, and delivery so that AI improves decisions rather than producing isolated artifacts.
    • Keep direct customer contact and domain expertise at the center of discovery, synthesis, and quality judgment.
    • Define the worst credible outcome before designing a customer-facing AI experience, then match controls to that risk.
    • Build evaluation and privacy into the product operating model, including criteria for refusing, escalating, or admitting uncertainty.
    • Measure AI leadership by better learning and safer outcomes, not by tool count, output volume, or automation alone.

    Building the next product operating rhythm

    The next step for product organizations is not a universal AI playbook. It is a disciplined rhythm in which teams choose a real problem, gather contextual evidence, define acceptable and unacceptable behavior, test a bounded intervention, and revise or stop it based on results. As AI capabilities change, that rhythm can remain stable. It gives product leaders a way to pursue faster learning without treating speed as a substitute for responsibility.

    References

  • Designing Awe: Intentional, Sensory-Rich Experiences to Elevate Product Leadership

    Designing Awe: Intentional, Sensory-Rich Experiences to Elevate Product Leadership

    What makes an event truly unforgettable—and what can product teams learn from it? As I listened to an illuminating conversation about crafting experiences, I found myself reflecting on how the same principles translate directly to product strategy, continuous discovery, and the day-to-day work of product management leadership.

    Listen to this episode on: Spotify | Apple Podcasts

    In this episode, the conversation explores how Petra Wille and her co-organizer Arne design experiences (not just events) at Product at Heart and their Product Leadership gatherings. From a candlelit speakers' dinner in a rosemary-covered greenhouse to a disco ball that appeared for exactly 20 seconds, the details reveal how intentional design, sensory cues, and a little bit of goofy magic help people shed their corporate armor and open up to real inspiration and connection. The parallels back to product design are unmistakable—from designing for delight and awe, to the classic question of who you're choosing to serve.

    In my role leading product teams, I see how these choices map directly to empowered product teams and the rigor of product discovery: you can’t please everyone, so you design deliberately for the right someone. That means curating for depth over breadth, and giving people agency through self-select paths—much like the "Hard Problems Club"—so niche audiences feel seen within a broader experience. It’s the same discipline we apply to product strategy and value proposition: clarity about the segment, the problem, and the kind of transformation we’re creating.

    The programming choices here are also instructive. The team designed the Product at Heart Leadership Event across one and a half days, including a farm excursion and a leadership improv workshop. Those decisions weren’t ornamental; they were part of a deliberate journey that builds safety, curiosity, and connection—precisely the conditions that help leaders generate better ideas and have the real conversations that move work forward. In product, we build that journey through thoughtful onboarding, product tours, and progressive discovery.

    I was struck by the role of sensory experience in unlocking inspiration—rosemary, zucchinis-as-instruments, and a three-meter disco ball. Too often, we conflate more features with more value; in practice, well-placed sensory or interaction details do more to create delight than another settings panel ever will. The same is true in software: microinteractions, purposeful motion, and small moments of surprise can change how people feel about your product, which changes how they use it.

    What Petra calls "serendipity moments" resonated with me. Creating space for people to shed their corporate armor and make unexpected connections is as critical in community and conference networking as it is in a product’s information architecture. When we design pathways that invite contribution—opt-in tracks, intimate circles, and unstructured time—we invite the kind of learning and collaboration most teams say they want but rarely experience by accident.

    The reflections on the World Domination Summit and the idea of designing for awe added a useful distinction: the difference between novelty and awe. Novelty is pleasant but fleeting; awe takes people out of the mundane and expands what feels possible. In product terms, awe is the moment a user realizes a new capability not only solves a task but changes how they think about their work. That’s the bar I want my teams aiming for in our roadmapping and journey mapping.

    There’s also a pragmatic lesson in investment. The details that seem extravagant are often the ones that matter most—and not because they’re expensive, but because they’re intentional. A disco ball that appears for exactly 20 seconds signals care, timing, and narrative. In product, that’s the difference between a scattered backlog and a cohesive story: choosing the few standout moments that deliver meaning, not just motion.

    For product leaders, the translation is clear: define who you serve, design for choice and delight, and invest in the details that unlock connection and insight. Whether it’s a farm excursion and leadership improv or a carefully crafted advanced-user path, the goal is the same—create conditions for real breakthroughs and lasting behavior change.

    "If we can get through that armor and shut off the business reflexes, then inspiration is more likely to hit." — Petra Wille

    Resources & Links

    Follow Teresa Torres: https://ProductTalk.org

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

    Mentioned in this episode

    Strong Product People by Petra Wille

    Product at Heart — Speakers Dinner Leadership (see the rosemary garden!)

    Reflections on Product at Heart’s 2026 Leadership Event

    Arne Kittler of Product at Heart

    Product at Heart Conference — Hamburg 2026 (read about the Hard Problem Clubs)

    House of Beautiful Business — an event that inspired Petra and Arne's approach to sensory experience

    Petra’s recap for this year’s House of Beautiful Business in Tangier — Rituals, Rugs, and Radical Tenderness – My Experience at the House of Beautiful Business in Tangier

    World Domination Summit — founded by Chris Guillebeau; "How to live a remarkable life in a conventional world"

    Derek Sivers — mentioned as a spoken word contributor at experiential events

    Have thoughts on this episode? I’d love to hear your perspective in the comments—what “awe moments” are you intentionally designing for your teams and your users?

    Inspired by this post on Product Talk.

    Book a consult png image
  • Migrate Analytics Platforms Without Chaos: 7 Proven Lessons to Plan, Move, and Land Cleanly

    Migrate Analytics Platforms Without Chaos: 7 Proven Lessons to Plan, Move, and Land Cleanly

    I’ve led and rescued more analytics migrations than I can count, and I know the pressure: every event, dashboard, and decision pipeline depends on getting it right. Migrating analytics platforms doesn't have to be painful. Get seven lessons from Human37 and Amplitude to help your team plan, migrate, and land cleanly.

    Here’s how I approach this work so teams keep momentum, regain trust in their numbers, and accelerate product-led growth on a unified analytics platform—without the rework and stakeholder fatigue that typically follow.

    Lesson 1 — Start with outcomes, not events. Before moving a single event, I align leaders on the questions we must answer and the decisions we must speed up: activation, retention, and expansion. I map those goals to a simple driver tree, then back into the behavioral analytics we need. This trims noise, tightens scope, and ensures Amplitude analytics (or any destination) is instrumented for decisions, not vanity metrics.

    Lesson 2 — Audit and map your data with rigor. I inventory current events, properties, IDs, and sources, then define a target schema with clear naming conventions, ownership, and versioning. Data governance and privacy-by-design are non-negotiable: we separate PII, document consent paths, and remove legacy debris. This step prevents schema drift and makes platform scalability sustainable.

    Lesson 3 — De-risk the cutover with a phased plan. Rather than a big-bang switch, I dual-run critical flows, compare telemetry, and use feature flags to roll forward (and back) safely. Observability and anomaly detection are my guardrails: I monitor volume, cardinality, and event timeliness to spot regressions early—long before executives notice broken charts.

    Lesson 4 — Treat instrumentation like product code. I wire schema checks into CI/CD, enforce typed analytics wrappers, and validate payloads pre-merge. With docs-as-code, the tracking plan stays current and reviewable. This keeps quality high at scale and avoids the slow death of broken funnels caused by well-meaning quick fixes.

    Lesson 5 — Enable the people, not just the platform. Tools don’t create insight—teams do. I run hands-on enablement with product tours and in-app guides tailored to each role, establish communities of practice, and publish short playbooks for common questions (activation analysis, cohort retention, and journey mapping). When customer success and growth marketers can self-serve, adoption sticks.

    Lesson 6 — Land cleanly with fast, visible wins. Within the first two weeks post-cutover, I showcase analyses that matter: retention analysis by use-case, friction points via session replay and heatmaps, and conversion lift by segment. These quick proofs build confidence, reinforce the value proposition, and keep stakeholders engaged through the longer tail of hardening.

    Lesson 7 — Govern and evolve continuously. After go-live, I schedule schema reviews, backlog grooming, and QBRs to prune events and refine definitions. Ownership is explicit, and changes flow through the same review process as code. This keeps the unified analytics platform trustworthy as the product (and org) changes.

    I’ve seen this playbook turn skepticism into momentum. In one migration I inherited mid-flight, we refocused on decisions, tightened governance, and phased the rollout; the team moved from fire drills to confident launches—and stakeholders finally believed the numbers again.

    If your team is staring down a migration, anchor on outcomes, automate quality, and invest in enablement. With disciplined execution readiness and the lessons I’ve applied alongside partners like Human37 and platforms like Amplitude, you can move fast, reduce risk, and land cleanly—without the chaos.

    Inspired by this post on Amplitude – Perspectives.

    Book a consult png image
  • A Systematic Product Launch Strategy Beyond Announcement Day

    A Systematic Product Launch Strategy Beyond Announcement Day

    A product launch is most useful when treated as an operating system for adoption, not a communications deadline. The central challenge is to connect a technically credible product story with clear positioning, coordinated execution, and evidence that customers are reaching the intended outcomes.

    The supplied practitioner account from Shivam.Consulting Blog provides one perspective rather than a set of independently corroborated benchmarks. Its value lies in connecting solutions engineering, product marketing, partner coordination, and product analytics into a coherent launch model that teams can adapt to their own context.

    Launch strategy begins with a credible customer problem

    The source describes Darshil Gandhi as a Director of Product Marketing at Amplitude responsible for product and partner launches, with previous experience as a solutions engineering principal. It argues that this combination is valuable because solutions engineering develops customer intimacy and technical credibility, while product marketing adds segmentation, positioning, and narrative discipline.

    That career path points to a broader launch principle: positioning should not be created separately from the conditions in which customers evaluate and use the product. A technically accurate message can still fail if it does not identify a meaningful audience or outcome. A polished market narrative can likewise fail if sales teams cannot defend it, demonstrations do not substantiate it, or the product experience does not deliver on it.

    The practical unit of launch planning is therefore not the feature alone. It is the connection among a target customer, a recognizable problem, a product capability, and an observable outcome. That connection should shape the value proposition, demonstration, enablement materials, onboarding path, and success measures. When those elements describe different versions of the product, friction appears between initial interest and sustained use.

    Readiness requires one narrative across the organization

    The source recommends crisp ownership and recurring execution-readiness reviews. It also emphasizes alignment among product management, engineering, solutions engineering, sales, and partner teams around a shared narrative, demonstration story, and definition of readiness. This frames stakeholder management as part of the launch design rather than an administrative task performed near release.

    A useful readiness review should test whether the launch can survive contact with a customer. Product and engineering can confirm what the product does and where its boundaries lie. Solutions engineering can identify implementation questions, proof requirements, and likely objections. Product marketing can ensure that the message identifies a relevant audience and differentiates the offer without exceeding the evidence. Sales and customer-facing teams can verify whether the story is usable in real conversations.

    Clear ownership does not mean that one function performs every task. It means that decision rights are visible: who approves positioning, who verifies product claims, who owns enablement, who decides whether an unresolved issue blocks launch, and who monitors adoption afterward. Recurring reviews then become decision forums rather than status meetings. Their purpose is to expose contradictions early enough to correct the message, demonstration, onboarding, or product experience.

    Partner launches must reduce adoption risk

    Partner launches introduce a second organization, another audience, and additional dependencies. According to the source, effective co-marketing should extend beyond a feature announcement to include validated use cases, shared success measures, and coordinated enablement. This shifts the objective from maximizing announcement visibility to making the combined proposition easier to understand, evaluate, and adopt.

    A shared use case is particularly important because an integration can be technically functional without having an obvious customer purpose. The joint narrative should explain what the customer can accomplish through the combination, which part each product plays, and what conditions must be present for the experience to work. The joint demonstration should then show that same value path rather than presenting two adjacent product tours.

    Shared success measures also prevent each partner from declaring success against a different outcome. Attention may matter to marketing teams, while activation, repeated use, retention, or expansion may matter more to the business case. The appropriate measures will vary by product, but they should be agreed upon before launch and connected to a defined customer behavior. Partner enablement should use the same language and proof so that customers do not receive conflicting explanations from the two companies.

    Measurement turns launch activity into a learning loop

    The source advocates instrumenting execution with Amplitude analytics, defining activation, conducting retention analysis, and using A/B testing across important touchpoints to evaluate messaging. These are reported practices from the supplied account, not independently verified evidence that a particular tool or method will produce the same result in every organization.

    The larger strategic lesson is that launch measurement should follow the customer journey. Awareness metrics can show whether the market encountered the message, but they cannot establish whether the promise led to meaningful product use. Activation measures whether users reach an early behavior associated with value. Retention analysis examines whether that behavior continues. Experiments can help determine whether changes to messaging or onboarding improve a defined outcome, provided teams specify the hypothesis and success measure in advance.

    This creates a feedback path from behavior to strategy. If the intended audience engages with the message but does not activate, the break may lie in qualification, onboarding, product friction, or a mismatch between promise and experience. If users activate but do not return, the initial use case may lack durable value or require stronger enablement. If a message variant improves response without improving product behavior, the team has learned about attention rather than adoption.

    Measurement should therefore influence decisions after the release date. Teams can refine positioning when customer behavior challenges the original assumptions, improve onboarding where the value path breaks, and revise enablement when customer-facing teams repeatedly encounter the same confusion. The launch becomes repeatable when these lessons are preserved and applied to the next release rather than disappearing into a retrospective.

    Key takeaways

    • Build the launch around a target customer, a meaningful problem, a defensible capability, and an observable outcome.
    • Combine technical credibility with segmentation and positioning so that the promise is both persuasive and supportable.
    • Use readiness reviews to resolve contradictions across the narrative, demonstration, enablement, onboarding, and product experience.
    • Treat partner launches as joint adoption programs with a shared use case, coordinated enablement, and agreed success measures.
    • Connect awareness to activation and retention, then use behavioral evidence to improve the message and customer journey.

    The strongest launch capability compounds over time: each release improves the organization’s understanding of its customers, its cross-functional decision process, and its ability to translate product value into sustained behavior. The next launch should begin with the evidence and unresolved questions left by the last one.

    References

  • How I Use Novus, the First Product Agent, to Turn Rapid Releases into Measurable Wins

    In a world of relentless CI/CD and accelerating release trains, product leaders like me can’t afford lagging signals or fuzzy readouts on what’s truly moving the needle. I need immediate, trustworthy feedback that connects code shipped to outcomes achieved and customer value created.

    Coding agents compress weeks of development into hours, but the faster your codebase changes, the harder it is to know what’s actually helping end-users.

    That tension is exactly why I brought Novus into my product toolbox. To keep up with the pace of development, over 600 product teams are already using Novus, the first-of-its-kind product agent, to automatically set itself up, monitor product data, and tell you what to do next.

    From my chair, that promise matters only if it translates into clear decisions. With Novus, I’ve been able to tighten the loop between experimentation and learning: it pairs eval-driven development with behavioral analytics and observability so I can see how a release influences activation, engagement, and retention—without spelunking through fragmented dashboards. The agentic AI backbone reduces the manual stitching I used to do across events, cohorts, and funnels, letting me focus on prioritization and product strategy instead of report wrangling.

    Day to day, Novus fits naturally into our AI workflows. It surfaces anomalies early, clarifies trade-offs, and frames next-best actions in the language of outcomes. Because it plugs into a unified analytics platform approach, I can maintain continuous discovery at scale while preserving the rigor of Agent Analytics: hypotheses are explicit, telemetry is consistent, and results are traceable. That’s the operating cadence I expect from modern product management leadership.

    If your roadmap moves faster than your learning loops, a product agent can be the missing link between speed and certainty. Novus helps me convert rapid releases into measurable wins, keeping the team aligned and confident about what to build next—and just as importantly, what to stop doing.

    Inspired by this post on Pendo – Best Practices.

    Book a consult png image