Tag: empowered product teams

  • AI Context Pulling Playbook: How I Get LLMs and Teams to Collaborate for Better Product Outcomes

    AI Context Pulling Playbook: How I Get LLMs and Teams to Collaborate for Better Product Outcomes

    In my role leading product, I’ve learned that the fastest path to higher-quality deliverables from large language models (LLMs) is not a clever prompt—it’s rigorous context. I call the practice AI context pulling: a repeatable way to assemble, compress, and structure the most relevant knowledge before the model ever starts generating. Done well, it turns generative AI into a dependable partner for discovery, prioritization, and execution.

    AI context pulling means I proactively gather the right artifacts (customer insights, analytics, strategy, constraints), manage context windows intentionally, and shape the model’s task with clear objectives and guardrails. This reduces hallucinations, improves alignment, and creates traceability back to sources—critical for product management leadership and stakeholder trust.

    Learn a new way in which product professionals can collaborate with AI to get even better results on their projects.

    Here’s the simple flow I use: first, I define the intent (e.g., “synthesize discovery interviews for a positioning brief”). Next, I inventory relevant context: top customer pains from product discovery, usage patterns from Amplitude analytics, recent support trends from Intercom, and any constraints from our product strategy. Then I run a retrieval-first pipeline to select only the most pertinent slices—favoring recency, representativeness, and canonical sources.

    Because context window management matters, I compress long documents into short, source-cited summaries and keep raw excerpts handy when nuance is important. My prompts follow a consistent structure: role and objective, constraints and audience, curated context, the explicit ask, preferred output format, and a brief self-check (e.g., “cite sources and flag uncertainty”). This is prompt engineering for reliability, not theatrics.

    A quick example: when drafting a one-page feature brief, I attach three items—the product strategy paragraph that sets the frame, a usage cohort analysis that highlights who’s affected, and five verbatim customer quotes. I ask the LLM to propose a problem statement, success criteria, and a shortlist of solution hypotheses, each tied to a cited piece of evidence. The result is a grounded, decision-ready artifact I can share with product trios and stakeholders.

    Tooling-wise, I keep it pragmatic. A lightweight retrieval-first pipeline (embeddings, metadata filters, and recency rules) ensures the LLM pulls what matters. I version prompts and contexts together so I can run quick A/B testing on output quality. And I log decisions and sources to support eval-driven development and continuous discovery.

    Common pitfalls are avoidable. Too little context yields generic answers; too much overwhelms the model. Stale docs can mislead; curate aggressively. Vague asks invite fluffy prose; specify outcomes, audiences, and formats. If the task is high risk, I bias toward smaller, well-cited outputs and expand iteratively with human review in the loop.

    To measure impact, I track rework rate, review time, and stakeholder alignment on first pass. Over time, teams adopting AI context pulling report clearer artifacts, faster synthesis cycles, and more confident decisions—because every recommendation traces back to evidence. That’s how humans and LLMs truly collaborate better: we provide the right context, and the model amplifies our judgment.

    If you’re ready to operationalize this, start by templatizing your most common product workflows—discovery synthesis, roadmap rationale, and release notes—and attach small, high-signal context packs. With a retrieval-first mindset and disciplined prompting, AI becomes an extension of your product craft, not a gamble.


    Inspired by this post on Pendo – Perspectives.


    Book a consult png image
  • Enterprise Go-To-Market That Wins: How Product Marketing Supercharges Analytics Adoption

    Enterprise Go-To-Market That Wins: How Product Marketing Supercharges Analytics Adoption

    In my role leading product management at HighLevel, I’ve learned that enterprise go-to-market lives or dies by the strength of the partnership between product and product marketing. When we operate as one team, we turn complex capabilities into clear outcomes that resonate with buyers and drive adoption at scale.

    I’m especially energized by the archetype of a product marketing manager at a leading analytics platform—someone “focusing on go-to-market solutions for enterprise customers.” That mandate requires rigor across product positioning, value proposition design, competitive differentiation, and sales enablement, all while aligning deeply with engineering and customer success. In practice, it means translating signal from a unified analytics platform into narratives and plays that close deals and expand accounts.

    Day-to-day, I partner with product marketing to validate messaging through continuous discovery and data. We use Amplitude analytics to instrument activation, engagement, and retention analysis—then feed those insights into product-led growth motions like in-app guides and product tours. A/B testing grounded in a clear minimum detectable effect (MDE) helps us separate noise from impact, while points of parity and true differentiation shape the story sellers can confidently carry into enterprise conversations.

    This is also where outcomes vs output OKRs keep us honest. Rather than celebrating launches, we anchor on measurable behavior change: faster time-to-value, higher user activation, deeper feature adoption, and multi-threaded stakeholder engagement. Product trios provide the operating rhythm, and stakeholder management ensures sales, marketing, and success move in lockstep with the roadmap and GTM calendar.

    If you’re building an enterprise GTM motion, start by tightening your value proposition to the top three pains your best-fit accounts actually feel, validate with real usage data, and then enable your field teams with crisp, data-backed talk tracks. With the right PM–PMM alignment and analytics foundation, your go-to-market strategy becomes a compounding advantage—not just a launch plan.


    Inspired by this post on Amplitude – Perspectives.


    Book a consult png image
  • Inside Google’s Product Model: Hard-Won Lessons to Build Empowered, Outcome-Driven Teams

    Inside Google’s Product Model: Hard-Won Lessons to Build Empowered, Outcome-Driven Teams

    I’ve been systematically exploring how the product model shows up inside iconic companies. After studying “The Product Model at Spotify” and “The Product Model at Amazon,” I’m turning my lens to Google—specifically, how the product operating model, product culture, and product strategy manifest in practice and what we can pragmatically take back to our own organizations.

    When I talk about the product model, I’m looking at the machinery that connects strategy to outcomes: empowered product teams, clear decision rights, tight product trios, continuous discovery, data-informed bets, and an operating cadence that enables learning at speed. My goal here is to unpack how those elements come together at Google and translate them into repeatable patterns you can adopt.

    At a high level, I focus on how teams are empowered to solve problems rather than ship outputs, how outcomes vs output OKRs clarify what matters, and how experimentation (from rapid prototyping to A/B testing) de-risks decisions before they scale. I also examine how engineering and product partner to balance platform scalability with customer value, and how stakeholder management reinforces alignment without slowing teams down.

    Why does this matter? Because the product model is a lever for resilience and speed. When product strategy is explicit and the operating model is built for learning, organizations multiply the impact of talented people. That’s how small, focused teams repeatedly deliver outsized results—even in complex, regulated, or high-scale environments like Google.

    In the sections that follow, I’ll synthesize what I see as the core patterns behind Google’s approach and distill them into actionable guidance: how to structure product trios, how to run continuous discovery alongside delivery, how to set and calibrate OKRs for outcomes, and how to evolve your product culture so empowered product teams can do their best work. My aim is not to idolize a model, but to extract what’s portable and help you adapt it to your context.


    Inspired by this post on SVPG.


    Book a consult png image
  • What It Takes to Build AI-Powered Products: A Senior Engineer’s Playbook and Mindset

    What It Takes to Build AI-Powered Products: A Senior Engineer’s Playbook and Mindset

    I spend my days partnering with technical leaders who bridge invention and impact. The role of a Senior Software Engineer at Amplitude working on AI-powered products epitomizes how engineering and product fuse to ship customer value with speed, safety, and conviction. In my world, that fusion isn’t accidental—it’s designed, measured, and relentlessly improved.

    When I form product trios—engineering, product, and design—we clarify the problem, the target users, and the measurable outcomes before a single line of code ships. This is how empowered product teams operate: we trade feature wish-lists for hypotheses, align on success metrics, and commit to learning loops that turn ambiguity into progress.

    On the technical front, modern AI systems demand a retrieval-first pipeline, robust data contracts, and a thoughtful orchestration layer for LLMs. I expect eval-driven development to be first-class: offline unit-style evals for prompts and policies, and online evals that track behavior changes and quality at scale. This rigor gives us confidence to ship, learn, and iterate without burning cycles on guesswork.

    Velocity matters, and so does reliability. I look for CI/CD that makes small, safe, frequent releases the default, and for DORA metrics to shine a light on delivery health. Pair that with platform scalability, clear SLOs, and pragmatic SRE practices, and teams earn the right to move fast without breaking trust.

    Responsible AI is non-negotiable. We operationalize AI risk management with guardrails, input/output filters, red-teaming, and human-in-the-loop review where stakes are high. Data governance and privacy-by-design ensure that our creativity never outruns our compliance—because durable products are built on durable trust.

    Impact comes from evidence. I advocate for disciplined A/B testing, careful minimum detectable effect (MDE) planning, and retention analysis that ties feature work to real business outcomes. Clear analytics pipelines and transparent dashboards keep stakeholders aligned and make good decisions repeatable.

    Ultimately, the Senior Software Engineer I want to collaborate with is a builder who balances systems thinking with customer empathy: someone who can design reliable architectures, instrument the work with meaningful evals, and co-lead discovery to de-risk the roadmap. When we combine that mindset with crisp execution, AI-powered products stop being demos—and start becoming indispensable.


    Inspired by this post on Amplitude – Perspectives.


    Book a consult png image
  • Plan Your 2026 Product Conference Calendar: Top Events, Locations, and Insider Tips

    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.


    Book a consult png image
  • 2026 Support Capacity Playbook: Bold AI Automation, Smarter Staffing, Zero‑Surprise SLAs

    Capacity planning has always been a high-stakes exercise in customer service, and when you miss, the signal shows up fast in backlogs and SLAs. I’ve lived that pressure across multiple cycles, and 2026 will reward teams that plan differently. AI fundamentally changes capacity planning because it changes the work. It resolves the bulk of your volume, speeds up execution, and elevates the complexity and value of what humans handle. The consequence is simple: planning models must evolve. This is the final installment in my 2026 customer service planning series, and I’m focusing on the tension every leader feels right now—be ambitious about automation, but avoid the trap of understaffing if your assumptions don’t hold. My goal is to share how AI changes the logic of capacity planning, what I’ve learned implementing these practices with my team and with customers, and the common traps to avoid. Traditional planning rests on relatively stable assumptions: volume grows predictably, work types stay consistent, handle times don’t swing dramatically, and productivity improves slowly with better tools and training. In an AI-first model, none of that is guaranteed, and the fundamentals flip. The mix of work changes as AI absorbs a growing share of simpler conversations, leaving humans with deeper, more time-consuming issues that demand human-to-human connection. Demand can actually increase when you remove friction, so AI can both resolve more and attract more volume. Human time splits differently as teammates solve customer problems and also review AI behavior, give feedback, improve content, and support system-level work. Performance becomes dynamic, not fixed—automation rate isn’t a one-time number; it can rise with care and fall with neglect. If you plan for 2026 using a pre-AI model—assuming similar productivity, similar work mix, and a linear relationship between volume and headcount—you will underestimate what it now takes to run a high-performing support organization. There are many metrics you can track, but the one to put at the center is automation rate (AI Agent involvement rate × AI Agent resolution rate). This single construct tells me what share of total volume AI actually resolves, how much work remains for humans, how much additional demand humans can absorb, and how ambitious I can be with headcount. Early in the journey, I prioritize raising involvement—getting the AI involved in more conversations. Once involvement is high, I shift to resolution on the hardest remaining work, where each additional 1% of automation can represent several people’s worth of capacity. In my 2026 plans, automation rate sits alongside projected inbound volume, average “output” per person for the more complex work that remains, and occupancy—how much time is allocated to customer-facing interactions versus operational and strategic work. Together, those inputs give a realistic picture of how many people you need and where they should spend their time. First, plan boldly on automation, but match it with investment. I do not cap automation assumptions at 40–50% “because AI is new.” Many teams are already modeling 60%, 70%, even 80%+ for 2026—when they invest in AI ownership and content. The investment is non-negotiable: named ownership for AI performance (AI ops, knowledge management, conversation design), clear automation targets by work type (e.g., informational vs. personalized vs. actions vs. deep troubleshooting), realistic expectations for what’s easy to automate and what’s not, and a concrete plan to raise automation over time in monthly or quarterly steps rather than a single jump. To decide where to invest first, I dig into the data. I start with the biggest volume drivers, separate content-led issues from those dependent on data or complex procedures, assume higher resolution potential for content-led topics once the knowledge base is in shape, and set more modest initial resolution expectations for system-dependent flows. Then I stair-step improvements as the systems, data contracts, and workflows mature. In short, bold automation goals only work when paired with the team structure, content, and systems required to reach them—and the discipline to iterate. Second, expect human “output” per person to go down. That’s a mindset shift. Historically, we assumed individual productivity would stay flat or tick up as tools improved. In an AI-first model, humans handle fewer conversations but more complex, cross-functional issues—and create more value despite lower case counts. I model a lower “cases closed per person” than prior-year baselines, explicitly assume the remaining work is more complex and time-consuming, and redefine productivity to include system-level work like AI Agent improvements, content updates, and policy or workflow change management. I also report “capacity created” from automation alongside human outputs, so leadership sees the full picture. Third, rethink occupancy: more time off the queues, on higher-value work. Traditional occupancy splits time between inbox and training, meetings, and breaks. Now there’s an expanding “out-of-inbox” portfolio that directly affects AI performance and overall capacity: reviewing AI-handled conversations, improving AI Agent triaging and handovers, contributing to content and procedures, feeding insights to product and engineering, and supporting system changes that reduce future volume. I set lower inbox occupancy targets than before and make the rationale explicit. People aren’t working less—they’re working differently. In planning, I assume more time spent on improvement and system work, make it visible (for example, X% in inbox and Y% on AI and system improvement), and treat this as critical, not a “nice to have.” If you don’t proactively allocate it, it won’t happen—and your automation and performance targets will suffer. Fourth, work with the finance team early, and treat your plan as a set of assumptions. Capacity planning with AI is a set of bets across automation rate, human output, demand growth, occupancy, and where surplus capacity (if any) goes. I bring finance in early, show that the plan is dynamic and directly tied to AI performance, and label every lever as an assumption with ranges. I commit to a quarterly review cadence with finance to compare assumptions versus reality and adjust headcount, targets, and investment as needed. The risks are real: if automation grows slower than expected and you stop backfilling too early, you’ll be understaffed for months. Hiring and onboarding take time, so course-correcting late creates strain. If you do produce surplus capacity, have a clear strategy to reallocate those teammates to higher-value work—improving systems, feeding insights back to product, supporting new channels, and driving proactive CX—rather than defaulting to reductions. I also set explicit guardrails—if automation rate misses by five points for two consecutive months, we pause planned reductions and revisit hiring gates. If it over-performs, we shift people into backlog eradication, content upgrades, or proactive outreach, so we bank compounding value. To set your team up for success in 2026, anchor your plan on automation rate, be honest that humans will handle fewer but harder conversations, and protect time for system improvements. Partner early and often with finance, avoid shrinking too fast, and design a plan for surplus capacity so you’re never caught flat-footed. If AI is going to handle the majority of your customer conversations, your plan has to be designed to help it do that well and to keep your team set up for meaningful, sustainable work. A 2026 plan built on adaptable assumptions—not fixed predictions—will hold up as your work, your systems, and your customers’ expectations continue to change. If you’d like future editions like this, subscribe and stay close—I’ll keep sharing what’s working, what isn’t, and how to tune your customer support AI strategy in real time.

    Inspired by this post on The Intercom Blog.


    Book a consult png image
  • Year-End Reflection for Product Leaders: Values, Themes, and the 100‑Wishes Reset

    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.


    Book a consult png image
  • AI in Product Design: My Proven Playbook, Real Use Cases, and the Tools That Win Faster

    AI in Product Design: My Proven Playbook, Real Use Cases, and the Tools That Win Faster

    In product design, AI has shifted from novelty to non-negotiable. I’ve watched teams accelerate discovery, compress prototyping cycles, and turn ambiguous ideas into validated experiences faster than ever—without sacrificing quality or customer trust.

    AI in product design has quickly moved from new to necessary. Here are the AI product design tools and approaches you need to stay relevant in this decade.

    From my vantage point leading product teams, “necessary” means AI is woven throughout the product lifecycle—discovery, prioritization, prototyping, validation, and iteration—not bolted on. The goal isn’t to chase hype; it’s to build durable advantage with clear AI Strategy, disciplined execution, and measurable outcomes.

    First, anchor the work in strategy. Tie every AI initiative to a specific customer problem and value proposition, then express that linkage with outcomes vs output OKRs. This keeps teams focused on real impact and avoids feature-chasing. It also sharpens product positioning and clarifies where AI can deliver competitive differentiation versus simple points of parity.

    Second, upgrade discovery. I rely on AI workflows to synthesize interviews, cluster themes, and surface insights at scale. A retrieval-first pipeline—grounding models in our own data—improves factuality and reduces hallucinations. Combine this with strong data governance and privacy-by-design so insights are trustworthy and compliant from day one.

    Third, make quality measurable. Adopt eval-driven development: define evaluation sets and acceptance thresholds that reflect real user tasks before you ship. Pair that with A/B testing and minimum detectable effect (MDE) discipline, so you learn quickly and confidently. Add safety guardrails (red-teaming prompts, content filters, and bias checks) to manage AI risk without slowing the pace.

    Fourth, enable empowered product teams. Product trios (PM, design, engineering) should co-create prompts, prototypes, and evaluation criteria. Give designers and PMs practical tools—LLMs for product managers, structured prompt templates, and reusable components—so AI-augmented work becomes the default, not a special project.

    Where does AI shine in product design today? Concept exploration and market scans, turning fuzzy opportunity spaces into crisp problem statements. Rapid wireframes and interaction ideas, using gen ai for product prototyping to explore multiple design directions in minutes. UX writing that adapts tone and reduces friction across onboarding, tooltip design, and microcopy.

    It also excels at guided experiences. I’ve seen strong lifts in user activation when we pair in-app guides and product tours with context-aware suggestions. For support and education use cases, a retrieval-grounded assistant can deflect tickets, shorten time-to-value, and reinforce the product’s value proposition at the exact moment a user needs help.

    Voice is another frontier. A well-scoped voice AI agent can accelerate complex workflows (think data entry or multi-step configurations) when hands-free is faster or more intuitive. Just be intentional about when agentic AI adds net value versus when a simple UI tweak would do.

    On the tooling side, my AI product toolbox is pragmatic and modular. For analytics and learning loops, Amplitude analytics and Pendo help quantify behavior changes and retention analysis. For in-product engagement and feedback routing, Intercom and HubSpot integrate cleanly with LLM-driven tagging and summarization. For ideation and automation, I use a ChatGPT connector and Claude Code for quick scripts, data wrangling, and prompt experiments. The constant: a retrieval-first pipeline that grounds models in approved knowledge and maintains context window management at scale.

    Risk management is built in, not bolted on. Set clear AI risk management policies, catalog model and data dependencies, and document decisions. Align with regulatory compliance requirements early, and keep an audit trail of prompts, datasets, and eval results. That’s how you move fast without breaking trust.

    If you’re getting started, begin small: pick one high-friction workflow, add a retrieval-grounded copilot, and measure the lift. Use the results to inform product roadmapping and sprint planning, then scale to adjacent use cases. With disciplined discovery, sharp evaluation, and the right tooling, AI becomes a force multiplier for product teams and a clear win for customers.


    Inspired by this post on Product School.


    Book a consult png image
  • Inside the Engine Room: How I Drive Scalable Analytics APIs, Reliability, and Performance

    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.


    Book a consult png image
  • Playing the 25-Year Game: Rethinking Networking, Ditching OKRs, and Owning the Full Stack

    Playing the 25-Year Game: Rethinking Networking, Ditching OKRs, and Owning the Full Stack

    I’m drawn to builders who choose decades over exits. The story behind Meter—providing full-stack networking infrastructure as a service for businesses—captures that ethos with unusual clarity. From day one, the strategy hinged on vertical integration, business model innovation, and committing to a multi-decade horizon. As a product leader, I see this as the rare combination that compounds: patient R&D, an earned right to own the stack, and a commercial model aligned with customer outcomes.

    Why think in 25-year horizons? In entrenched, often monopolistic markets like networking, short-term optimization simply doesn’t move the needle. Incumbents such as Cisco and Meraki shape expectations around procurement, installation, and support. If you want to reset the standard, you can’t iterate around the edges—you have to re-architect the experience end-to-end and give yourself the time to do it right. That’s the difference between building a product and building a company.

    I also share the contrarian stance on planning. Rituals can easily masquerade as rigor. “We don’t do OKRs” doesn’t mean don’t align; it means don’t confuse activity with progress. I prefer crisp narratives, simple success metrics, and a cadence that keeps teams close to customers. Planning without over-planning lets you steer with first principles: what problem are we solving, for whom, and how do we know it’s working?

    On that note, I relentlessly track unhappy customers. Satisfaction scores and dashboards are lagging indicators; the real signal is in the gaps, escalations, and stuck use cases. Building a habit of surfacing and resolving those moments creates the operational muscle you need later when you scale. It’s also how you find “seller-market fit” and sharpen your go-to-market motion.

    The origin story matters. Meter spent four-plus years in heads-down R&D, even scrapping a year of OS work during the process. That discipline—killing good work to unlock great work—is the hallmark of teams that play the long game. Shenzhen accelerated progress by compressing feedback loops between design, manufacturing, and iteration, a reminder that sometimes geography itself is a strategy choice.

    Getting to a sales-ready product requires intentional sequencing. Own the interfaces, the telemetry, the install experience, and the service envelope—not just the code. In networking, that means controlling the full stack so performance, reliability, and support converge into one promise. The surprising thing you should innovate isn’t only the feature set—it’s the business model. Turning networking into a service aligns incentives, reduces complexity for customers, and creates durable revenue with clear SLAs.

    Avoiding the one-trick pony trap is also central. The best teams design for adjacent expansion from day one: new sites, new form factors, new service layers. The secret to finding an excellent market is to look where switching costs and frustration are both high; that’s where a superior end-to-end experience can pry open demand. That’s also why Meter didn’t sell via traditional channels—a direct motion builds intimacy with the customer problem, strengthens pricing power, and helps validate “seller-market fit.”

    Resilience is the throughline: surviving COVID, Apple’s M1 transition, and “a thousand bad days.” In those stretches, pace and patience matter more than theatrics. I’ve learned to decouple management from authority, reduce meta-work, and tackle performance issues quickly—“when the person is the problem,” clarity and speed are an act of care for the whole team. There’s inherent value in going slowly when it preserves quality, trust, and optionality.

    For founders and product leaders, the takeaway is simple: build a company you’ll want to run for as long as possible. Focus on first principles decision making, empower product teams, and choose the few metrics that truly reflect customer value. Resist the comfort of templates; adopt only the practices that raise your odds of learning faster than the market evolves. Owning the full stack, rethinking the model, and extending your time horizon can transform even the most entrenched categories.

    This is how I aim to run product: fewer rituals, tighter feedback loops, and a relentless bias toward long-term compounding. When you commit to decades, you earn the right to define the category—one thoughtful release, one delighted customer, and one resolved escalation at a time.


    Book a consult png image
  • Train Leaders First: How Product Leadership Unlocks Real Transformation and Discovery

    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.


    Book a consult png image
  • Product Analytics for Everyone: Master Funnels, Retention, and Conversion to Drive Growth

    Product Analytics for Everyone: Master Funnels, Retention, and Conversion to Drive Growth

    Product analytics isn’t a specialist’s sport—it’s a team capability. In my role leading product teams, I’ve seen designers, engineers, marketers, and customer success partners uncover insights that shape strategy, accelerate product-led growth, and improve outcomes for customers. When we demystify the basics and bring analytics into everyday decisions, we build truly empowered product teams.

    Here’s the core promise of this approach: "Learn the product analytics fundamentals of funnels, retention, and conversion drivers so that anyone can confidently answer key product questions." That line has guided how I teach product managers to think—start with the essentials, tie them to real customer behaviors, and make the work repeatable across the organization.

    I start with funnels because they tell a story—the journey from discovery to value. A simple example: track the path from sign-up to user activation to the first value event. This reveals where onboarding succeeds or stalls, what friction blocks adoption, and which moments are ripe for optimization. With tools like Amplitude analytics or Pendo, we can break down conversions by segment, channel, or feature usage to isolate where improvements matter most.

    Next comes retention analysis, the clearest signal that we’re building something customers choose to return to. Cohort analysis shows who comes back and when; retention curves show where value compels a second, third, and tenth use. Tie retention to activation milestones and the outcomes customers achieve—not just logins—and you’ll quickly spot whether your product discovery assumptions hold up in the wild. A unified analytics platform makes these insights discoverable and repeatable across teams.

    Conversion drivers round out the picture. Once the funnel is clear and retention is stable, I look for the behaviors and experiences that predict success: feature combinations, time-to-value, message timing, or supportive content. Whether in Amplitude analytics or Pendo, correlating these drivers with outcomes lets us prioritize roadmaps with confidence. Pair this with continuous discovery—qualitative interviews, in-product feedback, and rapid experiments—and you’ll move from interesting data to decisive actions.

    This is how we build empowered product teams: by making analytics a daily habit rather than a quarterly report. We bring insights into roadmap reviews, design critiques, and sprint planning; we celebrate learning from experiments as much as shipping features; and we hold ourselves accountable to customer outcomes, not just output. When everyone can interpret funnels, discuss retention, and isolate conversion drivers, we make smarter bets faster.

    If you’re getting started, keep it simple. Define a clear activation metric, instrument the top of your funnel, and track a small number of cohorts. Share a weekly readout with highlights, surprises, and questions to investigate. Over time, stitch insights into narratives that drive product-led growth—and, most importantly, help customers achieve what they came for.

    Product analytics isn’t just for analysts. It’s a shared language for product discovery, onboarding excellence, user activation, and long-term retention. When we practice it together, we build better products and stronger teams.


    Inspired by this post on Amplitude – Best Practices.


    Book a consult png image