MktOS is a lightweight framework that helps marketers and teams generate measurable value through adaptive solutions to complex marketing problems by connecting strategy, execution, and continuous improvement.
Status: documented, untested. Independent team use has not yet been validated.
Visual guide — all six diagrams
This Guide is the core of the Official MktOS Documentation. The entity/process catalog defines the current scope; the operating cadence connects yearly, quarterly, monthly and sprint cycles. “Official” identifies the maintained reference, not external accreditation or demonstrated effectiveness.
Marketing involves uncertainty: audiences, channels and constraints change, and an effective solution cannot always be known in advance. MktOS makes intended value explicit, bounds the next useful work, and uses observed results to decide what follows.
Start with your first use and the marketing plan template. This guide defines the framework; the template helps you apply it.
Principles
- Make value explicit. Name whose behavior or situation should improve and how you will recognize improvement.
- Make work and evidence visible. Keep priorities, ownership, decisions and results accessible. Distinguish facts, assumptions and unknowns.
- Fit work to capacity. Bound the work, account for dependencies, and replace or defer commitments when new work arrives.
- Inspect and adapt. Continue, change or stop based on observations, including changing strategy when its assumptions fail.
- Assess delivery and impact separately. A published campaign proves delivery. Its effect needs its own evidence.
Connect strategy to delivery
Begin with research and diagnosis: audience, problem, existing results, opportunities and constraints. Strategy makes choices about whom to serve, which problem to address, the approach to try, and what to leave out. OKRs express intended improvement and its measures; filling in OKRs does not create those strategic choices.
Use this teaching sequence:
| Element | Question it answers |
|---|---|
| North Star Metric | Which enduring measure of customer value guides this scope, and what counts toward it? |
| Objective | What meaningful improvement are we seeking this period, and why? |
| Key Result | What measurable result will show improvement, from which baseline to which target? |
| Project | Which bounded intervention should influence a KR, within what scope and capacity? |
| Milestone | Which useful checkpoint shows progress, by when, with what completion evidence? |
| Task | What actionable work advances a checkpoint or fulfills a routine responsibility, with what completion evidence? |
| Completion criteria / Done-when gate | What evidence closes the project, and what makes us stop, narrow or extend it? |
Completion criteria are a project rule, not another item to manage. Tasks can advance milestones or represent routine work outside a project. A sprint is a time container for selected tasks and a useful goal; it is not another level beneath tasks.
For each KR, record the measure, source, baseline, target and observation window. Confirm someone can read the measure today. If not, include measurement setup in the work and keep the baseline unknown until measured. Never substitute zero for missing evidence.
Project management is integrated: make scope, owners, estimates, dependencies, milestones and completion criteria visible. Check specialist availability as well as total hours. Plan tasks near enough to execution to use current information. Keep an ordered backlog for uncommitted work.
Artifacts
MktOS integrates the selected artifacts around its existing North Star → OKRs → Projects → Milestones → Tasks structure:
- Product Backlog, Sprint Backlog and Increment organize work and usable delivery. Their commitments are the Product Goal, Sprint Goal, and Definition of Done. Define the product or service scope explicitly; a Product Goal can align with an existing objective but is not automatically the same thing.
- Definition of Workflow and board make flow, work-in-progress controls and movement policies explicit.
- A3 report, Business Model Canvas, Test Card and Learning Card make problem-solving, business-model assumptions, experiments and learning inspectable.
These are integrated artifacts, not a competing hierarchy or eight mandatory files per project. Use each at the relevant decision, retain useful existing versions, and link shared information. The artifact guide defines purposes, minimum contents, relationships and sources; working prompts support their use. The marketing plan connects strategic choices and outcomes to those artifacts.
The entity-relationship model shows how these concepts connect using established source names. Its cardinalities are proposed MktOS integration choices, not requirements inherited wholesale from those methods.
Responsibilities
Communication connects every responsibility and process: establish shared direction, coordinate commitments and dependencies, make decisions and changes visible, obtain feedback, and hand work over with a clear next action. Use shared records for routine visibility and discussions where interpretation or agreement is needed. It is a surrounding practice, not another sequential phase. The communication diagram illustrates this flow.
Name who chooses priorities and resolves tradeoffs, who coordinates each project, who delivers work, and who reads results. One person may hold all responsibilities when working solo.
In a small team, agree these responsibilities with the people involved. A coordinator needs an agreed way to resolve priorities and dependencies, including when contributors report to someone else. MktOS requires no new job titles or reporting lines.
Inspect and adapt
Set or reaffirm North Star Metrics and establish annual objectives and Key Results during yearly planning. Review their relevance, progress and forecasts quarterly; do not replace or reset OKRs merely because a new quarter begins. Quarterly execution planning adjusts projects, milestones, resources and priorities in service of the same annual outcomes. Monthly reviews inspect progress and constraints; weekly sprints organize delivery.
Quarterly checkpoints and expected progress are forecasts/milestones, not automatically new quarterly OKRs. Material evidence can justify an explicit strategic change: record the authority, reason, date and implications, preserving the prior target and results. A North Star Metric can remain appropriate across several years; annual planning need not invent a replacement.
The complete sprint cycle is Sprint Planning → delivery and daily inspection → Sprint Review → Sprint Retrospective → next Sprint Planning. Review inspects usable results and available outcome evidence with stakeholders; Retrospective improves how work happens. Choose one concrete improvement for the next sprint. Week one begins with Planning after checking starting evidence. These purposes can share compact sessions; the weekly routine provides agendas and the operating cadence defines broader planning/review inputs, responsibilities and outputs.
Assess objective, KR and project health independently: On Track, At Risk (behind but recoverable within available capacity), Off Track (unreachable without changing scope or target), or Not assessed (insufficient evidence to judge).
Distinguish delivery from pending observation. Waiting for a declared measurement window does not occupy an active delivery slot. Keep an owner, evidence source and next review date for follow-up. An experiment is complete according to its declared evidence criteria; inconclusive results remain inconclusive. Completing delivery never proves a KR was achieved.
Supporting methods and records
The MktOS Operating Handbook explains how the framework operates across planning, work management, delivery, measurement and communication. Playbooks guide bounded recurring jobs; start with Define a project. These are supporting guidance, not extra delivery artifacts or new levels in the work hierarchy. Keep standards in the handbook, job-specific steps in the playbook, and live commitments in the team's tool.
G.R.O.W.S. is an optional experiment method: Gather ideas → Rank → Outline experiments → Work → Study. Define the hypothesis, intervention, measure and decision criteria before execution. An experiment can span several sprints; sprint boundaries do not shorten its observation window.
Future compatibility requirement: MktOS must accommodate experimentation programs, including programs using G.R.O.W.S., rather than require every program to adopt one internal experiment process. The future design should connect strategic priorities and KRs to program-owned hypotheses/experiments, coordinate delivery and resources, and return evidence/learning to MktOS decisions. Keep the program's experiment lifecycle and observation windows explicit; identify the authoritative records and avoid duplicate tracking. This is a design requirement, not an implemented integration or a claim that G.R.O.W.S. provenance has been resolved.
Keep one accessible plan and delivery view in a tool that suits the team, with links to evidence and decisions. Use the operating handbook when detailed procedures or handoffs help; supporting records need not become extra meetings or duplicate trackers.
Sources and adaptations
MktOS combines Gabriel Zamp's marketing planning practice with adapted ideas. The definition and inspect-and-adapt approach draw on the Scrum Guide by Ken Schwaber and Jeff Sutherland (2020), published under CC BY-SA 4.0. MktOS changes the context, responsibilities and events; it does not claim to implement Scrum.
G.R.O.W.S. provenance remains unresolved; no originator is claimed. The source inventory records available inputs and attribution gaps. Examples illustrate decisions; observed applications are needed to establish what works.