How the planning method works

Status: draft, untested

Supporting explanation and illustrative example. The MktOS Guide is the current framework authority; Start here and the marketing plan template are the first-use route. This article retains its original example and teaching sequence. Its fixed timeboxes, solo work limit, and eight-week observation window are example settings. A sprint does not automatically change agreed targets, but new evidence can trigger an explicit replan. Waiting for measurement does not consume an active delivery slot; follow-up still needs an owner and review date. Read the weekly routine for current event guidance.

Cadence update, 2026-11-01: the current MktOS model establishes North Star Metrics and annual OKRs in yearly planning and reviews them quarterly. The quarter-based objective/KR setup described in this original teaching example is retained as historical illustration; use the current operating cadence and plan template for new work.

Some quarters the list of finished work is long: posts, emails, a new landing page, a webinar. And you can't say whether any of it brought in a customer.

I'm writing for solo marketers and teams of up to five. The same people plan the work, do it and report on it. There's little time left to ask whether it did anything, so the marketing stays busy and doesn't add up.

This article explains the planning method I've written down for that problem, from a quarter's direction down to a one-hour weekly loop. It's documented but untested: I haven't used it on a real planning session yet, which I come back to at the end.

Done is not the same as worked

The method rests on one rule: finishing the work doesn't prove the marketing worked.

A finished project shows you delivered something. It doesn't show your audience did anything differently. So a finished project doesn't mean the number it was meant to move has moved, and that number moving doesn't mean the bigger goal was met. Each needs its own evidence.

Completion is easy to see and outcomes arrive slowly, so plans drift toward counting completion. Then every busy quarter looks like a success.

The shape of the method

There are two parts:

• A planning session at the start of each quarter, where you work down six levels: North Star, Objective, Key Result, Project, Milestone and Done-when gate.
• A weekly loop of one hour, where you review last week and plan the next. Once a month that hour makes room for a monthly review.

The North Star has no end date; you revisit it once a year. Objectives, Key Results and projects are set each quarter. Evidence is checked monthly, and the work runs in weekly sprints: a sprint is the handful of tasks you commit to for the next seven days.

The running example

I'll use one example throughout. It's illustrative and the numbers are invented.

Say you're a solo consultant who sets up bookkeeping systems for small agencies. You have about 5 hours a week for marketing: 1 hour for the weekly loop, 2 for this quarter's project, and 2 for everything else, like posting, replying and the odd request. People find you on LinkedIn, follow you, and stop there.

Running the planning session

Before you start, open what you already have: last quarter's review if there is one, your audience and channel notes, your real weekly hours, ideas you've parked, and the current figure for each measure you might use, with where you read it. If something is missing, note the gap. Don't create it mid-session.

Then work down the six levels in order, in one sitting. At each level, answer the decision question before you fill in anything. Every health rating starts as Not assessed, because there's no evidence yet; the labels are explained further down. The output is a one-page plan, like the one at the end of this section.

Six levels, from North Star to done

1. North Star

Decision: Which one audience or revenue outcome shows your marketing delivered value? And which outputs will you refuse to count toward it? Outcomes are things like qualified leads, retained customers or pipeline. Outputs are posts published, emails sent, assets made.

Write down: the measure, what counts, what doesn't, and where it's tracked.

Example: qualified discovery calls per month, counted from your booking form. Qualified means an agency owner who fits the service and booked a call. Followers, posts and newsletter sign-ups don't count.

Common mistake: changing the definition quietly. Redefine it in one document and not another, and two versions of your top measure live at once.

2. Objective

Decision: Which audience, channel or funnel stage are you improving this quarter, and what will be different for that audience if it works?

Write down: the objective, why this and why now (with evidence), what this quarter will not try to improve, and its health.

Example: agency owners who find you on LinkedIn book a call instead of just following. Why now: you have a steady trickle of followers, but only about 2 calls a month come from LinkedIn. Not this quarter: search, the newsletter, referrals. Health: Not assessed.

Common mistake: trying to improve everything. The "not this quarter" line is what protects your focus.

3. Key Result

Decision: Which audience behaviour or business result will show the objective improved, read from which report, starting from what baseline? Think leads, sign-ups, replies, conversions or revenue.

Write down, for each Key Result (KR): the result, the measure and its data source, the baseline, the target, and its health.

If you don't know the baseline, write "unknown", never zero. A target built on a made-up zero shows progress the moment anything happens. And before you accept a measure, ask whether you can read it today. If you can't, making it readable becomes part of the work.

Example:

• Calls KR: qualified discovery calls from LinkedIn, read from the "how did you hear about me" field your booking form already has, over the last three months. Baseline 2 a month. Target 5 a month in the quarter's final month.
• Click-through KR: the share of profile visitors who click through to your booking page. Baseline unknown, because you don't track it yet. Target set once you have two weeks of data.

Common mistake: activity KRs, like "publish 12 posts". If every KR is an activity, the quarter can rate On Track across the board with no evidence of a marketing result.

4. Project

Decision: Which bounded piece of marketing work (a campaign, an asset, a channel test) do you expect to move which KR, and does it fit the hours you actually have each week?

Write down: the project, the KRs it supports, its scope, its budget in hours (total and per week), and its health.

Example: rebuild the path from LinkedIn to booking: your profile, the featured section, the booking page, and six case-study posts, about one a week from week 5. It supports both KRs. Budget: 24 hours over 12 weeks. That averages 2 hours a week. Weeks 3 and 4 need 4 hours each for the rebuild, so those two weeks borrow from your "everything else" time.

Common mistake: a plan that doesn't fit your real hours. A related one: keeping your spare hours in weeks 1 and 2, when the hard work is in weeks 3 and 4.

5. Milestone

I treat milestones as a planning level of their own, not just dates on a task list. Without them, a project only tells you it's late once it's over.

Decision: Which checkpoint shows this project is moving its KR, by when, and at what cost in hours?

Write down, for each milestone: a name, the KR it moves, the hours, the due date, and the evidence that it's done.

Example:

Total: 24 hours.

Common mistakes: milestones that are really to-do lists, and assuming a finished milestone means the KR moved. A finished rebuild means the path exists. Whether anyone uses it is a separate question.

6. Done-when gate

Each project has one gate. It closes the project, and it can fail.

Decision: What result has to exist before you call this work done? And what result makes you stop, narrow to one channel or segment, or carry it into next quarter? For example: a conversion count over a set window, replies from a named segment, or a test with enough sends or visits to read.

Write down: the done-when condition, where the evidence lives, a stop-or-narrow rule, what happens if the evidence is thin, and a KR check separate from completion.

Done means the evidence exists. Whether each KR passed is judged separately, against its own target. If the work doesn't fit your capacity, narrow the scope, never the evidence.

Example:

• Done when: all four milestones are complete, and eight weeks of booking data from after the path went live are recorded and compared with the 2-a-month baseline.
• Stop or narrow: if the posts bring fewer than 20 booking-link clicks in total by week 8, stop the case-study posts and narrow to the booking page alone.
• If the evidence is thin: the test carries into next quarter as unfinished. It doesn't pass.
• KR check: each KR is read against its own target, whatever the milestones say.

Common mistake: stop rules that all allow carrying on. "If it's slow, keep going and review" never triggers, so the gate can never fail.

The example plan on one page

Rating health separately

Use four labels: On Track, At Risk, Off Track and Not assessed. Not assessed means no evidence yet. Rate the objective, each KR and the project, each on its own evidence. As a rule of thumb, At Risk means the evidence says you're behind but can still recover in the hours you have; Off Track means you can't get there without changing the scope or the target.

Here's the example in week 10:

The project is on track and the calls KR isn't. If the project's On Track rating leaked into the KR, you'd go into the last two weeks believing the work had paid off. Rated separately, you see calls lagging while there's still time to ask why. The click-through row shows the other trap: a measure you set up and then stopped reading.

From milestones to tasks

Add tasks one milestone ahead. Don't plan the whole quarter's tasks upfront, because by week 6 you'll know things you didn't in week 1.

Each task gets an estimate, an output and its own "done when". When "Baseline readable" closes, you add the tasks for "Path rebuilt":

• Rewrite the profile headline and about section. 2 hours. Output: live profile. Done when published.
• Rewrite the booking page. 3 hours. Output: live booking page. Done when published and a test booking records its source.
• Rebuild the featured section. 2 hours. Done when live.
• Test the path. 1 hour. Done when a test visit reaches booking in two clicks.

Work on one task at a time. When a new request comes in, decide straight away. If a client asks you to run a webinar for their network, it either replaces planned work, and you note what it bumped, or it goes to the backlog, your list of parked ideas and requests. It doesn't get squeezed into this week's 2 project hours.

Each week you pick a few ready tasks into the sprint.

The weekly loop: Retro, then Planning

Each week has two events: a Retro on the sprint that just ended, then Planning for the next. The Retro goes first because last week's evidence should shape next week's plan. In week 1 there's nothing to review, so start with Planning.

The step names below are the ones I use; the right-hand column says what each means.

Retro: 30 minutes

Treat the Retro as an investigation of choices and conditions, without blame. Missing evidence stays missing; don't fill the gap with what probably happened. Write down what you learned, even if it's "this didn't work".

Example, week 7. The sprint goal was "publish case study 3". It went out two days late. The draft took the 1.5 hours you estimated, but the client's OK to name them took four days.

• Facts: the draft was ready on time. The approval wait made the post late.
• Conditions: you asked for permission after drafting, so the finished draft sat waiting.
• What you can influence: when you ask. How fast the client replies is out of your hands.
• Modify: start asking for permission to publish when a client project closes, before drafting. Owner: you. Cost: 15 minutes. Evidence: approval time on the next post.

Planning: 20 minutes

A sprint is a bet: this work, in these hours, should move this milestone and its KR. Keep one sprint goal and one task in progress at a time.

Example, week 8. Sprint goal: publish case study 4 and send permission requests for 5 and 6. It supports the case-study milestone, which moves the calls KR. The project's share of your week is 2 hours:

• Draft case study 4: 1 hour 15 minutes.
• Final edit and publish: 30 minutes.
• Send the two permission requests: 15 minutes. This is the Retro's improvement action.

That's 2 hours. It fits. First task: draft case study 4.

What a sprint can't change. A weekly sprint doesn't reopen the North Star or change the quarter's targets. An experiment can run across several sprints, so if the booking data needs eight weeks to read, keep the eight weeks even when one week looks bad.

Recording: 10 minutes

Use the last 10 minutes to record decisions and link evidence. The whole loop is 60 minutes a week. If recording runs over, cut discussion rather than quietly extending the hour.

A short record for each event:

• Retro: sprint goal; last action's effect (or "no evidence"); what shipped; main friction; one improvement action with its behaviour, owner, cost and evidence.
• Planning: sprint goal and the KR it supports; hours available, including carryover; selected tasks with estimates; the improvement action; first task.

There are longer versions of both events, 45 minutes for the Retro and 25 for Planning. Use them only in a week where the extra time has a real place in your hours. They don't fit inside the one-hour budget.

The monthly-review week

Once a month, for example in weeks 4, 8 and 12, the hour changes shape:

• Retro: 8 minutes
• Planning: 7 minutes
• Recording: 5 minutes
• Monthly reflection: 20 minutes on the month's weekly evidence, repeated friction, capacity and experiments, ending with one adjustment for next month
• KR and project review: 20 minutes on evidence, capacity and scope decisions

That's still 60 minutes. Don't run the normal hour and the monthly review in the same week.

What I don't know yet

I haven't used this on a real planning session yet, so I can't tell you it works.

My first test is to plan my next quarter from cold, using only inputs that already exist, and time how long it takes to reach a first real planning decision. I'm aiming for three hours or less. Then I'll use it on two real priorities, keep a log of where it slows me down or confuses me, and revise it from what actually happened.

If it works, it should make one thing hard to do: call a quarter good because it was busy.

If you try one planning session and one weekly loop, tell me where it breaks: which level stalled you, and how long your first session took.