Tag: empowered product teams

How I Use ChatGPT to Supercharge Product Management: Workflows, Prompts, and PM Playbooks

I treat ChatGPT as a force multiplier across the entire product lifecycle—from discovery and strategy to delivery and growth. Unlock workflows, prompts, and real PM tips showing how ChatGPT quietly reshapes product management behind the scenes.

My goal is pragmatic: turn generative AI into repeatable, measurable leverage for product discovery, product roadmapping and sprint planning, stakeholder management, and product-led growth without sacrificing quality, privacy-by-design, or judgment. This is how I apply LLMs for product managers in a way that strengthens customer empathy and speeds up decision cycles.

In discovery, I use ChatGPT to synthesize interviews, categorize sentiment, and surface emergent themes faster than a manual pass. I’ll feed it anonymized notes and ask for Jobs-to-be-Done statements, contradictory signals to validate, and the top three risks to our hypotheses. When the corpus gets large, I pair it with a retrieval-first pipeline and apply context window management so outputs stay grounded in real customer data.

On strategy and positioning, I draft and refine a crisp value proposition, clarify points of parity, and identify competitive differentiation. I ask ChatGPT to convert inputs into outcomes vs output OKRs, pressure-test assumptions, and produce a one-page narrative that even non-technical stakeholders can engage with. The result is faster alignment and fewer meetings to get to the same level of clarity.

For planning and delivery, I use ChatGPT to accelerate PRD outlines, user stories, and acceptance criteria, while explicitly requesting edge cases, failure states, and non-functional requirements. I’ll have it map risks to mitigations and suggest simple instrumentation aligned to DORA metrics and incident management readiness—useful when we’re iterating within a CI/CD cadence.

In experimentation, ChatGPT helps me frame strong A/B testing plans, calculate a minimum detectable effect (MDE), and sanity-check sample sizes. I also use it to translate metrics into plain language updates for the team, connect learnings to the next experiment, and propose follow-up analyses for retention analysis or activation bottlenecks.

For growth and onboarding, I prompt ChatGPT to generate hypotheses for user activation, in-app guides, and tooltip design that match personas and JTBDs. It drafts variations I can quickly test through Pendo or similar tools, supports product-led growth motions, and helps craft contextual copy that aligns with our value proposition without adding cognitive load.

Stakeholder communications get sharper and faster. I’ll ask for concise executive summaries, a version tailored for engineering leaders, and another for customer-facing teams. It’s especially effective for QBRs vs OKRs updates, where I need crisp narratives tied to outcomes, plus a plain-English articulation of risks and trade-offs for empowered product teams.

The guardrails matter. I set clear AI risk management boundaries, prevent any sensitive data from entering prompts, and align usage with data governance and regulatory compliance requirements. I also version and review prompts just like product artifacts, so the best ones evolve into a durable AI product toolbox the whole team can use.

If you’re getting started, pick one high-friction workflow—say, interview synthesis or PRD drafting—and timebox a week to build a repeatable prompt set and review rubric. Measure cycle-time savings and quality deltas, then expand to a second workflow. Within a month, you’ll have a lightweight operating model for AI Strategy that compounds across your roadmap.

Inspired by this post on Product School.

November 20, 2025
Scaling 16 ‘Startups Within a Startup’: My Enterprise GTM, PMF, and Sales Hiring Playbook

I’ve long believed the most resilient software companies master two hard things at once: they move decisively from mid-market to enterprise, and they ship multiple “best-of-breed” products without losing focus. The operating model that makes this possible — running 16 “startups within a startup” — resonates with how I build product organizations. In this piece, I’m unpacking the frameworks I use to make that model work at scale, from “product-market-sales fit” to capacity-driven go-to-market.

Why do companies get stuck in the mid-market? In my experience, it’s rarely just sales execution. It’s usually a product readiness gap hiding inside a distribution story. Enterprise customers expect battle-tested architecture, deep security and compliance, robust RBAC, data governance, audit trails, and predictable SLAs. They also expect a clear value proposition, strong references, and a crisp “who do we beat and why” articulation. If any one of those is fuzzy, your deals elongate or disappear. The fix starts by designing intentionally for enterprise and mid-market from day one: plan for scale, extensibility, change management, and procurement complexity — then validate with lighthouse customers, not just friendly pilots.

Sometimes the hardest enterprise move is saying no. I’ve advised teams to walk away from a marquee logo like Netflix when the requirements force unnatural acts that derail your roadmap. It feels counterintuitive — especially when the logo is irresistible — but your ideal customer profile must govern priorities. Your long-term velocity compounds when you align deeply with the customers who value your native strengths.

I differentiate between “product-market-fit” and “product-market-sales fit.” The former tells me a product delivers undeniable value; the latter tells me my distribution system can reproduce that value at scale. I watch for signals beyond anecdotes: win rates by segment, cycle time, ramp time to first deal, multi-threading depth, net revenue retention, and the percentage of customers who expand within two quarters. When these lag, I diagnose whether I have a product problem (insufficient value or clear “must-have” outcomes) or a distribution problem (positioning, enablement, or segmentation). The diagnosis determines whether I ship features, sharpen messaging, or rewire the motion.

On go-to-market, I build a capacity-driven machine instead of chasing deals. That means matching pipeline health to quota capacity, calibrating territories to intent density, and instrumenting enablement so new reps reach productivity with consistent talk tracks and crisp objection handling. I prefer simple, repeatable plays that compound: a precise ICP, strong proof packages, and a pricing model that meets customers where they are. When those are humming, founder-led GTM transitions smoothly to a scalable sales engine without losing the product’s original edge.

Hiring your first head of sales is a leverage point. I look for four things: pattern recognition in my specific segment, a builder’s mindset (process and playbooks without bureaucracy), rigorous pipeline hygiene, and the ability to partner with product on “where we win and why.” In the interview, I run scenario loops: how they’d disqualify non-ICP deals, how they’d recover a late-stage stall, how they’d deliver the first 90 days plan, and how they’d coach to a consistent message. Early founders absolutely need to learn sales — not to become the forever closer, but to encode customer truth into the product and the motion.

Strategic timing matters, too. There’s a well-known case of selling three days pre-IPO; whether or not you’d make the same call, the lesson stands: market timing, certainty of outcome, and board alignment are strategic variables, not afterthoughts. A healthy board brings independent thinking, timely guidance on capital and risk, and a unified narrative — especially when the market is volatile.

On competition, I pressure-test our narrative around points of parity and a “binary differentiator.” In crowded markets, incremental advantages don’t move the needle. You need one thing customers can’t ignore — faster time-to-value, a step-function in accuracy, or a cost curve that resets the category. I ask every team to prove a binary outcome: if we’re in the eval, there’s a clear, testable reason we win.

Launching multiple products simultaneously demands ruthless clarity. I structure the org as “startups within a startup,” each with its own GM, product roadmap, and GTM targets, but anchored to a shared platform for identity, data, and extensibility. Product managers operate as mini-entrepreneurs — owning P&L-like metrics, customer outcomes, and crisp product positioning — while a central platform team ensures consistency and speed. The rallying cry across these teams is simple: “We need to be best of breed.” If a product can’t credibly win on its merits, we either sharpen it until it does or we stop investing.

Execution lives in the details. I emphasize outcomes vs output OKRs, product trios for tight alignment, and continuous improvement powered by CI/CD so we can learn faster. We track DORA metrics like deployment frequency to ensure our cadence supports enterprise reliability. Weekly operating reviews focus on value delivered: have we solved the customer’s core job, and can our sales and success teams prove it with repeatable stories? When the answer is yes, expansion follows naturally.

Bringing it all together: moving upmarket, building “product-market-sales fit,” and running 16 product lines under one roof is achievable with the right structure and discipline. Design for enterprise from the start, let your ICP guide every trade-off, anchor GTM in capacity and repeatability, hire sales leaders who build with you, enforce a “binary differentiator,” and empower product managers as owners. Do that, and the “startups within a startup” model becomes a force multiplier — not just a slogan.

November 19, 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
From KPIs to Comebacks: How I Lead Through Setbacks with Curiosity, Care, and Discovery

Setbacks are the tax we pay for doing meaningful product work. As a VP of Product Management, I’ve learned that what separates resilient teams from the rest isn’t a lack of failures—it’s how we metabolize them. This episode of All Things Product with Teresa Torres and Petra Wille is a powerful reminder that recovery, reflection, and rigorous product discovery are as essential as speed and execution.

Listen to this episode on: Spotify https://open.spotify.com/episode/10LYRya7boYJBHTYBnE79E?ref=producttalk.org | Apple Podcasts https://podcasts.apple.com/kh/podcast/dealing-with-setbacks/id1794203808?i=1000737190520&ref=producttalk.org

What struck me most is how Teresa shares a deeply personal story about her long recovery from an injury—and how that journey mirrors the nonlinear reality of product development. In product, just like in healing, progress is rarely a straight line. We have surges, stalls, and moments that feel like reversals. Yet with the right mindset and rituals, we still move forward.

Professionally, we all face moments when your product fails to move a single KPI, when a launch falls flat, or when you just feel stuck. I’ve been there—in quarterly reviews, post-launch standups, and board prep. The instinct is to sprint straight into solutions. The wiser move is to respond with curiosity, emotional honesty, and resilience, then re-engage our discovery habits with intention.

If you’re a PM, designer, or researcher, consider this an invitation to rebalance. Recovery and reflection are just as important as velocity and success. That’s not soft talk—it’s how empowered product teams build durable performance without burning out.

On the emotional reality of setbacks, I’ve learned to normalize naming the loss. We put immense pressure on ourselves, and it’s okay (and necessary) to grieve product failures. When we acknowledge the disappointment, we regain the ability to observe clearly—and to learn.

Leaders play a crucial role here. I create space for teams to recover before jumping into post-mortems. We don’t whiteboard over feelings; we schedule time for decompression, then conduct a crisp, blameless review. That sequencing transforms the quality of insights and strengthens psychological safety.

Another lesson that resonates is the danger of tying performance too tightly to outcomes. Outcomes matter, but they are lagging indicators influenced by many externalities. I evaluate performance on behaviors: clarity of problem framing, rigor in discovery, quality of decision-making, and stakeholder alignment. This aligns with outcomes vs output OKRs and keeps us focused on controllable excellence.

How do we build resilience? Continuous discovery builds resilience by normalizing failure. When we test assumptions routinely with customers and data, we turn large, risky bets into a series of small, learnable steps. Teams recover faster because failure becomes feedback—frequent, cheap, and informative.

For perspective, I often use the 10–10–10 framework (from Decisive by Chip & Dan Heath). I ask: How will this setback feel in 10 minutes, 10 months, and 10 years? The answers de-escalate urgency, expand our time horizon, and produce better, calmer decisions.

Here are the key takeaways I’m carrying forward. Setbacks are not just inevitable—they’re part of doing meaningful product work. Giving teams time and space to process failure builds long-term resilience. Mourning losses is just as important as celebrating wins.

Healthy discovery cultures embrace reflection, psychological safety, and emotional honesty. And most importantly, staying consistent with discovery habits helps teams recover faster and learn more deeply.

Notable moments that stood out for me include: [00:02:00] Teresa shares the story of her injury and what it’s taught her about patience and setbacks. The parallel to product cadence is both humbling and motivating.

[00:10:00] Petra talks about a team whose carefully planned launch didn’t move a single KPI. I’ve led similar debriefs; when we anchor on customer insight gaps rather than blame, the next iteration improves dramatically.

[00:20:00] Discussion on allowing space for grief and frustration after failure. In my teams, we time-box “emotional processing” before we enter analysis mode—it humanizes the work and sharpens the learning.

[00:30:00] Why organizations must decouple performance reviews from short-term outcomes. I align evaluations to strategy execution quality, hypothesis discipline, and cross-functional collaboration.

[00:40:00] How continuous discovery can help teams normalize—and even learn to appreciate—setbacks. When discovery is weekly, momentum becomes self-healing.

If you want to dig deeper, here are useful links from the episode. Follow Teresa Torres: https://ProductTalk.org

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

Mentioned in the episode: Decisive by Chip & Dan Heath — The 10–10–10 framework for perspective in decision-making https://heathbrothers.com/books/decisive/?ref=producttalk.org

Teresa Torres’ Continuous Discovery Habits — Building resilience through ongoing discovery practices. https://www.amazon.com/Continuous-Discovery-Habits-Discover-Products/dp/1736633309?dchild=1&keywords=continuous+discovery+habits&qid=1621385051&sr=8-2&linkCode=sl1&tag=teresatorres-20&linkId=34bc439ac78da06e1398f7bf069b219e&language=en_US&ref_=as_li_ss_tl&ref=producttalk.org

Join the Conversation: Have thoughts on this episode? Leave a comment below. I’d love to hear how you create space for recovery while sustaining product velocity.

Full Transcript: Full transcripts are only available for paid subscribers.

Inspired by this post on Product Talk.

November 18, 2025
Inside PendomoniumX London: AI Transformation, Real-World Wins, and Product Innovation

Walking into PendomoniumX London, I could feel the AI revolution hitting its stride. The conversations were sharper, the demos more grounded, and the outcomes more measurable—a clear signal that AI Strategy is moving from slideware to shipped value in modern product management. PendomoniumX’s sixth stop brought 350+ software leaders together for a day of AI transformation, real-world stories, and product innovation. What stood out to me was the shift from hype to execution. Teams compared playbooks for gen ai and Generative AI, shared lessons from LLMs for product managers, and showed how they’re threading AI into product discovery, product roadmapping and sprint planning, and go-to-market motions. The focus was pragmatic: drive adoption, accelerate time-to-value, and make better decisions with cleaner signals. On the product-led growth front, I saw compelling examples of using Pendo’s in-app guides and product tours to increase user activation and reduce friction in key onboarding moments. When AI-enhanced experiences are paired with clear guidance and behavioral analytics, customers don’t just try features—they build habits. What I appreciated most were the leadership narratives: empowered product teams aligning around outcomes, candid retros on where AI prototypes missed the mark, and crisp frameworks for prioritizing the highest-leverage bets. The conference networking felt purposeful, with operators trading hard-won insights on experimentation velocity, data governance, and building trust into AI-infused experiences. My takeaway: AI is no longer a side project—it’s a core capability in product management. If we anchor our AI Strategy in clear customer problems, instrument for learning, and iterate with discipline, we can consistently turn innovation into impact. And with the right mix of PLG mechanics, in-app education, and thoughtful design, those gains compound across the product lifecycle.

Inspired by this post on Pendo – Perspectives.

November 17, 2025
AI Won’t Replace Engineers—Engineers Using AI Will: A Practical Playbook for Your Next Move

Will AI replace software engineers or reshape their roles? Explore risks, opportunities, and alternative career paths in tech.

I’m often asked whether AI will make software engineers obsolete. My short answer: AI is already automating tasks, not eliminating the role. The engineers who learn to orchestrate models, systems, and stakeholders will create more value—not less. The real shift is from keystrokes to judgment, from writing code to designing socio-technical systems that deliver outcomes.

Today’s gen ai assistants—think Claude Code and ChatGPT connector—excel at unit test scaffolding, boilerplate generation, refactoring, docstrings, and code search. When integrated into CI/CD, they can open draft pull requests, annotate diffs, and propose fixes. This lifts developer productivity and frees time for higher-leverage work: problem framing, architecture decisions, and customer discovery.

What changes in the role? We spend more cycles on product discovery, privacy-by-design, and AI Strategy, and fewer on repetitive implementation. We design agentic AI workflows that combine retrieval, tools, and guardrails; we evaluate trade-offs that blend performance, cost, and safety; and we partner with empowered product teams to ship the smallest valuable slice, learn, and iterate.

Measure what matters. If AI is working, DORA metrics should improve: higher deployment frequency, shorter lead time for changes, stable change failure rate, and faster MTTR. Pair that with outcomes vs output OKRs to avoid gaming the system—shaving seconds off a build is meaningless if it doesn’t move activation, retention, or revenue. A unified analytics platform can help connect engineering signals to business impact.

Risk is real—and manageable. AI risk management and data governance are now core competencies, not afterthoughts. Protect IP with robust access controls, context window management, and red-teaming. In production, instrument threat detection and response to catch prompt injection, data leakage, and model drift. Treat this like any other reliability discipline alongside SRE.

If parts of coding get automated, where can great engineers thrive? Several high-impact paths are emerging: platform engineering for LLMs (tooling, evals, observability), SRE for AI-infused systems, developer evangelism and education, product management for AI-native experiences, security engineering focused on model and data threats, and forward deployed engineers who pair with customers to solve messy, real-world problems.

How to upskill fast: build an AI product toolbox and ship small. Prototype gen ai features end-to-end—retrieval, function calling, human-in-the-loop QA—and connect them to your CRM integration or support stack. Use A/B testing with a clear minimum detectable effect (MDE) to validate impact. Leverage CustomGPT workflows for internal enablement and in-app guides or product tours to onboard users safely.

Here’s a pragmatic 90-day plan. Week 0–2: audit your top 10 engineering tasks by time spent; identify 3 that are ripe for AI augmentation. Week 3–6: pilot inside CI/CD with explicit guardrails; track DORA metrics and developer sentiment. Week 7–10: productionize the wins; document runbooks; add incident management paths. Week 11–12: share learnings with product trios, refine your value proposition, and set next-quarter OKRs.

AI won’t replace software engineers; engineers who master AI will outpace those who don’t. If we embrace the shift—toward systems thinking, responsible governance, and customer outcomes—we’ll build better products faster and open new, rewarding career paths. The opportunity is here and compounding.

Inspired by this post on Product School.

November 12, 2025
5 Costly UX Research Pitfalls I See Often—and How AI + Qual Insights Prevent Them

In product reviews and roadmap debates at HighLevel, I come back to a simple truth: great products start with great user research—but even seasoned teams fall into the same traps. After leading product discovery across empowered product teams and product trios, I’ve learned that a few avoidable mistakes consistently derail speed, quality, and outcomes.

Learn how to avoid the top five UX research pitfalls. Discover how AI and qualitative insights can help teams uncover the why behind user behavior.

The “why” behind user behavior is where durable growth lives. When we pair qualitative insights with analytics and a clear AI Strategy, we don’t just validate a solution—we de-risk the roadmap, improve user activation, and increase retention. Here are the five pitfalls I watch for and how I coach teams to avoid them.

Pitfall 1: Treating opinions as insights. Early in my career, I mistook strong stakeholder opinions for customer truth. Now I insist on a clear research question, a decision we will make with the evidence, and a hypothesis we’re trying to falsify. A/B testing is great for measuring impact when you’ve defined minimum detectable effect (MDE), but discovery research demands explicit learning goals and unbiased inputs.

How to avoid it: Write the decision statement first (“We will proceed with X if we learn Y”), then design the research. Keep a visible decision log so insights connect directly to product roadmapping and sprint planning, not to the loudest opinion in the room.

Pitfall 2: Leading questions and flawed methods. I still see interview guides that telegraph the desired answer. This corrupts the signal. Instead, I push teams to pilot guides with a product trio, remove solution language, and focus on behaviors. We complement interviews with in-app guides, targeted surveys, and session reviews using tools like Pendo and Intercom to capture moments of friction in-context.

How to avoid it: Ask neutral, behavior-first questions (“Tell me about the last time you…”) and validate with artifacts (screenshots, workflows). Pilot every guide with a colleague, then refine for clarity and neutrality.

Pitfall 3: Over-indexing on quantitative data and ignoring the why. Amplitude analytics and retention analysis tell me what happened; they rarely tell me why it happened. When teams chase dashboards without pairing them with qualitative interviews, we optimize for surface-level metrics and miss underlying jobs, anxieties, and unmet needs.

How to avoid it: Pair funnels and cohorts with a short round of qualitative interviews. Use Generative AI to summarize transcripts, cluster themes, and highlight contradictions, then validate themes against Amplitude analytics and CRM integration data. The synthesis is where insight emerges.

Pitfall 4: Recruiting bias—talking only to superfans or the most vocal detractors. If we only hear from power users, we build for edge cases; if we only hear complaints, we over-index on blockers. The result is a lopsided roadmap that misses mainstream value.

How to avoid it: Recruit across segments—new users, churned users, evaluators who never converted, and adjacent personas. Balance the sample and document who you didn’t talk to. For sensitive segments, lean on privacy-by-design practices and data governance so participants feel safe sharing candid feedback.

Pitfall 5: Weak synthesis and no path to action. Research often ends with a beautiful report that gathers dust. Insights must translate into choices: what we will do, what we will not do, and what we must learn next. Without this, research slows delivery without improving outcomes.

How to avoid it: Convert findings into atomic insights with evidence, confidence, and impact. Tie each insight to outcomes vs output OKRs, then schedule a decision review with the product trio. If you can’t articulate the decision, you haven’t finished the research.

How I use AI without losing the plot: I rely on LLMs for product managers to speed the busywork, not to replace judgment. Gen AI helps me transcribe, tag, and cluster themes; extract Jobs to Be Done; detect hesitation and sentiment; and draft UX writing variants for follow-up surveys. With a ChatGPT connector or similar tools, I can map qualitative themes to Amplitude analytics events and Pendo paths, revealing the narrative behind the numbers.

Guardrails matter: I apply AI risk management and privacy-by-design principles—no sensitive data in prompts, clear consent, and human-in-the-loop validation. AI is a force multiplier when the prompts are grounded in a solid research plan and the outputs feed a real decision.

A quick checklist I share with teams: define the decision and hypothesis; recruit a balanced sample; use neutral, behavior-first questions; triangulate quant with qual; synthesize into atomic insights; and link every insight to a concrete action or OKR. Do this, and you compress time-to-learning without sacrificing rigor.

When we respect the craft of research and thoughtfully apply AI, we consistently uncover the why behind user behavior—and build products that users adopt, love, and keep. That’s the fastest path to product-led growth and durable differentiation.

Inspired by this post on Amplitude – Perspectives.

November 11, 2025
Global Invoicing Nightmares: Hard-Won Product Lessons on EU Tax, Compliance, and Customer Value

I hit play on Global Invoicing – All Things Product Podcast with Teresa Torres & Petra Wille and felt an immediate jolt of recognition. We’ve all launched a feature that looked solid—until a small, overlooked detail broke everything. Their stories about global invoicing and taxes echoed challenges I’ve faced leading product for international customers: if you don’t design for the last mile of compliance, you can accidentally block the very "moment of value creation" your product promises.

Listen to this episode on: Spotify | Apple Podcasts

The conversation starts as a candid rant about EU tax compliance and quickly becomes a precise product management lesson: when we fail to map the entire path to customer value—down to the tiniest regulatory requirement—we can ship something “done” that still doesn’t work in the real world. That gap between intention and outcome is where good product teams live or die.

In my experience, the nightmare of global invoicing for small online businesses is very real. Even big platforms (like Squarespace and Teachable) miss the mark on EU tax compliance, and when they do, customers feel it immediately. It’s the kind of edge case that doesn’t show up in a demo but absolutely shows up in revenue. Or as Teresa put it, “It’s not a little detail when your client won’t pay the invoice.” — Teresa Torres

I appreciated how the episode digs into the difference between passing a regulatory checklist and actually meeting customer needs. Put plainly: the product isn’t “done” when the ticket moves to Done; it’s done when the customer completes the job—receives an acceptable invoice, pays successfully, and can reconcile it without friction. That’s why I lean hard on story mapping for regulatory work; it exposes the invisible steps where value creation can silently fail.

Here’s how the episode resonates with my own playbook: the nightmare of global invoicing for small online businesses is a systems problem; why even big platforms (like Squarespace and Teachable) miss the mark on EU tax compliance is a prioritization and discovery problem; how Petra and Teresa navigated invoicing across borders with Ableify and LearnWorlds highlights pragmatic tool choices and trade-offs; the key difference between meeting regulations and meeting customer needs is an outcomes-over-output mindset; what product teams can learn from regulatory edge cases is how to find the seams where markets, laws, and workflows collide; how missing a single detail can block the "moment of value creation" is a reminder that value is defined by customers; and why story mapping is critical for finding gaps between "we shipped it" and "customers got value" is the method that connects all of the above.

Practically, that means I treat regulatory features like any other high-stakes product surface: do real product discovery with affected users; co-design the happy path and the ugly edge cases; write acceptance criteria that include jurisdictional and document-level specifics (e.g., VAT numbers, invoice formats, timing rules); align with finance and legal early; and instrument the journey from invoice issued to invoice paid so we can see where real customers get stuck. This is outcomes vs output OKRs in action, and it’s one of the fastest ways to earn trust with stakeholders.

Key takeaways worth bookmarking: Customers define value, not your compliance checklist. Regulatory work still requires discovery—you can’t skip understanding user needs. The path to value doesn’t end when your feature works; it ends when your customer succeeds. “Sweating the details” isn’t micromanagement—it’s good product management.

Memorable quotes to bring back to your team: “If you don’t sweat the details, people choose other platforms.” — Petra Wille. “It’s not a little detail when your client won’t pay the invoice.” — Teresa Torres.

Follow Teresa Torres: https://ProductTalk.org | Follow Petra Wille: https://Petra-Wille.com

Mentioned in the episode: Squarespace | Stripe | Product at Heart | Teachable | LearnWorlds | Ablefy | Become a Better Product Leader: A 52-Week Transformation Journey | Product Talk Academy

Have thoughts on this episode? Leave a comment below.

Full transcripts are only available for paid subscribers.

Inspired by this post on Product Talk.

November 11, 2025
Prototypes vs Products: How I De-risk Ideas Fast and Ship Reliable Value at Scale

Note: This is part of the product creator series of articles, based on the overview article, The Era of the Product Creator. This series is for anyone who wants to create a successful product—whether or not you’ve had formal training or experience in product management, product design, or engineering. Over the years, I’ve watched smart teams stumble because they treated a prototype like a product. The distinction is simple but vital: prototypes exist to learn; products exist to earn trust by delivering value reliably at scale. When we blur that line, we ship avoidable risk to customers and slow ourselves down later with rework. When I build a prototype, I’m testing assumptions as quickly and cheaply as possible. It might be a clickable Figma mock, a Wizard‑of‑Oz demo, or a quick script stitching together a ChatGPT connector with a CustomGPT workflow. It’s intentionally disposable. I expect missing edge cases, fake data, hand‑waving on latency, and limited attention to security or privacy. The only goal is to answer the riskiest questions fast. A product is a promise. It’s hardened for reliability, performance, security, and privacy‑by‑design. It’s observable with real analytics, supports CI/CD and rollback, meets accessibility guidelines, and can be maintained by empowered product teams. It has clear SLAs, incident management runbooks, and instrumentation that lets me track outcomes vs output OKRs and DORA metrics. Keeping prototypes and products separate makes us faster and safer. Prototypes accelerate discovery; products operationalize value. If I catch myself “polishing” a prototype, I pause and either discard it or define the path to production with the right engineering rigor, data governance, and stakeholder management. Here’s how I decide. In prototype mode, I timebox learning to days, not weeks, and focus on a single risky assumption—value, usability, or feasibility. I validate through qualitative research and usability tests, not vanity metrics. To graduate to product work, I require a crisp problem statement, evidence of problem‑solution fit, a technical plan for scale and observability, a privacy and threat modeling review, and a measurement plan (including minimum detectable effect) for upcoming A/B testing. AI adds new wrinkles. For gen AI and agentic AI, I evaluate model behavior offline before exposing anything to customers. That includes prompt design, context window management, guardrails to minimize hallucinations, and clear fallback strategies. I define red‑team scenarios, logging for auditability, and policies for data retention and encryption as part of AI risk management. A recent example: we prototyped an agent workflow in a day that felt magical in demos. We resisted the urge to ship. Instead, we added authentication, rate limiting, PII redaction, human‑in‑the‑loop review, observability, and in‑app guides and product tours for onboarding. Only then did we move to a limited release with a well‑defined go‑to‑market strategy and support readiness. One more trap to avoid: calling a prototype an MVP. An MVP is still a product—minimal in scope but complete enough to deliver value, gather trustworthy data, and support customers. If you wouldn’t put your name on it or support it in production, it’s a prototype, not an MVP. If you’re a product creator, align your product trios around this discipline. Use prototypes to learn quickly in discovery, and use products to deliver outcomes in delivery. That mindset protects customer trust, speeds iteration, and moves you toward product‑market fit with far less waste.

Inspired by this post on SVPG.

November 7, 2025
AI Context Pulling Playbook: How I Make Humans + LLMs Collaborate for Sharper Product Outcomes

Over the last few years, I’ve learned that the fastest path to better product outcomes isn’t “more prompts,” it’s better context. When I combine thoughtful product judgment with disciplined context window management, LLMs become true partners—accelerating discovery, sharpening strategy, and improving execution.

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

When I say “AI context pulling,” I’m talking about the intentional process of assembling, structuring, and compressing the right product evidence—customer insights, metrics, constraints, and goals—so an LLM can reason effectively. For LLMs for product managers, the win is simple: by feeding the right inputs and framing the right outcomes, we turn generic AI into a strategic co-pilot for Product Management and AI Strategy.

I start by clarifying intent through outcomes vs output OKRs. Before I ask an LLM to ideate, critique, or plan, I anchor it in the product problem, the measurable outcomes we seek, and the guardrails we cannot cross (risk, privacy, brand). This keeps the collaboration focused and aligned with stakeholder management expectations.

Next, I build a tight “context packet.” I pull customer quotes from discovery notes, usage trends from our unified analytics platform and Amplitude analytics, funnel friction from Intercom transcripts, and commercial constraints from HubSpot data. Then I summarize, deduplicate, and highlight contradictions—so the model gets the signal, not the noise.

From there, I run an agentic AI workflow. In my AI product toolbox, I use CustomGPT workflows with specialized roles: a Summarizer (compress evidence), a Strategist (propose options), and a Skeptic (stress-test assumptions). This agentic AI pattern reduces blind spots and produces artifacts I can share with empowered product teams and executives.

I then bring the insights into a product trios forum (PM, Design, Engineering). We iterate on problem framing, explore solution narratives, and translate options into product roadmapping and sprint planning. The LLM helps us rapidly compare trade-offs, highlight dependencies, and craft crisp decision memos.

Execution still demands rigor. We validate with A/B testing when appropriate, size our minimum detectable effect (MDE), and monitor activation and retention signals. The model helps generate experiment variants and risk checklists, but we own judgment, ethics, and the call to ship.

Governance matters. I treat data governance and privacy-by-design as first-class constraints in every prompt, context packet, and workflow. Clear boundaries make collaboration safer—and paradoxically, more creative—because the LLM spends its cycles inside a well-defined sandbox.

Here’s a simple example: when we explored a new onboarding flow, I fed the model a compressed brief (user segments, friction points, support tickets, and conversion deltas). It returned three viable patterns, each with hypotheses and measurement plans. Our trio refined them, launched a controlled test, and used LLM-powered analysis to summarize learnings for leadership. The result: faster clarity, better decisions, and a tighter feedback loop.

The promise of AI context pulling isn’t that AI replaces product judgment—it’s that it elevates it. With the right structure, LLMs help us think more clearly, decide faster, and build what truly matters. If you’re ready to try this, start small: define an outcome, curate a context packet, and run a single agentic loop with your team. The compounding returns will surprise you.

Inspired by this post on Pendo – Perspectives.

November 6, 2025
From Code to Roadmaps: My Proven Playbook for Engineers Becoming Product Managers

"From code commits to boardrooms. Here are real stories of software engineers who swapped bugs for roadmaps on the road to product manager." I’ve made that leap myself and helped many engineers do the same. In this piece, I share the playbook I use to guide high-potential ICs into impactful product management roles—without losing the engineering rigor that makes them special.

Engineers make exceptional product managers because we’re trained to decompose complex systems, debug ambiguity, and reason from first principles. The transition isn’t about abandoning code; it’s about expanding your scope from implementation details to customer outcomes, market context, and business impact.

The first shift is mental: move from shipping outputs to driving outcomes. Features are a means; value is the end. I anchor this change with outcomes vs output OKRs, ensuring every roadmap item ties to a measurable user or business result rather than a checklist of tickets.

Next, upskill deliberately in three areas: product discovery, product positioning, and stakeholder management. Learn to design unbiased customer interviews, synthesize patterns from qualitative and quantitative signals, and craft crisp value propositions that resonate with real segments. Then practice executive-ready communication—clear decisions, concise narratives, and no jargon crutches.

Here’s the practical, low-risk way to get PM experience without changing your title: form a product trios working group (design, engineering, product) around a real problem. Lead discovery with a weekly cadence, run lightweight experiments, and translate insights into a draft product roadmapping and sprint planning artifact. Ship small, learn fast, and narrate the learning.

Build a simple portfolio that proves product judgment. Include one-page problem briefs, discovery notes, customer quotes, prioritized opportunity trees, and a before/after roadmap snapshot. For each artifact, quantify the impact: activation lift, support ticket reduction, conversion improvement—whatever outcome your work influenced.

If you want to pivot internally, propose a 90-day experiment. Volunteer to own a well-bounded problem, commit to an outcomes dashboard, and set a weekly stakeholder update. Keep a minimal engineering contribution during the trial to de-risk the transition for your team while you demonstrate PM leverage across the squad.

If you’re interviewing externally, prepare two deep case studies: one discovery-led (how you reduced uncertainty) and one delivery-led (how you aligned stakeholders and shipped). Be explicit about trade-offs, risks you retired, metrics you moved, and lessons learned. The best signals of product sense are clarity under constraints and an ability to say “no” for good reasons.

Once you land the role, use a 30-60-90 plan. In the first 30 days, map users, workflows, metrics, and decision rhythms; in 60, run a focused discovery sprint and align on your hypothesis-led roadmap; by 90, deliver a thin slice that proves value and establishes credibility with empowered product teams. Keep your communication tight, your dashboards honest, and your customers close.

Common pitfalls: translating directly from solution space to roadmap without validating problems; equating stakeholder satisfaction with customer value; and mistaking velocity for progress. Avoid them by running small tests early, revisiting segment-specific value propositions, and anchoring trade-offs to product-market fit lessons.

If you’re standing at the edge of this transition, start where you are: choose one user pain, one measurable outcome, and one small bet. Treat it like a product: define success, experiment thoughtfully, and learn in public. The road from engineer to product manager isn’t a title change—it’s a shift in how you create value.

Inspired by this post on Product School.

November 3, 2025