Tag: product management leadership

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 layer	Question to answer	Evidence to inspect
Capability	What product intervention was available and correctly configured?	Release, entitlement, and configuration records
Behavior	Did the intended users perform the intended action?	Events, paths, account identity, and cohort membership
Workflow	Did the way work was completed actually change?	Completion states, handoffs, errors, and process records
Outcome	Did the relevant operational or business measure move?	The agreed customer or company system of record
Decision	Was 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

July 20, 2026

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.

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.

July 7, 2026
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.

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.
July 6, 2026
Durable Product and Platform Leadership Beyond the Launch
A successful product can create momentum, but durable leadership determines whether that momentum becomes an enduring company or platform. The distinction is especially important for infrastructure businesses, where trust, scalability, and operating discipline must keep pace with adoption.

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

Product strength can conceal organizational weakness

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

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

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

Durable platforms reduce uncertainty at every stage

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

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

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

Leadership durability comes from connected operating loops

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

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

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

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

AI readiness should amplify a durable foundation

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

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

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

Key takeaways
- Treat product success as evidence, not immunity. Adoption does not eliminate the need for governance, ethical judgment, and explicit accountability.
- Design platforms around customer confidence. Fast onboarding, dependable primitives, clear documentation, and a credible scaling path matter together.
- Preserve constraints after capital or demand arrives. Resources should follow validated customer value rather than substitute for it.
- Measure incremental impact. Product-led and sales-led motions need a method for separating created lift from revenue that would have occurred anyway.
- Use AI to extend a durable value proposition. Emerging workflows are most useful when they compound an existing platform advantage.
Durable leadership is ultimately visible in what happens after early success: whether the organization converts attention into learning, learning into disciplined choices, and those choices into a platform customers can continue to trust.

References
- Shivam.Consulting Blog – Why Great Products Can Still Fail: The Leadership Lesson Every Team Needs
- Shivam.Consulting Blog – Why Supabase’s AI-Era Growth Playbook Should Reshape How We Build Platforms
July 3, 2026
Designing Awe: Intentional, Sensory-Rich Experiences to Elevate Product Leadership

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

Listen to this episode on: Spotify | Apple Podcasts

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

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

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

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

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

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

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

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

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

Resources & Links

Follow Teresa Torres: https://ProductTalk.org

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

Mentioned in this episode

Strong Product People by Petra Wille

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

Reflections on Product at Heart’s 2026 Leadership Event

Arne Kittler of Product at Heart

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

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

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

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

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

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

Inspired by this post on Product Talk.

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

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

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

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

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

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

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

Inspired by this post on Pendo – Best Practices.

June 17, 2026
Stop Forcing Organizational Change: How I Create Impactful Product Habits Without Burnout

Organizational change is exhausting—so I stopped trying to force it. After years of leading product teams, I’ve learned that trying to fix the people and processes around me is almost always wasted energy. If you’re eager to champion a better way of working inside a resistant organization, there’s a more sustainable path that actually drives results.

Here’s my starting point: individuals can’t change their organizations. I’m often asked to “train the PMs” or “install discovery practices,” but without executive sponsorship, organizational pain, and urgency, nothing moves. I now decline those well-intentioned requests and focus instead on creating the conditions for change.

My readiness check is simple and ruthless. Pain — organizational pain felt by leadership, not just you. Urgency — there has to be a cost to inaction. Awareness — people need to know solutions exist. If I can’t articulate these three clearly, I narrow the scope to what my team and I can control and demonstrate.

Practically, I elevate organizational pain by making it visible and quantifiable: missed outcomes vs output OKRs, customer churn tied to unmet needs, increased operational load from legacy workflows, or cycle time and deployment friction that slow learning. I create urgency by modeling cost-of-delay and showing the trade-offs we’re already making. And I build awareness by running small, transparent experiments that show there’s a credible alternative—continuous discovery, empowered product teams, and product trios solving for outcomes, not output.

“Organizational change starts with you — but it starts with you changing you, not your organization.” I take that literally. I refine my own discovery habits, make my assumptions explicit, and raise the quality bar on evidence. Whether it’s adopting AI responsibly in our workflow or redesigning how we do customer interviews, I change me first and let the results speak.

Show your work, don’t advocate your conclusions. Instead of arguing for “the right way,” I surface the pain, share how I reached my conclusion, and let others draw their own insights. I circulate decision logs that link customer evidence to product decisions, include short snippets from interviews, and map outcomes to proposals. That transparency lowers defenses, builds stakeholder buy-in, and shifts the conversation from opinion to observable facts.

Working within constraints, not against them. Stuck in a rigid, feature-factory process? You don’t have to change quarterly planning to do great discovery. Add customer context. Frame features around outcomes. Layer in the habits without touching the formal process. I’ve embedded discovery into existing rituals: adding customer insights to PRDs, tying features to measurable outcomes, and using thin-slice experiments that fit inside current delivery cadences. Over time, those habits compound.

The ripple effect is real. Teams that do great work and show it publicly become the ones everyone wants to emulate. That’s how influence actually spreads. I make results visible—brief Looms walking through our reasoning, dashboards that track outcome movement, and internal write-ups that highlight how the work changed a customer behavior. Visibility turns quiet wins into organization-wide momentum.

If you want a place to start this week, try this: define a sharp outcome, run three quick customer interviews, share your notes and decision rationale openly, and ship one small experiment tied to that outcome. Use the data to refine your next step and repeat. In a month, you’ll have a trail of evidence, not a pitch deck—and that’s what shifts minds.

In the end, sustainable change comes from consistent practice, not fiery advocacy. Focus on outcomes, make the pain and cost-of-inaction undeniable, and keep showing your work. The organization will move when it’s ready—your job is to make “ready” happen sooner by modeling what good looks like and making it impossible to ignore.

Inspired by this post on Product Talk.

June 16, 2026
Salesforce to Acquire Fin for ~$3.6B: Powerful AI Synergy, Product Strategy Takeaways

I’m processing a milestone moment for SaaS, AI strategy, and product leadership. One statement captures the news with clarity: “We’re excited to share that we just signed an agreement for Salesforce to acquire Fin for ~$3.6B. The transaction is expected to close in the fourth quarter of Salesforce’s fiscal year 2027.” As a product leader, I see this as a high-conviction bet on agentic AI, Customer Agents, and CRM integration at massive scale.

The backstory matters, and it’s remarkable: “Fin started as Intercom 15 years ago. We changed our name to cap our transformation just weeks ago. We were a darling of the SaaS era and invented so many of the patterns you see in software today. Nearly four years ago, in need of a reboot, we jumped on weeks-old modern LLMs to create and define the category we know as Customer Agents today.” That arc—from SaaS pioneer to LLM-powered category creator—illustrates how bold pivots, shipped with urgency and clear product strategy, can reset the trajectory of a company and a market.

From a product management lens, this deal reinforces a few truths: category creation rewards those who move first with conviction; “reboots” succeed when they’re anchored in genuine customer value; and modern LLMs, applied through disciplined roadmapping and eval-driven development, can unlock step-change outcomes in customer support ai strategy and product-led growth. It also signals the rising centrality of agentic AI and operational AI workflows inside the CRM.

The leadership dimension is just as instructive. As the announcement framed it: “Salesforce invented modern software and SaaS. And Marc Benioff is like the final boss of tech founder CEOs. In seat for 27 years, he’s one of the last of his era. Still pushing, pivoting, placing big bets.” That ethos—placing big, principled bets while adapting the operating model—sets the tone for what sustained product management leadership looks like at scale.

Customer continuity and acceleration are clearly emphasized: “To our customers: Over the past few years we’ve been shipping intensely. Including recently our groundbreaking model, Apex, and our paradigm-defining internal agent, Operator. With the resources of Salesforce this will only accelerate. And yet little will practically change. I’ll still be CEO, Des will still be running R&D, we’ll both still be committed to continuing to lead this category. Thank you very sincerely and deeply for your belief in us.” For practitioners, the signal is strong: continued focus on shipping, sharper execution readiness, and tighter integration paths inside the Salesforce ecosystem.

Smiles, clinking glasses, and a roundtable toast in a cozy private room capture the energy of a big day—celebrating Salesforce's definitive agreement to acquire Fin and the teams joining forces for what's next.

There’s a human heartbeat here too: “While this is not the end, it is a major, pivotal, special, and emotional moment for us.” Moments like this remind me that building enduring products is equal parts craft and courage—powered by teams who commit to the long game, navigate uncertainty, and still ship relentlessly.

Strategically, I expect near-term priorities to center on secure data flow and governance, deep CRM integration, and unifying telemetry for Agent Analytics across channels. On the roadmap, I’d anticipate tighter alignment between LLM safety, retrieval-first pipelines, and enterprise-grade observability—plus thoughtful go-to-market strategy enabling sales-led growth to complement product-led growth. The real unlock comes when Customer Agents are natively orchestrated with Service, Sales, and Marketing workflows—measured with clear outcomes vs output OKRs and reinforced by robust knowledge management.

For fellow product leaders, the takeaways are actionable: define category boundaries with crisp value propositions; balance speed with governance; invest in eval-driven development and continuous discovery; and keep your product trios aligned around measurable customer outcomes. Above all, build the operating cadence—metrics, rituals, and talent—that lets you compound small wins into durable differentiation.

And I appreciate the spirit of this closing line: “And now, time to get back to work. See you at our next product launch in a few weeks. (:” That’s the mindset that turns a headline into execution: celebrate briefly, then ship the next proof point.

Inspired by this post on The Intercom Blog.

June 15, 2026
Learning Together: The Small-Group Product Coaching Strategy That Accelerates Real-World Growth

I’m continually evaluating how to invest in my team’s professional development in ways that create lasting capability, not just momentary enthusiasm. Recently, I revisited a compelling conversation featuring Teresa Torres and Petra Wille that zeroes in on how product teams actually learn best—especially when we’re accountable for product management leadership and sustainable practice change across empowered product teams.

Listen to this episode on: Spotify | Apple Podcasts

What's the best way to invest in your team's professional development — train everyone at once, let people self-direct, or something in between?

In my experience, the answer depends on your goals, the maturity of your product discovery habits, and how you create peer accountability. What resonated most with me was their argument that small, intentional groups are a powerful (and underused) learning model—one that aligns with how we build momentum in product discovery, product strategy, and continuous discovery routines.

Three Models of Team Learning

Train everyone at once — builds shared language, but not everyone is ready at the same time

Self-directed learning — works for highly motivated individuals, but lacks accountability

Small-group learning — the sweet spot: peer accountability, shared momentum, and just-in-time relevance

Across my teams, I’ve seen organization-wide training create useful common ground, but it rarely changes day-to-day behaviors without a follow-on mechanism for practice. Self-directed learning can inspire, yet it often fails to translate into consistent habits without peer pressure and shared goals. Small-group learning, especially within product trios or adjacent squads, consistently drives the most adoption because it blends relevance, peer accountability, and just-in-time application to real customer interviews, roadmap decisions, and stakeholder management challenges.

Why Learning Together Works

Creates natural accountability and deadlines

Helps people apply concepts to their own real work

Especially valuable for product leaders, who rarely have built-in peers to learn alongside

I’ve found small cohorts particularly effective for product leaders who need a safe space to pressure-test decisions, compare notes on org design, and align on product strategy trade-offs—without slipping into status updates. When leaders learn together, they build shared muscle memory that makes it easier to reinforce practices like continuous discovery and communities of practice across the organization.

Group Coaching vs. One-on-One Coaching

Individual: sounding board, holding space, powerful questions

Group/team: real work in the room, peer learning, bridges between leaders who rarely collaborate

Keep participants as close colleagues — trust and vulnerability go up when people already know each other

One-on-one coaching is invaluable for personal reflection and targeted growth. But when I need to accelerate collective behavior change—like improving discovery cadence, refining opportunity solution tree reviews, or aligning around outcome-based roadmapping—group coaching wins. Keeping participants as close colleagues increases vulnerability and candor, which in turn speeds up learning and leads to real changes in how teams plan, prioritize, and ship.

Key Takeaways

Start a book club — debriefing together beats reading alone

Train pilot teams before rolling out org-wide

Encourage duos or trios to take courses together

Match your learning format to your actual goal

Keep coaching groups tight for more honest, productive sessions

Here’s how I operationalize this: I start with a pilot team to validate the learning format and cadence, then expand to adjacent trios to build a network effect. We anchor learning to current initiatives (not abstract theory), ensure weekly touchpoints, and capture playbooks in our internal knowledge base so improvements persist beyond the cohort.

Resources & Links:

Follow Teresa Torres: https://ProductTalk.org

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

Mentioned in this episode:

Communities of Practice

Petra Wille's book Strong Product Communities – The Essential Guide to Product

Become a Better Product Leader: A 52-Week Transformation Journey – Petra's email course with quarterly live Q&A

Teresa Torres’ book Continuous Discovery Habits

Continuous Discovery Habits (CDH) Book Club

Petra’s STRONG Product People Corporate book clubs

Teresa's Product Discovery Fundamentals course

Work with Petra

Learning together at a conference like Product at Heart

Teresa & Hope Gurion's group leadership coaching program through Product Talk Train Your Team

Join the Conversation:

Have thoughts on this episode? Leave a comment below.

Inspired by this post on Product Talk.

June 9, 2026
Crafting Beloved Tech Brands: My Moonshot Marketing Playbook for the Post-LLM Era

I spend a lot of my time asking a deceptively simple question: what does excellent marketing actually look like in 2026? From the vantage point of product leadership, the answer isn’t a spreadsheet or a channel plan—it’s a feeling. Beloved tech brands earn the benefit of the doubt, create gravity around their roadmap, and make customers proud to belong. That kind of momentum is not an accident; it’s a system.

Here’s the hard truth I’ve learned building and scaling products: giving teams different goals creates dysfunction. When brand, demand gen, product marketing, and comms run on fragmented OKRs, you manufacture internal headwinds. “Marketing is one engine – not separate pieces.” One strategy, one narrative, one set of outcomes—expressed through different craft disciplines and time horizons.

That unity of purpose clarifies executive roles, too. The real difference between an SVP and a CMO is scope and narrative ownership. A great CMO architects the whole system—portfolio allocation, brand architecture, integrated go-to-market strategy, and the bar for creative taste—while refusing to get dragged into decisions they should never be making (for example, approving every headline or micromanaging channel tactics). Leaders should decide the outcomes, standards, and constraints; teams should control the craft.

On portfolio design, I run marketing like a portfolio of moonshots. You need a healthy mix: proven programs that compound, emergent bets that learn fast, and a small set of true moonshots that can change the slope of the curve. The point isn’t bravado; it’s risk-balanced exploration. If everything ships safely, you’re under-investing in differentiation. If everything is a swing for the fences, you’re not building a repeatable growth engine.

This is where taste becomes a strategic advantage. “Ubiquity is the opposite of cool.” If you want to be beloved, you cannot treat every channel, audience, and moment as equal. Early on, selective distribution, distinctive creative codes, and tight community loops create status and meaning. Later, you scale without sanding off the edges that made the product special.

Why do a few companies build a flywheel of momentum while others stall? They align story, product, and distribution. The product earns trust, the narrative creates aspiration, and the go-to-market strategy ensures the right customers experience both at the right time. Then perception cycles kick in—the Silicon Valley clock turns—and irrational optimism or skepticism can amplify signals. The antidote is compounding proof: consistent product shipping, community advocacy, and creative that makes people care.

Scaling taste across an organization is teachable. I codify brand principles, narrative guardrails, and examples of “right” versus “almost right.” I replace abstract feedback with decision rubrics—what we keep, kill, or revise and why. I run recurring creative reviews with a small cross-functional council, so judgment compounds. Taste can’t be fully automated, but it can be operationalized: shared references, a story bible, and a high bar for craft that’s explicit, not mystical.

In a post-LLM world, the fundamentals haven’t changed—but the frontier has. Generative tools supercharge iteration and research, yet the artistry never really left. You still need a point of view, a tension worth resolving, and a value proposition that’s felt, not just stated. Can taste be encoded in software? Parts of it—pattern libraries, style constraints, data-driven feedback—absolutely. But the spark that makes work unforgettable remains human: judgment, risk tolerance, and the courage to ship something that might not fit the playbook.

That’s why telling an optimistic, yet realistic story about AI matters. Over-automation drains humanity; under-automation wastes potential. The best work pairs AI Strategy with craft leadership: LLMs for rapid exploration, humans for narrative decisions and ethical judgment. Your message should show how AI expands customer agency, not just efficiency.

The brand-versus-growth debate is a false choice. The right story accelerates pipeline, and the right demand programs reinforce the brand. Look at Apple’s discipline around product truth and design codes, or Google Chrome’s “The Web Is What You Make of It (Dear Sophie)” for proof that emotion and utility can co-exist. Notion, Pinterest, Square, HubSpot, and Harley-Davidson show how community, identity, and product-led growth interlock when the company knows exactly what it stands for.

When it comes to launches, I’ve learned that announcement videos full of humans, lack humanity. Overproduced gloss often dilutes the truth customers seek: what problem does this solve, how quickly can I feel the value, and why does it matter now? Real users, real context, and a crisp arc from problem to promise will outperform most theatrics.

Practically, I architect my week to protect taste and outcomes. Early-week for strategy, portfolio reviews, and cross-functional alignment; mid-week for deep creative and product marketing work; late-week for decision clears and postmortems. I time-box “disruptive energy”—space to chase non-obvious ideas—and I guard it like any critical meeting. Without protected cycles for exploration, the urgent will always suffocate the important.

If there’s a single takeaway: playbooks are obsolete, but the fundamentals are not. The channels change; the psychology doesn’t. Run one engine. Allocate a true portfolio. Scale taste with rigor. In the AI era, make people care. That’s how beloved tech brands are built—and how they endure.

June 4, 2026
Broken Procurement Is Costing You Talent: A Product Leader’s Playbook for Speed and Sanity

Procurement should accelerate value, not suffocate it. Listening to this episode, I found myself nodding (and wincing) through a painfully familiar story about how well-intended controls morph into barriers that keep great expertise out. As a product leader responsible for speed, outcomes, and brand experience, I see procurement as a direct mirror of culture—and an often overlooked part of the product operating system.

In the conversation, Teresa is cranky—and honestly, she has every right to be. She’s simultaneously juggling seven speaking engagement contracts, and six of them have become a part-time job in themselves—think 80-page ethics policies, 800-question security forms, and Multi-Factor Authentication (MFA) questions asked 17 different times. Meanwhile, the one company that just put her fee on a credit card? Scheduled, confirmed, and done in two weeks. That contrast is the whole story: friction repels talent; clarity and simplicity attract it.

Petra adds her own horror story—filling out 12 identical Word document forms—and together they surface a deeper truth I’ve seen across organizations: broken vendor processes don’t just frustrate consultants; they stop companies from getting the expertise they actually need. And despite what many assume, company size isn’t the deciding factor—leadership intent and process ownership are.

If you’ve ever wondered why a training got canceled, why a speaker backed out, or why your team can’t seem to bring in outside experts, this is likely the culprit: procurement theater. Repetitive forms, unbounded scope creep, and sprawling security reviews create drag that outlasts any short-term legal or compliance gain. The opportunity cost—lost learning, slower progress, and talent that simply says no—is enormous.

One detail that stood out: with CEO-level buy-in, a legal review timeline collapsed from four months to 10 days. I’ve seen the same thing. Executive sponsorship is the fastest procurement tool there is, and it reveals what the organization truly values. If you can compress the path when a leader cares, you can redesign the path so it’s always faster—without compromising real risk management.

I also loved the clarity of a simple policy from the episode: Teresa’s new policy is straightforward—her paperwork, credit card payment, no vendor setup—or no speaking engagement. That’s not obstinance; it’s a bright-line test for whether an organization respects expert time and understands total cost. The best experts have options, and friction filters them out first.

Here’s how I operationalize this in product-led organizations. Tier risk by engagement type (e.g., one-hour talk vs. long-term software vendor) and match the process to the risk. Offer a credit-card fast lane with standard, plain-English terms for low-risk work. Eliminate duplicate data entry and kill redundant questionnaires. Use a single, secure intake that auto-fills known fields. Track cycle time end to end, and publish SLAs for legal, InfoSec, and finance. Most importantly, make vendor experience a first-class metric—because it is a brand experience.

Security and compliance matter, but they must be right-sized. If you’re buying a keynote, you’re not buying data processing—so why the 800-question security review? Calibrate controls to actual data access and system interaction. The episode even references AWS DynamoDB and GuardDuty, plus Claude Code—helpful reminders that your stack context matters, but not every purchase touches it. Don’t conflate deep technical diligence for a SaaS integration with a simple, no-data engagement.

There’s a reason the classic film Office Space gets a nod—it’s the perfect metaphor for what happens when well-meaning governance calcifies. Bureaucracy compounds over time, usually after adverse events, until startups—or any team that still moves fast—run circles around you. Procurement that treats experts like adversaries won’t win the race that actually matters: learning faster than the market.

If you want the full story, listen to the episode here: Spotify (https://open.spotify.com/episode/2JHnTvnZX2WcFczml7ozKY?ref=producttalk.org) | Apple Podcasts (https://podcasts.apple.com/kh/podcast/procurement/id1794203808?i=1000770701690&ref=producttalk.org). It’s cathartic, but more importantly, it’s a blueprint for fixing what’s broken.

Mentioned in the episode: Hire Teresa to Speak (https://www.producttalk.org/hire-teresa-to-speak/), AWS DynamoDB (https://aws.amazon.com/dynamodb/?ref=producttalk.org), GuardDuty (https://aws.amazon.com/guardduty/?ref=producttalk.org), Claude Code (https://www.claude.com/product/claude-code?ref=producttalk.org), and Office Space (https://en.wikipedia.org/wiki/Office_Space?ref=producttalk.org).

I’d love to hear your experiences and fixes. Where does your procurement flow break, how do you measure cycle time today, and what would it take to create a vendor experience you’d be proud to put your brand on? Drop your thoughts below and let’s trade playbooks.

Inspired by this post on Product Talk.

June 2, 2026
Join Me in June: Master Opportunity-First Product Strategy with Continuous Discovery Habits

I’m celebrating the five-year anniversary of Continuous Discovery Habits by inviting you to read it with me this June. As someone who leads product management and coaches product trios, I’ve seen how a shared discovery practice tightens alignment, speeds up learning, and drives outcomes. This month, we’ll go deep on prioritizing opportunities—not solutions—and I’ll guide you step by step so you can apply the ideas on your own team.

Each month, I’m releasing an in-depth reading guide that includes:

We’ll discuss each month’s reading in the comments, and we’ll gather quarterly on a live call to unpack real-world applications, trade wins and missteps, and keep the momentum going.

Joining late? No problem. I monitor the comments on each reading guide throughout the year. Start with the current month or go back to January—whatever works for you. Ask for help, share what’s working, and connect with other readers at any point.

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

This Month’s Reading

Chapter:

Estimated reading time: ~16 minutes

This month's chapter will introduce you to:

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 key ideas across your product trios, engineering partners, and stakeholders. Invite them to read along with you so your discovery cadence—and your product strategy—advance together.

Reflect & Discuss What You Read

When we reflect and discuss what we read, we absorb more and apply it faster. This chapter challenges a deeply ingrained habit: prioritizing solutions. I’ve been in those meetings—spreadsheets full of features, heated roadmap debates, and a creeping sense that we’re optimizing outputs rather than outcomes. The shift to opportunity-first thinking changed how my teams frame bets, sequence discovery, and communicate product strategy.

Individual Reflection

Team Discussion

Put It Into Practice

This month is all about shifting from solution-first to opportunity-first thinking. These short, focused exercises will help your product trio practice opportunity prioritization and improve decision speed without sacrificing product discovery rigor.

Exercise: Map Your Roadmap to Opportunities

Time: 45 minutesDo this: With your product trio

Take your current roadmap or backlog and work backwards. For each planned feature or solution:

This exercise often reveals that you're either:

Use these insights to inform your next prioritization conversation.

Exercise: Practice Two-Way Door Thinking

Time: 30 minutesDo this: With your product trio

Choose 3-5 recent or upcoming product decisions. For each one, discuss:

The goal is to calibrate your team's decision-making speed. Two-way door decisions should be made quickly with "just enough" evidence. One-way door decisions deserve more deliberation and data.

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 members at the bottom of this post.

Related In-Depth Guides

Supplementary Reading

Related Courses

Our Live Discussion Schedule

Our live discussion sessions are for registered members. Sessions are not recorded. Invitations will go out two weeks before the scheduled event—reserve time now.

Audio Summary

Prefer to listen? Stream the audio overview here: June — Prioritizing Opportunities (audio).

Ready to put continuous discovery into action? Grab the book, share the videos with your team, schedule the exercises, and join the community sessions. Opportunity-first product strategy is a muscle we can build together.

The chapters we will be readingA preview of the most important concepts we'll be learning aboutShort videos you can share with friends and colleagues to help spread the ideasIndividual and team discussion questions to help you absorb and engage with the readingTeam exercises to help you put the ideas into practiceAdditional reading to help you go deeper on the core ideasChapter 7: Prioritizing Opportunities, Not SolutionsWhy product strategy happens in the opportunity space, not the solution spaceHow to focus on one target opportunity at a time to deliver value iterativelyUsing the tree structure to simplify prioritization decisionsThe four criteria for assessing opportunities: sizing, market factors, company factors, and customer factorsWhy treating prioritization as a messy, subjective decision leads to better outcomes than scoring formulasThe concept of two-way door decisions and how they apply to opportunity prioritizationWork on one small opportunity at a time – Reduce your batch sizeGetting started with compare and contrast decisions – Choose the right target opportunityTurn big intractable problems into smaller, more solvable problems – The power of decompositionThink about your team's current roadmap or backlog. How much of your time is spent prioritizing features versus understanding and prioritizing customer opportunities? What would change if you flipped that ratio?Reflect on the last time you made a product decision. Did you treat it as a one-way door (irreversible) or a two-way door (reversible)? How did that framing affect your decision-making process and timeline?Consider the four assessment criteria (opportunity sizing, market factors, company factors, customer factors). Which of these does your team currently emphasize most? Which do you tend to overlook or underweight?As a team, list the top 5-10 items on your current roadmap or backlog. For each one, try to identify the underlying customer opportunity it addresses. If you can't clearly articulate the opportunity, what does that tell you about how you're making decisions?The chapter argues against scoring formulas (like RICE or ICE) for prioritization, calling them "made-up math." If your team uses a scoring system, discuss: What is it really measuring? Does it help you make better decisions, or does it just make subjective decisions feel more objective?Walk through a recent prioritization decision. Did you assess options in isolation ("should we build this?") or compare and contrast them? How might your decision have been different with a compare-and-contrast approach?Identify the customer opportunity it's meant to addressWrite it as something a customer might say (e.g., "I can't find anything to watch" not "We need better search")Look for patterns: Are multiple solutions addressing the same opportunity? Are some solutions disconnected from any clear customer need?Spreading yourself thin across too many opportunitiesOver-investing in a single opportunity with multiple solutionsBuilding solutions with no clear opportunity attachedIs this a one-way door decision (hard to reverse) or a two-way door decision (easy to reverse)?If it's a two-way door, what's the smallest step we could take to learn whether we're on the right track?What would we need to see to know we made the wrong choice?If we realize we're wrong, how quickly could we course-correct?Opportunity Solution Trees: Visualize Your Discovery to Stay Aligned and Drive OutcomesCustomer Interviews: Uncover Hidden Insights from Every ConversationPrioritize Opportunities, Not Solutions7 Key Benefits of Using Opportunity Solution TreesProduct in Practice: How 2-Way Door Decisions Helped Simply Business Learn FastProduct in Practice: Getting Started with Opportunity Solution Trees at SuperAwesomeProduct Discovery Fundamentals: Learn a structured and sustainable approach to continuous discovery.Tuesday, June 16, 2026: 9am-10am PDTThursday, September 17, 2026: 9am-10am PDTWednesday, December 16, 2026: 9am-10am PST

Inspired by this post on Product Talk.

June 2, 2026