Category: Product Management

  • 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

  • How to Choose a North Star Metric That Guides Product Teams

    How to Choose a North Star Metric That Guides Product Teams

    A North Star Metric should help a product organization recognize whether customers are receiving meaningful value. It is not simply the largest number on an executive dashboard or the metric that is easiest to improve.

    The supplied Amplitude – Perspectives material frames the subject as the difference between good and bad North Star Metrics, but it does not provide the underlying criteria or examples. The guidance below therefore applies established product management principles to that decision without attributing unsupported specifics to the source.

    The role of a North Star Metric

    A North Star Metric is a shared measure of the customer value a product delivers. Its purpose is alignment: product, design, engineering, marketing, and leadership should be able to use it when evaluating priorities and discussing progress.

    That makes it different from a financial target, a team-level key performance indicator, or a temporary campaign measure. Revenue and retention remain important business outcomes, but a North Star Metric usually sits closer to the customer behavior that creates those outcomes. It should clarify what valuable product use looks like without pretending that one number can describe the entire business.

    Key takeaways

    • A useful North Star Metric reflects customer value, not activity alone.
    • Teams must be able to influence it through product decisions.
    • The metric needs a precise definition, consistent data, and a meaningful time window.
    • Guardrail metrics are still necessary because optimizing one measure can create unintended effects.
    • A candidate that rewards volume without quality is a warning sign.

    What separates a strong metric from a weak one

    A strong candidate connects three ideas: customers experience value, the organization can influence the behavior, and the behavior is plausibly related to durable product success. The connection does not need to prove causation immediately, but the product team should be able to state the logic clearly and test it over time.

    The metric must also be operational. Everyone should understand what event qualifies, which users or accounts are counted, how often the measure is calculated, and how edge cases are handled. If two analysts can produce materially different answers from the same definition, the organization does not yet have a dependable North Star Metric.

    Finally, the measure should be sensitive enough to inform decisions without becoming noisy. A metric that changes mainly because of seasonality, acquisition spending, or data-pipeline behavior can distract teams from the product experience they are trying to improve.

    Why attractive metrics can still be misleading

    Weak North Star candidates often measure motion rather than value. Total registrations, page views, messages sent, or time spent may rise even when users fail to accomplish their goals. Such measures can still be useful diagnostic indicators, but naming them as the North Star may encourage teams to maximize quantity at the expense of relevance, quality, or trust.

    Lagging financial outcomes present a different problem. Revenue is essential to company health, yet it may not tell a product team which customer experience to improve next. It can also move because of pricing, sales execution, or market conditions. A metric becomes more actionable when teams can trace it through a driver tree to product behaviors they can investigate and influence.

    A practical selection and validation process

    The selection process should begin with the product’s value proposition: what meaningful result is the customer trying to achieve? Teams can then identify observable behaviors that indicate that result occurred, compare candidate measures against historical retention or continued use, and document the assumptions connecting behavior to value.

    Before adoption, the proposed metric should be tested against uncomfortable scenarios. Could it rise while customer outcomes deteriorate? Could a team inflate it through repeated low-value actions? Does it exclude an important user group or business model? These questions expose incentives that a polished metric name can conceal.

    Once selected, the North Star should be paired with guardrails such as quality, reliability, satisfaction, retention, or risk measures appropriate to the product. It should also be reviewed when the strategy, customer base, or value proposition changes. The goal is not to preserve a metric forever; it is to maintain a credible link between product decisions and customer value.

    A well-chosen North Star creates a useful constraint for decision-making. The next step is to define the candidate precisely, challenge the incentives it creates, and confirm that teams can connect their work to its movement without losing sight of broader product health.

    Inspired by this post on Amplitude – Perspectives.

    Book a consult png image
  • How Cohort Retention Analysis Turns Churn Into Action

    How Cohort Retention Analysis Turns Churn Into Action

    A falling retention rate tells a product team that customers are leaving, but it does not reveal which customers are struggling or what changed in their experience. Cohort retention analysis makes that broad signal more useful by comparing groups of users over time.

    This article explains how to define meaningful cohorts, interpret their retention patterns, and turn the findings into product decisions without mistaking correlation for proof.

    Why aggregate retention can hide the real problem

    An overall retention metric blends together customers who may have joined under different conditions, adopted different workflows, or encountered different versions of a product. That average can remain steady even when one segment improves and another deteriorates.

    Cohort analysis separates users according to a shared characteristic or experience and then examines their behavior. A team might group customers by signup period, acquisition path, initial use case, plan, or completion of an activation event. These are analytical choices rather than universally correct definitions. The useful cohort is the one tied to a decision the team can make.

    Amplitude – Perspectives describes cohort analysis as a way to answer how a particular user group has interacted with, or may interact with, a product. Its central value is diagnostic: behavioral data becomes easier to interpret when teams stop treating the customer base as one uniform population.

    Start with a decision, not a dashboard

    A productive analysis begins with a focused question. For example, a product team may want to know whether customers who reach an important workflow retain better than those who do not, or whether users acquired after a product change behave differently from earlier users.

    The team then needs a consistent starting event, a meaningful return event, and an observation window. The starting event establishes when users enter the cohort. The return event represents continued value, so it should reflect genuine product use rather than an incidental action. The observation window must be long enough to match the product’s normal usage rhythm.

    This framing prevents a common analytical failure: generating many segment comparisons without knowing which result would change a roadmap, onboarding flow, lifecycle message, or customer-success intervention.

    Key takeaways for product teams

    • Cohorts expose differences that a blended retention average can conceal.
    • A useful cohort shares a characteristic connected to a product or go-to-market decision.
    • Retention should be based on a return behavior that represents recurring customer value.
    • A cohort pattern identifies where to investigate; it does not establish why the pattern occurred.
    • The analysis becomes valuable only when it leads to a test, intervention, or sharper research question.

    Read cohort patterns without overclaiming

    If one cohort retains better than another, the difference is evidence of an association, not automatically a causal relationship. Customers who adopt a particular feature may retain because that feature creates value, but they may also have arrived with greater intent, more suitable use cases, or stronger implementation support.

    Product teams should therefore use cohort findings to narrow the search for an explanation. Behavioral analysis can be paired with customer interviews, support themes, journey mapping, or a controlled experiment when one is practical. Teams should also check whether cohort definitions, tracking changes, seasonality, or incomplete observation periods could be distorting the comparison.

    Small or highly specific cohorts deserve additional caution. Their apparent movement may reflect a few customers rather than a repeatable product pattern. The goal is not to find the most dramatic chart; it is to identify a credible signal that can guide the next decision.

    Turn the analysis into a retention loop

    Once a meaningful difference appears, the team can identify the experience that separates stronger and weaker cohorts, form a hypothesis, and choose an intervention. Depending on the problem, that intervention might involve onboarding, in-product guidance, product reliability, customer education, or the sequence in which value is introduced.

    The source frames retention as a high-return product priority and cites Bain & Company research indicating that a 5% increase in retention can raise profits by 25% to 95%. That reported range should not be treated as a forecast for every business, but it explains why teams pay close attention to improvements in customer longevity.

    Cohort analysis is most useful as a recurring operating practice: define the question, compare relevant groups, investigate the difference, make a change, and observe subsequent cohorts. Used this way, retention reporting becomes less of a backward-looking scorecard and more of a disciplined method for improving the customer experience.

    Inspired by this post on Amplitude – Perspectives.

    Book a consult png image
  • Feature Management as a Product Development Discipline

    Feature Management as a Product Development Discipline

    Feature management gives product teams a controlled way to decide how new capabilities reach users after the underlying code has been deployed. This separation can make releases more gradual, observable, and reversible.

    Amplitude – Perspectives presents feature management as a contributor to innovative product development and introduces the topic through insights from guest Chris Condo, identified by the publication as a Forrester Principal Analyst. Because the available source is only a brief summary, the practical guidance below explains the established discipline without attributing unreported claims to Condo or the publication.

    Feature management extends beyond feature flags

    A feature flag is a technical mechanism that can turn behavior on or off without requiring a fresh deployment. Feature management is the broader operating practice around that mechanism: defining the intended audience, controlling exposure, observing results, assigning ownership, and deciding whether to expand, revise, or remove a feature.

    The distinction matters because a flag alone does not create a sound product decision. Teams still need an explicit hypothesis, release criteria, relevant evidence, and a person accountable for the outcome. Without those elements, flags can become permanent switches that add complexity while providing little learning value.

    Controlled exposure changes the release decision

    A conventional launch can bundle several decisions into one moment: deploy the code, make it available to everyone, announce it, and accept the operational consequences. Feature management allows teams to separate those decisions. Code may be deployed while access remains limited, then exposure can expand as confidence grows.

    Common approaches include enabling a capability for internal users, a defined customer segment, or a limited share of eligible traffic. The appropriate sequence depends on the feature’s risk, the quality of available signals, and the team’s ability to respond when something goes wrong. A narrow rollout is useful only when the organization is prepared to monitor it and act on what it learns.

    Key takeaways for product teams

    • Define the customer problem and expected outcome before configuring a rollout.
    • Treat deployment, release, and promotion as related but separate decisions.
    • Set expansion, pause, and rollback criteria before exposing the feature.
    • Combine behavioral evidence with customer feedback and operational signals.
    • Assign an owner and a removal date for every temporary flag.

    A practical operating loop

    Feature management works best as a repeatable decision loop rather than a collection of launch-day controls. A lightweight process can keep product, engineering, design, data, and go-to-market participants aligned:

    1. Frame the decision. State what the team expects to improve and which users should benefit.
    2. Choose the exposure plan. Identify eligible users, exclusions, rollout stages, and safeguards.
    3. Prepare observation. Confirm that product, reliability, and support signals can reveal both value and harm.
    4. Review the evidence. Decide whether to expand access, hold the rollout, change the experience, or withdraw it.
    5. Close the loop. Remove obsolete flags, document the decision, and carry the learning into future product work.

    This process should remain proportional to the risk. A minor interface adjustment may need little ceremony, while a change affecting permissions, billing, privacy, or a critical workflow warrants stronger controls and broader review.

    The discipline has costs as well as benefits

    Controlled releases can reduce exposure to problems and improve learning, but they also create operational obligations. Multiple feature states increase testing demands. Targeting rules can make customer support harder when users see different experiences. Long-lived flags can complicate the codebase, and poorly designed experiments can produce misleading signals.

    Governance therefore belongs inside the practice, not around it. Teams need naming conventions, access controls, auditability, flag inventories, cleanup expectations, and clear decision rights. Product leaders should also distinguish experimentation from risk control: a rollout designed to detect failures is not automatically a valid test of customer value.

    The most useful next step is modest: select one meaningful upcoming release, define its exposure and decision criteria in advance, and use the resulting evidence to refine a repeatable feature-management approach.

    Inspired by this post on Amplitude – Perspectives.

    Book a consult png image
  • A Practical Framework for Measuring New Feature Success

    A Practical Framework for Measuring New Feature Success

    A feature is not successful merely because it shipped. Its value depends on whether the intended users encounter it, adopt it, gain a better experience, and produce an outcome that matters to the product or business.

    The brief from Amplitude – Best Practices frames this challenge through three questions: Are people using the feature? Is it improving the user experience? Is it affecting the company’s bottom line? Because the supplied source does not provide its promised seven-step method, the framework below uses those questions as a starting point and applies established product measurement principles without attributing unsupported details to the source.

    Start with the decision, not the dashboard

    Before selecting metrics, the product team should identify the decision that the evidence will inform. The question might be whether to expand the rollout, improve discoverability, revise the interaction, continue investing, or reconsider the feature altogether.

    This decision-first approach prevents a common measurement problem: collecting large volumes of activity data without knowing what result would change the roadmap. A useful success definition names the target user, the behavior expected to change, the intended user benefit, and the product or business outcome that benefit should support. It should also specify a reasonable evaluation window without treating an arbitrary deadline as proof of success or failure.

    Build the measurement chain before release

    Feature measurement works best as a connected chain rather than a single headline metric. The chain begins with eligibility: which users could reasonably benefit from the feature? It then tracks exposure, meaningful use, repeated use where appropriate, and a downstream outcome.

    That distinction matters because an eligible user who never sees a feature represents a different problem from a user who sees it and declines to engage. Likewise, an initial click is not necessarily evidence that the feature delivered value. The analytics plan should define events consistently, distinguish accidental interaction from meaningful completion, and preserve enough context to compare relevant user groups.

    Teams should also record a baseline when one is available. If the feature is intended to improve an existing workflow, measuring the old experience creates a reference point. Feature flags or controlled experiments can strengthen the comparison, but they do not replace a clear hypothesis or reliable instrumentation.

    Read adoption, experience, and outcomes separately

    Adoption shows reach and relevance

    Adoption analysis asks how many eligible users discovered the feature, how many completed its meaningful action, and whether use continued when repetition is part of the value proposition. Weak adoption can indicate poor discoverability, limited relevance, unclear positioning, or friction in the first-use experience. Analytics can reveal where behavior changes, but qualitative research is often needed to explain why.

    Experience measures whether use was worthwhile

    Usage alone cannot establish that the experience improved. The team should examine the outcome the feature was designed to influence, such as completing a task with less friction, reaching a useful result, or avoiding an undesirable path. Relevant guardrails should also be monitored so that a gain in one area does not conceal deterioration elsewhere.

    Business impact requires a credible connection

    The source explicitly raises the question of bottom-line impact, but the supplied material reports no result or measurement method. In practice, a product team should state the expected causal path instead of assuming that feature use automatically creates commercial value. A business metric may sit downstream of several influences, so correlation should be treated as a signal to investigate rather than conclusive proof.

    Key takeaways

    • Define the product decision that measurement will support before choosing metrics.
    • Separate eligibility, exposure, meaningful adoption, repeat behavior, and downstream outcomes.
    • Evaluate user benefit independently from raw activity or click volume.
    • Use baselines, comparison groups, and guardrails where the product context permits.
    • Combine behavioral evidence with qualitative research before assigning a cause.

    Turn the evidence into a product decision

    The final review should distinguish among several possibilities: the feature creates value and merits expansion; the concept is useful but its discovery or execution needs work; the evidence is inconclusive; or the expected outcome is not materializing. Writing down that judgment, its supporting evidence, and the next test makes measurement part of product management rather than a post-launch reporting exercise.

    A disciplined team does not wait for a dashboard to declare victory. It defines what success would change, gathers evidence suited to that decision, and uses the result to make the next investment more deliberate.

    Inspired by this post on Amplitude – Best Practices.

    Book a consult png image
  • A Practical Framework for Choosing Product Management Tools

    A Practical Framework for Choosing Product Management Tools

    Product management tools can reduce coordination work, preserve decisions, and help teams turn customer and product signals into action. Choosing them well, however, requires more than comparing feature lists.

    The supplied Amplitude – Perspectives excerpt defines these tools broadly as platforms, websites, and software that make a product manager’s job easier. Because the excerpt does not include the product names, evaluations, senior-PM advice, or supporting details promised by its headline, the framework below does not attempt to reconstruct that missing list.

    What belongs in a product management tool stack

    A product management stack is the collection of systems used to support recurring product work. Depending on the organization, that work may include collecting customer evidence, analyzing behavior, defining priorities, documenting decisions, planning delivery, running experiments, and communicating progress.

    The important distinction is between owning software and enabling a workflow. A tool creates value when it makes a necessary activity clearer, faster, more reliable, or easier to share. If it merely duplicates an existing system, it can add another place to search, update, and reconcile.

    Key takeaways

    • Start with the product workflow and its friction points, not a catalog of vendors.
    • Evaluate adoption, integration, governance, and decision quality alongside features.
    • Give each system a clear purpose and a defined owner.
    • Reassess tools when the team, product, or operating model changes.

    Begin with the decision the team needs to improve

    A useful selection process begins by naming a specific decision or handoff that is not working. The problem might be scattered customer feedback, weak visibility into user behavior, inconsistent prioritization, unclear ownership, or roadmap updates that require repeated manual effort.

    From there, the team can define what better performance looks like in general terms: less duplicate entry, a more dependable record of decisions, easier access to evidence, or clearer communication between product, design, engineering, and go-to-market groups. This keeps procurement tied to an operating need rather than enthusiasm for a new interface.

    It also clarifies whether software is actually the answer. Some problems come from missing ownership, inconsistent terminology, or an undefined process. Adding a platform to that environment may formalize the confusion instead of resolving it.

    Assess the full cost of fit

    Functional coverage matters, but it is only one part of fit. A team should also consider how naturally a candidate tool enters existing work, which systems it must exchange information with, how permissions will be managed, and what effort will be required to maintain trustworthy data.

    Adoption deserves particular attention. A sophisticated platform offers little practical value if contributors avoid it or if stakeholders cannot understand its outputs. A narrower tool that supports a well-defined workflow may outperform a broader suite that demands extensive configuration and behavior change.

    The evaluation should therefore test real work rather than an idealized demonstration. Representative users can walk through a normal task, identify where information enters the system, and examine how the resulting decision reaches everyone who depends on it. That exercise reveals workflow gaps that a feature checklist may miss.

    Control tool sprawl with ownership and review

    Every adopted system should have a stated job, an accountable owner, and a clear relationship to the team’s source-of-truth systems. Those boundaries reduce the risk that roadmaps, customer insights, and delivery status drift into conflicting versions across multiple platforms.

    Periodic review can then focus on outcomes: whether the tool is used, whether its information remains credible, whether it supports better decisions, and whether another system now covers the same need. The goal is not the largest possible stack. It is a coherent product operating environment in which each tool continues to earn its place.

    Inspired by this post on Amplitude – Perspectives.

    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

  • How Snapbar Turned Crisis Into an AI-Native Photo Experience Revolution

    How Snapbar Turned Crisis Into an AI-Native Photo Experience Revolution

    What does it take to reinvent a 14-year-old company, not once, but twice? I ask that question often when I look at mature product organizations, because the hardest transformations rarely start with a clean slate. They start with real customers, legacy expectations, operational muscle memory, and a market that suddenly refuses to behave the way it used to.

    Snapbar is a useful case study in that kind of transformation. The company began as a wedding photo booth side hustle, grew into a national events company, and then watched COVID wipe out the entire business overnight. As a product leader, I find that moment especially important because it separates teams that are attached to the current expression of their product from teams that understand the deeper customer need underneath it.

    The deeper need was never just a physical photo booth. It was identity, participation, memory, brand engagement, and a shareable experience that people could take with them. When in-person events disappeared, Snapbar went from physical photo booths to a cross-platform virtual product built on WebRTC in spring 2020. That was not a cosmetic pivot. It was a first-principles rebuild under pressure.

    I have seen many teams talk about innovation when conditions are favorable. Snapbar’s story is more interesting because the team had to innovate when the existing business model was unavailable. That kind of constraint can be clarifying. It forces product teams to ask: What job are we really doing for customers, and what parts of our current solution are merely historical artifacts?

    The next reinvention came from generative AI. Pushed by declining repeat business, Snapbar dove deep into Stable Diffusion, custom LoRA fine-tunes on H100/H200 GPUs, and eventually a reasoning-model-powered generative image and video pipeline. What stands out to me is not simply that the team adopted gen ai. It is that they connected AI capabilities to a domain they already understood deeply: photography, events, brand activations, and experiential marketing.

    This distinction matters. In product management, technology FOMO can lead teams to bolt AI onto workflows without a clear strategic advantage. Snapbar appears to have moved differently. They used 14 years of industry knowledge to identify where AI could change the experience itself, not just automate a back-office task or generate a novelty output.

    The product evolution is a strong example of applied AI. Snapbar integrated Stable Diffusion 1.5 as their first generative AI model and ran custom LoRA fine-tunes on H100/H200 GPUs to produce brand-quality outputs nobody else in their space could match. That level of execution shows the difference between experimenting with a model and building a differentiated product system around it.

    I also appreciate the way the team moved from negative prompts to reasoning model long-form prompts. In brand environments, creative control and safety control are not optional. A brand activation must feel imaginative, but it also has to remain on-message, inclusive, and predictable enough for a live event setting. Better prompt engineering becomes part of the product’s trust layer.

    One of the most important product details is the meta-prompting pre-processing pipeline designed to ensure user likenesses, including non-obvious details like disabilities, are accurately represented in generated images. That is not a minor implementation detail. It reflects a more mature view of AI risk management, representation, and customer experience.

    From my perspective, this is where product strategy and ethical technology intersect. Generative AI systems can easily flatten people into generic outputs. A thoughtful product team has to decide what fidelity means, what consent means, and how much control users and brands should have over the final artifact. Snapbar’s approach suggests that representation is not just a model-quality problem; it is a product-design problem.

    Podcast cover art for Just Now Possible with Teresa Torres, featuring bold white and yellow text on a navy background and Snapbar AI photo booth branding.
    Just Now Possible spotlights Snapbar’s journey from photo booths to AI-powered brand experiences, framing reinvention, creativity, and applied AI as the center of the conversation.

    The company’s experiential marketing platform lets brands “world build” at conferences, trade shows, and live events by bringing fans into branded creative worlds. That phrase matters because it reframes the photo booth from a capture device into a participatory brand system. The user is not merely photographed. The user becomes part of a designed world.

    I see this as a broader shift in product experience. Static brand impressions are giving way to co-created moments. Snapbar added participatory user inputs through Mad Lib-style prompts and prompt injection, turning photo experiences into co-creation moments between brands and their audiences. That is a more durable engagement loop than simply asking someone to pose in front of a branded backdrop.

    The operational story is just as relevant for product and engineering leaders. Snapbar used Claude Code and Codex to build and ship features rapidly as a small bootstrap team, and developed a four-pillar agent orchestration framework: context, tools, verification, and workflows. I like that framing because it treats AI-assisted development as a system of work, not a magic shortcut.

    In my own product leadership work, I keep coming back to the same lesson: AI workflows only become reliable when the team defines the surrounding operating model. Context determines whether the agent understands the problem. Tools determine what it can actually do. Verification determines whether the output is trustworthy. Workflows determine whether the capability compounds across the organization.

    Snapbar is now building customer-facing “vibe coding” using the Claude Agent SDK so brands can configure and create experiences themselves within Snapbar’s platform. That is a meaningful product move. It shifts creation closer to the customer while keeping the workflow inside a controlled product environment. For brand teams, that could reduce dependency on custom service work while still preserving creative flexibility.

    This is the kind of AI Strategy I find most compelling: not a generic claim that AI will transform everything, but a specific path from domain expertise to product capability to customer empowerment. Snapbar did not abandon its past. It converted years of event, photography, and brand knowledge into a new interface for generative AI.

    The core lesson for product teams is clear. Reinvention does not always mean discarding the original business. Sometimes it means identifying the durable customer need, rebuilding the delivery mechanism, and then using new technology to expand what the experience can become. Snapbar’s journey from wedding photo booths to virtual WebRTC experiences to AI world building shows how a team can preserve its market intuition while changing nearly everything about the product surface.

    For product leaders evaluating gen ai opportunities, I would take three practical lessons from this story. First, start with the customer experience, not the model. Second, treat brand safety, representation, and verification as product requirements from the beginning. Third, use agentic AI internally only when the team has a clear framework for context, tools, verification, and workflows.

    Snapbar’s story resonates because it is not about chasing a trend. It is about a team using necessity, curiosity-led self-education, and disciplined product thinking to build something that feels native to the generative AI era. That is the difference between adopting AI and becoming AI-native.

    Inspired by this post on Product Talk.

    Book a consult png image
  • 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
  • From Static Scores to Adaptive Customer Health Intelligence

    From Static Scores to Adaptive Customer Health Intelligence

    Customer health should help a team change an account outcome, not merely describe it after the fact. That requires moving beyond a fixed score toward intelligence that detects meaningful changes, explains their likely significance, and supports timely intervention.

    The supplied source frames this transition as a response to changing product usage, buyer behavior, and support patterns. Its larger implication is operational: customer health becomes a continuously examined hypothesis about adoption, value, risk, and expansion rather than a permanent formula embedded in a dashboard.

    Static health fails when its assumptions stop matching the account

    A conventional health score usually compresses several indicators into one status or number. This can make a portfolio easier to scan, but the simplicity conceals a critical dependency: the result is only as useful as the rules, weights, thresholds, and data behind it.

    The source argues that those assumptions gradually diverge from reality as customer behavior and product usage change. A score may retain the appearance of precision even when it reflects an earlier version of the product, customer journey, or commercial relationship. The resulting problem is not simply stale data. It is model drift: the organization continues interpreting current accounts through assumptions that may no longer describe them.

    This limitation becomes especially consequential when customer success teams are expected to protect Net Recurring Revenue (NRR) and improve retention analysis. A delayed score may confirm that adoption has weakened or support pressure has increased, yet arrive too late to influence the underlying outcome. Portfolio visibility is useful, but retrospective classification alone does not provide the cause, urgency, or appropriate response.

    Adaptive intelligence connects signals, interpretation, and action

    Adaptive customer health is better understood as a system than as a more sophisticated score. The source identifies behavioral analytics, anomaly detection, journey mapping, AI workflows, and risk scoring as capabilities that can reveal movement before a formal review or escalation makes it obvious. It also calls for a connected view spanning onboarding, adoption, support activity, value realization, and expansion potential.

    Those elements perform different jobs. Behavioral analytics describes how engagement is changing. Anomaly detection calls attention to departures from an account’s expected pattern. Journey mapping places activity within a stage or intended path. Risk scoring estimates the significance of the combined evidence. Workflow then routes that interpretation to a person or process capable of acting on it.

    The distinction matters because faster calculation is not necessarily adaptation. A fixed formula refreshed in real time can still reproduce obsolete assumptions. A genuinely adaptive approach must re-examine which changes are meaningful, compare signals in context, and make its reasoning visible enough for a team to judge. The useful output is therefore not just a revised number, but an intelligible account narrative: what changed, why it may matter, how urgent it appears, and what action deserves consideration.

    Product and customer success need one behavioral model

    The source positions product management and customer success as parts of the same operating system. That connection is essential because many health signals originate in the product, while their meaning often depends on commercial and relationship context. Product data can show a change in activation or adoption; customer success can add knowledge about expected value, organizational priorities, stakeholder changes, and renewal conversations.

    Neither perspective is sufficient by itself. A decline in activity can be concerning, expected, or irrelevant depending on the customer’s journey and intended outcomes. Conversely, positive usage can coexist with unresolved support friction or weak value recognition. Combining product behavior with support and relationship context reduces the risk that one visible metric becomes a misleading proxy for the entire account.

    This shared model also creates a feedback loop. Customer success teams can identify alerts that were useful, noisy, or missing important context. Product teams can use recurring patterns to examine onboarding, activation, and adoption barriers. The health system then becomes more than an account-ranking mechanism: it becomes a structured way to learn how product experience and customer outcomes interact.

    Key takeaways

    • A health score is only reliable while its underlying assumptions continue to reflect customer behavior and the product experience.
    • Adaptive health combines signals across onboarding, adoption, support, value realization, and expansion rather than treating one metric as the complete account story.
    • Anomaly detection and behavioral analytics become operationally useful when they are connected to context, urgency, and workflow.
    • Product management supplies behavioral and journey insight, while customer success contributes relationship and outcome context.
    • The practical test is whether the system helps a team choose an appropriate action while the account outcome remains changeable.

    Accountable action matters more than algorithmic complexity

    The source does not argue for removing human judgment. It explicitly retains a role for experienced customer success managers, executive conversations, and disciplined business reviews, while proposing that these activities should be informed by timely signals rather than retrospective summaries. This establishes a useful boundary: intelligence should augment account judgment, not disguise uncertain inferences as facts.

    That boundary has design implications. Teams need to know which evidence triggered an alert, whether the evidence is complete, and how strongly it supports the proposed interpretation. They also need a way to record what action was taken and whether it helped. Without that feedback, an AI-assisted workflow can scale noise as easily as insight.

    Evaluation should consequently focus on decision quality rather than dashboard sophistication. A useful system should help distinguish meaningful change from ordinary variation, reveal the factors behind a risk assessment, place the account within its journey, and connect the finding to an accountable next step. Its models and thresholds should also be reviewed as products, customer behavior, and business priorities evolve.

    The next stage of customer health intelligence will be defined less by a universal score than by an organization’s ability to learn from changing behavior. Teams that preserve explainability, human review, and workflow accountability can make adaptation practical without mistaking automated confidence for customer understanding.

    References