Tag: stakeholder management

Plan Your 2026 Product Conference Calendar: Top Events, Locations, and Insider Tips

I’m curating a living list of 2026 product conferences to help product managers, product leaders, and empowered product teams plan ahead with confidence. I use this calendar to align my team’s discovery work, roadmapping, and go-to-market strategy—and to prioritize conference networking and learning that moves the needle on product-led growth.

This list is not exhaustive. If there’s a product conference missing that should be here, please send it to conferences@producttalk.org. I’ll keep updating this as new events are announced so you have a reliable guide throughout the year.

I’ll be teaching a workshop and speaking at the Product at Heart conference in June in Hamburg, Germany. If you plan to attend, be sure to say hi.

Are you looking for the 2025 Product Conferences list? Find it here.

How I use this guide: I map events to our quarterly OKRs (outcomes vs output OKRs), focus on sessions that sharpen product discovery, stakeholder management, and product roadmapping and sprint planning, and bring a clear plan for takeaways I can apply the day I’m back. If you’re exploring AI Strategy and LLMs for product managers, you’ll find several strong options below.

January

Jan 28 — Product-Led Summit — Washington, DC, USA

Jan 30–31 — Prdkt+ — Cairo, Egypt

February

Feb 1–4 — WebSummit — Doha, Qatar

Feb 2–20 — DeveloperWeek Hackathon — San Jose, CA, USA & Virtual

Feb 4 — DDX Innovation & UX Conference — Tokyo, Japan

Feb 4–5 — UX360 Virtual Summit — Virtual

Feb 7–8 — DDX Innovation & UX Conference — Dubai, UAE

Feb 18–20 — DeveloperWeek — San Jose, CA, USA

Feb 18–20 — ProductWorld — San Jose, CA, USA

Feb 24 — ProductCon — London, UK

Feb 24–25 — axe-con — Virtual

Feb 24–25 — Product-Led Summit — Austin, TX, USA

March

Mar 9–10 — Gartner Product Leadership Conference — Grapevine, TX, USA

Mar 12–18 — SXSW — Austin, TX, USA

Mar 23–26 — The Annual ACM Conference on Intelligent User Interface — Paphos, Cyprus

Mar 26 — Chief Product Officer Summit — New York, NY, USA

Mar 26–27 — Product Operations Summit — New York, NY, USA

Mar 26–27 — Product-Led Summit — New York, NY, USA

April

Apr 1–2 — Product-Led Summit — Denver, CO, USA

Apr 11 — ProductCamp — Phoenix, AZ, USA

Apr 13–14 — Business of Software — Cambridge, UK

Apr 13–17 — ACM CHI — Barcelona, Spain

Apr 14 — Chief Product Officer Summit — Palo Alto, CA, USA

Apr 15–16 — UX Nordic — Aarhus, Denmark

Apr 15 — AI Product Summit — San Jose, CA, USA

Apr 20–21 — Product at Heart Leadership — Hamburg, Germany

April 22–23 — UX360 NA — Atlanta, GA, USA

May

May 7–8 — ProductWorld 2026 — Opatija, Croatia

May 9 — DDX Innovation & UX Conference — Munich, Germany

May 11–13 — UXDX — New York, NY, USA & Virtual

May 11–14 — Web Summit — Vancouver, Canada

May 12–13 — Product Operations Summit — Amsterdam, The Netherlands

May 12–15 — UXLx User Experience — Lisbon, Portugal

May 13 — Leading the Product Leaders Forum — Melbourne, Australia

May 13–15 — SaaStr Annual — San Mateo, CA, USA

May 14 — Leading the Product Conference — Melbourne, Australia

May 19 — La Product Conf — Paris, France

May 20 — Leading the Product Leaders Forum — Sydney, Australia

May 20 — ProductCon — New York, NY, USA

May 21 — Leading the Product Conference — Sydney, Australia

May 27–29 — UXDX EMEA — Berlin, Germany & Virtual

May 22 — La Product Conf — Madrid, Spain

May 27–28 — Dublin Tech Summit — Dublin, Ireland

May 28–29 — Chief Product Officer Summit — Amsterdam, The Netherlands

May 28–29 — Product-Led Summit — Amsterdam, The Netherlands

June

Jun 8–11 — Web Summit — Rio de Janeiro, Brazil

Jun 15–16 — #mtpcon: A Mind the Product conference — London, UK

Jun 16 — Growth Minded Superheroes — Frankfurt, Germany

Jun 17–18 — Product-Led Summit — Seattle, WA, USA

Jun 22–26 — UXPA International — Las Vegas, NV, USA

Jun 23–24 — UX360 EU — Berlin, Germany

Jun 24–25 — Product-Led Summit — London, UK

Jun 26 — Product at Heart Conference — Hamburg, Germany

July

Jul 2–3 — Agile on the Beach — Falmouth, UK

Jul 26–28 — Agile2026 — Washington, DC, USA

Jul 26–31 — HCI International — Montreal, Canada

August

Aug 5 — ProductCon AI: Online Edition — Virtual

September

Sep 16–17 — uxcon — Vienna, Austria

Sep 16–18 — Hatch Conference — Berlin, Germany & Virtual

Sep 17 — DDX Innovation & UX Conference — San Diego, CA, USA

Sep 17 — Chief Product Officer Summit — San Francisco, CA, USA

Sep 22–23 — Product-Led Summit — San Francisco, CA, USA

Sep 22–23 — Product Operations Summit — San Francisco, CA, USA

Sep 28–30 — B2B Summit EMEA — London, UK

Sep 30–Oct 2 — GOTO Copenhagen — Copenhagen, Denmark

October

Oct 14–15 — Product-Led Summit — Berlin, Germany

Oct 16 — Just Product 2026 — Munich, Germany

Oct 26–27 — Y Oslo — Oslo, Norway

Oct 28 — Product-Led Summit — Sydney, Australia

Oct 28–29 — Product-Led Summit — Boston, MA, USA

November

Nov 9–12 — Web Summit — Lisbon, Portugal

Nov 11–12 — Product-Led Summit — Toronto, Canada

Nov 11–12 — Leading Design — London, UK

If you’re attending any of these, let me know—conference networking is always better with a plan and a friendly face. And if you’ve got a must-attend event on your radar, send it to conferences@producttalk.org so I can keep this guide comprehensive for the community.

Inspired by this post on Product Talk.

December 17, 2025
Year-End Reflection for Product Leaders: Values, Themes, and the 100‑Wishes Reset

I’ve been closing the year with a deliberate reflection ritual for more than a decade, and this season I found fresh energy for it after listening to an insightful conversation with Teresa Torres and Petra Wille on All Things Product. Their approaches mirror the evolution many product leaders experience: moving from rigid annual goal-setting to values-led themes, longer time horizons, and a healthier respect for spaciousness. In my own practice, that shift has created better focus, less pressure, and far more meaningful outcomes.

Prefer to listen? You can find this episode here: Spotify | Apple Podcasts. I took notes with my team in mind and translated the discussion into a simple, values-driven framework that any product organization can adopt.

Why does annual reflection matter for product people? Because our work lives at the intersection of ambiguity, trade-offs, and time. If we only measure ourselves by shipped output or quarterly OKRs, we overlook the compounding value of learning, relationships, and judgement. I treat this ritual as a strategic reset: a chance to surface patterns, adjust expectations, and recommit to outcomes over output.

My own reflection habit started scrappy—paper notebooks, messy timelines, and even artful visualizations inspired by Dear Data by Giorgia Lupi & Stefanie Posavec. Like Petra, I’ve found that tactile, analog artifacts unlock insights I miss in a spreadsheet. Over time, I’ve kept the spirit and simplified the mechanics: a “what went well” review, a short list of hard lessons, and a handful of decisions that paid off—or didn’t.

The biggest evolution for me has been moving from rigid annual goals to values and themes. I still run OKRs, but I use them to track progress, not identity. The lens of process vs. outcome goals—reinforced by ideas from Atomic Habits—helped me set fewer, better commitments. For example, instead of “launch X by Y,” I’ll emphasize the cadence of customer discovery, the health of the product trio, and the quality of decisions made along the way.

One exercise that changed my practice is the “100 wishes” list. It’s powerful—and surprisingly difficult. Pushing past 30 or 40 wishes forces me to name latent interests and long-range intentions I rarely say out loud. Combined with decade-level themes, the list helps me balance ambition with patience. I don’t try to do it all next year; I use it to spotlight direction, not deadlines.

I also review patterns across years: Where did over-scheduling create hidden costs? When did I protect focus time and what did that unlock? Paul Graham’s Maker’s Schedule, Manager’s Schedule remains a useful calibration tool here. And when I feel the pull toward constant throughput, I revisit Stefan Sagmeister’s The Power of Time Off (TED Talk) to remind myself why strategically creating space often yields the most valuable ideas.

Of course, not every year follows plan—and that’s normal. Reflection helps me spot unrealistic expectations early and let them go. When setbacks hit, I’ll rewatch Dealing with Setbacks and re-ground in continuous discovery. The question isn’t “Did we do everything?” but “Did we learn fast, protect customer value, and make trade-offs aligned with our values?” That’s how empowered product teams compound impact.

My sharing philosophy has become more nuanced over time. Some reflections are public to invite dialogue and accountability; others stay private so I can process honestly. I’ve found it helpful to publish what I’m saying no to, capture a theme for the year ahead, and keep the rest for myself and my team. This balance preserves motivation while still contributing to the broader product management leadership community.

If you’re designing your own ritual, consider this lightweight flow: review wins and tough calls, write your “100 wishes,” extract a few values-based themes, then translate those into process goals for Q1. Revisit monthly, not just annually. If you like structured prompts, Chris Guillebeau’s How to Conduct Your Own Annual Review from The Art of Nonconformity offers a practical template you can adapt to your context.

For deeper dives and complementary ideas, I bookmarked these as part of my year-end reset: What I’m Saying No to This Year—And Why, Ask Teresa: My Leaders Still Want Roadmaps with Timelines—What Should I Do?, Scaling Impact: A Look at the Year Ahead (2022), Let’s Connect in 2025: A Look at the Year Ahead, The Interview Coach, and Petra’s own year-ahead reflections (here and her 2026 version). I also recommend revisiting the prior conversation on leadership and change: Role of Leadership in Transformations.

I’d love to hear how you approach your end-of-year reflection. What questions bring you the most clarity? Which practices help you set an intentional, values-driven path for the next year? Share your process—I’m always looking to learn from other product creators and leaders.

Inspired by this post on Product Talk.

December 16, 2025
Inside the Engine Room: How I Drive Scalable Analytics APIs, Reliability, and Performance

I build and scale analytics platforms with a product mindset, and the work starts with the "middleware and compute systems that power analytics at scale." In platforms like Amplitude analytics and other unified analytics platform architectures, that foundation is what makes everything else possible.

Day to day, I oversee the "APIs behind charts, cohorts, and metrics—driving performance, reliability, and platform scalability." When those APIs are fast and resilient, every product team—from growth to customer success—can trust the insights they use to ship, learn, and iterate.

From an engineering leadership standpoint, I partner closely with SRE to define SLOs and error budgets, wire CI/CD pipelines for safe deploys, and track DORA metrics so we improve speed without compromising quality. This combination reduces incident management toil and shortens MTTR while keeping data freshness and query latency within strict thresholds.

From a product management leadership lens, the goal is clarity: crisp APIs, predictable contracts, and transparent stakeholder management across data, engineering, and GTM teams. That alignment empowers product teams with reliable cohorts and metrics, accelerates experimentation, and de-risks roadmaps.

If you’re scaling analytics, invest first in the platform layer: middleware and compute, schema governance, caching strategies, and cost-aware compute. Do that well, and the visible experience—charts, cohorts, and metrics—feels effortless, even as you grow to serve billions of events with confidence.

Inspired by this post on Amplitude – Best Practices.

December 12, 2025
Train Leaders First: How Product Leadership Unlocks Real Transformation and Discovery

I recently listened to Role of Leadership in Transformations – All Things Product Podcast with Teresa Torres & Petra Wille, and it crystallized a pattern I’ve seen across multiple transformations: teams often get trained in continuous discovery, but nothing changes because leadership habits stay the same. If you want to move from projects to true product thinking, “train your leaders first” isn’t a catchy mantra—it’s a prerequisite.

The episode digs into why discovery training can be stellar while adoption still stalls. I’ve witnessed this firsthand: teams return excited to interview customers and test ideas, but leaders continue to manage via features, roadmaps, and approvals. The result is predictable—discovery fades. When leaders evolve how they evaluate work, talk about outcomes, and shape rituals, discovery sticks. Without that shift, even energized, empowered product teams drift back to output.

What resonated most was how organizational dynamics kick in the moment teams start bringing real customer evidence to the table. Discovery uncovers conflicts. Sales, account management, stakeholders, and executives all feel the impact when the old “my job is to tell teams what to build” mindset collides with evidence-driven practices. Hierarchy also clashes with modern product practices—because in discovery, “all ideas come equal.” Product culture isn’t an accident; it must be intentionally created through norms, expectations, and systems that prioritize outcomes over output.

I’ve also seen the leadership skills gap up close. Many product leaders never learned continuous discovery themselves, so they aren’t equipped to coach it, critique it, or celebrate it. This is where great product management leadership shows up: the ability to assess discovery quality, reinforce outcomes vs output OKRs, and run cadences that create momentum. Leaders who invest in building these muscles—often through communities of practice and structured coaching—transform the operating environment for product trios and cross-functional teams.

The episode’s discussion of pilot teams is spot-on. Start small to surface hidden blockers—the corporate “immune system”—before going broad. Pilots expose decision bottlenecks, misaligned incentives, and policy friction that standard training never reveals. Tools like the Product Leadership Wheel help set clearer expectations for the craft of product leadership, while a coherent Product Operating Model makes the path from pilots to full transformation explicit and durable. I’m particularly excited about resources like the Discovery Habits Toolbox because they give leaders practical ways to coach continuous discovery without reverting to feature policing.

Here are the big takeaways I’m carrying forward. Skills training isn’t enough—if leaders still manage through feature requests and static roadmaps, teams will abandon discovery even if they loved the training. Leaders need training too—they must know how to evaluate discovery work, talk about outcomes, and create rituals that reinforce new habits. Discovery will surface conflicts—plan for stakeholder management, alignment with sales and account teams, and executive sponsorship. Product leadership is a craft—seniority alone doesn’t create clarity, systems, or culture. And transformations should start with leaders and pilot teams—because that’s where the real blockers live.

If you want to go deeper, listen to this episode on Spotify: https://open.spotify.com/episode/5cBTEbYX1YW3BF6icAPXzi or Apple Podcasts: https://podcasts.apple.com/kh/podcast/role-of-leadership-in-transformations/id1794203808?i=1000740342572. It’s a concise masterclass on why leadership behaviors—not just team skills—determine whether continuous discovery thrives.

For further exploration, I recommend these resources. Follow Teresa Torres: https://ProductTalk.org. Follow Petra Wille: https://Petra-Wille.com. Product Talk Academy’s Train Your Team by Teresa Torres: https://learn.producttalk.org/train-your-team. Melissa Perri’s “Train leaders first, not last.” Linkedin post: https://www.linkedin.com/posts/melissajeanperri_train-leaders-first-not-last-most-product-activity-7380927349732839424-sqBJ/. Coaching for Product Leaders/Executives by Petra Wille: https://www.petra-wille.com/coaching-packages. Product Leadership Wheel by Petra: https://www.petra-wille.com/plwheel.

To get hands-on with discovery skills, check out Story-Based Customer Interviews: https://learn.producttalk.org/course/story-based-customer-interviews. For visual management, see An idea board—do we see enough potential?: https://images.squarespace-cdn.com/…/idea_board3.png and Four Taskboards in a simple illustration: Idea Board, Product Overview Board, Product Discovery Board and Development Team Board: https://images.squarespace-cdn.com/…/boards.png. Opportunity Assessment: Do We Want to Invest in Discovering This Idea?: https://www.petra-wille.com/blog/opportunity-assessment-do-we-want-to-invest-in-discovering-this-idea?rq=taskboard.

If you’re preparing your organization to adopt a product operating model, read Is Your Organization Ready to Adopt the Product Operating Model?: https://www.producttalk.org/organizational-readiness/ and The Product Operating Model Explained: From Pilot Teams to Full Transformation: https://www.producttalk.org/the-product-operating-model/. Communities of practice can accelerate leadership growth: Community of Practice by Petra: https://www.petra-wille.com/community-of-practice. For foundational texts, see TRANSFORMED: Moving to the Product Operating Model: https://www.svpg.com/books/transformed-moving-to-the-product-operating-model/ and EMPOWERED: Ordinary People, Extraordinary Products: https://www.svpg.com/books/empowered-ordinary-people-extraordinary-products/.

I’d love to hear how you’re enabling continuous discovery in your context. What leadership behaviors have made the biggest difference? Where does your corporate immune system show up, and how are you addressing it with pilot teams, clearer expectations, and a consistent product operating model? Share your perspective—I read every comment.

Inspired by this post on Product Talk.

December 9, 2025
Master the Kano Model: Prioritize Features That Delight and Drive Product-Led Growth

When I sit down with our product trios to shape the next quarter’s roadmap, I rely on The Kano Model to cut through the noise and focus on what actually moves the needle for customers and the business. It gives me a rigorous, human-centered lens for separating baseline expectations from differentiators and sustained value creation.

Learn how the Kano Model prioritizes the product features that matter by categorizing them into must-haves, satisfiers, and delighters.

Here’s how I think about each category in practice. Must-haves are the non-negotiables—if they’re missing or broken, no amount of innovation will save the experience. Satisfiers scale linearly with user happiness; do them better, and customers feel the improvement immediately. Delighters surprise users with unexpected value that elevates the product’s perceived quality and creates memorable moments that fuel advocacy.

In continuous discovery, I mix quantitative Kano surveys with qualitative interviews to validate which capabilities land in each bucket for specific segments. We ask both functional and dysfunctional questions (e.g., “How would you feel if this feature existed?” and “How would you feel if it didn’t?”) to avoid false positives and to distinguish true delighters from nice-to-haves. This approach de-risks assumptions and keeps our product discovery anchored in real customer voice.

Translating insights into action starts with outcomes vs output OKRs. Must-haves protect core outcomes like reliability, trust, and activation. Satisfiers inform product roadmapping and sprint planning by tying investment to measurable improvements such as speed, accuracy, or completion rate. Delighters earn a deliberate share of the roadmap to strengthen competitive differentiation and to refresh our value proposition before market expectations shift.

Kano also sharpens product-led growth motions. By aligning satisfiers with key activation steps and running retention analysis on cohorts exposed to delighters, we can see where excitement features become habit-forming behaviors. When a delighter consistently correlates with improved retention or expansion, it graduates into the backbone of our product positioning.

Stakeholder management gets easier with a shared framework. I present the portfolio as a balanced mix: must-haves that protect reputation, satisfiers that demonstrate continuous improvement, and delighters that signal vision. This narrative connects short-term reliability with long-term strategy and helps leaders understand why some high-effort ideas are best sequenced behind critical must-haves or high-yield satisfiers.

A quick caution: delighters decay. What delights today often becomes tomorrow’s must-have. I schedule periodic re-reads of our Kano results, especially after major releases or market shifts, to recalibrate where features sit. Combined with A/B testing and usage analytics, this habit prevents us from over-investing in fading differentiators and ensures our roadmap stays crisp and customer-centered.

If your roadmap feels crowded or your team debates priorities without resolution, bring The Kano Model to your next planning session. It adds structure to product discovery, clarifies trade-offs, and helps us deliver a roadmap that not only works—but wins.

Inspired by this post on Product School.

December 9, 2025
Sharper Signals, Stronger Collaboration: How Session Replay Accelerates Problem Solving

In fast-moving product cycles, weak signals slow teams down and let avoidable issues linger. I’ve been leaning on Session Replay to strengthen those signals and align stakeholders faster, especially when we’re balancing roadmap bets with day-to-day reliability fixes.

Discover how frustration analytics, error analytics, and shareable filters in Session Replay help you spot problems faster and collaborate more effectively.

Frustration analytics has become my shortcut to the moments that truly matter. Instead of sifting through countless replays, I start where friction peaks and focus on the sessions that best represent real user pain. In one onboarding flow, these insights pointed us to a confusing step that was suppressing user activation; a simple adjustment to the layout and copy led to higher completions and fewer support tickets.

Error analytics turns anecdotes into evidence. By pairing error trends with conversion and retention analysis in Amplitude analytics, we isolate the defects with the highest customer and revenue impact. That clarity helps my team sequence fixes in sprint planning with confidence—and it gives leadership a clean narrative for why certain issues deserve priority now.

Shareable filters have been a quiet superpower for cross-functional collaboration. I create saved views for specific cohorts—first-time users, power users, or high‑value accounts—so engineering, design, and support can reproduce exactly what I’m seeing in Session Replay. No more screen recordings in Slack or back-and-forth on “what filters did you use?” Everyone starts from the same context and moves to decisions faster.

This workflow fits naturally into how our product trios practice continuous discovery. We pick one question each week, open a shared filter, and review a handful of targeted sessions together. Within the same unified analytics platform, we connect what we observe to metrics that matter, then translate insights directly into product roadmapping and sprint planning without losing momentum.

If your goal is sharper detection of issues and stronger collaboration across stakeholders, these capabilities deserve a place in your toolkit. They compress time-to-insight, improve stakeholder management, and fuel product-led growth by focusing attention where it delivers the most customer value.

Inspired by this post on Amplitude – Best Practices.

December 3, 2025
Why Betting on Amplitude Paid Off: My Take on Dan Grainger’s High-Impact Migration

I love when a bold platform bet translates into tangible product impact. Watching a team commit to a unified analytics platform and then operationalize it across the business is a master class in strategic focus and change management. That’s exactly what this story captures—and why it resonates with my own experience leading complex analytics migrations.

Learn how Dan Grainger led Haven's migration to Amplitude, focusing on user-friendly analytics and data governance for non-technical teams.

That single sentence distills what matters most: if analytics aren’t accessible to non-technical teams, you won’t get the adoption needed to drive outcomes. “User-friendly analytics” isn’t window dressing; it’s the linchpin for empowered product teams and true product-led growth. When teams can ask and answer their own questions—without waiting on analysts—velocity and quality of decision-making improve immediately.

From a product management lens, two elements stand out. First, the choice of Amplitude analytics as the central system of insight—consolidating scattered tools into a unified analytics platform—creates one source of truth for activation, adoption, and retention analysis. Second, a rigorous approach to data governance ensures that trust in the data scales alongside usage, especially for non-technical stakeholders who need clarity, not caveats.

Execution matters. In my playbook, these transformations succeed when you treat them as product initiatives, not IT projects. I partner early with stakeholder management champions, form product trios to define the measurement plan, and use in-app guides, product tours, and targeted onboarding to drive behavior change. The goal is simple: shorten time-to-insight for frontline teams while keeping the instrumentation robust and consistent.

Data governance is the quiet force multiplier. Clear tracking plans, consistent event taxonomies, role-based access, and privacy-by-design guardrails prevent entropy. When everyone speaks the same analytics language, you avoid “metric du jour” debates and keep the focus on outcomes vs output OKRs. That’s where scalable impact comes from.

Measurement closes the loop. I’ve found that when non-technical teams can self-serve retention analysis, funnel drop-off, and user activation patterns, they start running continuous discovery by default—asking better questions, testing smarter hypotheses, and accelerating learning cycles. Amplitude’s strength is not just visualizing what happened, but making it easy to connect behavior to outcomes teams care about.

The broader leadership lesson is straightforward: choose a platform that your broadest set of contributors can and will use daily, invest early in governance, and build enablement into your rollout plan. That’s how a migration becomes a multiplier. When the right platform meets the right operating model, the win is less about a tool and more about a learning culture that compounding value over time.

If your analytics stack feels fragmented or underused, this is your nudge. Align on a unified analytics platform, meet teams where they are with user-friendly analytics, and let governance do the heavy lifting behind the scenes. The payoff—in speed, alignment, and smarter bets—comes faster than most teams expect.

Inspired by this post on Amplitude – Best Practices.

December 2, 2025
From Output to Outcomes: How I Align Stakeholders Around a True Product Operating Model

When I push our organization to adopt the product operating model, I’m emphasizing a foundational shift—from “shipping roadmaps of features (output)” to solving real customer and business problems, measured by “business results (outcomes)”. That’s the difference between activity and impact, and it’s the only way to build durable value at scale.
This change inevitably reaches beyond the product organization. It reshapes how company stakeholders in Sales, Marketing, Customer Success, Finance, Legal, Security, and Operations engage with product teams, and it reframes what they expect from us. Instead of asking, “When will feature X ship?” they learn to ask, “How will we move the outcome that matters?”
In practice, the product operating model is a contract: product teams commit to outcomes, and stakeholders commit to partnership. That partnership means we co-own the problem, align on evidence, and share accountability for results. The reward is clarity—everyone sees how their work ladders to strategy and why the sequence of work makes sense.
Here’s how I align stakeholders around this model. First, I ground everything in outcomes vs output OKRs. We replace feature roadmaps with a clear strategy, prioritized problems, and measurable objectives. Our product roadmapping and sprint planning then serve the objectives—not the other way around—so capacity is allocated to the highest-leverage bets.
Second, I build empowered product teams around product trios (product, design, engineering). We practice continuous discovery with stakeholders: we share opportunity trees, test riskiest assumptions early, and bring partners into research when it informs go-to-market strategy, pricing, or enablement. This keeps us honest and avoids late-stage surprises.
Third, I establish operating rhythms that make outcomes visible. Monthly stakeholder reviews focus on progress toward objectives and what we’re learning—not status theater. Quarterly, we connect OKRs to business performance so leaders can see the throughline from discovery and delivery to pipeline, retention, or margin. If priorities shift, we renegotiate objectives explicitly.
Fourth, I define metrics that stakeholders trust. We use a balanced set of leading indicators (activation, engagement, cycle time) and lagging indicators (revenue, retention, unit economics). We socialize definitions early so no one debates the scoreboard mid-game. The result: faster decisions and less “data whiplash.”
Fifth, I invest in change management. Moving from outputs to outcomes can feel threatening if your success has historically been measured by launch volume or roadmap commitments. I address this head-on with training, transparent comms, and clear decision rights. The message is simple: outcomes create more autonomy for empowered product teams and more predictability for stakeholders.
At HighLevel, this approach has been especially powerful when cross-functional dependencies are high. For example, when we set an objective to improve user activation for a new CRM integration, we didn’t promise a bundle of features. We committed to a measurable lift in activation and a shorter time-to-value, co-owned with Customer Success and Marketing. That alignment unlocked smarter experiments, tighter enablement, and a more credible launch narrative.
The anti-patterns are predictable: treating OKRs as a renaming of the roadmap, equating discovery with indecision, or isolating product decisions from go-to-market strategy. The cure is equally consistent: bring stakeholders into discovery, attach every bet to an objective, and show progress with evidence—not just demos.
Ultimately, the product operating model is a leadership choice. It asks us to trade certainty theater for learning velocity, and feature checklists for business impact. When stakeholders see that shift pay off—in faster cycles, clearer priorities, and results that matter—support for the model moves from compliance to conviction.

Inspired by this post on SVPG.

December 1, 2025
Design Your Community of Practice: Proven Strategies for Continuous Learning and Growth

When I think about how I stay sharp as a product leader, one principle anchors my approach: design your learning system—don’t leave it to chance. Communities of practice are that system. They turn curiosity into a habit, accelerate product discovery, and strengthen product management leadership across empowered product teams.

I recently dug into a powerful conversation on the All Things Product podcast that explores how product people can intentionally design their own communities of practice—and why that matters for long-term learning and growth. The insights apply whether you operate as an independent coach or you’re scaling continuous discovery inside a product org.

I appreciated the contrast in learning styles. Teresa shares an introvert-friendly approach to continuous learning: curating a personal learning network (PLN) filled with people she wants to learn from. Petra contrasts that with a more collaborative style—learning with others through small peer groups, hackathons, and local meetups. Together, they unpack how each approach supports curiosity-driven development, how to find your “definition of good” when starting something new, and the habits that make learning a deliberate practice.

In my own practice leading product trios and shaping outcomes over output, I rotate between these modes. When I need speed or depth on topics like product discovery or stakeholder management, I learn from people: I curate a tight set of voices, reverse-engineer their decisions, and study how they frame trade-offs. When I need new patterns or accountability, I learn with people: I form small peer circles to review experiments, pressure-test roadmaps, and critique discovery plans. Both paths create momentum—one by focus, the other by feedback.

Key takeaways I’m acting on right now:

– What a “community of practice” really means in modern product work: the infrastructure that makes continuous discovery sustainable—and keeps empowered product teams aligned on craft.

– The difference between learning from people vs learning with people—and when to use each depending on whether you need depth, breadth, or accountability.

– How to find like-minded peers for collaborative learning: start with one person you respect, ask who they regularly spar with, attend one local meetup with a clear learning goal, and follow up with a structured exchange.

– Building your Personal Learning Network (PLN): set a theme (e.g., pricing, product roadmapping and sprint planning), prune it quarterly, and track “who I’m learning from” with the same rigor you track stakeholders.

– Personal knowledge management as a product skill: treat notes, highlights, and artifacts as a system, not a junk drawer—so insights compound and are easy to retrieve when you need them.

– Why curiosity-driven learning builds stronger product intuition: schedule time for curiosity and socialize it with peers so it scales beyond individual motivation.

– How committing to talks, books, or courses drives deeper learning: public commitments create productive pressure and force you to clarify your thinking.

Here’s the simple playbook I use with my team: define a quarterly learning theme; curate a small PLN aligned to that theme; assemble a peer circle (PM, Design, Eng) for monthly critiques; commit to shipping one artifact publicly (a talk, guide, or internal workshop); and close the loop with a short write-up on what changed in our decisions, discovery cadence, or bets. It’s lightweight, measurable, and fits neatly alongside product-led growth priorities.

Two quotes from the discussion capture the spirit perfectly:

“Nobody on that list knows they’re in my personal community of practice.” — Teresa Torres

“Sometimes you don’t know your new definition of good until you start learning.” — Petra Wille

If you’d like to go deeper, you can listen to the episode on your favorite platform:

Listen to this episode on: Spotify | Apple Podcasts

Prefer video? Watch here: https://www.youtube.com/watch?v=4jimuRg_Q_k

Resources & Links I found useful:

Follow Teresa Torres: https://ProductTalk.org

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

Communities and references mentioned:

Product Tank Hamburg

Product at Heart conference

Mind the Product community

Curation – All Things Product with Teresa & Petra episode

Hamel’s Blog

AI Evals for Engineers and PMs course by Hamel Husain (get 35% off through Teresa’s link) on Maven

Harold Jarche’s Personal Knowledge Management workshop

Petra’s book, Strong Product Communities – The Essential Guide to Product Communities of Practice

I’d love to hear how you’re designing your own community of practice. What’s your learning theme this quarter? Which peers are you building with, and what commitments are helping you go deeper? Drop your thoughts—I’ll share my own PLN stack and peer-circle cadence in a future post.

Inspired by this post on Product Talk.

November 25, 2025
25 High-Impact Career Paths for Software Engineers Beyond Coding: My Real-World Playbook

I’ve spent years helping talented engineers explore what’s next when pure coding no longer feels like the only—or best—path. From hiring across cross-functional teams to mentoring career pivots, I’ve seen firsthand how engineering strengths translate into high-leverage roles that shape product, strategy, and growth.

Software engineers have alternative career options leveraging their skills in roles like product manager, data scientist, business analyst, and 22 more.

When an engineer moves into product management, they’re not starting from scratch—they’re redirecting problem-solving, systems thinking, and customer empathy toward outcomes. In practice, that means mastering product discovery, strengthening stakeholder management, and getting fluent in product roadmapping and sprint planning, so decisions are guided by impact rather than “outputs vs outcomes” confusion. I’ve watched this transition unlock empowered product teams and clearer prioritization across complex backlogs.

Data-oriented paths are equally compelling. If you enjoy experimentation and evidence-based decisions, roles in analytics or data science reward rigor. Think A/B testing, identifying the minimum detectable effect (MDE), and using tools like Amplitude analytics to translate behavioral signals into product bets. Pair that with retention analysis and you’ll become indispensable to growth conversations.

Business-facing roles such as business analyst or product marketing manager are ideal if you’re energized by customer problems and market narratives. Your engineering fluency sharpens value propositions, product positioning, and go-to-market strategy in a way that resonates with both buyers and builders. In my teams, the best bridges between product and revenue often came from former engineers who could articulate trade-offs with clarity.

If operational excellence is your edge, consider SRE, DevOps, or cybersecurity. The same instincts that push you toward clean CI/CD pipelines and resilient architectures translate well into incident management, threat detection and response, and privacy-by-design practices. These roles reward systems thinking and the ability to balance reliability with delivery speed.

For engineers who love community and storytelling, developer evangelism is a natural fit. You’ll translate complex concepts into actionable guidance, from in-app guides and product tours to UX writing and documentation. The best evangelists I’ve worked with turn feedback loops into product insight, strengthening activation and product-led growth without heavy sales pressure.

Customer-facing technical roles—solutions engineer, forward deployed engineer, or technical consultant—let you stay close to the product while solving real-world problems. You’ll drive onboarding quality, user activation, and adoption while surfacing insights that influence roadmaps. Done well, this work tightens the loop between customer outcomes and product decisions.

AI-centered roles are expanding rapidly. If you’re curious about AI Strategy, retrieval-first pipelines, or the practical use of LLMs for product managers, you can bring an engineer’s discernment to a noisy space. The most valuable contributors here pair pragmatic architecture choices with clear risk management and measurable business value, not hype.

Leadership tracks remain a strong option too. The IC to manager transition isn’t about title; it’s about raising the ceiling for others. You’ll coach empowered product teams, shape organizational development, and align initiatives to defensible metrics—think DORA metrics for flow, leading indicators for value, and OKRs that measure outcomes over output.

If you’re exploring a pivot, start small and intentional. Run “career A/B tests” by taking on cross-functional projects, shadowing adjacent roles, or shipping a lightweight portfolio that demonstrates the new muscle. Join a ProductCon session, practice conference networking, and refine a narrative that links your engineering foundation to the outcomes your target role owns.

Finally, map your personal unfair advantages—domain knowledge, systems thinking, customer empathy, or operational rigor—to the roles that value them most. With focus, you can reposition your engineering experience into a differentiated story that accelerates your next chapter. The breadth of options is real, and with a deliberate plan, you’ll turn curiosity into conviction—and conviction into impact.

Inspired by this post on Product School.

November 24, 2025
UX Product Manager Playbook: Master the Design-PM Overlap and Fast-Track Your Career

I’ve spent years leading product organizations where the best outcomes emerged from a tight handshake between design rigor and product strategy. The role that consistently sits at that high-impact intersection is the UX product manager. Done well, it’s the engine of product-led growth: deeply empathetic with users, relentlessly focused on outcomes, and fluent in both discovery and delivery.

Curious about the UX product manager role? Discover how it overlaps with design, PM, and why it might be the next step in your career.

At its core, a UX product manager owns the customer experience end-to-end while steering the business toward measurable outcomes. I translate user insights into prioritized problems, shape the solution space with designers and engineers, and validate decisions with data. Unlike a traditional PM who may skew toward market sizing and business cases, or a designer who may emphasize interaction patterns and visual systems, I integrate both frames to ensure we ship experiences that users adopt, retain, and recommend.

On the design side, I work hand-in-hand with product designers and UX writing to define the problem, craft flows, and stress-test usability. I obsess over clarity, affordances, and friction—especially during onboarding. Strong UX writing often makes or breaks first-run experiences, and I treat microcopy as part of the product, not an afterthought.

On the product management side, I anchor teams on outcomes vs output OKRs, facilitate product discovery, and drive prioritization against clear value propositions. I operate within empowered product teams and build tight product trios with design and engineering so we can validate assumptions fast, reduce waste, and increase the surface area for innovation.

Day-to-day, my craft blends qualitative research and quantitative analysis. I lean on tools like Amplitude analytics, Pendo, and Intercom to instrument funnels, run A/B testing, and perform retention analysis. When I experiment, I’m explicit about the minimum detectable effect (MDE) to avoid inconclusive reads. I measure the impact of changes on activation, time-to-value, and core feature adoption—and I make sure we can trace improvements to specific user segments.

User activation is my early warning system. If activation is lagging, I revisit the first-mile experience: guidance, progressive disclosure, in-app guides, product tours, and contextual tooltip design. I also ensure our onboarding is sequenced around the critical path to value rather than a feature parade. When activation improves, downstream KPIs like retention and expansion usually follow.

If you’re looking to become a UX product manager, start by strengthening three pillars: customer insight, product strategy, and experience design. Build a habit of continuous product discovery—co-creating with users, running lightweight experiments, and synthesizing findings into actionable decisions. Learn to translate insights into a product roadmapping and sprint planning cadence that energizes the team and keeps stakeholders aligned.

Your portfolio should read like a decision journal, not a gallery of screens. For each case study, frame the problem, outline constraints, describe alternatives considered, and show the experiments you ran. Include the metrics that mattered (activation, adoption, retention), the instrumentation you used, and the decisions you made when data was ambiguous. Hiring managers want to see your thinking under uncertainty and how you rallied cross-functional partners.

Communication and stakeholder management are differentiators. I tailor narratives for executives (trade-offs and business impact), for engineers (clarity on constraints and sequencing), and for design (user jobs, heuristics, and the narrative arc of the experience). Clear, frequent updates keep momentum high and reduce thrash, especially when priorities shift.

On the execution side, I make sure delivery never drifts from discovery. Every sprint is tied to a learning goal or outcome. We pair quick prototypes with production experiments, and we celebrate killing ideas that don’t move the needle. That discipline keeps us focused on outcomes and accelerates iteration speed without sacrificing quality.

Finally, a few career accelerators: get comfortable with analytics, learn the language of UX writing, practice story-based demos, and go deep on onboarding patterns. If you can move activation, you can change the trajectory of the business. Pair that with a strong perspective on product-led growth and you’ll be ready to lead product work that compounds.

The UX product manager role is a force multiplier. It’s where rigor meets empathy, and where design and PM converge to create experiences customers love—and businesses rely on. If that intersection energizes you, you’re already on the right path.

Inspired by this post on Product School.

November 19, 2025
How I’m Rebuilding Customer Service for 2026: An AI‑First Playbook for Real Impact

Like many support leaders right now, I’m deep in 2026 planning. The more I map scenarios and stress-test assumptions, the clearer one thing becomes: the way work gets done has fundamentally changed, and that change must reshape our customer service organization.

In 2026, you won’t get the full value of AI by keeping your org chart, systems, and operating model the same. You need to think differently about how support is structured, how performance is owned, and how your systems evolve around an AI-first model. That’s the lens I’m using across my team and our cross-functional partners.

To help you do the same, I’m launching a 2026 customer service planning series. Over the next five weeks, I’ll share how I’m approaching roles, skills, organizational design, and an operating model that makes AI the backbone of support—not a bolt-on feature.

We’ll publish each edition here and on LinkedIn. If you’d rather get them by email as soon as they go live, drop your details and I’ll send each edition straight to your inbox.

But before you can make any of those decisions, you need the right mindset and the right internal conditions for change. That’s where I’m starting this week.

Week 1: Start with a mindset shift

If you were building support from scratch today, you’d design around AI from day one. That’s the mindset to carry into 2026—and it’s the mindset I’m using to guide investment and accountability.

Too many teams still treat AI like a feature instead of infrastructure. They tack it onto existing processes, limit scope to tier-one issues, and never evolve the organization or systems around it. I’ve seen that approach stall progress and fragment the customer experience.

Those teams are thinking too small. They chase incremental efficiency, underinvest in the system change required to make AI successful, and get stuck. The result: a reactive team, a choppy customer experience, and value left on the table.

AI Agents are fully capable, end-to-end resolution engines. They fundamentally change the architecture of support.

To plan effectively and get the most value out of the technology, you need to adjust your mental model. Here are the mindset changes I’m prioritizing.

1) Move from ‘AI as a tool’ to ‘AI as infrastructure’

For the past decade, support systems have been the intermediary between customers and human support agents. AI isn’t an intermediary, it’s the first touchpoint (and often the last), the primary resolver, it manages workflows, orchestrates handoffs, and takes real actions.

Planning with the “AI is a tool” mindset leads to small optimizations that don’t move the needle. Planning with the “AI is infrastructure” mindset lets you redesign around the real sources of value creation.

Here’s what I’m designing around in 2026:

• Clear ownership of Agent performance

• A feedback loop that never shuts off

• A shared understanding of when humans step in

• Systems that evolve as AI capabilities expand

This framing sets up every decision that comes later in your planning process.

2) Look at how the work is changing

You need to plan your 2026 support organization around what the distribution of work will be—not what it is today. AI has shifted where volume goes, what humans spend time on, where judgment is needed, how performance is measured, and how the customer experience is designed.

If your planning assumes the current distribution is stable, you’ll design the wrong structure. I’m modeling for the work that’s coming, not just the work on our queue today.

3) Think like a product leader

When customers primarily interact with your AI Agent, support becomes responsible for designing the customer experience—not just managing it.

“Support is becoming a product function, and you are becoming a product leader”

Design your 2026 support org for AI from day one. This Gamma testimonial shows how an AI agent (Fin) resolves 80%+ of inbound requests, letting a small team scale customer service efficiently without increasing headcount.

Support is now a product surface, and support teams act like AI product teams. They:

• Design the customer experience

• Create and curate the knowledge layer that drives AI quality

• Maintain continuous improvement loops and tune system behavior over time

This is a big shift. Your planning—hiring, skills, rituals, and metrics—needs to reflect that evolution.

4) Redefine performance

This is a big mental leap for support leaders. Traditional performance was measured on speed and satisfaction, but AI performance is measured on resolution, impact, and system reliability.

Planning for 2026 means assuming that:

• Humans will handle a smaller % of volume.

• Customer experience will be shaped by AI’s performance, not throughput

• “Support productivity” gets measured differently

When AI handles the bulk of your support volume, you need new metrics for how your team creates value. In practice, that means instrumenting AI and human-in-the-loop workflows with the same rigor you’d apply to a customer-facing product.

5) Understand that your value increases as AI takes on more work

You need to re-orient your team around AI’s performance to get the most value out of it. The more complex work you give it, the higher impact it will have.

Instead of routing complex, messy questions straight to your human team, shift their focus to improving the AI system so it can take on more over time.

Automating low-effort questions reduces noise, but automating complex workflows changes the economics of your entire team. It creates asymmetric returns that compound as AI absorbs the work that once demanded the most time and skill.

6) Plan for adaptability

A big difference between traditional planning and 2026 planning is simple: change will be constant.

“Change is hard, but the teams that adapt will be the ones who get the most out of this opportunity”

AI learns, evolves, and improves continuously. I’m asking, “How do we build an organization designed to adapt fast as the system evolves?” That question is informing everything from team topology to knowledge governance and experimentation cadence.

Food for thought

Heading into 2026, your org chart will look different—and that’s a good thing. Your people will play new, more meaningful roles as designers, curators, and stewards of an AI-first customer experience.

Once you accept that 2026 demands a different way of thinking, working, and planning, you can move to the next stage: designing the support organization that fits this future. I’ll share exactly what that looks like next week, including roles, skills, and ownership models that have worked well in my experience.

Want the full series delivered by email? Drop your details and I’ll send each edition to your inbox as soon as it’s published.

Inspired by this post on The Intercom Blog.

November 18, 2025