The cheapest alignment tool you have. If you can't fit your project on one page, you don't understand it yet.
A one-pager is not a compressed version of a long document. It is a forcing function. When you sit down to write it, you will discover that you have been avoiding several hard questions — and the blank fields will stare back at you until you answer them.
The one-pager exists because of one truth: ambiguity is expensive. Every hour your team spends building something that isn't aligned with what stakeholders actually want is an hour you cannot recover. The one-pager is where you spend two hours to save two months.
There is a second reason. Most engineers are much better at talking about what they're building than at explaining why anyone should care. The one-pager forces you to write the "why" before the "what." Once you've done that, every conversation you have about the project is sharper.
Write the one-pager before you write any code and before you have any kick-off meetings. The meetings are to review the one-pager, not to discover the project's purpose together in real time.
Every field below earns its place. None of them are optional. If you find yourself unable to fill a field, that is signal — it means you have more thinking to do before the project starts.
Pick a name that is specific and memorable. Not "Auth Revamp" but "SSO for Enterprise Tier." The name should remind everyone — including you, six months later — what the project actually does.
Avoid codenames like "Project Phoenix" that tell you nothing. They feel cool in week one and confusing in week twelve, when three new people have joined and nobody remembers what Phoenix refers to.
This is the hardest field to fill correctly, and the one most people get wrong. The mistake is writing what you plan to build instead of what is broken right now in the world.
A problem statement describes a gap between the current state and a desired state. It does not mention your solution. If your problem statement contains any verbs like "build," "create," or "implement," you have written a solution, not a problem.
"We need to build a new authentication system that supports SSO and integrates with enterprise identity providers."
"Our auth system cannot support SSO. Three enterprise customers with a combined $4M ARR have told us this is a hard blocker before they can sign. We lose 2–3 similar deals per quarter because of it."
Notice what the right version does: it gives the reader a number, names the stakeholder impact, and makes the cost of inaction concrete. Now anyone who reads it understands why the project matters — without you having to explain it in a meeting.
This field forces you to articulate urgency. If you cannot answer it, the project may not deserve to happen this quarter. Resources are always scarce. A project with no answer to "why now" is competing against projects that do have an answer — and it will lose.
Common valid answers: a regulatory deadline, a contract clause, a competitive threat, a system that compounds in cost if you wait, or a blocker on another high-priority project. One of these should be true of your project. If none of them are, that is worth knowing before you start.
Ask yourself: if we delay this project by one quarter, what gets worse? If the answer is "nothing obvious," either the urgency is hidden and you need to surface it, or the project should be lower priority.
Write scope, not features. A feature is "support SAML 2.0 protocol." Scope is "enterprise-grade SSO that works with any major identity provider, with no changes required from customers." One describes an implementation detail. The other describes what the customer gets.
Use plain language. "A service that does X" is better than "a horizontally scalable microservice leveraging event-driven architecture to achieve X." Nobody needs to know how it works in a one-pager. They need to know what it does.
Keep it to five bullets maximum. If you have more than five, you have either scope that needs trimming or bullets that need merging.
This is the most underused field in every project brief, and it is the most powerful for preventing scope creep. Explicit non-goals are scope protection in writing.
Think about the three or four things that someone will definitely ask for in week six. Write them here now, before they ask. When they ask, you can say: "That's actually out of scope for this phase — it's listed in the one-pager. We'll tackle it in phase two." The conversation becomes five seconds instead of forty-five minutes.
"We are not migrating existing non-enterprise users in this phase." / "We are not building the self-service provisioning UI — admins will use the API." / "We are not supporting legacy LDAP — SAML and OIDC only."
Be specific. "We are not doing everything" is not a non-goal. "We are not supporting on-premise deployments in this version" is a non-goal.
The difference between an output and an outcome is the difference between shipping code and changing something in the world. Success metrics should be outcomes — things that change because of what you built, not just evidence that you built it.
"SSO feature shipped. SAML and OIDC supported. 100% test coverage."
"3 blocked enterprise deals unblocked. Enterprise conversion rate increases from 18% to 28% in the quarter following launch."
Good metrics are measurable before the project ends. If you can't measure it, you can't celebrate winning or diagnose losing. Write down how you will measure each metric and who owns the measurement.
Two to three metrics is the right number. One metric is too fragile — you might hit it for the wrong reason. Four or more metrics means you're not sure what success looks like.
This is not where you list every possible thing that could go wrong. It is where you name the two or three things that could kill the project or force a major rethink. Risks at the "project-threatening" level, not the "this sprint might slip a day" level.
Each risk should have a name and a sentence. "The identity provider integration may take three times longer than estimated because we've never integrated with a third-party IdP before, and our only reference is a six-year-old internal doc." That is a real risk. "Something could go wrong with the database" is not a real risk — it's anxiety in sentence form.
You'll do deeper risk work in the risk register (Appendix C). In the one-pager, just surface the headline risks so stakeholders know what you're watching.
Not a Gantt chart. Not a sprint plan. Just the shape of the project — the big checkpoints that let everyone know what comes when. Three or four dates maximum.
Use outcome-based milestone names, not task-based ones. Not "backend complete" but "system can handle real IdP login end-to-end." Not "testing done" but "staging tested with one real customer's SSO config."
Be honest about your estimates. Adding two weeks of buffer to every estimate is not honesty — it is hidden pessimism that will compound. Be explicit about what you know and don't know. "We expect the IdP integration to take 3–5 weeks; we've never done this before and our estimate has high uncertainty" is better than a fake precise date.
List who is on the project and what they own. Not just names — roles. "Priya — owns IdP integration" tells the reader something. "Priya — engineer" does not.
If your project needs more than eight people, you either have scope that should be split, or you have a multi-team project that needs a different structure. A one-pager for a 30-person effort is not a one-pager — it is a cover sheet for a much larger coordination problem.
Include the DRI (Directly Responsible Individual) for the whole project at the top. There should be exactly one name here. Two DRIs means no DRI.
List every team you need something from and what you need. This is the field that most often reveals a project is not ready to start. If you need three other teams and none of them know about it yet, starting the project right now will create a traffic jam in three months.
Be specific. "Need Identity team to expose a new API endpoint for SCIM provisioning by week 6" is a dependency. "May need some help from platform" is not.
For each dependency, add: who on that team you've already talked to. If the answer is "nobody yet," the project should not start until you've had that conversation.
Here is a complete one-pager for a realistic project. Read it once as a stakeholder — notice how much you understand about the project after thirty seconds.
Talk to the three people who most need this project to succeed. Not to gather requirements — to understand their definition of success. The one-pager should reflect their language, not yours. When they read it back, they should think: "This person gets it."
Write the problem field first. If it takes you more than twenty minutes, stop and schedule a conversation with the product or business stakeholder. You're missing context, not writing skill.
Fill in "What We're NOT Building" last. By then you'll know what everyone keeps asking about, and you'll have a cleaner sense of what belongs in phase one versus later.
Share it with three people before you use it in a meeting: your manager, the most skeptical stakeholder, and a peer engineer who isn't on the project. Their questions will tell you exactly which fields are weak.
Do not wait for the document to be perfect. A 90% one-pager that gets into the hands of stakeholders is worth ten times more than a 100% one-pager that's still in your drafts folder.
Update the one-pager when the scope changes significantly. Not every week, but when something major shifts. The version history is a record of how your understanding of the project evolved — and that is useful context for anyone who joins mid-way.
Before you call your one-pager done, run through this:
The one-pager is not a deliverable. It is a thinking tool that becomes a communication tool. The act of writing it does as much work as the document itself. If writing it felt easy and fast, you probably didn't push hard enough on the hard questions.