There was no honest playbook for building in Africa. So we wrote one.
There was no honest playbook for building in Africa. So we wrote one.
How it works
Most early plans are a list of things the founder is sure about. This one is a list of things to check. Fill in the six blocks in order, run the experiments in block 4, and rewrite blocks 2 and 3 when the results come in. If nothing changes after a sprint, you are not testing anything.
Define the long-term impact you aim to create and the specific problem you’re solving for your target audience.
Why it matters
Everything downstream inherits these three lines. A vague problem produces vague assumptions, and assumptions that cannot fail produce experiments that teach nothing.
How to fill it in
Write the three lines in one pass, then read them to someone outside the company. If they cannot repeat the problem back to you, it is not specific enough yet.
List key assumptions about your users, market, or solution that need to be tested to reduce risk.
Why it matters
A plan is a stack of beliefs. Writing them down separates what you have evidence for from what you are hoping. Ranking by damage tells you what to test first.
How to fill it in
List every assumption before you judge any of them, then rank by damage rather than by how easy each one is to test. Three to seven lines is the working range.
Start with the assumptions that would kill the business, not the ones that are easy to test.
Outline the minimal feature set needed to test core hypotheses and deliver value quickly.
Why it matters
The MVP exists to settle one argument, not to be version one. Naming what it leaves out is what keeps it small; the pull is always to build what you already wanted to build.
How to fill it in
Fill in the hypothesis and the feature set first and decide the format last. Once you know what you are testing, the cheapest way to test it is usually obvious.
An MVP is not a small version of the product. It is a test with a product-shaped front.
Plan structured tests with measurable goals to validate assumptions and guide decisions.
Why it matters
A test with no pass mark set in advance becomes a story you tell afterwards. The threshold is what makes a result capable of being wrong.
How to fill it in
Set the threshold before you run anything, and write it as a number. If you cannot name a number, the experiment is not ready to run.
Use numbers you can count: sign-ups, paid orders, repeat use, calls booked. Not “interest” or “positive feedback”.
Record insights from experiments and user feedback to inform next steps and product evolution.
Why it matters
The only block that accumulates. Six months in, it is the record of what you believed, what happened and what you changed. It is the document investors ask for and almost nobody has.
How to fill it in
Add a line on the day an experiment ends rather than at the end of the sprint. What you lose by waiting is always the reason behind the decision.
Write the decision down. Founders who don’t tend to persevere by default.
Break work into short, time-bound cycles focused on learning, building, or testing.
Why it matters
Short cycles force a decision on a fixed date rather than when the work feels done. Typing each sprint build, measure or learn stops months of building with nothing measured.
How to fill it in
Plan one sprint at a time rather than a quarter, and name an owner even when the team is two people. A goal that belongs to everyone is the first one to slip.
Weekly for pre-launch teams, monthly once you have paying customers.
How to use it
Work through Vision and problem, Assumptions and MVP design in a single sitting. A rough version you go back and revise is worth more than a considered one you never finish.
Run the first experiment before you refine anything else on the page.
After every experiment, update blocks 2, 3 and 5 before planning the next sprint.
Keep old versions. The trail of what you believed and dropped is worth more to investors than the current plan.
