Lesson 2.4: Writing the one-page plan for a customer

The one-page plan turns discovery into an agreement a customer can read in five minutes. Learn its ten parts, a full example and how to set a date you can keep.

By the end of this lesson you will be able to write a one-page plan for a customer project: a short document that states the problem, the people, the scope, the success metric, the timeline, the risks and the decisions you need. You will learn the ten parts of the page and the order that makes it easy to read, see a complete example for a lender, rewrite a weak plan into a strong one and use a simulator to set a delivery date you can actually keep. This lesson closes Module 2. It collects the work of Lessons 2.1 to 2.3, the problem, the stakeholders and the pilot scope, into one document. You should have read those lessons. No technical background is needed.

In Lesson 1.1 you were asked to write a small version of this document, and in Lesson 2.3 you wrote its middle section. Now you will write all of it. The aim is not paperwork. A one-page plan is the cheapest way to find out, before any building starts, whether you and the customer agree about what you are doing. Most disagreements in a project are cheap to settle on page one and expensive to settle in week eight.

Why one page

The length is a deliberate constraint. There are four reasons for it.

It forces clarity. If you cannot say it on one page, you probably do not yet understand it. Cutting a plan down shows which parts you are unsure about. It gets read. An executive will read one page before a meeting. They will not read twelve. A document nobody reads is not an agreement. It can be checked. One page can be compared with reality every week. A long plan hides contradictions inside it. It can change. A short plan is easy to update and to send again, which matters because plans change as you learn.

One page does not mean one screen of tiny print. It means roughly 400 to 600 words, with a few small tables, that a reader can take in within five minutes. Appendices are fine for detail, such as a data dictionary or a long list of risks, as long as the page itself stands alone.

The ten parts of the page

A good page answers ten questions, in this order. The order matters, because a reader who stops after the third part should already know what the project is and what you need from them. # · Part · The question it answers · Length1 · Title and one-line summary · What is this, in one sentence? · 1 line 2 · The problem · What is going wrong, for whom, and how much does it cost? · 2 to 3 lines 3 · The outcome and metric · What will be different, and how will we measure it? · 3 to 4 lines 4 · Scope · What is in, and what is deliberately out? · A small table 5 · People · Who is involved and who decides what? · A small table 6 · Approach · How will we do it, in a few steps? · 3 to 5 lines 7 · Timeline · When are the milestones and the decision date? · A small table 8 · Data and access · What do we need from the customer, and by when? · 3 to 5 lines 9 · Risks and assumptions · What could go wrong, and what are we assuming? · 3 to 5 lines 10 · Decisions needed · What do we need from the reader now? · 2 to 4 lines Notice where the decisions sit. Many people put them last, as a conclusion, and then bury them. A better habit is to put a one-line ask at the top, in the summary, and list the details at the end. A reader who takes in only the top of the page should know what you want from them.

Most of the content comes from earlier lessons. The problem is the sentence you wrote in Lesson 2.1. The people come from the map in Lesson 2.2. The metric, scope and exit rule come from Lesson 2.3. The new parts are the approach, the timeline, the data and access list, and the risks. They turn an idea into a plan.

Predict first: a customer's executive will read only the first two or three lines of your plan before a meeting. What two things should those lines contain? Decide before you read on.

The first two lines should contain the problem, in plain words with a number, and the decision or help that you need from the reader. For example: "Borrowers in the first overdue band pay late too often, costing about ₹40 lakh a month. We propose a six-week pilot of language-matched reminders in one city, and need approval of the data extract by 14 November." Someone who reads nothing else knows what is wrong, what you propose and what you need. Everything below is detail for those who want it.

Writing each part well

A few practical rules make each part stronger.

Summary and problem. Use plain words. Write the problem as a person and a number, not as a technology: "Borrowers cannot understand their statements, which leads to 3,000 calls a month" is better than "Inefficient customer communication."

Outcome and metric. One metric, with the baseline and the target. Add the guardrail in the same lines. Anyone should be able to recompute the metric from the definition.

Scope. Use the five dimensions: who, what, when, where, how much. The "out of scope" column is not decoration. It is the first thing you will point to when scope creeps.

People. List by role, not by long titles. Say who the sponsor is, who the day-to-day contact is, who owns the data, who approves security and legal matters, and who the users are. Add one line on who decides what. Do not put your private notes on attitudes in the document.

Approach. Three to five steps in plain words, for example "build a rough version in two weeks, show it to the team, then harden and deploy". Do not list technologies unless the customer needs to approve them. The reader wants to know what will happen, not how each piece works.

Timeline. Milestones with dates, and the decision date at the end. Leave visible room for the approvals that take time. A timeline that has no room for reviews tells the reader you have not met their organisation.

Data and access. A short list: which data, from which system, in what format, who provides it and by when. Also the accounts, permissions and approvals you need. This list is a request. Make it specific enough that the customer can start the work the same day.

Risks and assumptions. Write the three to five that matter most, each with what you will do about it. An assumption is something you believe but have not checked, such as "the nightly file contains all accounts". Naming it lets the customer correct you early.

Decisions needed. A numbered list of what you need now, who must decide and by when. "Approve the data extract (Head of IT, by 14 November)." If there is nothing to decide, say "no decisions needed this week", which is also useful.

Voice and style

The tone should be calm, concrete and short. A few habits help.

Plain words. Say "load" and not "ingest". Say "check" and not "validate" if the reader prefers it. When a term is needed, define it once. Numbers over adjectives. "About 3,000 calls a month" beats "many calls". Active voice with names. "The data team provides the extract" is clear about who. "The extract will be provided" is not. No surprises. Nothing on the page should be new to the sponsor. Walk through it with them before you send it widely. No hiding. Put the hard things, such as a tight date or a risky dependency, where they can be seen. Hidden risks come back later as broken trust.

A complete example

Here is a full one-page plan for the lender pilot from earlier lessons. It is invented for teaching, and every name and figure is illustrative. Read it once for the whole, then again to see how each part answers its question.

> Pilot plan: language-matched reminders for first-month overdue loans > > Summary. Borrowers whose payment is a few days late often pay only after several calls. We propose a six-week pilot of automatic reminders in each borrower's own language, for one city, and need approval of a nightly data extract by 14 November. > > Problem. About 41 per cent of first-band overdue accounts pay within seven days. Callers spend most of their day on accounts that would pay after a reminder, while harder accounts get one call a week. Better sorting and messaging could free about a third of caller time. > > Outcome and metric. The share of first-band accounts paying within seven days: baseline 41 per cent (last three months), target 48 per cent. Guardrails: complaints at or below 2 per 1,000 contacts and no messages outside permitted hours. A random half of eligible accounts will not receive reminders, as a control. > > Scope. In: collections team A, 12 callers, one city; first-band accounts; reminders in the borrower's preferred language; a nightly file. Out: other cities and bands, legal notices, settlement offers, the mobile app, live system integration. > > People. Sponsor: Head of Collections. Day-to-day: Collections team leader. Data owner: central IT. Message approval: Compliance officer. Budget: Finance controller. Users: twelve callers. Our side: one forward deployed engineer and one product engineer. > > Approach. (1) Spend a week with the callers and the data. (2) Build a rough version in two weeks and review it with the team. (3) Deploy into the lender's own cloud account. (4) Run for six weeks, with a weekly one-page update. (5) Review the results against the target and decide. > > Timeline. Week 1: discovery and data access request. Weeks 2 to 3: build and message template review. Week 4: deploy and test. Weeks 5 to 10: run. Week 11: review. Week 12: decision on rollout. Compliance review of templates takes about two weeks and starts in week 1. > > Data and access. A nightly file of overdue accounts with due date, amount, language and payment status, delivered to the lender's cloud account from 18 November; an account for our engineer with read access to that file; a list of permitted contact hours from Compliance. > > Risks and assumptions. The file may have gaps in the language field (we will agree a default). Template approval may take longer than two weeks (we start it in week 1). We assume callers can see the reminder status of an account (to be confirmed this week). Seasonal changes may affect payment rates (the control group handles this). > > Decisions needed. (1) Approve the nightly extract: Head of IT, by 14 November. (2) Agree the metric, target and control group: Head of Collections, by 14 November. (3) Name a Compliance reviewer for templates: Compliance officer, by 14 November.

That page is about 480 words. A busy reader can understand it in four minutes, an approver knows exactly what is being asked and an engineer can start work from it. Check how each earlier lesson is used: the problem sentence, the map of people, the scoped metric with a baseline, a target, a guardrail and a control group, and the approvals started early.

The timeline in the example puts the two-week template review first, so that it finishes while the system is being built. The chart shows the weeks in each phase.

An approval only saves time if it is started early. Try it: set how long the build takes, how long the approval takes and the week you send the request, and see when the pilot can start.

At the defaults the request goes out in week 1, comes back in week 2 and the pilot can start in week 4, right after the build. If the request waited until week 4 the pilot could not start before week 6.

Worked example: rewriting a weak plan

Here is a weak plan, the kind that often arrives in practice, followed by what is wrong with it and a rewrite of its opening.

Weak: "Project: Collections Transformation. We will leverage AI to optimise the collections process end to end, improving efficiency and recovery across the organisation. The project will be delivered in phases over the coming months in collaboration with all stakeholders. Success will be measured by improved outcomes."

What is wrong? There is no problem (who, what, how much), no number, no scope, no dates and no way to tell if it worked. The words "leverage", "optimise", "end to end" and "outcomes" sound impressive and say nothing. Nobody can disagree with it, which is exactly the problem: you cannot agree to something that says nothing.

Rewritten: "Pilot: language-matched reminders for first-month overdue loans. About 41 per cent of these accounts pay within seven days. We propose a six-week pilot in one city to raise this to 48 per cent, and need approval of a nightly data extract by 14 November."

The rewrite has a name that says what it is, a number, a target, a boundary and an ask. It could be wrong, which is a virtue: a clear statement can be corrected, and a vague one cannot.

Worked example: the plan review meeting

A plan is only useful if the customer has read and agreed it. The plan review is a short, structured conversation, and it is the moment when the page becomes an agreement.

Send the page a day ahead, with one line saying what you want from the meeting. In the meeting, spend a few minutes on each of three things. First, the problem and the target: "Is this the problem you want solved, and is this the result that would make you roll it out?" Second, the scope and the people: "Is anything in the wrong column, and is anyone missing?" Third, the decisions: "Can we settle these today?"

Listen for corrections. In the lender example, suppose the Head of Collections says: "The first band is right, but we also send letters, and callers sometimes also text. Your reminders may duplicate those." That is gold. It may change the approach, add a risk and add a person to the map, such as whoever runs the letters. Update the page at once and send it back the same day, marked "version 2, with changes from today's meeting". A customer who sees their words appear in the plan within hours trusts the process.

End the meeting by agreeing how approval will be recorded. For most pilots a reply email saying "agreed" from the sponsor is enough. For larger ones, there may be a signature. Whichever it is, keep the approved version and the date. When scope creep arrives in week six, that page is your shared memory.

Setting a date you can keep

The most common weakness in a plan is the timeline. Dates set in the optimistic mood of the first meeting are often missed, and a missed date costs more trust than a later date promised honestly.

The problem has a simple shape. Your own work has a planned length. On top of it sit dependencies you do not control: data access, security reviews, approvals, availability of users. Each has some chance of slipping, and each slip takes some time. If you add up the expected slips, you get a realistic estimate of how much longer than planned the work may take, and that tells you how much buffer to put into the date you promise.

The simulator below does the sum. Enter the planned length of the work, the number of outside dependencies, the chance that each slips, the weeks it costs when it does and the buffer you plan to add. It shows the expected finish, the date you would promise and the gap between them. The model is deliberately crude: it treats slips as independent and adds their expected values, which real life does not. Use it to see how quickly outside dependencies pile up, not as a forecast.

Try three things. First, raise the number of dependencies from four to eight and see how the expected finish grows. Second, set the buffer to zero and see how short a promised date can be of the realistic one. Third, add a buffer equal to the expected slip and see the gap close.

At the defaults, four dependencies each with a 30 per cent chance of slipping two weeks give an expected slip of 2.4 weeks, so the expected finish is 12.4 weeks against a promised 12. The promised date is a little tight, and the right move is either to add half a week of buffer, or to start the slowest approvals in the first week, as Lesson 2.2 recommended, which lowers the chance of slipping. Notice the second idea: you can often reduce the risk rather than only padding for it.

Keeping the page alive

A plan that is never touched after the first meeting stops being the plan. A good habit is to tie your weekly update to it. Each week's update starts with three lines taken from the page: which milestone is next, whether it is on track and what you need. If something changes, such as a date moving or a risk becoming real, change the page, mark the new version and say what changed.

Changes to scope deserve special care. When someone asks for a change, say what it would cost in time, money or other work, and ask the sponsor to decide. Record the decision on the page. This is not bureaucracy. It protects the customer from surprises and you from an unmeasurable project.

Common mistakes

Starting with the technology. The reader cares about the problem and the result. Lead with those. Burying the ask. Put what you need at the top and again in a short decisions list. Too long. If it runs past a page, cut the detail into an appendix. Long plans are skimmed, and skimmed plans are not agreed. Vague words. "Optimise", "leverage" and "improve outcomes" cannot be checked. Use numbers and names. Optimistic dates. Add up the outside dependencies, start the slow ones in week one and add buffer. A plan nobody agreed. Send it ahead, walk through it and record the approval. A plan that never changes. Update the page when facts change, mark the version and say what changed. Private opinions on the page. Keep notes on attitudes in your own map, not in a document that circulates.

Key takeaways

A one-page plan turns discovery into an agreement a customer can read in five minutes and check against reality every week. It has ten parts: summary, problem, outcome and metric, scope, people, approach, timeline, data and access, risks and assumptions, and decisions needed. Put the problem and the ask in the first two lines. Everything else is detail for those who want it. Use plain words, numbers and names. A clear plan can be corrected. A vague one cannot be agreed. A plan review turns the page into an agreement: send it ahead, listen for corrections, update at once and record the approval. Set dates by adding the expected slips from outside dependencies, start the slow ones early and add buffer.

Check yourself

1. Name the ten parts of the one-page plan. Summary, problem, outcome and metric, scope, people, approach, timeline, data and access, risks and assumptions, and decisions needed. 2. What two things should the first lines of a plan contain? The problem in plain words with a number, and the decision or help you need from the reader. 3. Why is "we will leverage AI to optimise collections end to end" a weak plan line? It has no problem, number, scope or date, and nobody can check it. It sounds impressive but cannot be agreed or corrected. 4. A plan has 8 weeks of your own work and 5 outside dependencies, each with a 20 per cent chance of a 3-week slip. What is the expected finish? The expected slip is 5 × 0.20 × 3 = 3 weeks, so the expected finish is 11 weeks. 5. Besides adding buffer, how can you make a date safer? Start the slow dependencies, such as data access and security reviews, in the first week, so that their chance of slipping falls.

Try this

This exercise takes about forty minutes and produces a real first plan. Use the problem and pilot scope from your exercises in Lessons 2.1 to 2.3.

1. Write the one-line summary, including the ask, and the problem with its number. 2. Copy in the metric, baseline, target and guardrail from Lesson 2.3, and the scope table. 3. List the people by role, and who decides what. 4. Write the approach in three to five steps, and a timeline with dates and the decision date. Put the slowest approval first. 5. List the data and access you need, who provides it and by when. Write three risks, each with a response, and one assumption you have not checked. 6. Write the decisions needed, with names and dates. 7. Use the simulator to check your timeline: count the outside dependencies and decide how much buffer is honest. 8. Read the page aloud in under five minutes, cut anything that does not help the reader, and give it to a friend with one question: "What would you need to approve this?"

A good result is a one-page plan of 400 to 600 words that a stranger can understand in five minutes and say yes or no to. Keep it. You have written the document that opens every real forward deployed project, and the next module shows how to start building from it.

Sources

The lender plan, the weak example, the figures and the simulator's defaults are the author's illustrations for teaching, not documents or data from a real company. The ten-part structure is a practical layout written for this lesson, not an industry standard.

Tags: Forward Deployed Engineer Planning Scoping Customer communication Beginner