Monthly Focus Documents Instead of Roadmaps (2026 Guide)

A monthly focus document is a one-page plan, written as each month begins, that lists the few projects a team will finish in the next 30 days, who owns each one and why it matters. It replaces a long roadmap with a short, dated commitment you rewrite every month, so the plan never drifts far from what the team is actually doing.

Roadmaps tend to fail quietly. The slide gets made in January, everyone nods, and by April it describes a company that no longer exists. A focus document accepts that plans change and makes the change a monthly habit instead of an awkward admission. This guide covers what goes in one, how it differs from a roadmap, when you still need the roadmap, a template you can copy, how to run the month around it, and how to keep it in apps you already have on a Mac.

What is a monthly focus document?

A monthly focus document is a short written plan for one month of work: a sentence on what the month is for, a handful of projects with a named owner each, and a line on why each project made the cut. It is deliberately small. If it runs past a page, it has turned back into a roadmap.

Raycast, the Mac launcher company, described the practice in a January 2021 post by Thomas Paul Mann. At the time the team was five people, fully remote, and wanted a way to stay on multi-week projects instead of spending every day reacting to bug reports and feedback. Each project in their document had an owner and a link to its project in Linear, every team member owned at least one project, and the summary at the top deliberately left out metrics and growth targets. The author was also candid that he didn't know how well it would hold up as the team grew.

You don't need to copy their format to get the benefit. The idea underneath is what matters: decide a little, write it down, give each piece an owner, and decide again in four weeks.

Focus document vs. roadmap: what's the difference?

A roadmap is a forward list of features or projects, often stretching a year or more, that tells people what will be built and roughly when. A focus document covers one month, names owners rather than dates, and explains the reason for each project. The roadmap answers "what's coming?"; the focus document answers "what are we doing right now, and why this instead of something else?"

The "why" row is the one that matters most. Marty Cagan of Silicon Valley Product Group argues in The Alternative to Roadmaps that the core problem with a typical roadmap is that it tells teams what to build without stating the problem it's meant to solve, so nobody can tell whether a feature is still worth building when circumstances change. His alternative leans on a product vision and measurable objectives per team, with firm date commitments kept for the cases that genuinely need them.

Basecamp makes a similar point from a different angle. In Shape Up, its book on how it works, the chapter Bets, Not Backlogs argues that long backlogs pile up work nobody will ever get to and leave the team feeling permanently behind. Basecamp works in six-week cycles followed by a two-week cool-down, and its betting table commits only one cycle ahead, leaving everything else open. A monthly focus document is the same instinct on a calendar-month rhythm.

When a focus document beats a roadmap, and when it doesn't

A monthly focus document works best for small teams whose plans change faster than a quarterly review can keep up with: early-stage startups, a product team inside a bigger company, an agency squad, or one person running several projects. It works badly as the only plan when someone outside the team needs a date they can build on.

Reach for the focus document when:

• The team is small enough that one page covers everyone. Each person owns at least one line, so nobody's work is invisible.
• Priorities move month to month. A new customer, a launch, a fundraising round or a reorg changes what matters, and you want the plan to change with it without a big replanning exercise.
• Interruptions are eating the big work. Writing down the few projects that matter makes it easier to say no, or not yet, to everything else.

Keep a roadmap, or at least a short list of dated commitments, alongside it when:

• Customers or sales need dates. An enterprise deal that depends on a feature by a contract date needs that date written somewhere more permanent than this month's page.
• Other teams depend on you. A platform team, a partner integration or a regulatory deadline needs a longer view than 30 days.
• Leadership or a board wants direction. A short statement of where the product is heading over the year gives the monthly documents something to point at.

A client once pressed me for a delivery date on something we had only just started shaping. Rather than invent one, I told them which month it was in the focus document and promised a firmer date at the next month's review. That held up far better than a guess would have. The two documents don't compete; the roadmap says where you're heading, and the focus document says which steps you're taking this month.

What goes in a monthly focus document

Every monthly focus document needs four parts: one sentence on what the month is for, a short list of projects with an owner and a reason each, a list of what you're deliberately not doing, and a few lines looking back at last month. Anything beyond that is optional.

• The month in one sentence. What should be true by month's end? "New customers can set up the product without a call" is a month. "Work on onboarding" isn't.
• Three to six projects. Fewer than three and you probably don't need the document; more than six and the month won't hold them. Each one gets a single owner, a one-line description of what will exist when it's done, and a line on why it beat the alternatives.
• A definition of done for each project. Something a stranger could check: shipped to all users, sent to the client, merged and documented.
• What we're not doing. The tempting projects that didn't make the cut, named out loud so nobody quietly starts them.
• Last month in three lines. What finished, what slipped and why. Keep it honest and short.
• Links, not detail. Point each project to wherever the real work lives, such as a task board, a design file or a brief. The focus document is the index, not the workspace.

The "not doing" list is the part I'd keep if I could keep only one. The first time I wrote one, it felt almost rude to list good ideas we weren't going to touch. By the middle of that month it had become the most useful line on the page, because it ended the same conversation every time it came up.

A monthly focus document template you can copy

[Team name] focus: [Month year]
Written [date] by [your name]. Next one: first Monday of [next month].

THIS MONTH IS FOR
[One sentence: what will be true when this month closes.]

PROJECTS
1. [Project name]  |  Owner: [name]
   What: [What will exist when it's done, in one line.]
   Why now: [Why this beat everything else this month.]
   Done means: [Something anyone could check.]
   Link: [task board, brief or doc]

2. [Project name]  |  Owner: [name]
   What:
   Why now:
   Done means:
   Link:

3. [Project name]  |  Owner: [name]
   What:
   Why now:
   Done means:
   Link:

NOT DOING THIS MONTH
- [Tempting project], because [one-line reason].
- [Tempting project], because [one-line reason].

UNPLANNED WORK
- Small fixes: the owner of that area handles them without asking.
- Anything bigger: raise it, and say which project above it would replace.

LAST MONTH
- Finished: [list]
- Slipped: [project], because [reason]. [Moved to this month / dropped.]
- Learned: [one line]

Rename the headings to suit your team. The structure matters more than the labels: purpose, owned projects, explicit trade-offs, a rule for interruptions and a short look back.

How to write a monthly focus document in about an hour

Writing a monthly focus document should take one person about an hour, plus a short meeting to agree it. If it takes a full day, the team is negotiating the plan in the document instead of before it.

1. Look back first. Open last month's document and mark each project finished, slipped or dropped. Write the three "last month" lines before anything else, so the new plan starts from what really happened.
2. Collect candidates. Gather what's on people's minds: customer requests, things that slipped, ideas from the past month. Ask each person for the one project they think matters most.
3. Write the one-sentence purpose. Pick the outcome that matters most this month. If you can't agree on it, that disagreement is the real planning conversation, so have it now.
4. Choose the projects that serve that sentence. Cut until each person owns at least one and nobody owns more than they can finish. Move the cuts to "not doing."
5. Give every project one owner. Not a pair, not a team. Others can help, but one name decides how the work gets done.
6. Write the why and the done line. If the why is hard to write, the project probably doesn't belong this month.
7. Share it and hold a 30-minute review. Owners confirm they can deliver their line, or say what they'd swap. Then the document is fixed for the month.

Writing a project line people can act on

A project line works when someone outside the team could read it and know what will exist once the month is over. Vague lines are the most common reason a focus document stops being useful by week two.

Weak: "Improve onboarding. Owner: product team." No single owner, no finish line, no reason.

Better: "New sign-ups can import their contacts in the first session. Owner: one named engineer. Why now: it's the step most trial users stop at. Done means: live for all new accounts, with a help article."

The second version takes thirty seconds longer to write and saves a month of people working on slightly different ideas of "better onboarding."

How to run the month around the focus document

A focus document only works if the team looks at it after the first week. Three light rituals keep it alive: a kickoff when it's agreed, a short midpoint check, and a review that feeds straight into next month's document.

• Kickoff (right after the review that agrees it). Walk through the page in 15 to 30 minutes. Each owner says what done looks like for their line.
• Midpoint check (around the 15th). Each owner says on track, at risk or blocked. At-risk projects get a decision now: cut the scope, get help, or move the line to next month.
• Review (last few days). Mark each project finished, slipped or dropped, and note why. That becomes the "last month" section of the next document.

Unplanned work is where most monthly plans break. Decide the rule before the month starts and write it on the page. A useful default: small fixes go to whoever owns that area and don't need approval; anything bigger has to name the project it would push out; and requests that keep coming back become candidates for next month instead of interruptions this month.

If your team runs its tasks in Linear, its cycles can sit underneath a monthly plan: Linear's docs say a cycle can last 1 to 8 weeks on a repeating schedule, open issues normally roll over into the next cycle, and an optional cooldown can follow each one. A four-week cycle lines up roughly with a calendar month, though not exactly, so pick which calendar the team follows and say so in the document.

How to keep a monthly focus document on a Mac

On a Mac, a shared note in Apple Notes is enough for a monthly focus document: everyone can edit it, you can see who changed what, and it syncs to iPhone and iPad through iCloud. Teams already living in Notion, Google Docs or Confluence should keep the document there instead; the right home is wherever people already look every day.

To share the note so the team can edit it, per Apple's Notes guide for macOS:

1. Open the note in the Notes app.
2. In the toolbar, click Share.
3. Choose Share a Link in the menu that opens, then set who can access it and whether they Can edit or Can view and download.
4. Send the invitation. If you share it through Messages, Apple says you'll get updates in that conversation whenever someone changes the note.

Collaboration needs the note to be stored in iCloud, with upgraded iCloud notes. To share every month's document at once, keep them in one folder and choose Share Folder from the folder's Control-click menu instead.

Two features make Notes better for this job than it first looks. Show Highlights, available from Share or from the participants' pictures in the toolbar, colors each person's changes and shows when they last edited; Show All Activity lists what changed since you last opened the note, day by day (Apple). For a midpoint check, that activity view tells you quickly which project lines have moved.

I keep the current month's note pinned at the top of Notes on my Mac, so it's the first thing I see when I open the app. Select the note and choose File > Pin Note, per Apple's guide to pinning notes; when the month ends, unpin it and pin the new one.

Then make the writing itself a fixed appointment. In Calendar, create a one-hour event for writing the document, open its details, click the Repeat pop-up menu, choose Custom, set Frequency to Monthly, select On the and pick the first Monday, as Apple's Calendar guide describes. Put the 30-minute review on the day after.

Where monthly focus documents go wrong

Most monthly focus documents go wrong in one of a few predictable ways, and each has a simple fix.

The rollover row is the one worth watching. When I've watched a project sit on focus document after focus document without finishing, the honest answer has usually been that nobody believed in it enough to cut it. Saying so in the review is uncomfortable for about a minute and saves another month.

For more on how small teams split up planning and follow-through, see AI for COOs and operators, and if you're weighing a daily planner for your own share of the month, our look at Sunsama and its alternatives compares the options.