Your AI Should Be Arguing With You... and Making You Sweat!

Inside the PRFAQ gauntlet: Amazon's method for killing bad ideas before they cost you months, now powered by the BMad Method and an AI that refuses to let you off the hook.

Simon Sinek told us to Start with Why. I consumed that book in a weekend (I'm a self-admitted business book junkie) and nothing changed, and I bet many can say the same thing. Because as pithy and easy as that sounds, starting with why is hard and it takes work.

And here's the uncomfortable truth about AI that nobody in the industry seems willing to say out loud: most of the tools we're building are designed to skip that work. Generate the PRD, auto-fill the template, summarize the requirements, ship faster, think less. For the decisions that matter most, I think that's exactly backwards.

The Problem with Starting with What

Most product failures don't happen because the team built it wrong; they happen because the team built the wrong thing entirely, skipping the Why and going straight to the How. The standard playbook makes this worse: you get an idea, write a PRD, break it into epics, and start building. The PRD feels like rigor because it has sections and stakeholder sign-offs and acceptance criteria. It looks like due diligence, but it's all What and How, and nobody is stopping to ask Why.

That's because a PRD is fundamentally a planning document for something you've already decided to build, a document that assumes the answer is yes. By the time you're writing acceptance criteria for user story 3.2, the question of whether the product should exist at all has been quietly retired, lost somewhere between the initial excitement and the Jira board.

Amazon figured this out decades ago, and their solution literally forces you to start with Why.

Write the Press Release First

Before any product at Amazon gets funded, someone writes the press release announcing the finished product to the world, before anyone touches a technical spec or architecture diagram. They call it Working Backwards, and the full artifact is a PRFAQ: Press Release, Frequently Asked Questions.

The logic is brutal in its simplicity: if you can't write a compelling announcement for something that doesn't exist yet, you don't understand it well enough to build it, and if the announcement isn't compelling even on paper, why would anyone care when it ships?

This isn't theory. AWS didn't start with a technical architecture; Jeff Bezos and Andy Jassy spent over a year writing, revising, and debating PRFAQs before a single line of code was written, and that patience produced a business generating tens of billions in annual revenue. When Amazon abandoned the process for the Fire Phone, the result was a $170 million write-off on a product whose 3D camera effects solved no customer problem anyone could articulate.

Hundreds of PRFAQs get written at Amazon every year, and most never get approved. As Colin Bryar and Bill Carr wrote in Working Backwards: "The fact that most PR/FAQs don't get approved is a feature, not a bug."

The press release forces you to answer questions that PRDs let you defer indefinitely. Who exactly is this for, and not "developers" or "small businesses" but a specific person with a specific problem? What actually changes in their life once this exists? And if you have to explain why it matters, it probably doesn't matter enough.

Then come the FAQ sections, which is where the real interrogation begins. The Customer FAQ puts you in the shoes of a busy, skeptical person who has been burned by promises before, and demands you confront every objection standing between interest and adoption, especially the one question you've been hoping nobody asks. The Internal FAQ is worse: you're facing the engineering lead, finance, legal, and the executive who's seen a hundred pitches, and every question demands concrete specifics. "What's the hardest technical problem here?" "What don't we know how to build yet?" "What do we have to say no to in order to do this?" "What kills this?" Every vague answer represents a gap that will sink the product six months into development.

AI Should Make You Think Harder, Not Less

The PRFAQ process was designed for rooms full of people challenging each other's thinking: a product manager writes the draft, the leadership team tears it apart, and the customer FAQ gets sharpened by someone who actually talks to customers. Most of us don't have that room. Solo founders, small teams, indie developers: you're writing the PRD, building the product, and talking to customers all at the same time, which means the critical thinking that's supposed to happen between people happens between your ears, and your blind spots stay blind.

The obvious AI solution would be to automate the document itself, to feed in your idea, get a polished PRFAQ back, and skip the hard parts, which completely misses the point.

The value of the PRFAQ lives in the analysis, the thinking you're forced to do, the assumptions you're forced to confront, the uncomfortable questions you're forced to answer honestly. Skip that process and you've got a pretty artifact with no substance behind it, which is exactly the problem with PRDs in the first place.

So when I built the PRFAQ process into BMad Method, I built it as an adversary. The BMad Analyst runs you through a gauntlet of five stages (Ignition, Press Release, Customer FAQ, Internal FAQ, and The Verdict) and challenges your thinking at every step. Lead with a solution instead of a problem, and it redirects you to the customer's pain. Lead with a technology, and it pushes harder, because AI is a "how," not a "why," so strip the buzzword and ask if anyone still cares. Give a vague answer in the FAQ, and it demands specifics, because "enterprise-grade security" is not an answer; what certifications, what encryption, what SLA? Dodge the hard question, and it finds it and asks it anyway.

Before any drafting begins, the process fans out subagents to scan your existing documents and research the competitive landscape, so the PRFAQ isn't built on assumptions but informed by what's actually happening in the market right now. This is AI doing the opposite of what everyone expects: instead of making the process easier, it makes the process better by making it harder.

I Killed My Own Idea in 40 Minutes

A few people had been asking for essentially the same feature: the ability to type a sentence or two about an idea and have BMad Method generate the full PRD, architecture, epics, and stories in one shot. No conversation, no analysis sessions, just idea in, complete project plan out, start coding immediately. I'll admit I was genuinely excited about it, already picturing the demo, two sentences producing a complete project plan, the kind of thing that would absolutely go viral.

The early stages of the PRFAQ went well enough, with a clear customer and a real pain point, because nobody wakes up excited to write a PRD. But when I sat down to write the press release headline, something felt wrong. "BMad Method turns your idea into a complete project plan instantly." That was a shortcut headline, and I could already hear my own argument from the top of this post throwing it back at me.

The Customer FAQ is where the cracks opened up. The Analyst asked a question I couldn't shake: "How is this different from just vibe coding with extra steps?" I argued that the output would be meaningfully structured (real PRDs, architecture docs, properly scoped stories), but the Analyst pressed on the foundation: all of that structure would be built on two sentences of input, which means the AI would be filling in hundreds of assumptions I never actually made, and there would be no reliable way to know which ones were right.

So I shifted my argument to the idea that it would serve as a starting point people could refine, something better than a blank page. The response cut deeper: users would receive a document full of someone else's assumptions and spend hours correcting it, when they could instead spend 40 minutes thinking through the problem with the Analyst and end up with a plan they actually trust.

I tried one more angle, framing it as a way to lower the barrier and get people who would never do planning to at least start with something. The Analyst's response is the one that actually stopped me: "Are you building for people who want to think rigorously about their product, or people who want to skip that entirely? Because those are fundamentally different users who need fundamentally different tools, and the second group already has what they need: a chat prompt and a code editor."

The Internal FAQ made it worse. Every question exposed another structural problem: how do you validate architecture decisions that nobody actually made? How do you account for the false confidence that comes from a polished document built on almost zero input? And the one I couldn't answer: if this feature succeeds, does it attract people who value what BMad Method actually does, or people who want to vibe code with nicer formatting?

Forty minutes in, I killed it. But the PRFAQ wasn't done with me yet, because the most valuable thing it produced wasn't a dead feature request; it was a clear picture of what the right idea actually looked like.

The people asking to skip planning weren't entirely wrong about the problem, even though they had the wrong solution. The existing PRD process felt too regimented, too many pre-canned questions, too much "fill in section 4.2." It felt like paperwork, and when something feels like paperwork, people look for the skip button. The PRFAQ surfaced something I hadn't considered: the process itself needed to meet people where they are.

So instead of building a skip button, I reworked how the PRD conversation works entirely. In the upcoming release, you can throw it a brain dump, a rambling voice note transcript, a half-baked pitch you typed on your phone at 2am, a Slack thread, whatever raw material you have. The agent takes that messy input and works with you conversationally, pushing you to flesh things out where it's thin, challenging assumptions that don't hold up, and asking you to cut where you're overbuilding, without any rigid template that marches you through sections step by step even for sections that do not apply. No "please fill in the customer segment field," just a real back-and-forth that produces a solid PRD because you actually thought through the hard parts yourself.

The people who want to skip thinking entirely are still not my users, and that's fine; products like Lovable serve them well, because no quality product is truly one-size-fits-all. BMad Method's ecosystem of community-contributed modules exists precisely because different workflows demand different tools. But the people who have the ideas and the intent and just couldn't stand the rigid process? The PRFAQ showed me they were right about the problem. That's the part nobody tells you about this process: it doesn't just kill bad ideas. Sometimes it kills the bad version of a good idea and shows you what you should have been building all along.

The PRD Isn't Dead. The PRFAQ Isn't for Everyone.

I'm not saying throw away your PRDs, because the PRFAQ isn't the right starting point for every project. Building a hobby project? Start with a brief or jump straight to the PRD. Cloning something that already works because you want to compete in the same space? You don't need to prove the market exists. The PRD is the right tool when you already know What and Why and just need to plan the How.

But if you believe you have a real idea, one that can differentiate, that could move the needle or represent the next significant investment of your time and your team's time, something you think might actually matter, then it's time to run the gauntlet.

The result of a successful PRFAQ run is the document itself plus a distillate, a dense context pack that feeds directly into PRD creation. The PRFAQ can replace or live alongside the product brief in your planning pipeline, and if the idea survives, the PRD practically writes itself because all the hard thinking is already done.

Let the BMad Analyst challenge every assumption you hold. Let the Customer FAQ find the question you've been avoiding, and let the Internal FAQ expose the gaps between your vision and reality. If you come out the other side, you earned it: your idea survived the hardest questions anyone could throw at it before a single line of code was written, and you'll move forward with clarity and conviction instead of hope.

And if the idea doesn't survive, you just saved yourself months of building something the market never wanted, which is exactly what the system was designed to do.

Try it yourself. BMad Method is free and open source.

npx bmad-method install

Then fire up your agent and run the PRFAQ gauntlet. Bring your best idea and see if it survives.

GitHub | Docs | Discord