Category: Product Management Leadership

  • Our Operating Model Is the Product—Why We Built Product Partners to Accelerate Outcomes

    Our Operating Model Is the Product—Why We Built Product Partners to Accelerate Outcomes

    I’ve learned that customers don’t just buy features—they buy the way we discover, decide, build, ship, and support. In other words, the operating model is the product. That realization has shaped how my team and I at HighLevel translate product strategy into tangible, repeatable outcomes that show up in quality, reliability, onboarding, and consultative support every single day.

    We created Product Partners to codify that operating model and scale it with discipline. It’s a blueprint and operating rhythm that unifies product strategy with go-to-market strategy, customer success, and solutions engineering—so empowered product teams can move faster without sacrificing clarity, governance, or customer trust.

    First, we anchored on continuous discovery. Product trios work shoulder-to-shoulder with customer-facing teams to run customer interviews, journey mapping, and A/B testing, then validate insights with session replay and behavioral analytics. We use driver trees and opportunity solution trees to connect problems to outcomes, ensuring prioritization is evidence-based and aligned to product-market fit—not just output.

    Second, we elevated delivery excellence. Our practices emphasize CI/CD, feature flags, observability, SRE-informed incident management, and DORA metrics to shorten feedback loops while raising the bar on stability. Privacy-by-design, data governance, and regulatory compliance are built into our workflows, and we make deliberate build vs buy decisions to protect platform scalability and long-term velocity.

    Third, we integrated go-to-market alignment from day one. Solutions engineering and customer success shape requirements early, so launches include in-app guides, product tours, onboarding paths, and consultative support that accelerate user activation. We tie outcomes vs output OKRs to stakeholder management rituals, ensuring sales-led and product-led growth motions reinforce each other instead of competing for focus.

    Finally, we closed the loop with a unified analytics platform. Activation, retention analysis, and Net Recurring Revenue (NRR) sit alongside qualitative signals from customer interviews and support. This single source of truth helps us refine product positioning, sharpen value propositions, and improve roadmapping and sprint planning with clear, testable hypotheses.

    What does this mean for our partners and customers? Faster time-to-value, fewer handoffs, clearer expectations, and a shared lens on the metrics that matter. Product Partners isn’t a side program; it’s how we operationalize trust—through transparency, consistent rituals, and a bias toward learning that compounds.

    If this resonates, you’ll feel it in how we discover, build, and support together. I’ll continue to share our playbooks—covering continuous discovery, onboarding, and outcome-based planning—so we can keep raising the standard for product management leadership and product-led growth, one operating rhythm at a time.

    Inspired by this post on Product School.

    Book a consult png image
  • Figma’s Executive Scaling Playbook for IPO Readiness

    Figma’s Executive Scaling Playbook for IPO Readiness

    If your company may pursue an IPO, the tempting move is to wait until the filing window is visible, then recruit executives who have done it before. That sequence solves for credentials. It does not necessarily build the decision system the business will need.

    Figma took a different path. An operator who joined when the company had about 30 people and was not yet charging for its product grew into the CFO role, while the company adopted public-company habits years before its 2025 IPO. The useful lesson for you is not simply to promote insiders. It is to develop executive judgment, operating cadence, and economic instrumentation as one connected system.

    Key takeaways: the playbook on one page

    • Expand a leader’s decision scope before expanding the title. Look for progression from doing the work, to framing the questions, to allocating resources, to improving decisions across the company.
    • Install public-company behaviors before the transaction demands them. Figma began operating this way three years before its IPO, using quarterly rhythms, tighter controls, a close that could withstand scrutiny, and a coherent forward-looking narrative.
    • Treat product, finance, and go-to-market as joint owners of the economic model. They need the same driver tree, definitions, telemetry, and assumptions before they debate pricing or investment.
    • Manage AI investment as a portfolio of explicit bets. Usage, customer value, cost-to-serve, decision triggers, and risks should be visible even when the underlying economics are changing quickly.
    • Use leadership transitions to redraw decision rights. Replacing a departing executive without reconsidering the operating model preserves yesterday’s bottlenecks.

    Scale executive judgment before you scale titles

    Praveer Melwani joined Figma in 2017 as its first business operations and finance hire. The company was still around 30 people and had not begun charging for the product. He became CFO in 2022 and helped lead the company through its IPO in 2025.

    The important pattern is the sequence of work. Early responsibilities included building driver trees, challenging go-to-market assumptions, and establishing the mechanics of board management. Later responsibilities moved toward defining the questions the company needed to answer, directing capital, and shaping the operating cadence. The role grew because the decisions grew.

    You can use that sequence as an executive-readiness ladder. It is more informative than tenure or the seniority of a candidate’s last title.

    Executive modeWork that demonstrates readinessFailure signal to watch
    OperatorBuilds the model, tests assumptions, and makes the basic process reliable.Produces accurate work but cannot explain which decision it should change.
    Question-setterIdentifies the uncertainty that matters, frames options, and defines success.Waits for the founder or another executive to determine what deserves attention.
    AllocatorConnects product evidence, financial constraints, and strategic upside to resource choices.Treats the budget as a fixed entitlement rather than a set of revisable bets.
    System leaderImproves the cadence, decision rights, narrative, and judgment of the wider team.Remains the indispensable reviewer for every important decision.

    Do not promote someone merely because they are excellent in the first row. Give them work from the next row and observe what happens. Ask a strong operator to frame an ambiguous company problem, recommend where resources should move, document the trade-offs, and run the decision through the relevant functions. You are testing whether the person can create clarity beyond the boundaries of the original role.

    I use a similar first-principles test when evaluating a prospective VP, especially in a function the founder does not know deeply:

    • Can the candidate map how the business creates and captures value?
    • Can they define success metrics and show where those metrics could mislead the team?
    • Can they explain a meaningful trade-off in plain language?
    • Can they describe the team and decision system they would build, rather than only the work they would personally perform?
    • Can they teach the executive team something useful in 30 minutes?

    Run this test on your actual business context, not a generic case interview. A candidate who asks sharper questions, exposes a hidden assumption, and improves the decision has demonstrated more than someone who recites the standard playbook from a previous employer. Prior experience still matters, but learning velocity and expanding scope deserve more weight than familiarity alone.

    Make IPO readiness a company cadence, not a finance workstream

    Figma began behaving like a public company three years before its IPO. That is not a universal countdown for every company. The more important point is the order of operations: the habits came before the event that would test them.

    Late preparation forces teams to create controls, reconcile definitions, improve forecasting, and construct a credible narrative while the stakes are already high. Early preparation turns the same work into ordinary management. It also reveals weak ownership and unreliable data while the company still has room to correct them.

    • Quarterly operating rhythm: Review changes in the business drivers, the assumptions behind the forecast, the resulting resource choices, and the risks that could alter the plan. A performance presentation without a decision is reporting, not an operating review.
    • Close and controls: Make ownership, evidence, access, and material judgments explicit. The goal is not bureaucracy for its own sake. It is to produce numbers that leaders can use without reopening the entire chain of custody every time.
    • Forward-looking narrative: Connect past performance to the decisions now being made. Explain what changed, why management believes it changed, what will be done next, and what evidence would invalidate that view.
    • Decision record: Preserve the assumptions, alternatives, owner, and follow-up trigger behind a material choice. This prevents the company from rewriting the reasoning after the outcome is known.

    This discipline can accelerate decisions because product, finance, and go-to-market stop renegotiating the basic facts in every meeting. Product brings evidence about behavior and roadmap alternatives. Finance brings the model, sensitivities, and constraints. Go-to-market brings customer context, commercial implications, and execution dependencies. The executive owner makes the cross-company choice and records what would cause it to change.

    A useful quarterly decision packet should answer the following questions:

    <!– wp:list {
  • What the Intercom-to-Fin Rebrand Teaches Product Leaders

    What the Intercom-to-Fin Rebrand Teaches Product Leaders

    If you are deciding whether an AI product should become your company name, you probably do not have a naming problem. You have a portfolio commitment problem. The rename will make your bet visible, but it will also force you to explain what existing customers still own, what will keep improving, and what now defines the company’s future.

    The Intercom-to-Fin move offers a clean way to think about that decision. The company is now named Fin, while Intercom remains its customer service software platform; Intercom 2 has also launched as a complete rebuild with continued investment behind it. The growth brand moves up to the corporate level without erasing the durable product brand beneath it. That is the strategic work of this rebrand.

    The decisive choice is what you do not rename

    The most important word in this rebrand is not Fin. It is “remains.” Intercom remains a product, a customer commitment, and a place where the company can keep creating value. Fin becomes the corporate identity and the clearest expression of the next growth thesis.

    Changing the company name while retaining the established product name is not an incomplete rebrand. It is deliberate brand architecture. The two names answer different customer questions:

    • The company brand answers: What future is this organization building toward?
    • The product brand answers: What can I buy, operate, renew, and rely on today?
    • The category brand answers: What new capability should I understand, budget for, and compare with alternatives?

    Those answers do not always belong under one name. Forcing them together can make the new strategy sound smaller than it is or make the established product appear to be on its way out. Keeping Intercom as the platform avoids turning corporate ambition into accidental product deprecation.

    Before approving a similar rename, write a transition contract. This is not a legal document. It is a short internal statement that every product, sales, marketing, support, recruiting, finance, and communications leader can use without improvising. It should answer:

    1. Exactly which entity is being renamed?
    2. Which products keep their current names?
    3. What changes for an existing customer because of the rename?
    4. What explicitly does not change?
    5. Where will investment increase, continue, or decline?
    6. How should someone describe the relationship between the company and each product?

    If the answers vary by executive, your organization is not ready to communicate the rename. Customers will encounter every inconsistency as a separate strategic story.

    A new category needs a clean place in the buyer’s mind

    Established brands are efficient because buyers use them as shorthand. The same shorthand becomes restrictive when a company wants to define a substantially different category. People do not continuously reassess every vendor from first principles. They attach new information to what they already believe.

    That is why a legacy name can create friction even when it has strong awareness and customer trust. The problem is not that buyers dislike the old brand. The problem is that they already know where to file it. Every pitch for the new category begins with a correction: the company you associate with one product is now asking you to understand it as something else.

    Fin had time to develop as a distinct service-agent identity before becoming the company name. The business introduced Fin three years before the corporate rename and deliberately led with that name while keeping Intercom in the background. That sequence matters. It allowed the category proposition to earn meaning before the corporate identity was placed behind it.

    You should look for the same underlying evidence before elevating a product brand:

    • Prospects ask for the new product or category by name instead of treating it as another feature of the established platform.
    • The product has a distinct job, competitive set, buying conversation, and roadmap.
    • Your largest resource-allocation decisions increasingly revolve around the new category.
    • The existing company name repeatedly requires explanation before buyers understand the new proposition.
    • The legacy product can remain a coherent, investable business under its own name.
    • Leadership is willing to keep prioritizing the category when it competes with comfortable, near-term work elsewhere in the portfolio.

    Wait if the new product still depends almost entirely on legacy demand, if “AI” is the only thing making it sound like a new category, or if leaders cannot explain the future of the existing portfolio. A corporate rename should settle a strategic truth that is already visible in the product and resource decisions. It cannot manufacture that truth.

    Test the strategy before you test the name

    Name preference is the least important question at the start. A memorable name cannot rescue an unstable thesis, and a room full of favorable reactions cannot prove that the proposed architecture makes sense. Test the decisions the name is meant to encode.

    Strategic permanence

    Ask whether the new identity can survive normal product evolution. A company named after a feature will eventually outgrow its name. A company named for a durable category, customer outcome, or long-term platform has more room to expand.

    Pressure-test the choice against plausible roadmap changes. If the current interface changes, the underlying models improve, or the product expands into adjacent workflows, does the name still represent the company? If one disappointing planning cycle would make leadership retreat to the old story, the corporate rename is premature.

    Customer comprehension

    Do not ask customers whether the new brand “makes sense.” That question invites politeness. Show them the proposed naming hierarchy without an explanation and ask them to describe:

    • What the company does.
    • What they can buy.
    • What happened to the existing product.
    • Which name they expect to see in the application, documentation, support experience, and commercial relationship.
    • Whether the new offering feels like a feature, a product, a platform, or a category.

    The vocabulary in their answers matters more than a preference score. If customers merge the company and product into one ambiguous object, the hierarchy needs work. If established customers assume their product is being replaced, the continuity story is too weak. If prospects still describe the company only through the old category, the new position has not yet become legible.

    Portfolio durability

    Every product affected by the rename needs a stated fate: promoted, retained, integrated, or retired. Silence creates its own answer, and customers usually interpret it as declining commitment.

    The Intercom-to-Fin architecture avoids that ambiguity. The corporate brand follows the AI growth engine, while the established platform receives a rebuilt product and continued investment. You can apply the same discipline by requiring a roadmap, owner, customer promise, and success measure for every brand that survives the transition.

    Operating commitment

    A company name is a resource-allocation claim. Check whether hiring plans, executive attention, roadmap capacity, sales enablement, partner priorities, and operating metrics already support the future implied by the name.

    This is where weak rebrands reveal themselves. The homepage changes, but planning continues to favor the old center of gravity. Sales compensation rewards the previous motion. Product teams keep describing the AI offer as an add-on. Recruiting language promises one future while internal goals fund another. If those contradictions remain, the market will believe the operating behavior rather than the new identity.

    Turn the rebrand into an operating model

    A corporate rename touches more than brand assets. It changes the nouns people use to make product, commercial, and technical decisions. Treat it as a cross-functional migration with a defined architecture, owners, dependencies, and observable failure modes.

    Before launch, remove internal ambiguity

    Start with an inventory of named objects. Separate the corporate brand, legal entity, product names, application name, AI agent, domains, documentation, status pages, integrations, partner listings, support channels, and customer-facing team names. They may not all change together, and some should not change at all.

    Create a controlled vocabulary for each object. Record the approved name, a plain-language definition, the transition phrase, phrases to avoid, and the person responsible for exceptions. Then apply it to roadmap documents, release notes, sales materials, onboarding, job descriptions, support macros, analytics labels, and executive reporting. This prevents each function from inventing a slightly different portfolio.

    Keep the public brand change separate from legal and payment instructions. A new display name does not automatically mean that the contracting entity, tax information, or bank details changed. Telling customers to update those records without confirmation can create payment failures, procurement delays, and fraud risk. Legal and finance owners should identify any real operational changes and communicate them through established, verifiable channels.

    Build the customer FAQ from actual consequences, not brand language. Cover logins, existing contracts, invoices, data handling, support access, integrations, domains, saved links, product roadmaps, and administrative work. For every item, say whether action is required. “No action required” is useful only when you have verified it across the relevant systems.

    At launch, separate ambition from continuity

    Lead with the scope of the change. Say which name belongs to the company, which belongs to the existing product, and how the new category fits. Then explain why the corporate identity is changing. Follow that with a precise account of what existing customers should expect.

    Do not rely on “nothing changes” as reassurance. It is usually too broad to be credible, especially when a new product strategy and increased investment are central to the story. Name the stable elements instead: the product that remains, the workflows that continue, the commitments that persist, and any interfaces or commercial records that stay the same.

    Use the same architecture everywhere a customer can encounter the company. A clear launch page cannot compensate for an application header, help center, invoice, partner marketplace entry, or sales deck that implies a different relationship. Transitional wording can help connect the names, but it should have an exit condition rather than becoming permanent clutter.

    After launch, measure the translation tax

    Launch reach tells you that people saw the rename. It does not tell you that they understood it. Establish a pre-launch baseline where possible, then monitor evidence of confusion:

    • Support conversations asking whether the existing product is being discontinued or replaced.
    • Sales calls in which representatives must repeatedly correct the company-product relationship.
    • Documentation searches that mix old and new names in ways your information architecture does not handle.
    • Broken redirects, failed bookmarks, authentication problems, or integration errors caused by changed domains or labels.
    • Procurement and accounts-payable questions about the company name, contracting entity, or invoice sender.
    • Prospect descriptions of the category after encountering the new positioning.
    • Retention, adoption, and expansion for the established product, tracked separately from awareness of the new corporate brand.

    Review the language in those interactions, not just their volume. The words customers use will show whether the new mental model has formed. Retire transition copy only when support, sales, search, and customer interviews indicate that people can move between the names without assistance.

    Key takeaways for your own portfolio decision

    • The Fin corporate name expresses the future growth bet; retaining Intercom protects a valuable product identity and signals continued commitment.
    • A corporate rename is a brand-architecture and resource-allocation decision, not a cosmetic marketing project.
    • Elevate a product name only when the category, roadmap, buying conversation, and operating priorities already support it.
    • Tell customers exactly what is renamed, what remains, what changes, and whether they need to act.
    • Validate comprehension with unscripted customer explanations, not name-preference questions.
    • Measure confusion across support, sales, documentation, procurement, integrations, and product health after launch.

    If this decision is in front of you, bring a one-page transition contract to your next portfolio review. Ask product, sales, support, legal, finance, and recruiting to describe the company and its products using the same nouns. If they cannot, keep working on the architecture. If they can, and your resource allocation already matches the story, the rename can do its real job: make the strategy easier for the market to understand.

    References

  • Beyond the Product Builder Hype: How AI, org design, and joy shape PM success

    Beyond the Product Builder Hype: How AI, org design, and joy shape PM success

    I recently spent time with the debate behind the "product builder" trend—asking whether it’s the future of product management or just another wave of tech FOMO. The conversation featuring Teresa Torres and Petra Wille is a useful prompt, but what matters most is how we translate these ideas into healthy product practices inside our own organizations.

    Here’s my take: the product builder movement is neither a mandate nor a fad—it’s a tool. The right question isn’t "should product managers code?" but whether leaning into building advances outcomes for our customers and our teams. In practice, that means letting interest and skill—not pressure—set the pace.

    Petra captured it perfectly: "Just because I can do it — is it something I enjoy doing? And do I have enough experience to really get into the flow?" Those two tests—joy and depth—are underrated filters. I’ve seen PMs light up when prototyping or vibe coding a thin slice, and I’ve also seen well-meaning dabbling create hidden complexity that slows everyone down later.

    Org design determines whether this works. It’s not about the tools—it’s about clarity of roles, healthy interfaces between product, design, and engineering, and explicit guardrails for where experiments stop and production begins. AI has raised the stakes: "AI can make unskilled work look polished. That’s a feature and a bug — executives see the shine, engineers inherit the mess." If you’ve ever watched a glossy demo turn into weeks of refactors, you know exactly what this looks like.

    To avoid that trap, I deliberately separate the three layers where AI is changing product work: personal productivity, team process, and product strategy. Treating these as different stacks keeps expectations clean: a prompt that accelerates personal workflows isn’t the same as an AI-enhanced process that reshapes delivery, and neither automatically produces durable product advantage. Don’t conflate them.

    Discovery remains stubbornly human. "Why discovery still requires talking to your customers (sorry)" is more than a friendly nudge. AI can broaden our search space and sharpen analysis, but it doesn’t replace qualitative conversations or the judgment that comes from pattern recognition across real customer contexts. Continuous discovery and disciplined customer interviews are still the most reliable compasses we have.

    Where does "vibe coding" fit? It’s great for roughing out concepts, de-risking slices, and communicating intent when words or static mocks won’t cut it. Tools like Claude Code make this faster than ever, and familiar stacks like Ruby on Rails lower the bar for spinning up functional prototypes. But remember the design system trap: AI can make bad decisions look good on the surface. If you don’t control for architecture, accessibility, data contracts, and handoff quality, your team pays the integration tax later.

    In well-set-up orgs, the output-oriented muscle memory gets rewired. When AI frees up time, strong teams reinvest it into better problem framing, sharper opportunity solution trees, and tighter product strategy—rather than simply chasing more output. That’s a leadership challenge, not a tooling problem, and it shows up quickly in how teams make trade-offs.

    Here’s how I operationalize this with empowered product teams: we articulate clear boundaries for prototypes versus shippable code, define decision rights for when PMs or designers "build," and align on review gates that protect quality without stifling speed. We also make the three AI layers explicit in roadmapping and retros, so improvements to personal workflows don’t get mistaken for strategic advantage.

    My distilled guidance echoes the episode’s throughline. The product builder trend isn’t a mandate — it’s a tool. Let enjoyment and skill guide who on your team leans into it. Organizational readiness determines whether AI empowers your team or creates chaos. Don’t conflate personal efficiency, process change, and product impact—they require different responses. Discovery fundamentals haven’t changed; AI helps you go deeper, not skip the work. And the real takeaway on product builders: not everyone has to build, but everyone can if they want to.

    If you want to hear the full discussion that sparked these reflections, listen on Spotify or Apple Podcasts. Then tell me: where will you apply builder energy in your team—and where will you deliberately say no?

    Resources & Links: Follow Teresa Torres: https://ProductTalk.org. Follow Petra Wille: https://Petra-Wille.com. Mentioned in this episode: Claude Code, Vibe coding, Ruby on Rails.

    One more quote I loved because it centers autonomy and craft: "It’s a tool in our toolbox. We can decide who on our team has fun with it, wants to do it, wants to contribute." That’s the mindset that sustains both momentum and morale.

    Inspired by this post on Product Talk.

    Book a consult png image
  • From Internal FinOps Agents to Customer-Embedded Optimization

    From Internal FinOps Agents to Customer-Embedded Optimization

    Your cloud-cost agent can identify the line item that moved and still fail to change a single decision. The gap appears after the diagnosis: the recommendation arrives without the product, pricing, ownership, and risk context needed to act.

    If you are taking an internal FinOps capability into the customer experience, design for a closed decision loop. The goal is not autonomous cost cutting. It is a governed system that connects spend to customer value, recommends the next move, and proves whether the move worked.

    Design a decision loop, not another cost dashboard

    Start by naming the decision your product will improve. A broad promise such as optimize cloud spend gives the agent no useful boundary. A better contract is: detect a material change in workload cost, identify the most plausible driver, propose one permitted response, route it to the right owner, and verify the effect.

    Draw the product boundary around an outcome

    The operating loop is simple to describe: observe, explain, propose, authorize, execute, and verify. A dashboard normally stops at observe or explain. An agentic FinOps workflow carries evidence into a recommendation and then closes the loop with an approved action and post-action telemetry.

    Agentic does not mean unrestricted. It means the agent can select the next permitted step based on context. Deterministic services should still perform calculations, enforce policies, check permissions, and execute infrastructure changes. Use the model where interpretation is valuable: reconciling signals, building a driver narrative, identifying missing context, explaining tradeoffs, and routing a decision.

    That distinction matters in FinOps. A model should not improvise a billing calculation, invent a price, or bypass a commitment policy. If a calculation has one correct result, compute it in code and give the result to the agent as evidence.

    Build four layers with explicit responsibilities

    • Evidence layer: Billing exports, usage metering, observability, product telemetry, pricing logic, feature flags, deployment activity, environment metadata, customer segmentation, and ownership records.
    • Reasoning layer: Driver trees, anomaly triage, competing explanations, confidence evidence, and recommendation selection.
    • Action layer: Policy checks, approval routing, change preparation, execution, rollback, and escalation.
    • Learning layer: Post-action telemetry, realized outcomes, agent evaluations, customer feedback, and recurring patterns that belong in the product roadmap.

    A retrieval-first pipeline that combines billing, usage, observability, product, and go-to-market context is more useful than a large prompt containing a monthly cost export. Retrieve the records needed for the current decision and preserve their lineage. Every recommendation should reveal which records were used, when they were updated, which pricing assumptions applied, and what the agent could not retrieve.

    Customer-facing retrieval adds another non-negotiable boundary: tenant isolation must be enforced before context reaches the model. Do not rely on a prompt to prevent cross-customer disclosure. Access control belongs in the retrieval and service layers, with the resulting access decision recorded in the audit trail.

    Start with one anomaly and one reversible response

    Your first release does not need to optimize every cloud service. A practical thin slice is anomaly detection plus one high-leverage remediation path. For example, the agent might detect a change in non-production workload cost, connect it to a schedule change, prepare a schedule correction, request approval from the workload owner, and monitor the next usage window.

    Choose a first action that is bounded and reversible. A scheduling correction is easier to inspect and undo than a long-term financial commitment or a production capacity change. The purpose of the thin slice is to prove the whole operating loop, not merely the anomaly model.

    Make every recommendation safe enough to act on

    A recommendation without an execution envelope is an opinion. It may be correct, but the recipient still has to reconstruct the evidence, find the owner, assess the downside, and decide how to validate it. That is where apparently intelligent systems create more work than they remove.

    Use a recommendation contract

    Treat every agent recommendation as a structured product object. At minimum, require these fields:

    1. Decision: The exact choice the recipient is being asked to make.
    2. Scope: The account, workload, service, environment, and time window affected.
    3. Owner: The person or role accountable for the workload and the person authorized to approve the action.
    4. Evidence: Links to the billing, usage, observability, deployment, and product records that support the diagnosis, including their freshness.
    5. Driver path: The causal chain the agent believes explains the change, plus material alternative explanations it considered.
    6. Proposed action: The change, its expected mechanism, and any assumptions behind an estimated effect. If the effect cannot be estimated reliably, say that it is unknown.
    7. Confidence and unknowns: Evaluation-backed confidence evidence, missing context, and conditions that would invalidate the recommendation.
    8. Execution envelope: Policy checks, blast radius, approver, expiration, rollback procedure, and escalation path.
    9. Verification plan: The telemetry, observation window, success condition, and stop condition used after the action.

    The expiration field is easy to overlook. Cloud state changes quickly enough that an old recommendation can remain plausible after its evidence has gone stale. Expire the recommendation when its pricing, topology, deployment, or usage assumptions are no longer current. Force a fresh retrieval before execution.

    Grant autonomy by action class

    Do not give an agent one global autonomy setting. Earn autonomy independently for each action class:

    1. Observe: Detect and organize a possible anomaly.
    2. Explain: Build a driver tree and expose supporting evidence without proposing a change.
    3. Recommend: Propose an action while a human retains approval and execution.
    4. Prepare: Generate a change plan or dry run, but require an authorized owner to apply it.
    5. Execute within policy: Apply a reversible, bounded action only when the policy engine, permissions, evidence freshness, and rollback checks all pass.

    Purchasing a cloud commitment or altering production resources can create real financial or availability exposure. Keep finance and service owners in the approval path until confidence evidence and post-action telemetry demonstrate reliable performance for that specific intervention. Good results on anomaly explanations do not establish that the same agent is safe to execute infrastructure changes.

    Governance should be visible in the product, not left in a policy document. Show the approver which data was accessed, which rules passed, who changed the recommendation, what action ran, and what happened afterward. Privacy-by-design, data controls, and transparent decision logs are part of the user experience when the system influences money and production infrastructure.

    Evaluate the decision loop, not the prose

    A polished explanation is not evidence of a useful agent. Build evaluations around the failure modes that can block or distort a decision:

    • Did the recommendation use the correct customer, workload, environment, price, and time window?
    • Can each material claim be traced to an underlying record?
    • Does the driver path match known cases, including cases with several plausible causes?
    • Does the agent abstain when ownership, telemetry, or pricing context is missing?
    • Did approval routing and policy enforcement behave correctly?
    • Can the recipient perform the proposed action without reconstructing missing steps?
    • Did post-action telemetry confirm the expected direction of change without creating an unacceptable operational tradeoff?

    Put retrieval changes, prompts, policies, and tools through the same delivery discipline as application code. Eval-driven development, CI/CD, and a weekly shipping cadence make regressions visible before a persuasive but poorly grounded recommendation reaches an operator or customer.

    Embed the capability with customers before scaling it

    The first customer version should not be a general-purpose cost chatbot. It should be a narrow, product-assisted engineering motion in which a Forward Deployed Engineer, or FDE, helps the customer connect product usage, cloud architecture, and cost-to-value.

    Choose a small pod and customers that can teach you

    A sensible starting shape is one FDE pod focused on two or three high-potential customers. High potential should not mean merely the largest cloud bill. Select customers where the team can access the necessary evidence, an accountable sponsor can authorize changes, the problem is likely to recur, and the customer agrees to clear data and governance boundaries.

    • Evidence readiness: Billing, metering, observability, pricing, and deployment context can be joined without weeks of manual reconciliation.
    • Decision access: An engineering, product, or finance owner can approve an intervention and explain the operational constraints.
    • Learning value: The problem represents a pattern that may apply beyond one account.
    • Measurability: The customer and FDE can agree on a cost-to-value measure before making a change.
    • Governance fit: Data access, retention, tenant isolation, approvals, and audit expectations are explicit.

    If any of these conditions is absent, the engagement may still be commercially important, but it is a weak environment for deciding whether the agentic product works. Separate account urgency from product-learning quality.

    Run a customer optimization loop that produces reusable knowledge

    1. Define the value unit. Agree on what an active workload or valuable unit of product usage means. Total spend alone cannot distinguish efficient growth from contraction.
    2. Establish the baseline. Record current cost per active workload, time-to-first-value, relevant deployment behavior, and the constraints the customer will not trade away.
    3. Build the driver tree. Connect the spend change to services, environments, releases, product behavior, and customer usage. Surface gaps instead of filling them with assumptions.
    4. Select one intervention. Prefer the smallest action that can test the diagnosis. Document the expected mechanism, approver, risk, and rollback before execution.
    5. Verify the outcome. Compare post-action telemetry with the agreed baseline. Record savings, unit-economics movement, performance effects, adoption effects, and unintended consequences separately.
    6. Codify the pattern. Capture the inputs, decision rule, action, exceptions, safeguards, and evidence required to repeat the intervention.
    7. Send a weekly learning packet to product. Include successful patterns, failed diagnoses, missing platform capabilities, customer language, and recommendations that still depend on FDE judgment.

    Within a quarter, this loop should make it possible to distinguish interventions that can be automated, patterns that should become native product features, and problems that still require deeper solutions engineering. The point is not to eliminate the FDE. It is to reserve that scarce judgment for cases where ambiguity and customer context remain material.

    Make the commercial incentive legible

    Customer-embedded optimization creates an obvious trust question for a consumption business: does the vendor want the customer to spend less or consume more? The clean answer is to optimize cost-to-value rather than either number in isolation.

    A customer’s total cloud cost can rise while cost per active workload improves because valuable usage is growing. Total cost can also fall because the customer is using less of the product, which is not an optimization success. Label the outcome precisely: lower total spend, lower unit cost, avoided waste, shifted commitment, higher useful consumption, or reduced operational risk. Do not collapse these different effects into a generic savings claim.

    The FDE is also a trust boundary. The role should explain the recommendation, expose assumptions, and represent the customer’s constraints. It should not become a human interface for repetitive exports and one-off queries that the platform ought to handle.

    Turn field work into a roadmap, not permanent custom service

    A strong FDE can make a weak product look successful by solving every gap manually. That is useful for an individual customer and dangerous for product strategy. You need an explicit test for moving work from the field into an agent workflow or native platform capability.

    Apply a productization test to every recurring intervention

    1. Can the same signal be retrieved reliably across the intended customer segment?
    2. Can the decision logic be expressed without undocumented customer-specific knowledge?
    3. Can the action be bounded by a stable policy, approval path, and rollback procedure?
    4. Can the outcome be measured with telemetry that exists before and after the change?
    5. Do the likely exceptions fit a review workflow, or do they fundamentally change the decision?

    If the signal, decision, action, and measurement are repeatable, make the pattern a native feature or automated playbook. If the evidence is repeatable but judgment varies, keep an agentic workflow with human review. If the action carries high financial or availability risk, keep the FDE and accountable owner in the loop. If the pattern is a one-off, document it but resist turning it into product scope.

    Use a scorecard that reveals where the loop is breaking

    DimensionMeasureDecision it informs
    Insight speedTime-to-insight from a material spend changeIs the system finding the issue early enough to change an engineering decision?
    Action qualityRecommendations with evidence, an owner, a permitted action, and a verification planIs the agent producing executable decisions or polished commentary?
    EconomicsRealized savings per recommendation and cost per active workloadDid the intervention improve spend or unit economics for the intended value unit?
    ReliabilityPost-action effects, abstentions, rollbacks, and policy failures by action classWhich interventions have earned more autonomy, and which need tighter controls?
    Customer outcomeTime-to-first-value and NRR movement on FDE-supported accountsIs the motion improving adoption and durable account value? NRR is directional evidence, not proof of causation.
    Product leverageRecurring field patterns converted into features, guardrails, or in-product guidanceIs customer work compounding into a scalable product?

    Recommendation volume, prompt length, and agent activity are operating diagnostics, not business outcomes. A quiet system that changes a few high-value decisions can be more useful than an active system that produces hundreds of unactioned findings.

    Make build versus buy a component decision

    Do not treat the choice as one monolithic platform decision. Separate commodity capabilities from the context and workflow that create differentiation. Evaluate billing ingestion, normalization, anomaly detection, the context model, pricing logic, recommendation policy, approval routing, execution, and agent analytics independently.

    • Does the capability require knowledge of your architecture, pricing model, feature flags, customer usage, or deployment behavior?
    • Can an external component preserve evidence lineage, tenant isolation, and decision logs at the level your customers require?
    • Is the capability a generic input to the product, or is it where your product makes a differentiated decision?
    • Can your team evaluate and operate the component continuously, including regressions after model, prompt, policy, or data changes?
    • Will the component reduce time-to-value without trapping critical customer and pricing context in an opaque workflow?

    Unique architecture, pricing, and growth loops can justify building the context and decision layers. But weak tagging, unclear ownership, and missing observability undermine either path. Fix those foundations before expecting an in-house or purchased agent to produce precise optimization decisions.

    Give the core product to a product trio spanning product management, engineering, and FinOps. Bring FDE, customer success, SRE, finance, and security into discovery and evaluation where their decisions are affected. Field requests should enter the roadmap with evidence of recurrence, strategic importance, or platform leverage rather than becoming an informal side door to custom development.

    Key takeaways

    • Define the product as observe, explain, propose, authorize, execute, and verify. Diagnosis alone is not an agentic outcome.
    • Retrieve billing, usage, observability, pricing, product, and ownership context for each decision, with lineage and tenant boundaries enforced outside the prompt.
    • Represent every recommendation as a governed contract containing evidence, owner, action, risk, approval, rollback, expiration, and verification.
    • Grant autonomy by action class. Keep humans in the loop for commitments and production changes until that intervention has reliable post-action evidence.
    • Start customer delivery with one FDE pod and two or three customers that offer evidence access, decision access, measurable value, and reusable learning.
    • Measure time-to-insight, realized outcomes, unit economics, reliability, customer value, and productized patterns instead of counting recommendations.

    This week, choose one recurring cost anomaly and map the complete path from underlying records to a verified action. Name the owner, approval rule, rollback, and success telemetry before improving the prompt. Do not add a second workflow until the first can explain what changed, why the action was allowed, and whether it improved customer cost-to-value.

    References

  • How a Digital Analytics Visionary Shapes My Product Strategy for Growth, Retention & Monetization

    How a Digital Analytics Visionary Shapes My Product Strategy for Growth, Retention & Monetization

    Data has always been my compass for building products that customers love and businesses depend on. Few sentences distill that imperative as crisply as the one below—and it continues to inform how I prioritize, experiment, and scale outcomes across the roadmap.

    Krista is a digital analytics leader, product strategist, and industry evangelist. She helps businesses use data to drive growth, retention, and monetization.

    That mandate mirrors how I run product: leverage behavioral analytics to uncover patterns, translate those insights into hypotheses, and validate them through rigorous A/B testing. I start by instrumenting the user journey end to end, then use cohort analysis, funnel diagnostics, and retention analysis to pinpoint where activation, engagement, or monetization is stalling. From there, I map driver trees to connect inputs (feature adoption, time-to-value, onboarding friction) to outputs (retention, conversion, revenue), so every experiment has a clear line of sight to business impact.

    On experimentation, I hold the bar high: define the minimum detectable effect (MDE) up front, ensure clean experiment design, and size samples to reduce noise. I combine Amplitude analytics with qualitative signals from continuous discovery to prioritize tests that move the needle, not just the vanity metrics. When a variant wins, I don’t stop at the lift—I track downstream effects on user activation, long-term retention, and monetization, ensuring we’re compounding gains rather than optimizing in silos.

    For product-led growth, I focus on the moments that matter most: first-value, aha, and habit formation. Journey mapping helps me identify the shortest, clearest path to value, while targeted in-app experiences and contextual nudges accelerate activation without adding friction. Every iteration feeds a learning loop—measure, learn, and ship—so we can pursue step-change outcomes, not incremental tweaks.

    Ultimately, the craft is in translating analytics into action. When teams can trace a feature idea to a specific behavioral pattern, test it with a well-powered A/B experiment, and observe durable improvements in retention and revenue, momentum takes care of itself. That’s how I operationalize data to deliver growth, retention, and monetization at scale.

    Inspired by this post on Amplitude – Best Practices.

    Book a consult png image
  • 4 Costly Agent Analytics Myths—And the Data-Backed Metrics I Rely on Instead

    4 Costly Agent Analytics Myths—And the Data-Backed Metrics I Rely on Instead

    In my work with product, operations, and support leaders, I’m often asked to help make sense of Agent Analytics—what to track, how to attribute outcomes, and where to invest. After reviewing countless dashboards and running experiments across human agents and AI agents, I’ve learned that some of the most common measurement beliefs are precisely the ones that lead teams astray.

    What comes up in conversation with leaders about Agent Analytics, and why not everything is what it seems.

    Below, I unpack four pervasive myths I encounter and share the data-centered practices I use to replace them. My goal is simple: help you upgrade the way you measure performance so you can improve customer outcomes, accelerate learning, and scale impact with confidence.

    Myth 1: “Lower average handle time (AHT) means higher performance.” AHT is useful but incomplete. When teams optimize solely for speed, they often push complexity into repeat contacts, reopens, or escalations. In the data, that shows up as a weak or negative relationship between lower AHT and durable outcomes like first contact resolution (FCR), customer effort, or revenue per conversation.

    Reality and what I measure instead: I right-size speed by pairing AHT with intent-level resolution and recontact rate. For simple intents (password reset, billing address update), shorter is usually better. For complex intents (tiered troubleshooting, multi-step verification), “right-speeding” wins—slightly longer interactions that prevent rework. Practically, that means segmenting by intent complexity using behavioral analytics, tracking weighted “intent resolution rate,” and monitoring repeat-contact windows (24–168 hours) to catch downstream pain.

    Myth 2: “AI agent containment tells the whole story.” A high containment rate can mask failure modes such as unresolved intent, silent abandonment, or low-quality handoffs that frustrate customers and spike human workload later.

    Reality and what I measure instead: I break containment into three parts for voice and chat flows: (1) intent resolution without escalation, (2) graceful handoff quality when escalation is necessary, and (3) post-handoff efficiency and satisfaction. For voice AI agent experiences, I also track escalation clarity (did the transcript summarize history and intent?), time-to-human, and customer satisfaction on the combined interaction. This provides a fuller view of customer support ai strategy effectiveness and avoids over-crediting automation for partial wins.

    Myth 3: “Quality is subjective, so it can’t be measured at scale.” Teams often default to sporadic QA because they assume it can’t be standardized across channels or agent types. The result is noisy feedback loops and stalled coaching.

    Reality and what I measure instead: Quality becomes measurable when it’s grounded in observable behaviors linked to outcomes. I use a rubric anchored in behavioral analytics (e.g., verified customer need, correct resolution path, policy compliance, empathy markers) and validate it via correlation with FCR, recontact, and retention analysis. To scale, I combine calibrated human reviews with AI-assisted scoring, check inter-rater reliability weekly, and use driver trees to connect quality levers to business results. This creates a consistent, coachable signal for both human agents and AI flows.

    Myth 4: “If the dashboard is green after launch, we’ve won.” Early wins can reflect novelty effects, cherry-picked routing, or short-term incentives that don’t persist. Declaring victory too soon locks in fragile gains and hides regressions across cohorts.

    Reality and what I measure instead: I treat go-live as the start of learning. I use A/B testing with a clear minimum detectable effect (MDE), stagger ramps, and hold out stable control cohorts for at least one full demand cycle. I track outcomes vs output OKRs—focusing on intent resolution, customer effort, and revenue/customer health over vanity metrics. I also monitor seasonality and channel mix shifts inside a unified analytics platform to ensure improvements generalize beyond the first week.

    How I operationalize this day to day: (1) define intents and complexity upfront, (2) unify journey data across channels, (3) instrument resolution and recontact rigorously, (4) apply driver trees to isolate what actually moves outcomes, and (5) iterate via disciplined experiments rather than sweeping changes. This approach aligns product and operations, speeds up coaching, and ensures AI investments compound rather than decay.

    If you’re rethinking your Agent Analytics stack, start by replacing each myth with a sharper metric: pair AHT with intent-level resolution, pair containment with handoff quality and satisfaction, pair QA with outcome-linked rubrics, and pair green dashboards with robust experiments. The payoff is a measurement system that earns trust, guides better decisions, and consistently improves customer and business results.

    Inspired by this post on Pendo – Best Practices.

    Book a consult png image
  • Taste vs. Evidence in the AI Era: What Product Leaders Must Invest In Now

    Taste vs. Evidence in the AI Era: What Product Leaders Must Invest In Now

    I just finished listening to "Taste – All Things Product Podcast with Teresa Torres & Petra Wille," and as a product leader shipping AI-powered capabilities at HighLevel, Inc., I wanted to pressure-test the sudden obsession with "taste."

    If you're curious, you can listen to this episode on Spotify or Apple Podcasts.

    The core question landed perfectly for our moment: Is "taste" the must-have skill of the AI era — or just the latest tech buzzword in a world where AI is eating through design, delivery, and discovery?

    Teresa pushes back hard, highlighting how slippery the term can be. "It's just this month's flavor of founder mode." She points out that "taste" is rarely defined, can't be easily taught, and too often becomes shorthand for "my preference trumps yours." Just as importantly, "It's not about your taste. It's about your customer's taste."

    Petra adds needed nuance from years in the craft: pattern-recognition is real, and some people do develop sharper product sense over time. As she put it, "I am a strong believer that you develop product sense and taste over time. It's never finished."

    Both threads lead back to familiar roots in product: product sense, founder mode, and the enduring myth of the lone visionary. They even grapple with the big question on everyone’s mind—Will AI Eat Taste Too?—and where that leaves product teams navigating GenAI, LLMs for product managers, and evolving product strategy.

    Here’s my take. "Taste" can be useful as a personal north star, but it is not a decision system. In my teams, we bias toward evidence: continuous discovery, customer interviews, discovery synthesis with opportunity solution trees, and tight collaboration in product trios. Opinion can start the conversation, but evidence should end it.

    Practically, that means investing in the skills that compound: Discovery skills — understanding customers, matching solutions to real needs. Human-to-human interaction skills. Learning to collaborate with AI effectively. Critical thinking and judgment grounded in evidence.

    On AI collaboration specifically, we treat GenAI as a force multiplier, not a decider. We prototype with AI to explore breadth, then narrow with qualitative and quantitative signals, ablation-style experiments, and clear success criteria. The bar I hold myself to is simple: taste without evidence is just opinion.

    Three lines I underlined from the conversation:

    "It's just this month's flavor of founder mode." — Teresa Torres

    "It's not about your taste. It's about your customer's taste." — Teresa Torres

    "I am a strong believer that you develop product sense and taste over time. It's never finished." — Petra Wille

    If you want to go deeper, these references are helpful for sharpening judgment without falling into the "great man" theory trap.

    Follow Teresa Torres: https://ProductTalk.org

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

    Founder mode

    Marty Cagan: Founder-Style Leadership

    Vercel/v0 CEO Guillermo Rauch on building taste: from Lenny Rachitsky’s Linkedin post

    Continuous discovery (Read Teresa’s Everyone Can Do Continuous Discovery—Even You! Here’s How

    The "great man" theory

    Steve Jobs and the myth of the lone product visionary

    Have thoughts on this episode? Leave a comment below and share how your team balances product sense with evidence in the age of AI.

    Inspired by this post on Product Talk.

    Book a consult png image
  • 5 Proven Agent Skills I Use to Automate Weekly Product Reviews with Claude, Cursor, and Codex

    5 Proven Agent Skills I Use to Automate Weekly Product Reviews with Claude, Cursor, and Codex

    Weekly product reviews are where strategy meets execution, and over the past year I’ve turned them into a high-signal, low-friction ritual by leaning on agentic AI. As VP of Product Management at HighLevel, Inc., I’ve standardized a set of agent skills that compress preparation time, surface the right insights, and keep PMs, engineers, and designers focused on decisions—not document wrangling.

    "Learn how our teams use agent skills with claude, cursor and codex to run product reviews as PMs, engineers, and designers. Here are 5 killer use cases for builder."

    Below, I walk through the five skills I rely on most in our weekly cadence—each one mapped to a clear product management outcome. They’re simple to set up, easy to govern, and aligned with core practices like continuous discovery, product roadmapping and sprint planning, and eval-driven development.

    Skill 1 — Backlog triage with signal extraction: I point an agent at fresh tickets, customer notes, and experiment results to cluster themes, tag impact, and flag regressions. Using a retrieval-first pipeline and Agent Analytics, the assistant ranks items by value, effort, and risk so our meeting starts with a prioritized, explainable shortlist instead of a raw queue.

    Skill 2 — PRD and spec synthesizer: Ahead of the review, an agent drafts a one-page PRD update from design diffs, git history, and decision logs. With Claude Code and Cursor, it highlights interface changes, acceptance criteria, and open questions, linking back to sources. The result is a crisp, auditable brief that keeps product trios aligned without re-litigating context.

    Skill 3 — Experiment and metrics analyzer: An analytics agent pulls A/B testing readouts, checks minimum detectable effect assumptions, and annotates anomalies. It turns raw telemetry into a narrative: what moved, by how much, and whether we trust it. This makes our discussion about tradeoffs, not spreadsheets, and speeds commitments on next steps.

    Skill 4 — Voice-of-customer synthesizer: The assistant clusters interviews, support threads, and NPS verbatims into jobs-to-be-done and pain themes. It proposes opportunity solution tree updates and calls out places where our roadmap diverges from customer signal. That keeps continuous discovery alive in the room—even when time is tight.

    Skill 5 — Roadmap and sprint planning co-pilot: After decisions, an agent converts outcomes into scoped backlog items, engineering tasks, and stakeholder updates. It drafts sprint goals, flags dependency risks, and aligns work to objectives. Because it’s grounded in the meeting record, it preserves intent while removing ambiguity.

    Under the hood, prompt engineering patterns and guardrails keep these workflows predictable: a retrieval-first pipeline for context, eval-driven development for quality checks, and role-specific prompts for PMs, engineers, and designers. With Claude Code I generate structured diffs and test scaffolds; with Cursor I accelerate code-review summaries; and with codex I bootstrap utility scripts that keep the loop tight between insights and implementation.

    The payoff is tangible: higher decision velocity, fewer meetings to “re-clarify,” and clearer accountability across the product organization. Just as important, governance and privacy-by-design are built in—every agent logs rationale, cites sources, and respects data boundaries—so leaders can scale AI workflows confidently.

    If you’re looking to level up your product reviews, start with these five skills, measure impact with Agent Analytics, and iterate. Small automations compound quickly, and the more consistently you run them, the more your team’s attention shifts from preparing content to making better product decisions.

    Inspired by this post on Amplitude – Perspectives.

    Book a consult png image
  • Mastering Product Marketing with Amplitude Analytics: Proven Playbooks for Sustainable Growth

    Mastering Product Marketing with Amplitude Analytics: Proven Playbooks for Sustainable Growth

    I’m continually refining how we use analytics to elevate product marketing, and this collection brings together my most effective playbooks for driving measurable growth with Amplitude Analytics. If you’re focused on product-led growth, you’ll find pragmatic guidance on translating behavioral analytics into sharper positioning, stronger activation, and durable retention.

    In my day-to-day work, I connect product strategy with go-to-market strategy by grounding every narrative in real user behavior. That means using event data to validate our value proposition, mapping journeys to uncover friction, and aligning product positioning with the moments that actually matter in-app. The outcome is a marketing engine that mirrors how customers discover, adopt, and expand within the product.

    Activation and retention are where outcomes are won or lost. I detail how to set leading indicators for user activation, instrument key behaviors, and run retention analysis that distinguishes healthy engagement from noisy usage. You’ll see how I turn cohort insights into precise messaging, targeted onboarding, and experiments that compound over time.

    Cross-functional execution is essential, so I share ways to operationalize a unified analytics platform across product, marketing, and customer success. With shared metrics, product trios can move faster from product discovery to launch, and marketing can scale campaigns that reflect what’s truly driving adoption. This tight loop reduces guesswork and increases our hit rate on both features and narratives.

    If you’re building a modern product marketing function, these essays and guides will help you move from intuition-led storytelling to evidence-backed strategy. Dive in to learn how I connect behavioral analytics to positioning, packaging, and roadmap choices—so every campaign and release ladders up to meaningful customer outcomes and sustainable growth.

    Inspired by this post on Amplitude – Perspectives.

    Book a consult png image
  • Master Opportunity Mapping with Continuous Discovery Habits — Join the May 2026 Book Club

    Master Opportunity Mapping with Continuous Discovery Habits — Join the May 2026 Book Club

    Five years in, Continuous Discovery Habits continues to be one of the most practical frameworks I use to align empowered product teams, sharpen product strategy, and convert customer interviews into outcomes. To celebrate its impact, I’m hosting a community read-along and inviting you to dig in with me this May.

    Each month, I’m releasing an in-depth reading guide to make learning stick. You’ll find the chapters we’ll be reading, a preview of the essential concepts, short videos to help you spread the ideas across your organization, individual and team discussion prompts, team exercises to put the concepts into practice, and additional reading if you want to go deeper. My goal is simple: help you turn product discovery into a steady habit, not a once-a-quarter activity.

    We’ll discuss each month’s reading in the comments, and we’ll gather quarterly on a live call to compare notes and share what’s working. Joining late is absolutely fine—I monitor the conversation throughout the year. Start with the current month or rewind to January; you can ask for help, share wins and roadblocks, and connect with other readers anytime.

    If you want to participate, grab a copy of the book (or dust off your old one), share the "Spread the Love" videos with your team, block focused time for the exercises, and register for the community sessions. Let’s do this together.

    This Month’s Reading

    Chapter: Chapter 6: Mapping the Opportunity Space

    Estimated reading time: ~23 minutes

    This month’s chapter will introduce you to why opportunity mapping is critical for structuring the ill-structured problem of reaching your desired outcome; how to move from overwhelming opportunity backlogs to well-structured opportunity spaces; the power of tree structures for depicting parent-child and sibling relationships between opportunities; how to identify distinct branches in your opportunity space using key moments in time; common anti-patterns to avoid when building your first opportunity solution tree; and why structure "gets done, undone, and redone" as you continue to learn.

    Need a copy? Grab the book.

    Share the Love with Friends and Colleagues

    We learn best in community. Use these short videos to spread the core concepts from this chapter—then invite your team to join the book club with you.

    The need for opportunity mapping – You will never fully satisfy your customers' desires

    Understanding the structure of an opportunity solution tree – Depicting two types of relationships

    Turn big intractable problems into smaller, more solvable problems – The power of decomposition

    How to map an opportunity space – Getting started with opportunity solution trees

    A well-structured opportunity space has distinct branches – Identify key moments in time

    Reflect & Discuss What You Read

    Reflection turns reading into capability. This chapter asks us to shift from reacting to every request to deliberately structuring the opportunity space. If you’ve ever felt overwhelmed by a never-ending backlog or pressure to ship output over outcomes, this is where the fog starts to lift. As you read, focus on how your team currently organizes (or doesn’t organize) what you hear from customers.

    Individual Reflection

    1) Think about your current product backlog or opportunity list. Is it a flat list, or do you have some structure to it? If you were to group similar opportunities together, what patterns would emerge?

    2) When was the last time you heard a customer need and immediately jumped to a solution without exploring whether there were related opportunities? What would change if you took the time to map how that opportunity connects to others?

    3) Review the anti-patterns from the chapter (opportunities framed from your company's perspective, vertical opportunities, opportunities with multiple parents, etc.). Which of these do you recognize in how your team currently talks about opportunities?

    Team Discussion

    1) As a team, pick a top-level opportunity you're currently working on. Try breaking it down into sub-opportunities together. Where do you struggle? Where do you disagree about how to frame or group opportunities? What does that tell you about gaps in your shared understanding?

    2) Look at your experience map (from Chapter 4) and identify 3-5 distinct moments in time during your customer's experience. Could these become the top-level branches of your opportunity solution tree? Where do you see overlap, and where are there clear distinctions?

    3) Discuss the quote from Barbara Tversky: "Structure gets done, undone, and redone." How does your team currently respond when you discover new information that changes how you understand the opportunity space? Do you treat your opportunity map as fixed or as something that evolves?

    Put It Into Practice

    Reading is step one; building your first opportunity solution tree is where the real learning happens. The exercises below are exactly how I coach product trios to transform ambiguous problems into aligned action.

    Exercise: Build Your First Opportunity Solution Tree

    Time: 60 minutes. Do this: With your product trio.

    Start by reviewing your interview snapshots from the past few weeks. For each opportunity you captured, ask the three questions from the chapter:

    Is this opportunity framed as a customer need, pain point, or desire (not a solution)?

    Is this opportunity unique to one customer, or have we seen it in more than one interview?

    If we address this opportunity, will it drive our desired outcome?

    Then, using your experience map, identify 3-5 distinct moments in time to serve as your top-level opportunities. Group the opportunities from your interviews under these top-level branches.

    Look for opportunities to add structure to each branch. Group similar opportunities together and identify a parent opportunity. Look for vertical stacks (one parent, one child) and fill in missing siblings. Reframe opportunities that are too broad or that could live in multiple branches.

    Don’t aim for perfection. Get something on paper (or a digital canvas) and iterate the tree with every new interview.

    Exercise: Practice Framing Opportunities from Your Customer’s Perspective

    Time: 30-45 minutes. Do this: With your product trio.

    Take 10-15 opportunities from your current backlog or list. For each one, ask: "Can I imagine a customer saying this?" If the answer is no, reframe it from your customer’s perspective. For example:

    "Increase subscription conversions" becomes "I want to know if this product is worth paying for"

    "Reduce support tickets" becomes "I can't figure out how to do X"

    "Improve onboarding completion" becomes "I'm not sure what to do next"

    This exercise helps you spot business-centric opportunities disguised as customer opportunities. It also trains your team to listen for opportunities in interviews that are framed from the customer’s point of view.

    Go Deeper: Additional Reading

    If you prefer an audio summary of this month’s reading, including the book chapters and the following resources, I’ve included an audio version for paid subscribers at the bottom of this post.

    Related In-Depth Guides

    Opportunity Solution Trees: Visualize Your Discovery to Stay Aligned and Drive Outcomes

    Customer Interviews: Uncover Hidden Insights from Every Conversation

    Supplementary Reading

    Prioritize Opportunities, Not Solutions

    Product in Practice: Opportunity Mapping at Grailed

    Product in Practice: Opportunity Mapping at trivago

    7 Key Benefits of Using Opportunity Solution Trees

    Getting Started with Opportunity Solution Trees at SuperAwesome

    Bringing Order to Chaos: Using Opportunity Solution Trees in Everyday Life

    Other Voices

    Why Groups Struggle to Solve Problems Together by Al Pittampalli

    More PM Problem Areas by Marty Cagan

    Five Superpowers of Diagrams by Abby Covert

    Critical Thinking is Product Management by This Is Product Management

    Our Live Discussion Schedule

    Our live discussion sessions are for paid subscribers. Sessions are not recorded. Invitations will go out to Supporting Members and CDH Members two weeks before the scheduled event. But reserve the time on your calendar now.

    Tuesday, June 16, 2026: 9am-10am PDT

    Thursday, September 17, 2026: 9am-10am PDT

    Wednesday, December 16, 2026: 9am-10am PST

    Audio Summary

    This summary was produced by NotebookLM. The sources supplied were the book chapters as well as all of the additional reading.

    Inspired by this post on Product Talk.

    Book a consult png image
  • CPO Leadership in the AI Era: A Practical System for Focus

    CPO Leadership in the AI Era: A Practical System for Focus

    You open a portfolio review and find an AI request from nearly every direction. One team wants an assistant. Another wants an agent. A third has a promising prototype that now needs production funding. Every request sounds plausible, yet approving all of them would spread the company across disconnected experiments.

    This isn’t primarily a prioritization problem. It is a leadership-system problem. Your job as CPO is to define the customer advantage worth pursuing, concentrate attention on a few coherent bets, specify the evidence that earns more investment, and make it clear what the company will stop doing. The roadmap should record those choices. It should not make them for you.

    Allocate attention before you allocate roadmap space

    AI expands the number of things a product team can plausibly build. It does not expand engineering capacity, customer attention, management bandwidth, or the company’s tolerance for operational risk at the same rate. That mismatch is why an orderly backlog can still represent a deeply unfocused strategy.

    A prototype adds to the confusion because it compresses the distance between an idea and a convincing demonstration. A good demo shows that a capability may be technically possible under selected conditions. It does not establish that customers will adopt it, that it will perform reliably across real workflows, that its economics will work, or that competitors cannot reproduce it.

    Before discussing priority, force each proposed investment through four decisions:

    • Customer advantage: What will a specific customer be able to do materially better, faster, or more safely?
    • Behavioral outcome: What observable change would show that the advantage matters, such as stronger activation, repeated use, retention, or expansion?
    • Business consequence: Which company outcome should move if the customer behavior changes, such as NRR, gross margin, payback, or cost-to-serve?
    • Opportunity cost: Which existing initiative, workflow, or commitment will receive less attention if this bet is funded?

    The fourth decision is where focus becomes real. If a proposal enters the portfolio without displacing time, money, or executive attention somewhere else, the company has not prioritized it. It has merely added it.

    A shared driver tree makes these trade-offs visible. Start with the company outcome. Connect it to the customer behavior that must change, the product lever expected to change that behavior, and the evidence required from the current initiative. If a team cannot draw a credible path through those layers, pause the funding discussion until it can. That is more useful than arguing about whether the item belongs near the top or middle of a feature list.

    Your leadership context changes how you create this clarity. In a founder-led company, you often need to influence without becoming deferential: preserve the ambition in the founder’s vision while pressure-testing assumptions with customer evidence, data, and portfolio consequences. Under a hired CEO, the emphasis shifts toward explicit investment theses, capital allocation, and a tighter connection among product, financial, and go-to-market plans.

    In either setting, ambition must be more precise than a mandate to become an AI company. Name the customer capability you want to own, the workflow in which it matters, and the durable advantage the company can build around it. Technology is an ingredient. Customer advantage is the strategic claim.

    Turn AI feature requests into testable investment theses

    A feature request arrives with a solution already embedded in it. An investment thesis keeps the solution open long enough to test whether the opportunity deserves capital. That distinction matters when models, interfaces, and implementation patterns are changing faster than an annual plan can absorb.

    Rewrite each material AI proposal using this structure:

    <!– wp:list {