Alan Byrne, Product Leader for Mozilla's Firefox extensions ecosystem, argues that the best product work is less doctrine and more judgement. In conversation with Randy Silver, he breaks down why prioritisation frameworks like RICE and MoSCoW often masquerade as science while quietly embedding subjectivity — and why he prefers writing clear "what and why" statements over chasing false precision.
From his experience at QuickBooks and Twitter, Alan explores when PRDs are genuinely valuable (complex systems, high risk, trust and safety concerns) and how to keep them lean enough to stay useful. The discussion also digs into the tension between moving a metric and doing right by users, the dangers of gamifying growth, and how product managers can translate customer problems into narratives that align engineers, executives, and sales.
Chapters
Key Takeaways
Prioritisation frameworks can be useful rhetoric, but they are not objective truth. Treat scoring as a prompt for discussion, not a substitute for judgement.
The most durable product skill is uncovering intent: what users are trying to do, why they are doing it, and what "better" means in their context.
Narrative beats numbers when you need alignment. A crisp "what, why, and why now" travels further than a spreadsheet score.
Goals work when they connect the boardroom to the build. Tie roadmap items to a clear outcome, and make that connection legible to engineers and stakeholders.
Be wary of metric gaming. Making a funnel "slippery" can inflate sign-ups while quietly poisoning retention, trust, and long-term value.
PRDs earn their keep when complexity is high and risk is real. Their job is to surface unknowns, cross-functional concerns, and misuse cases before shipping.
Cut templates ruthlessly. Keep PRDs focused on the problem, the intended outcome, and the must-haves — then iterate in phases rather than attempting perfection upfront.
Prototypes are great for exploration and user testing, but "weekend code" rarely translates cleanly into production work. A sketch can sometimes communicate intent better than a polished mock.
"Good enough" is a product decision, not an engineering compromise. Define acceptance criteria in outcome terms so teams know where robustness matters and where speed matters.
Product management is organisational circulation. Discovery insights should travel to engineering, sales, marketing, and leadership so the whole business speaks to the same customer truth.
Keep reading
Inside modern product game design - Cheryl Platz (Riot Games, Microsoft)
Why product democracy doesn't work - Blagoja Golubovski (VP Product, Usercentrics)
How to predict product failure
Building products for pilots: A case study - Cristina Bustos (Swiss AviationSoftware)