How to Brief an AI-Native Software Factory
Most software projects go wrong before development begins — not because the development team is bad, but because the brief they received was incomplete. A good brief for an AI-native software factory is not a list of features the business wants. It is a precise description of the problem being solved, the outcome that will confirm success, the users who will interact with the software, and the constraints the build must work within. This article is the practical guide to getting it right.
The quality of a software build is determined, more than any other single factor, by the quality of the brief that preceded it. This is not a new observation — it is one of the most consistent findings in thirty years of software project research. It is also one of the most consistently ignored findings in practice, because writing a good brief is harder than it appears, and most business leaders have never been taught what one looks like.
A brief is not a feature list. It is not a description of what the software should look like. It is not a collection of user stories, a set of wireframes, or a Notion document full of ideas that accumulated over six months.
A brief that works — one that gives an AI-native development team the information it needs to produce the right software in the shortest time — is a precise answer to five specific questions. This article explains what those questions are, what good answers look like, and the common mistakes that make briefs inadequate without the person writing them realising it.
Why Most Briefs Are Inadequate
Before describing what good looks like, it is worth understanding why most briefs fall short — because the inadequacies are predictable and they each produce predictable consequences.
Feature-first rather than problem-first. The most common briefing failure is starting with a list of features the business wants rather than a description of the problem the software is meant to solve. "We need a dashboard that shows utilisation by team member, a project tracker with RAG status, and a billing module that integrates with Xero" is a feature list. It describes a solution. It does not describe the problem the solution is meant to address, which means a development team that could have suggested a better solution has no basis on which to do so.
Outcome-free. Most briefs describe what the software should do but not what the software should produce — what will be measurably different in the business when the software is working correctly. Without a defined outcome, there is no basis for assessing whether the build succeeded. The development team's definition of "done" and the business stakeholder's definition of "done" are different — and the difference only becomes visible when the software is delivered and one party feels it is incomplete.
User-light. Generic references to "users" or "the team" conceal significant variation in how different people will interact with the software, what they need to accomplish, and what their constraints are. A brief that says "users will be able to view and edit project status" does not distinguish between a project manager who needs granular editing capability and an executive who needs a read-only summary view — two different requirements that will drive different design decisions.
Constraint-free. Software does not exist in isolation. It integrates with existing systems, operates under regulatory requirements, must run on specific devices, and must perform within specific response time parameters. A brief that does not specify constraints produces software that may work perfectly in isolation and fail when it is connected to the environment it has to operate in.
Each of these inadequacies is recoverable — but the recovery happens during the build, when it is most expensive. A brief that identifies the problem, defines the outcome, describes the users precisely, and specifies the constraints allows the development team to make good decisions from the start rather than discovering bad ones mid-build.
What a Good Brief Contains
A brief that is ready to be handed to an AI-native development team contains answers to five questions. None of them can be answered with a sentence. All of them require the business stakeholder to think carefully before writing.
1. What problem are you solving?
Not "we want a tool to manage X" but a precise description of the current state, the gap between the current state and the desired state, and the business consequence of that gap.
Good: "Our resourcing process currently runs on a spreadsheet maintained manually every Monday morning. The process takes three hours, produces errors when team members update their own availability without informing the operations lead, and results in an average utilisation rate of 69% against our 76% target. The estimated revenue impact of the utilisation gap is £210,000 per year."
Inadequate: "We need a better way to manage resourcing."
The difference between these two is not just precision. It is the presence of a business case, a measurable problem, and a basis for evaluating whether the solution worked.
2. What does success look like — in measurable terms?
Not "the software should make resourcing easier" but the specific, measurable outcome that will confirm the software is working.
Good: "The resourcing process takes no more than thirty minutes per week. Utilisation is tracked in real time against a 76% target. Double-booking incidents, currently averaging two per month, drop to zero."
Inadequate: "The team finds it easier to manage resourcing."
The measurable success criteria are the acceptance criteria for the build. They are also the basis for the business case that justifies the investment.
3. Who will use the software, and what do they need to do?
Not "the operations team" but a precise description of each user group, their role in the process, what they need to see, what they need to do, and any constraints on how they can interact with the system.
Good: "Three user roles: Operations Lead (full edit access — manages team allocation, resolves conflicts, produces weekly report), Team Member (limited edit — updates own availability and project hours, views their own allocation), Senior Management (read-only — views team and project utilisation dashboard)."
Inadequate: "The operations team and management will use it."
Each user role typically drives different screen designs, different permission structures, and different data requirements. A brief that conflates them creates ambiguity that the development team will resolve — probably differently than the business intended.
4. What systems must it integrate with, and what data must it exchange?
Not "it needs to connect to our existing tools" but a precise description of each integration: the system, the data flowing in each direction, the authentication mechanism, the frequency of the exchange, and the business rules governing what happens when the integration fails.
Good: "Integration with Xero (read billing rates per project, write invoice line items). Integration with our internal HRIS (read team member names, roles, and cost rates). No real-time requirement — daily sync is sufficient. If sync fails, the last successful data set remains visible with a 'last updated' timestamp."
Inadequate: "It needs to connect to Xero and our HR system."
Integration specifications are the most consistently underestimated element of software briefs. What sounds like a simple connection is frequently a significant development task once the data mapping, authentication, error handling, and edge cases are fully specified. A brief that describes integrations in summary terms produces integration estimates that are wrong — almost always too low.
5. What are the constraints?
Performance requirements (response time, concurrent users), security requirements (data classification, authentication standard, hosting requirements), device requirements (web, mobile, specific browser support), regulatory requirements (data residency, compliance standards), and timeline requirements (the date by which the software must be operational, and the consequence of missing that date).
Good: "Must be accessible on mobile (iOS and Android) and desktop browsers. Data must be hosted within the UK (GDPR and client data residency requirements). Response time for all core views must be under two seconds on a standard 4G connection. Must be operational before the start of the new financial year on 1 April."
Inadequate: "Standard enterprise security, should work on mobile."
Constraints define the boundaries within which the design and architecture decisions must be made. A software system designed without understanding its constraints must be redesigned when those constraints become apparent. That redesign is expensive when it happens mid-build.
What to Do With the Brief Before Handing It Over
A brief that answers all five questions is ready to be developed into a full specification — but it is not yet a specification. The brief is the input to the specification process; the specification is what the development team builds from.
Before handing over the brief, there are two validations worth completing.
Read it as the developer. Review the brief from the perspective of someone who has never seen the business and has only this document to work from. Identify every place where a decision has been left to interpretation. Every "the system should handle exceptions appropriately" or "users will be notified when relevant" is a decision that the development team will make differently than the business intends. Replace interpretive language with precise description.
Identify what you have assumed. Every brief contains assumptions — about how the business currently works, about what the users already know, about what the integration system will allow. List the assumptions explicitly. They are the most likely source of mid-project surprises: the assumption that proved incorrect and required the build to adapt.
A brief with explicit assumptions is not a weaker brief. It is a more honest one — one that allows the development team to validate the assumptions early rather than discovering they were wrong in week eight.
The Xamun Discovery session is designed to develop the brief collaboratively — drawing out the precise problem statement, the measurable success criteria, the user roles, the integration requirements, and the constraints in a structured conversation rather than a document review. The output is the foundation for the xDD specification that precedes every build.
Related reading: What Is Spec-First Software Development? Why It Changes Everything About AI Projects → What Is AI-Native Software Development? The New Standard for Building Business Applications → How Long Does It Actually Take to Build an AI-Powered App →