AMA: Ignition SVP, Product, Tammy Hahn on Product Development Process

tl;dr: A good beta is tightly scoped, participant-quality over quantity, and designed to answer specific questions; it is not just “get feedback.” 1. Start with the right participants Work closely with Customer Success to identify customers who are: Good partners (healthy accounts, low churn risk, responsive) Strong ICP fit (the feature solves a real problem for them) Willing to engage (usage, feedback sessions, potential references) Set expectations upfront: this is not passive access. They’re ...Read More

tl;dr: Engineering should be involved from the start—because in an AI-native world, the distinction between roles is breaking down. What’s changing: Roles are converging into “product builders.”The traditional split (PM defines, Design designs, Engineering builds) is collapsing.Teams are increasingly made up of generalists who can go from problem → solution → implementation. Context replaces handoffs.Speed and quality now depend on everyone having full context, not clean role boundaries.If engin ...Read More

tl;dr: The core assessment happens within a small team of product builders but it’s shaped by broader company priorities. What’s changed: Small, high-context teams own the problem.Typically ~3 product builders who can cover product thinking, design, and engineering.Because roles are collapsing, these teams don’t rely on handoffs: they operate with shared context and full ownership. Problem assessment is a team sport.The team is responsible for: Understanding the customer and their pain points Va ...Read More

tl;dr: Post-launch is about triangulating signal quickly—and being ruthless about what to double down on vs. kill. Three inputs I rely on: Product analytics (what’s happening)Adoption, engagement, drop-off points.This tells you where things are working or breaking, but not why. Customer conversations (why it’s happening)Use analytics to identify who to talk to.If users are dropping off at a specific step, go directly to them and understand the friction. Frontline feedback (what’s surfacing at sc ...Read More

tl;dr: I don’t use a separate framework for AI. I evaluate it the same way I would any feature: does it solve a real, validated problem and materially improve the user’s workflow? A few principles behind that: “AI for AI’s sake” isn’t useless. It's training.Teams need reps. Low-risk AI features are a practical way to learn how to build, evaluate, and communicate AI. Just don’t bet the roadmap on them. Users don’t want “AI.” They want outcomes.The most valuable use cases are often unglamorous: su ...Read More

tl;dr: AI has shifted roadmap planning from upfront certainty to continuous learning. The constraint is no longer building; it’s deciding what’s worth keeping. What’s fundamentally changed: The cost of building has collapsed.AI has made code generation fast and cheap. The historical need for heavy upfront discovery and design (because build was expensive) no longer applies. The bottleneck has moved.If you keep long discovery and design cycles, Product and Design become the constraint. Engineerin ...Read More