Startup OS connects your go-to-market strategy to the work already running for your product. It records who you serve, why they would buy, how they reach useful value, what you are testing, and which decisions the evidence supports. You accept the strategy; agents work within your existing permissions.
From strategy to learning
- Inspect the product. Read the charter, founder direction, customer and commercial evidence, previous tests, reviews and execution configuration. Distinguish the buyer from the user. Missing measurement stays unknown.
- Propose the strategy. A GTM thesis records segments, value propositions, customer journeys, hypotheses and a limited set of motions. Each motion connects to an existing quarterly bet. Proposed strategy remains a proposal until your accepted strategic decision and its complete state are committed to Operations.
- Design a bounded test. Choose an uncertainty that can change a decision. Record the mechanism, supporting and disconfirming signals, owner, dates, measurement and stop conditions before running.
- Register, then start. Review and commit the complete experiment definition and the decisions for its registration and start. Execution checks the current running snapshot, current strategy, quarter, permissions and limits.
- Collect attributable evidence. Keep measured customer outcomes separate from sends, visits and provider receipts. An unavailable count is not zero; an issued key is not payment; a payment is not renewal.
- Review and decide. The weekly business review can propose continuing, completing, stopping or modifying a test, changing a motion, collecting evidence or asking you to decide. The complete decision and related state go through the existing review and merge path. Later work checks what was actually adopted.
This uses the existing operating loop, weekly review and quarterly planning. Adopting GTM does not create another scheduler, change your product’s stage, open permissions or start experiments automatically. Existing operating responsibilities can continue independently of a paused test.
What an experiment must register
Every test needs a unique product-scoped ID, the decision it informs, a falsifiable hypothesis and mechanism, the primary observable outcome, a predeclared success or disconfirmation boundary, start and end dates, an analysis plan and a decider. Record an accountable owner and link the test to the accepted thesis, active motion, hypothesis and applicable approved quarterly bet. Evidence and state links identify the exact retained source versions.
| Design | Required preparation |
|---|---|
| Statistical comparison | A dated measured baseline, comparison design and its weakness, guardrails, and a pre-run sample adequacy assessment. Insufficient samples cannot establish a winning variant. |
| Qualitative discovery | Participant selection and exclusions, method, maximum participants and actions, expected and disconfirming signals, prior evidence status, interpretation limits, owner and a decision boundary. Unknown prior evidence does not require an invented numeric baseline. |
The lifecycle is designed → registered → running → complete. A stopped test is retained as abandoned. For adopted execution, each transition retains the preceding snapshot and an accepted decision tied to that exact test and definition. Commit registration before the start date. registered alone cannot execute; the current snapshot must be running within its fixed window.
Changing a registered hypothesis, protocol, thresholds, analysis or window creates a new designed successor with a distinct ID. Keep the original test and its results, including failed and inconclusive work. A review’s “continue” decision cannot extend the registered window.
Which approvals are needed
Registration records what will be tested. Permission determines which actions may happen.
| Action | Approval or authority |
|---|---|
| Inspect sources and prepare a proposal | Within existing read and preparation rights. Drafts do not change accepted strategy. |
| Register and start an adopted test | Accepted transition decisions plus current, verifiable authority for their decision class. Autonomous effects require L2 or higher and the applicable action permissions. A decision cannot widen a manifest grant. |
| Send, publish, contact customers or change code | The product’s permission for that action and surface, its class grant, scope and guardrails. A standing allowed grant within scope needs no repeated approval; an approval-required action needs its specific approval. Draft-only and denied permissions cannot be bypassed by registering a test. |
| Launch a paid test | Founder authorization of the exact immutable paid plan, total budget, currency, window, stop conditions and approval expiry. A parent learning test does not authorize spending. |
| Change pricing, market, positioning or quarterly strategy | Your strategic decision. Financial commitments remain your decision. |
| Respond to a founder request | Review the recommendation, options, evidence and consequences. A dashboard response prepares a GitHub proposal; the committed decision resolves it. Coupled experiment or strategy acceptance uses the complete review proposal. |
New products start at L1: propose. Existing internal documentation or maintenance grants do not provide general permission to run acquisition experiments. Each product’s manifest and decision-rights policy remain authoritative. Silence is never approval. See Permissions and operating modes.
Limits and execution ownership
The end date, participant or action ceiling, guardrail breach, expired authority, inactive motion or uncertain action requires review before more effects. Do not extend a test or retry an ambiguous send to make it succeed.
Adopted work declares one existing receipt owner. Local effects need a retained working directory and execution journal. The GitHub App can own supported GitHub effects durably; linked external publication and paid effects on ephemeral GitHub runners remain preparation-only. Browser routines use an instruction protocol, rather than a sandbox around arbitrary browser actions. First Customers continues to prepare outreach for founder sending.
Provider receipts establish transport. Independently measured evidence establishes customer outcomes. Uncertain execution needs reconciliation before another attempt.
What you see
The product’s business overview shows approved goals and dated measures, active motions and tests, hypothesis evidence status, the latest weekly review, accepted priorities and unresolved decisions. Proposed plans and staged changes are distinguished from adopted state. Missing, stale, private and unavailable evidence remain visible conditions. The view is generated from your canonical Operations repository; it is not a separate strategy database.
Quarterly planning can compare the starting and current strategy, close previous bets, review tests and motion economics, and propose the next allocation of capital and founder attention. Actual, estimated and unknown resources stay separate. A future-quarter plan only governs work when that quarter applies. Portfolio allocation waits for sufficient real product learning evidence.
From an approved plan to issues
Once you approve a quarter’s plan, each active bet becomes an initiative: a parent issue that states the bet, how it would be proven wrong, and which routines already carry its recurring work, with a sub-issue for each piece of one-off work (a feature, a page, a campaign asset, the set-up of a test) in the repository that work changes. A bet large enough gets its own GitHub Project, as any initiative does. A daily turn files them the first time it sees the approved plan, so nothing is filed for a plan you have not approved.
A model proposes the breakdown but cannot file it. A separate step with no model checks every part against your declared repositories, the approved plan and existing labels, files nothing if any part is out of bounds, and mentions nobody. When a weekly review stops a bet, or the next quarter’s approved plan drops it, its open work is closed as not planned with a comment saying why. Reopen anything you disagree with.
It needs the issues permission and one more repository secret on operations, PRODUCT_INITIATIVES: a fine-grained token owned by your product’s organization, limited to the product’s repositories, with Issues read and write, Contents read and Metadata read. Onboarding asks for it. Without it the turn says so once and does nothing.
Prepare and check from the CLI
The CLI reference lists the review commands. They prepare or inspect state; they do not silently accept strategy, register tests, merge proposals, publish, send or spend.
Closing an unaccepted proposal leaves current operation intact. After adoption, preserve history and use a reviewed compensating decision or successor. Do not erase accepted snapshots or uncertain receipts to restore activity.
Monthly portfolio review
The integrated review extension lets a monthly portfolio compare your GTM motions using their original weekly reviews, experiments and learning records. It reports missing weeks and ranks scale, continue, modify, pause or stop proposals with evidence and explicit stop conditions. Quarterly review can use these memos without duplicating observations or counting a monthly memo as a weekly review. The dashboard shows monthly coverage and source links separately from the latest week.
Capital and capacity allocations remain proposals. Strategic scaling, material reallocation, pricing and commercial commitments retain founder review and the existing separate paid approvals. Monthly editorial marketing review keeps its current role. Product enablement follows reviewed adoption and a manual rehearsal; the template’s new monthly portfolio cadence starts disabled. The extension is available through the coordinated v0.153 release.