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/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
I’m excited to share two opportunities this season to uplevel your craft, connect with peers, and leave with practical, repeatable techniques you can apply immediately to your product work.
We will be doing another round of Claude Code: Show and Tell on May 26th at 9am PDT. These community-driven sessions are hands-on and fast-paced—we swap proven workflows, compare prompts, and pressure-test approaches together. You’ll see how product teams are operationalizing AI workflows in real contexts and walk away with ideas you can adapt for your own roadmap and experimentation pipeline. Invites will go out to Supporting Members and CDH Members tomorrow. If you'd like to join us, keep an eye on your inbox for the invite.
I love these Show & Tell sessions because they translate tacit knowledge into clear, reusable playbooks. Whether you’re refining evaluation loops for LLMs, streamlining discovery synthesis, or standardizing prompts for consistency, the shared rigor and camaraderie make it a high-signal hour for any product leader invested in AI workflows.
I also want to share that I'll be teaching our June 4th – July 9th cohort of Product Discovery Fundamentals. This is the last time I'll be teaching this cohort in its current format. If you've been thinking of enrolling in this program, and want to take it with me, this is your last chance. Register here.
Across this cohort, we’ll practice continuous discovery habits—framing opportunities, tightening assumptions, running lean experiments, and aligning product trios on evidence-backed decisions. If you want a rigorous, repeatable system for turning customer insight into confident prioritization and compelling product strategy, I’d be thrilled to have you in the room.
The world can feel like it’s spinning, and as a product leader, I feel that pressure acutely—juggling customer needs, stakeholder expectations, and the relentless news cycle. I recently listened to a powerful conversation with Teresa Torres and Petra Wille about staying grounded when everything feels “bonkers,” and it offered a practical, human way to keep showing up without losing yourself.
What resonated most was the invitation to live my values through small, consistent actions. Rather than waiting for grand gestures or perfect solutions, I’m leaning into the mindset of “Something is better than nothing.” It’s the same spirit we bring to continuous improvement in product: make a change, evaluate impact, iterate.
“Create the world you want to live in” has become a daily prompt for me. I’m applying it to how I spend my attention, time, and platform—three scarce resources for any product management leader. I’m not going to do everything perfectly, but I can make better trade-offs this week than I did last week, and I can keep improving.
Practically, that looks like reconsidering which speaking invites I accept, especially when representation is skewed. If a stage is heavily male, I now ask organizers about their plan for balance before committing. I also question travel expectations for short talks when a high-quality virtual experience is possible—good for sustainability, budgets, and energy. These choices compound, just like product roadmapping and sprint planning decisions.
Petra’s “under-complexity” lens was a wake-up call. In product, oversimplified narratives—whether a single KPI, a vanity metric, or a forced binary—usually increase fear and bad decisions. The same is true in civic discourse. To counter that, I’m seeking more nuance on purpose: reading multiple sources on the same story, listening for who’s not in the room, and noticing how the same facts can carry different meanings depending on who’s telling it.
One simple habit helps: I’ll read The New York Times and The Wall Street Journal on a headline, then follow up with Tangle by Isaac Saul, which lays out “what the left says / what the right says / editor’s take,” sometimes including perspectives from affected communities. It’s a lightweight form of personal knowledge management that improves my product judgment and my citizenship.
Another idea that stuck with me is swapping media proxies for human connection. In product, we don’t ship based on secondhand opinions—we run customer interviews, co-create with users, and build empowered product teams. The same principle applies in community: talk to someone directly affected, ask real questions, and stay curious. When conversations get heated, I try to build bridges, reduce proxies, and look people in the eye.
I’m also reflecting on platform responsibility. Even a “small” platform can snowball through weak ties inside a company or community. I’m asking: When should I speak up? Where should I draw lines? And when is “staying in your lane” actually a way to avoid necessary leadership? These are the same stakeholder management questions we navigate in product strategy—assess impact, clarify intent, and act with integrity.
Local grounding matters, too. I’ve found energy and clarity in community-level action: voting, attending public protests when it feels right, mentoring, and supporting nonprofits like World Pulse. I love the framing of “don’t mess with my neighbors”—it keeps me focused on tangible care when the internet starts to feel like reality. I’ve also seen leaders use angel investing in agriculture-related efforts as a counterbalance to “internet reality,” channeling resources into durable, real-world outcomes.
If you want to experiment this week, pick one small lever you control: where you spend money, time, attention, or your platform. Add nuance by reading at least two different perspectives before reacting. Replace proxies with people by talking to someone with lived experience. Reduce polarization by asking, “what shaped that view?” before judging it. And go local—connect with neighbors or a community group and let small actions compound.
If you’d like to hear the full conversation that inspired these reflections, you can listen on Spotify or Apple Podcasts. Here are the direct links: Spotify: https://open.spotify.com/episode/1sxEFquu73ZB9fL9gGk6Om and Apple Podcasts: https://podcasts.apple.com/kh/podcast/staying-sane/id1794203808?i=1000755696295
Resources I’m exploring and recommend: World Pulse (https://www.worldpulse.org/), The New York Times (https://www.nytimes.com/), The Wall Street Journal (https://www.wsj.com/), and Tangle by Isaac Saul (https://www.readtangle.com/ and https://www.readtangle.com/author/isaac-saul/). For builders and writers, I also appreciate Ghost (https://ghost.org/) as an open-source publishing platform. If you work in or with the MENA ecosystem, take a look at MENA Product Summit ’26 (https://www.prdkt.plus/summit26). Colleagues like Jeff Merrell (https://jeffdmerrell.com/) and grassroots efforts such as No Kings Protest (https://www.nokings.org/) offer additional perspectives and ways to get involved.
If this resonates, share it with a teammate who’s been feeling the weight of the world. I’d love to hear one small, values-aligned action you’re taking this month—what “something” will you try next?
I hear the same refrain from product leadership peers everywhere: we’re overwhelmed. Shrinking headcount, constant AI disruption, economic uncertainty, and relentless context switching make it feel like we’re carrying two jobs—setting strategy while shielding our teams. I recently listened to an episode of All Things Product that zeroes in on what a real support system for product leaders looks like, and it resonated deeply with my day-to-day.
Want to listen to the conversation yourself? Find it on Spotify or Apple Podcasts.
Here’s the core tension I see (and felt early in my own leadership journey): product leaders tend to underinvest in themselves. We hold onto work because it feels faster, safer, or “just easier if I do it.” But that pattern quietly taxes strategy, slows learning, and caps team throughput. The hidden cost of “doing it all yourself” is real.
Early in my tenure leading product, I tried to keep every plate spinning—roadmap reviews, stakeholder prep, user research, executive updates—while protecting my team’s focus. I was busy and useful, but not maximally valuable. The turning point came when I started building a lightweight support stack: a few hours of executive assistant help each week, targeted research support for bet sizing, and a personal cadence with a leadership coach. The result wasn’t just more time; it was better time.
One provocative point that landed hard: product leaders rarely have executive assistants—and that’s a problem. If your calendar is your operating system, an EA is an extension of your leverage. Mine now handles scheduling, meeting hygiene, prep packets, and post-meeting artifacts. That shift moved me from “calendar triage” to “strategic curation.” It also reinforced a core principle: delegation is a leadership skill, not a weakness. When I delegate outcomes (not just tasks), my team learns, ownership grows, and we ship decisions faster.
Support for strategy work shouldn’t stop at the calendar. Research and data enable better bets. Lightweight research ops, access to product analytics, and brief synthesis sprints keep me anchored in evidence without drowning in artifacts. Paired with a strong community of practice, I get a steady stream of comparative patterns—how other leaders delegate, scope advisory boards, or run decision reviews—which short-circuits trial-and-error.
Coaches were framed as shortcuts for clarity, accountability, and skill-building—and I agree. A good coach compresses cycles, sharpens decision quality, and holds the mirror up when you drift into doer mode. Two quotes captured the mindset perfectly: “You are a pro athlete. It makes sense to think about how you scale your impact without adding more to your calendar.” — Petra Wille. “As you get busier, it becomes more important to focus on the value only you can bring.” — Teresa Torres.
There’s also a helpful nudge to let go of perfectionism: “80% done by someone else is 100% awesome.” — Dan Martell (quoted). In practice, that means I accept great drafts from others, then add the 10–20% only I can contribute—context, narrative, and the sharp edges of the decision.
What about AI? The conversation hits a practical middle ground I share: use AI where it compounds leverage—meeting summaries, research synthesis starters, doc outlines, and backlog triage. But keep humans where judgment, alignment, and context truly matter—strategy framing, stakeholder management, and the final decision-making loops. In other words, apply an AI Strategy that respects product leadership’s uniquely human work.
Key themes I took away: why product leaders struggle to scale themselves; the true cost of “doing it all yourself”; why not having executive assistants limits impact; delegation as a core leadership capability; how to identify and protect the work only you can uniquely do; using research and data to inform strategy; coaches as accelerators for clarity and accountability; communities of practice as a force multiplier; adopting a “professional athlete” mindset; when AI helps—and when humans still matter; and the liberating mantra that “80% done by someone else is 100% awesome.”
If you’re wondering where to begin, start small and practical. Audit your time: what work truly requires you? Experiment with small amounts of support (even a few hours a week). Delegate outcomes, not just tasks. Keep the hands-on work you love—but be intentional. Use peers, coaches, and communities to learn how others delegate. Don’t wait until burnout to build your support system.
Resources mentioned if you want to go deeper: Follow Teresa Torres: https://ProductTalk.org. Follow Petra Wille: https://Petra-Wille.com. Petra’s Coaching for Product Leaders: https://www.petra-wille.com/coaching-packages. Dan Martell’s book Buy Back Your Time: https://www.buybackyourtime.com.
I’m curious: what’s one outcome you’ll delegate this week, and what support would make it stick? Share your thoughts in the comments—your playbook might be exactly what another product leader needs right now.
If your community of practice needs constant reminders, fills its agenda with updates, and produces little that teams use afterward, the problem probably is not motivation. The community was given a meeting cadence before it was given a job.
Your job as a product leader is to create a repeatable path from a live problem to a better decision, a stronger practice, and knowledge another team can reuse. That is how you design continuous learning as a system instead of hoping it emerges from another recurring call.
Give the community a practice to improve, not a topic to discuss
A broad subject can attract interest without changing anyone’s work. Product strategy, discovery, AI, leadership, and experimentation are all reasonable areas of interest, but each is too large to serve as an operating purpose.
Start with a practice that members perform and can inspect. Opportunity framing is a practice. Writing an AI evaluation plan is a practice. Preparing an experiment decision is a practice. Stakeholder management is still too broad until you identify the behavior you want to improve, such as exposing trade-offs before a roadmap commitment is made.
A useful purpose statement has four parts:
Members: Who needs to learn together?
Practice: What recurring part of their work should get better?
Learning activity: What will they examine, attempt, or critique together?
Work consequence: What should change in a decision, artifact, or team behavior?
For example: This community helps product trios improve opportunity framing by critiquing active discovery artifacts, so teams can separate evidence from assumptions before choosing a solution.
That statement is narrow enough to guide an agenda. It tells members what to bring, tells a facilitator what kind of discussion belongs, and gives a sponsor something more meaningful to inspect than attendance.
Choose a quarterly learning theme with these filters:
Members are encountering the problem in current work, not merely expressing general interest in it.
The practice is shared enough that one person’s case can teach something useful to others.
A real artifact can make the practice visible. That might be an opportunity map, discovery plan, evaluation set, experiment brief, decision record, or stakeholder narrative.
Improvement can be noticed in later work. You should be able to point to a changed question, assumption, method, trade-off, or decision.
The theme is narrow enough to defer adjacent subjects. A community without boundaries becomes an internal conference with no coherent learning loop.
Write those choices into a short charter. Include the theme, target practice, current definition of good, artifact members will examine, evidence of progress, and what is out of scope. Treat the definition of good as a starting hypothesis. Learning can reveal a stronger standard after the work begins; the charter should be stable enough to focus the community but not so rigid that it prevents that discovery.
Combine learning from people with learning with people
A community needs external input and collaborative practice. Input without practice becomes content consumption. Collaboration without input can recycle the same local assumptions. Design both modes deliberately.
Learning mode
Use it when you need
Useful inputs
Expected output
Learning from people
Depth, a reference point, or a clearer definition of good
A tightly curated personal learning network, talks, books, courses, examples, and practitioners whose decisions you can examine
A heuristic, annotated example, sharper question, or alternative approach to test
Learning with people
Feedback, accountability, new patterns, or pressure-testing
Peer circles, artifact critiques, hackathons, meetups, and cross-functional working sessions
A revised artifact, changed decision, new experiment, or reusable lesson
The bridge between the two modes matters more than the volume of material consumed. Begin with a live question from the work. Curate external input that can sharpen that question. Bring the work artifact to peers. Critique its assumptions and trade-offs. Record what changed. Store the lesson where the next person facing the problem can retrieve it.
For an AI product community, the live question might concern an evaluation plan for a support agent. External examples can help the group notice missing failure cases, but reading alone does not improve the plan. Members need to inspect the proposed evaluation set, challenge what it represents, identify gaps, and document the resulting change. The work becomes the learning surface.
Track the network as working infrastructure. For each person or resource, note the practice you are learning, the artifact or decision that demonstrates it, the question it helps answer, and the action you intend to try. Prune the list when the theme changes or an input repeatedly fails to affect your thinking. The goal is not to follow everyone worth knowing. It is to make the right expertise retrievable when a decision needs it.
Build a cadence that ends in changed work and reusable artifacts
A community meeting is only one step in the learning loop. If the loop begins with an agenda and ends when the call finishes, members may enjoy the conversation while the organization loses most of its value.
A lightweight operating model can fit alongside product delivery:
Set a quarterly theme. Tie it to a practice teams currently need to improve.
Curate a small learning network. Gather examples and perspectives that challenge the community’s current standard.
Run monthly critiques. Use current work from product, design, and engineering rather than hypothetical exercises.
Publish one teaching artifact. Turn the strongest learning into a talk, guide, workshop, template, annotated example, or decision pattern.
Close the loop. Write down what changed in a decision, discovery cadence, product bet, or working method.
Do not ask a member to present everything they know about the theme. Ask them to bring something unfinished that matters to a real decision. The critique should answer a small set of questions:
Decision: What decision is the owner preparing to make?
Artifact: What document, model, prototype, dataset, or plan exposes the current thinking?
Evidence: What is known, what is assumed, and where is confidence weak?
Trade-off: Which constraint or competing objective makes the decision difficult?
Critique request: What does the owner want peers to challenge?
Change: What will the owner revise, test, reject, or investigate after the session?
The final question prevents critique from dissolving into commentary. Advice is not yet learning. Learning becomes visible when the owner changes an artifact, runs a test, revises a decision, or explains why the critique did not alter the course.
Keep the feedback about the work, not the person’s competence. Sensitive examples can be anonymized, but stripping out every constraint makes the exercise artificial. Preserve the decision context, evidence, and trade-offs that peers need in order to give useful criticism.
Separate community roles so the founder is not the system
A community becomes fragile when one enthusiastic leader selects every topic, provides every answer, facilitates every discussion, and writes every note. Distribute the work:
Steward: Maintains the charter, boundaries, and relationship to organizational priorities.
Curator: Finds relevant people, examples, and learning inputs for the current theme.
Facilitator: Keeps sessions focused on the stated decision and critique request.
Artifact owner: Brings live work and decides what to do with the feedback.
Synthesizer: Captures the reusable lesson, change made, and retrieval metadata.
A small community can combine roles, but the responsibilities should still be explicit. Rotating artifact ownership also prevents the group from becoming an expert’s help desk. Members learn to expose their reasoning, offer precise critique, and teach what they have understood.
Use the same structure for every durable artifact: context, decision, evidence, critique, change, result still to be observed, and reusable principle. Tag it by practice and decision type rather than only by meeting date. A folder full of chronological notes is an archive. A collection organized around future retrieval is a knowledge system.
Diagnose failure modes and show evidence of impact
Community leaders often respond to weak participation by adding speakers, reminders, or more topics. Those actions can increase activity while preserving the design flaw. Read the symptom as evidence about the operating model.
What you notice
Likely design problem
What to change
Sessions become status updates
Live work is being reported rather than examined
Remove the progress round. Require a decision, artifact, and explicit critique request.
Conversations are energetic but nothing changes afterward
The learning loop ends at discussion
Close every critique with a named change, test, investigation, or reason for retaining the current approach.
The same experts do most of the talking
The community has become a help desk or lecture series
Rotate artifact ownership and ask members to expose their judgment, not just request answers.
Every session covers a different subject
The theme is too broad or absent
Return to one quarterly practice and place adjacent requests in a backlog.
Notes accumulate but are rarely reused
Capture is organized around meetings rather than retrieval
Use a common artifact template and tag lessons by practice, decision, and problem.
People attend but stop bringing unfinished work
Critique may feel unsafe, performative, or disconnected from current decisions
Review the invitation, keep feedback about the artifact, and let owners state the feedback they need.
The community depends on its founder
Operational knowledge and authority have not been distributed
Make roles explicit, rotate them, and document the cadence.
Do not make attendance your primary success measure. Attendance can show reach, but it cannot tell you whether anyone learned, changed a practice, or made a better-informed decision. It is possible to fill every session and still run a content club with no operational effect.
Use an evidence chain that a product or executive sponsor can inspect:
Participation: Members bring relevant work and a real decision question.
Artifact change: A plan, model, evaluation, narrative, or discovery artifact is revised after critique.
Practice change: A team adopts, tests, or deliberately rejects a method with its reasoning recorded.
Knowledge reuse: Another person can find the artifact and apply it to a later decision.
Decision trace: The close-loop note identifies what changed in the team’s cadence, choices, or bets.
This chain is more defensible than claiming the community directly produced a business outcome. Product teams still own delivery and results. The community improves the quality and availability of the practices those teams use. Connect it to business impact when the trace is real, but do not skip the intermediate evidence.
At the end of the quarterly theme, review the artifacts and ask: Which critiques changed work? Which lessons were reused? Which assumptions survived testing? Which part of the definition of good became clearer? Which unresolved practice deserves the next theme? If you cannot answer those questions, adjust the design before adding another meeting.
Key takeaways
Define the community around a recurring practice and a visible change in work, not a broad topic or an attendance goal.
Combine curated learning from people with artifact-based learning alongside peers.
Use a quarterly theme, monthly critique, teaching artifact, and change record to complete the learning loop.
Make unfinished work the center of each session and end with a revision, test, investigation, or explicit decision.
Organize knowledge for retrieval by practice and decision type, not merely by meeting date.
Show impact through artifact changes, practice changes, reuse, and decision traces before connecting the community to business results.
Before scheduling the next session, write the purpose sentence and name the artifact members will examine. Invite them to bring a live decision, then publish a short record of what changed after the critique. If you cannot name the practice or the expected output yet, keep designing the community before you create its calendar.
