Status: documented, untested. Updated 2026-11-01.
This handbook explains how to operate MktOS. The MktOS Guide defines the framework; this handbook explains responsibilities and working standards. A playbook guides one repeatable job from its trigger to a useful output. Neither introduces another delivery hierarchy or requires a separate tool.
Start with the area relevant to your work:
| Area | Operating question | Practical guidance |
|---|---|---|
| Direction and planning | What outcomes guide our work? | Plan template and cadence. |
| Work management | What will we commit to, and does it fit? | Define a project playbook. |
| Sprint delivery | How do we produce useful results? | Weekly routine. |
| Measurement and learning | What does the evidence tell us to change? | Artifact prompts and the standards below. |
| Communication | Who needs to understand, decide or act? | Shared records, discussions, decisions and handoffs below. |
Use one shared plan and delivery view. The handbook is reusable guidance; actual commitments and results belong in the team's working records.
1. Direction and planning
Apply the integrated artifacts to the existing North Star, OKRs, projects, milestones and tasks. A3/Canvas support diagnosis and choices; the Product Backlog and Sprint Backlog organize delivery; usable Increments meet the Definition of Done; Test/Learning Cards connect experiments to decisions. The Definition of Workflow governs the shared board. Use the working prompts inside existing records.
| Responsibility | What to do | Useful output |
|---|---|---|
| Qualify the evidence | Read customer/market context, prior results and constraints; distinguish facts, assumptions and gaps. | A supported problem/opportunity and unresolved questions. |
| Make strategic choices | Decide audience, problem, offering, positioning and route to market, with evidence and exclusions. | Direction that explains why the work should create value. |
| Establish outcomes | Set/reaffirm North Star Metrics and annual OKRs; define metric/source, baseline, target and reading responsibility. | One assessable annual plan; unknown baselines remain unknown. |
| Review and adapt | Inspect annual outcomes quarterly and execution more frequently; record material decisions. | Updated execution priorities, forecasts and owned next actions. |
Strategy and OKRs answer different questions: strategy makes choices about how marketing will create value; OKRs describe the improvement and evidence sought. Filling an OKR table does not supply a missing strategy.
Set/reaffirm North Star Metrics and establish annual OKRs during yearly planning. Quarterly reviews inspect those same annual commitments and adjust execution priorities, resources and forecasts. A quarterly session does not automatically create fresh OKRs. Material strategic changes require a recorded decision preserving the prior target and evidence.
Milestones are meaningful checkpoints between a project and its completion gate, following Gabriel's recorded milestone decision. Tasks describe actions. A sprint is a time container for selecting and inspecting work, rather than another level beneath a task.
2. Work management
Keep requests and ideas visible in the backlog before making commitments. The person responsible for priorities decides whether to accept, defer, reject or replace existing work. Clarify the expected contribution and urgency; refinement makes approaching work small and clear enough to select. Routine tasks do not need artificial projects.
Use the Define a project playbook when an outcome needs a bounded intervention. A project needs scope, ownership, acceptance and completion criteria, feasible capacity, and an expected contribution to the plan. Tasks and milestones link to that project; a board view must not duplicate their records.
For solo work, one person may plan, decide, deliver and review. A small team names who owns each result and who can change priorities, scope or commitments. Check each person's availability and specialist dependencies; a team total alone can hide a bottleneck.
Include recurring work, urgent requests and review time when assessing capacity. A new request replaces an existing commitment or waits. Use weekly events for practical planning, inspection and improvement; size the agenda to actual capacity. An experiment's observation window may span several sprints.
When scope, capacity or dependencies change, show the effect on commitments and obtain the decision from whoever holds the relevant authority. Do not quietly absorb extra work or reset annual targets to match delivery progress.
3. Sprint delivery
Run Sprint Planning → delivery and daily inspection → Sprint Review → Sprint Retrospective → next Sprint Planning. The weekly routine provides compact agendas; it is not necessary to create another playbook for information already explained there.
Planning agrees a Sprint Goal, selected work and an actionable approach. Inspect progress, blockers and remaining capacity during delivery. Verify usable Increments against the Definition of Done and item acceptance criteria; unfinished work remains visible. Delivery can occur before Sprint Review.
Review useful results with relevant stakeholders and use feedback to adapt the backlog. Retrospective examines how the work happened and selects one improvement for the next sprint. The same session may support several purposes without erasing their different decisions.
4. Measurement and learning
Keep three judgments separate:
- Delivery quality: does the usable output meet its acceptance criteria?
- Project completion: does the work meet its declared done-when gate, including any required observation or decision?
- Marketing outcome: did the audience or business measure improve against its own target?
Specify these before work starts. Do not shorten an experiment's evidence window to make it look complete, or infer outcome achievement from a finished deliverable. Record thin or inconclusive evidence honestly. A material change in evidence or constraints can trigger a recorded revision by the responsible decision-maker.
Each measure needs a source, qualification rules, reading owner and observation date/window. Confirm access before relying on it. Routine analytics, research and delivery feedback can produce observations without a formal experiment. Use Test/Learning Cards for experiments, or link an existing evidence/decision record instead of copying it.
At review, compare observations with expectations, explain limitations, and record continue/change/stop or an inconclusive verdict with the next action. When delivery closes before outcome observation, keep the observer, source and next review visible. Measurement waiting is not active delivery capacity, but remains WIP when within the workflow's declared start/finish boundary.
Future experimentation-program compatibility, including programs using G.R.O.W.S., remains a recorded design requirement. This handbook does not implement a program integration or require a program to adopt a new lifecycle.
5. Communication
Communication surrounds all five operating areas. The accountable owner makes the relevant records understandable and reachable; affected contributors provide feedback and flag missing information.
| Situation | Communication needed |
|---|---|
| Direction or new commitment | Explain intended value, boundaries, responsibilities and tradeoffs; involve people whose capacity is being committed. |
| Routine progress | Update the shared work record; use an asynchronous update when attention is needed. |
| Blocker or material change | State impact, options, decision needed and who can resolve it; communicate before dependent work proceeds. |
| Review | Provide usable output, evidence and limitations; capture stakeholder feedback and the resulting decision. |
| Handoff | Provide accessible inputs/output, current state, unresolved issues, recipient and next action; confirm receipt where responsibility transfers. |
Use a discussion when interpretation or agreement is needed. A routine update does not automatically require a meeting, new approval or acknowledgement. Record material decisions with authority, reason, date and affected commitments.
Use the team's chosen planning tool for live owners, commitments, tasks, dates and health. Keep reusable guidance and supporting evidence in documents. Link records instead of maintaining duplicate boards. Operately is Gabriel's current implementation, not a requirement of MktOS; its local rules are in Q4 governance.
The Work Record is optional supporting material for complex evidence, repeat use, agent work or handoffs. Ordinary users can keep the necessary decisions and evidence links in their plan. A handoff identifies the work, usable inputs, latest output, unresolved decisions, recipient and next action.
Agent-specific capability, account-access and execution instructions belong in the agent runbook. A source document or a saved artifact cannot authorize an external action.
Maintain and check
When changing a core definition, update the MktOS Guide first and check the affected template, event guide, examples and navigation. Keep a short dated change note. Source qualifications and unresolved attribution are maintained in the source register.
A documentation review checks clarity, consistency, source traceability and feasibility. Observed application checks whether a real user can make a useful decision and act on it. Mark guidance as documented, reviewed or tested according to the evidence that exists. Do not claim user validation from an agent rehearsal.
Add a playbook only when a recurring job needs instructions beyond the existing templates/agendas. Each playbook states when to use it, inputs, responsibility, ordered decisions/actions, output/completion, exceptions and communication. Improve it from use before expanding the library. Definitions remain in the Guide/catalog, standards in this handbook, and job-specific instructions in playbooks.
Sources and adaptations
This handbook applies MktOS's documented choices. Scrum informs sprint delivery and quality; Kanban informs flow; A3 and Strategyzer's tools inform reasoning and experimentation. The artifact guide and source register provide the source links and limitations. Annual OKRs with quarterly reviews are MktOS's chosen cadence, not a claim that every source method prescribes it.
Historical development record
On 2026-11-01, the user-supplied workflow-development playbook informed this handbook's original SP01–SP07 sequence: frame, qualify inputs, draft direction, bound delivery, review/handoff, apply/observe, learn/maintain. The original implementation included capability mappings, a source register and the Work Record. Structural checks passed; representative use and human validation remained pending. Details are retained in the friction log.
The Q4 workflow build has its own readiness checklist and cold-run packet. Their frozen criteria and historical five-level references describe that development test; they do not override current framework decisions.
The later milestone decision and the current simplification supersede this handbook's former five-level mandate. This revision separates strategy from OKRs, makes Work Records optional for first use, and moves implementation detail behind the core guide. It does not establish a completed human trial or change Q4 commitments.