A free writing template
First-focus plan
Choose a useful short-term outcome and make room for the work that supports it.
Use it when a team needs a shared starting point for a Focus and wants to avoid treating every request as equally urgent.
No account or email needed. Downloads work without JavaScript.
Make the structure useful
Current facts.
A clear next step.
Replace the prompts with your own context. Keep an unanswered question visible when the facts are missing. Agree the people and decisions rather than copying them from the example.
The blank and filled versions are portable Markdown. They do not install native Tellenze templates or create workspace work.
Plan work with Focuses- 01
Agree one outcome for the Focus and the evidence that would show progress.
- 02
Check available capacity and existing commitments before selecting work. An estimate is not a promised duration.
- 03
List a small set of defined work, its dependencies and the people who will coordinate it.
- 04
Agree when to inspect progress and what to do when a blocker or new request changes the plan.
01 / Your starting point
Begin with the real work.
Copy or download this version. Replace the placeholders, then review the definition with the people who will use it.
Portable Markdown
Blank template
Use the preview below, then copy the text or download a .md file.
First-focus plan
Focus outcome
[One useful change we want to make]
Why now
[Who needs this outcome and why it matters now]
Evidence of progress
[Observable result or evidence we will inspect; state any baseline that is known]
Capacity and commitments
- Planning window: [a useful period agreed by the team]
- Available people and capacity: [confirmed availability, including time away]
- Existing commitments: [support, operations and other work to reserve room for]
- Planning assumptions: [uncertainty to revisit; estimates are not promises]
Selected work
For each item:
- Outcome and work link: [a defined result]
- Contributor and coordinator: [agree the people involved]
- Current estimate: [use the team's scale, or mark not sized]
- Dependency and next action: [what must happen first]
- Completion check: [how we will verify the result]
What stays outside this Focus
[Work we deliberately leave for later, with the reason]
Inspection and change
- Progress check: [when and who]
- Blocker response: [how we make a blocker and its next action visible]
- New request response: [who decides what changes, and which existing work leaves]
Close and learn
[Compare the outcome with the evidence, record unfinished work and choose one useful lesson]
View blank template Markdown source
02 / A fictional example
See how the sections connect.
The Northstar customer portal is fictional. Its receipt-download scenario shows a writing approach, with assumptions, unfinished checks and required decisions kept visible.
Use the structure with your own facts. Example text is not evidence of a shipped feature or approval for an action.
Portable Markdown
Filled example
Use the preview below, then copy the text or download a .md file.
First Focus: a useful receipt download
Fictional example: Northstar customer portal. This is a planning example, not a delivery forecast.
Focus outcome
Customers can retrieve a clear receipt for a completed order without a Support request.
Why now
The portal team wants to address repeated receipt requests while preserving room for normal support work.
Evidence of progress
Inspect a reviewed receipt download against the agreed fields, ownership checks and failure behavior. A Support-request baseline is not yet available; do not claim a reduction.
Capacity and commitments
- Planning window: the team's next agreed Focus.
- Available people and capacity: confirm developer and reviewer availability before activating the Focus.
- Existing commitments: reserve capacity for portal support and previously agreed maintenance.
- Planning assumptions: receipt generation uses the existing PDF approach. Revisit the plan if that assumption fails.
Selected work
- Outcome and work link: agree the receipt fields and payment-date timezone, then link the decision.
- Contributor and coordinator: the product owner coordinates the definition; a developer contributes the implementation.
- Current estimate: discuss the implementation using the team's current scale after the timezone decision.
- Dependency and next action: the implementation waits for confirmed fields and timezone; the product owner resolves them.
- Completion check: a reviewer inspects a correct PDF, refused cross-customer access and a retry after a download failure.
What stays outside this Focus
Refund receipts, email delivery and bulk downloads stay outside the Focus because they are separate outcomes.
Inspection and change
- Progress check: inspect the definition and blockers at the team's agreed check-in.
- Blocker response: link the unresolved decision to the work item and state who will resolve it.
- New request response: the product owner and contributors agree any scope change and identify which selected work must leave.
Close and learn
Record what passed review, what remains unfinished and whether the early receipt-field review prevented rework. Choose one follow-up action from actual evidence.
View filled example Markdown source
Check before you share
A useful file.
A result you can trust.
- Replace placeholders and fictional facts.
- Check that readers can open every source.
- State what is verified and what remains unfinished.
- Agree the next action and any required approval.
Another useful starting point
Keep the next conversation clear.
COME TAKE A LOOK
A little less busy.
A lot more together.
Curious? Join the waitlist and see how we welcome your team.
Tell us a little about your team. We’ll explain the next steps and invite you when we have capacity for your workspace.
Join waitlist Start with your email. No payment needed to join.