ORBITAL: objective, resources and budget

This is lesson 11, the first of six about ORBITAL. It supports Developer weeks 3 and 4 (plan the product, then defend the roadmap) and the Master Developer work of turning an idea into a funded plan.

1. Why this matters

Every product starts with a wish: “people should be able to do X”. A wish is not a plan. A plan says what exactly will be true, when, what it needs and what it costs. Without that, every later argument (about scope, staff, delay) has nothing to stand on.

ORBITAL is the Dojo’s name for a seven-part product plan. The seven letters are Objective, Resources, Budget, Indicators, Transport, Activities and Logistics. The source material says it can be used for a project, a programme, a company or a department. This lesson covers the first three letters. They answer three plain questions: what do we want, what do we need, and what does it cost?

The 2030 Product Development Manager (PDM) writes these three sections personally, because they are decisions: what to aim at, what to spend, what to give up. An agent can draft, calculate and check. It cannot know what your customers will pay for, what your investors will tolerate or what your team can bear. Those are your judgments.

A word on honesty: ORBITAL is a Dojo tool, not an industry standard. It borrows well-known ideas (goals with numbers, resource planning, budgeting) and puts them in a fixed order that people from every discipline can read.

2. Key ideas, explained

Objective: the one outcome

The objective is the outcome you want, in measurable words. The source lists four parts of a good one: a clear goal, a spark of innovation, a measurable result and alignment with the larger strategy. In plain words, a good objective passes five checks.

Check	Question	Example (weak)	Example (strong)
One outcome	Is it one thing?	“Grow and improve returns and sign cafés”	“Customers return cups at any partner café”
A number	How will we know?	“Many cafés”	“Eight cafés open the pilot”
A date	By when?	“Soon”	“By 31 March”
An owner	Whose name is on it?	“The team”	“Maya”
A reason	Which larger goal does it serve?	(blank)	“Fewer single-use cups in the city, which is why cafés joined”

It is the same idea as the SMART test from lesson 9, applied at plan size. A related method called OKR (objectives and key results) writes the objective in words and attaches two to five numbers. You can use the OKR style inside ORBITAL: the Objective is the O, and the key results become the Indicators in lesson 12.

An objective is not a feature list. “Build a mobile app” is an activity. “Customers can return a cup in under a minute” is an outcome. Write the outcome. Choose the activities later.

Resources: what you need

Resources are everything the plan needs to be carried out. The source groups them as people, technology and materials. For a software product we use five groups.

Group	Examples	Question to ask
People	You, a designer, a café contact, a lawyer, an accountant	Who has the skill, and how many hours do they have?
Tools and platforms	Code hosting, a database, a payment provider, an agent service	Which are free, which are paid, which can we replace?
Data	Customer interviews, a list of cafés, a price list	Do we own it? May we use it?
Equipment and materials	Tablets, cups, wash equipment, signs	Do we buy, rent or borrow?
Partners	A cup supplier, a washing partner, the first cafés	What do they need from us in return?

For every resource, write a status: available (we have it), to find (we know what we need but not who), or to buy (we know and it costs money). Anything to find is a risk. Anything to buy goes into the budget.

The source also asks you to check capability: do the people have the skills, and is the use of resources sustainable? In practice: write down who will do each task, and say honestly where a skill is missing. A missing skill is not a failure. A hidden missing skill is.

Agents are resources too. In 2030 a plan lists the agent jobs it expects (research, drafts, tests) with the cost of the service and the person who reviews the output. Record their limits as you would for any new colleague.

Budget: money in time order

A budget is a plan for money: what you expect to spend, when and where the money comes from. The source asks for an itemised budget, cost control and reporting. A simple budget has four parts.

1. Lines by category. For example: people, tools, equipment, partners, legal and accounting, contingency.
2. A month-by-month view. Money moves over time, and a budget that is fine in total can still run out in month three.
3. Sources. Where the money comes from: your savings, a grant, a customer fee, a sponsor. Mark each as secured or hoped for.
4. An approver and a rule. One named person approves spending over a set amount, and spending is checked against the plan at a fixed rhythm (for example, every month).

Two habits protect a budget. First, add a contingency: a reserve for the unexpected. Ten to twenty percent is a common starting point, but adjust it to your risk, and write your reason. Second, split one-off costs (equipment, set-up) from running costs (monthly tools, staff). Running costs are the ones that quietly sink a small company.

Budget numbers must be labelled by confidence, using the marks from lesson 4: KNOWN (from an invoice or a price page), BELIEVED (from a reliable estimate) and GUESS. A budget full of guesses is still useful, if everyone can see that they are guesses.

A money word to define: burn rate is how much money you spend each month. Runway is how many months you can continue at that rate with the money you have.

3. Step by step: write the first three letters

1. Write the objective as a draft sentence. “By , can , measured by .”
2. Run the five checks (one outcome, a number, a date, an owner, a reason). Rewrite until all five are yes.
3. Check the reason. Which larger goal (a STAR Reach, a UBF opportunity) does the objective serve? Link the file.
4. List resources in the five groups. Give each a status and an owner.
5. Mark every skill gap. For each gap choose: learn, hire, borrow or drop the part of the plan.
6. Draft the budget lines. One line per cost, with a category, a one-off or running flag, a month and a confidence mark.
7. Add the sources of money and mark them secured or hoped for.
8. Compute the month-by-month balance. If it goes below zero in any month, change the plan, not the arithmetic.
9. Add a contingency line with a reason.
10. Name the approver and the review rhythm.
11. Ask a finance colleague (or a friend with business experience) to challenge the three sections.
12. Commit to frameworks/orbital.md under three headings, and open a merge request.

4. Worked example: TrailMug

All numbers below are invented for teaching. They are not a forecast and they are not real prices.

TrailMug is the fictional reusable-cup service. Maya has finished lessons 5 to 10: her galaxy, her STAR and her portfolio. Now she writes the first three letters of her pilot plan.

O: Objective.

By 31 March, eight partner cafés in one city lend and take back TrailMug cups, and at least 70 of every 100 cups lent are returned within seven days. Owner: Maya. Reason: fewer single-use cups, which is why the cafés joined.

Maya runs the five checks. One outcome: yes (lend and return, one loop). A number: yes (eight cafés, 70 of 100). A date and an owner: yes. A reason: yes. She notes that “70 of 100” is a GUESS, because she has no return data yet. She writes: “Replace after the first month of real data.”

R: Resources.

Resource	Group	Status	Owner	Note
Maya (20 hours a week)	People	available	Maya	Founder and PDM
Part-time designer (6 hours a week)	People	to find	Maya	Needed for the café page by week 4
Accountant for set-up questions	People	to find	Maya	One session
Code hosting and pipelines	Tools	available	Maya	Free plan
Payment provider (test mode)	Tools	available	Maya	Behind an adapter, so replaceable
Agent service for drafts and tests	Tools	to buy	Maya	Monthly fee; every output reviewed
400 cups and 8 lids-and-sleeves sets	Equipment	to buy	Maya	From a cup supplier
Washing partner	Partners	to find	Maya	No price yet: main risk
Eight pilot cafés	Partners	available	Maya	Letters of interest, not contracts

Maya’s skill gap: design. Her choice: borrow, with a part-time designer.

B: Budget (invented, in a made-up currency “TM$”).

Line	Type	Mar	Apr	May	Confidence
Cups and sleeves	One-off	2,000	0	0	BELIEVED (a supplier quote)
Designer	Running	600	600	600	BELIEVED
Agent service	Running	80	80	80	KNOWN (price page)
Washing (partner)	Running	0	400	400	GUESS (no quote yet)
Accountant	One-off	150	0	0	BELIEVED
Contingency (15% of the rest)	Reserve	400	170	170	Maya’s reason: the washing price is unknown
Total out		3,230	1,250	1,250
Money in: Maya’s savings	Source	4,000	0	0	Secured
Money in: café monthly fees	Source	0	400	800	Hoped for
Balance at month end		770	-80	-530

Look at what the table shows. Total costs are covered over three months only if the café fees arrive. In April the balance is already negative. Maya decides: ask the washing partner for a quote before she orders cups, and start with 250 cups instead of 400. She changes the plan. She does not change the arithmetic. A finance friend reads the table and asks one question that helps: “What if two cafés pay late?” Maya adds a line to Logistics (lesson 14).

Notice who did what. Maya decided the objective, the sources and the scale of the pilot. An agent drafted the table layout and checked the sums. A friend challenged the weakest assumption.

5. Working with AI agents on this

	For Objective, Resources and Budget
What the PDM decides	The objective and its number. Which resources to accept. How much to spend and where the money comes from. Who approves spending.
What agents do	Draft the section layout. Turn your notes into the resource table. Add up the budget and test what happens if a cost rises or income arrives late. Search public price pages for tools. List questions a funder would ask.
How the PDM verifies	Recompute any sum by hand once. Open every price link and check the date. Compare the objective with the five checks. Ask the agent which numbers are guesses.
Who else is involved	Finance (budget, tax), the founder or sponsor (objective), legal (contracts), the people named as owners.

A brief you can adapt:

Context: frameworks/galaxy.md and frameworks/star.md (read only).
Task: draft the O, R and B sections of frameworks/orbital.md for the
pilot described in my notes (below). Use the layout in the template.
Rules:
1. Do not change my objective sentence. Check it against five tests
   (one outcome, a number, a date, an owner, a reason) and list failures.
2. Resources: use the five groups. Status is available, to find or to buy.
   Do not invent suppliers or prices. Write "UNKNOWN" instead.
3. Budget: use my figures only. Add a confidence mark to every figure:
   KNOWN, BELIEVED or GUESS. Compute month-end balances and show the
   formula in a comment. List the three figures that would hurt most
   if wrong.
4. Return markdown only. Put every question for me under OPEN QUESTIONS.

When this work becomes orchestration (several agents running at once, say one on prices, one on the table and one on a risk review), give each its own branch and folder, and let a gate decide what merges: the budget file needs your review before it is accepted. The agent orchestration track explains how.

A reminder from The Way: people write epics and roadmaps; AI never does. ORBITAL sits above them. The objective you write here is what the epic later serves.

6. Common mistakes and how to avoid them

• An objective that is a to-do list. “Build the app” is an activity. Write the outcome.
• Two objectives in one. Split them, or pick one.
• No date. An objective with no date is a hope.
• Resources without owners. A resource with no owner is nobody’s job.
• Hiding skill gaps. Say where you are weak. Then borrow, learn or hire.
• A total with no timeline. A fine total can hide a negative month.
• No contingency. Something will change. A reserve with a stated reason is honest.
• Treating guesses as quotes. Mark every figure.
• Letting an agent invent prices. An invented number looks as good as a real one. Ask for sources or “UNKNOWN”.

7. Practice

Goal: write the O, R and B sections of an ORBITAL for your product, or for TrailMug.

1. Create frameworks/orbital.md with three headings: Objective, Resources, Budget.
2. Write the objective sentence. Run the five checks and record the result for each.
3. Write the resource table with groups, status and owner. Mark at least one skill gap and your choice (learn, hire, borrow or drop).
4. Write the budget with at least six lines, a month-by-month view, sources of money and a confidence mark on every figure.
5. Run the agent brief above on your notes. Compare its output with your own, and record in AI use: what you accepted and what you changed or rejected.
6. Ask someone from finance or business (a person, not an agent) to find the weakest assumption. Record their comment.
7. Open a merge request.

Deliverable: frameworks/orbital.md with the O, R and B sections, confidence marks on every number, an AI use: line and one human review comment.

8. Checklist

• My objective has one outcome, a number, a date, an owner and a reason.
• Every resource has a group, a status and an owner.
• I named at least one skill gap and what I will do about it.
• The budget shows each month, not only the total.
• Every figure is marked KNOWN, BELIEVED or GUESS.
• Each source of money is marked secured or hoped for.
• A named person approves spending.
• A person outside my discipline challenged the draft.