The PR/FAQ has re-entered the software conversation as organizations look for lightweight, working-backwards artifacts to anchor AI-assisted development, and used correctly it is a valuable front-end scoping document. It forces clarity on customer, outcome, and business value before a line of code is written. That is a good thing.
The problem is what is happening in practice. Organizations are increasingly treating the PR/FAQ as the specification itself - handing it to AI assisted coding tools as the requirements document and letting the coding tool fill in everything the PR/FAQ does not say.
That is not spec-driven development. That is vibe coding with a cover sheet. And in an enterprise setting, it is a dangerous and arguably irresponsible way to build software.
.
* * *
Spec-driven development has re-entered the conversation around AI-assisted coding, and the PR/FAQ is being miscast as the specification itself. Here is why that is dangerous
The PR/FAQ, short for Press Release and Frequently Asked Questions, originated as an Amazon working-backwards artifact and has since been adopted well beyond Amazon. The concept is straightforward.
Before committing engineering resources to a new product, feature, or capability, the team writes a short internal press release as if the product had already launched, followed by a list of the questions a customer, an analyst, or an executive would ask about it.
The press release forces the team to answer the essential questions that are almost always handled too loosely at the start of an initiative.
• Who is this actually for?
• What problem does it actually solve?
• What is the measurable customer benefit?
• What will success look like in plain language?
The FAQ then forces the same discipline on the harder internal questions. What are we explicitly not building? What are the dependencies? What are the known risks? What governance questions remain open?
Used this way, the PR/FAQ is a useful discipline. It is fast to produce, it is easy for executives to read, and it surfaces scoping ambiguity that would otherwise get discovered weeks into development. In the AI era, where the pressure to “just start building” is higher than ever, that kind of upfront outcome clarity is genuinely valuable.
I want to give the PR/FAQ its due. As a scoping document, it works.
Here is where the current conversation about spec-driven development is getting something important wrong.
A PR/FAQ is a narrative artifact. It is prose. It is written in the language of executive persuasion and customer benefit. It is deliberately short, deliberately simple, and deliberately non-technical. Those are the features that make it effective for its intended purpose - aligning stakeholders on what is worth building and why.
Those same features are exactly why it fails as a specification.
A PR/FAQ does not define the end-to-end business processes the solution must operate within. It does not define the business data - the entities, attributes, relationships, and cardinality - that the solution must manage.
It does not define the lifecycle states of the key business objects, the events that trigger state transitions, or the transitions that must be prohibited. It does not define the decision logic, the branching, the loops, or the alternative paths.
It does not define the exception conditions, the escalation rules, the governance constraints, or the business rules that actually determine how the work gets done.
These are specification questions. The PR/FAQ is silent on every single one of them.
That silence is not a flaw in the PR/FAQ. It is a feature of the format. The PR/FAQ was never designed to answer those questions. It was designed to answer a different and much smaller set of questions - the scoping questions. Conflating scoping with specification is the category error at the heart of the problem.
Here is what is happening in the field right now. Teams are writing a PR/FAQ, handing it to an AI assisted coding tool, and asking the tool to build from it. The PR/FAQ becomes the de facto requirements document for the entire initiative.
This is dangerous. And in the context of any system that touches customers, money, compliance, sensitive data, or core business operations, it is arguably irresponsible. I have made this point before in the context of vibe coding, and it applies here with even more force.
A PR/FAQ is vague by design. It is supposed to be. It tells the model what the product is supposed to do in the language of customer benefit, and nothing more. When an AI coding tool reads a PR/FAQ, it sees intent without structure. It sees a headline without a blueprint. And it does what AI coding tools always do when they encounter ambiguity - it fills the gaps with statistical plausibility.
Every gap in the PR/FAQ becomes an invisible assumption baked into the generated code. Every unstated business rule becomes an improvised business rule. Every undefined exception path becomes an improvised exception path. Every missing state transition becomes an improvised state transition. The AI is not being negligent. It is doing exactly what it is designed to do. The negligence is in asking it to do that work in the first place.
What looks fast at the beginning becomes expensive later. Teams fall into the same cycle I described in my earlier post, Spec-Driven Development Starts with Model-Driven Analysis, prompt revisions, user re-clarification, partial fixes, recoding, rework, and retroactive testing.
Weak thinking gets accelerated. Ambiguity gets operationalized. Defects move downstream faster. The PR/FAQ did not cause the problem, but it was never equipped to prevent it. It was the wrong tool for the job.
The message is clear. Do not build important systems from a PR/FAQ. A PR/FAQ is a scoping document. Treat it as one.
None of this means the PR/FAQ is without value. It means the PR/FAQ needs to be placed correctly in the delivery pipeline.
The PR/FAQ belongs at the very front. It belongs before the analysis work begins. It answers the executive-level questions that need to be answered before anyone invests in deeper specification. Is this initiative worth pursuing? Who is it for? What is the business value? What are we explicitly not building? What are the high-level risks? Those questions deserve an answer, and the PR/FAQ is a reasonable way to produce one.
Once the PR/FAQ is approved, however, the real work begins. That work is business systems analysis. And that is where Inteq’s MoDA/Framework® enters the picture.
Inteq’s MoDA/Framework® and method, MoDA is short for Model Driven Analysis, is built on a simple but powerful idea. Use a cohesive set of intuitive, business-oriented visual models to rapidly discover, critically analyze, and clearly blueprint forward-facing business requirements.
These models include process maps, activity diagrams, entity relationship diagrams, and state transition diagrams. Each model plays a specific role, and together they form an integrated, synergistic view of the business space.
The Four Integrated Models
These are precisely the things a PR/FAQ does not address. And precisely the things an AI coding tool should not be left to guess.
The MoDA/Framework® is the Rosetta stone of business and systems analysis. It provides a common standard for clear communication of business knowledge among analysts, business domain experts, and IT professionals. Its visual models overcome the ambiguity and subjectivity that plague text-based requirements.
Its pattern recognition discipline enables analysts to rapidly identify recurring business rules across industries. Its synergistic integration across the four models ensures that a change captured in one view is immediately reflected in the others - so gaps, disconnects, and misconceptions surface early rather than during testing.
This is what a specification looks like. Not prose. Not headlines. Not executive narrative. Integrated visual models that expose the real logic of the business before code gets produced.
Here is the point that most executives get wrong when they hear the phrase “model-driven analysis.” They assume it means long, heavyweight, waterfall-style modeling efforts that drag on for quarters. That is not how Inteq works, and it is not how MoDA was designed to be applied.
Inteq’s business systems analysis consulting is delivered as a focused, high-intensity, short-duration sprint - typically three to five weeks depending on scope. The deliverables are not academic. They are a comprehensive, validated set of business and user requirements properly structured and organized to move directly into build.
They include visual models of the in-scope processes, data, rules, exceptions, and scenarios. They include a business glossary that eliminates terminology drift. They include templates the organization can use going forward. And they are designed from the start to be testable, implementable, and usable by build teams, vendors, and AI coding tools.
This is the point I want executives to understand. Rigorous analysis does not slow delivery down. Poor analysis slows delivery down. A three-to-five-week MoDA sprint at the front of an initiative eliminates weeks and months of downstream rework, recoding, reinterpretation, and testing churn. The total end-to-end cycle is almost always shorter when the business thinking is done rigorously at the start.
The Correct Sequence for AI-Assisted Development
Put the pieces together and the correct sequence becomes obvious.
First, write the PR/FAQ. Use it to align stakeholders on customer, outcome, scope, and business value. Use it to make the go or no-go decision. Keep it short. Keep it honest. Treat it as a scoping document - because that is what it is.
Second, once the initiative is approved, run a focused MoDA sprint. Convert the intent captured in the PR/FAQ into rigorous, integrated, model-driven specifications that define the process, the data, the rules, the states, and the exceptions with the clarity that AI coding tools - and human engineers - actually need to build from. Three to five weeks. Build-ready output. No interpretation gaps.
Third, let AI coding tools do what they are genuinely good at. Generate code from clear specifications. Generate tests from the same models that specified the behavior. Refactor, refine, and accelerate delivery against a blueprint that was designed from day one to be the source of truth.
This is the combination that actually works. It is also the combination that most organizations are skipping.
The PR/FAQ is a useful scoping document. It earns its place at the front of the delivery pipeline. But it is not a specification, it was never designed to be a specification - and treating it as one is how enterprise AI-assisted development initiatives quietly turn into rework factories.
The competitive advantage in AI-assisted delivery does not come from writing the most persuasive PR/FAQ. It comes from the quality of business analysis that sits between the PR/FAQ and the generated code. That is where ambiguity gets eliminated. That is where business rules get made explicit. That is where exception paths get mapped. That is where the blueprint gets built. And that is precisely what the MoDA/Framework® and method is designed to deliver - rapidly, rigorously, and in weeks rather than months.
Do not ask AI to build important systems from a press release. Ask AI to build from models. And if you want model-driven development to work, start with model-driven analysis
If your organization is adopting AI-assisted development and wants to make sure the upstream analysis layer is strong enough to support it, Inteq can help.
Through our business systems analysis training programs and requirements specification consulting services , we help organizations turn business complexity into clear, integrated, build-ready specifications — in weeks, not months.
Inteq can help you:
Contact us at info@inteqgroup.com | 800.719.4627
Download a PDF of This Post
* * *
Related Posts:
The Secret Sauce to Unlocking Agentic AI
The Uncomfortable Truth About AI Agents
The Secret Sauce of Enterprise-Grade Agentic AI
Agentic AI - Breaking the Myth of the Iron Triangle
Why AI Agents Often Fail to Improve Business Processes
Spec-Driven Development Starts with Model-Driven Analysis
* * *
Subscribe to my blog | Visit our Knowledge Hub
Visit my YouTube Channel | Connect with me on LinkedIn
Check out our business analysis Training Courses and Consulting Services
Contact us at info@inteqgroup.com