Ceremony scaled to evidence.

The amount of process is a function of the evidence, not the ambition

Four modes, and you unlock them. That single idea is the product: a one-evening idea gets almost nothing, a thing with real users gets more, and each rung names what earns it before you climb, then declines to stop you, because it's your project.

The consequence people miss is the downward one. A project that stays in Quickstart forever is a legitimate outcome, not a failure to progress. Most ideas should die there, cheaply, and a tool that makes every idea feel like it deserves a spec is a tool that makes bad ideas expensive.

Three rungs, and the grade is what somebody did

stated-pain → observed-behavior → commitment. Fixed, closed, and graded honestly rather than generously: "great idea, I'd definitely use that" lands on rung one and stays there no matter how the conversation felt.

• Desk research never enters the ladder. Reading that three rivals charge $40 is context and lives with the claim it informs, carrying a source and a date. Watching one customer switch is evidence. A ladder that grades two different kinds of thing grades neither.
• The only reward for real evidence is quiet. The conscience gets less talkative as commitments land. There is no score that goes up.
• One signal per file. Evidence is an object with an id, not a feeling you carry between sessions, so it survives the week you forget it.

An answer store with interchangeable frames, not a framework

You never pick a framework. You answer questions, and the frame is a view you switch: the same answers render as the Humane Product Canvas, a Lean Canvas, a Business Model Canvas, or a one-page brief for someone outside. Switching re-renders what you already said instead of interviewing you again, and a cell you haven't answered shows as unanswered in every frame rather than quietly disappearing to make a view look complete. The same answers are the Canvas chapter of the playbook, and a deck when you press Present.

Two questions ride along in every frame, and no conventional canvas has them: who this could harm or exclude, and the principles you'll hold when holding them costs you something. Un-defaulting the framework was never meant to make those optional.

The humane frame stopped being the default and became the floor; the author's own preferred framework lost its privileged position because it hadn't earned it. That decision, with its falsifier

Prototype and pretotype are not the same word

They answer opposite questions and BOSS keeps them apart deliberately.

• A prototype asks "can I see it?" The smallest runnable, clickable version of the one core thing, in the fastest stack, then it runs it, so you react to something on screen instead of arguing with a blank page. Build-first is a legitimate way to start a lean cycle; the gaps get filled after you can see it, not before.
• A pretotype asks "does anyone want it?" A fake door, a wizard-of-oz, a concierge version, built before the thing exists, time-boxed to days. For the page-shaped ones BOSS can publish a real shareable URL in one turn, with signup pointed at a form, because the page itself stores nothing and says so.

Both live at the first rung. Testing whether anyone wants the thing is not an advanced move, and holding it back until you have something to test would put it after the build it exists to prevent.

The moment "we should build this" becomes a contract

An idea becomes a feature with a goal, acceptance criteria and a smoke check, plus three paths that must not break, named up front rather than discovered:

• The money path — whatever takes payment, or grants access someone paid for.
• The destructive path — whatever deletes, overwrites or cannot be undone.
• The negative path — who must NOT be able to see this. The one nobody writes down, and the one that becomes an incident.

It also carries a validated-learning field, so a feature has to say what it will teach you, and an evals field for anything a model decides. Acceptance criteria answer "did we build it"; those two answer "should we have."

Name the flow, then cut a step

For anything a user walks through, the spec asks you to write the steps, and for each one, what it asks the user for and why it's needed now. A step that can't answer is the step to cut. Then the two paths that usually exist only on paper: what the flow looks like for someone with nothing yet, and where they land when a step fails.

The spec also opens the persona the feature names, and reads the current bets and the declined list before it writes, so a feature can't quietly re-propose something the roadmap already said no to.

A persona that gets less fictional as you learn

Most personas are written once, in a workshop, and are wrong forever afterwards; nobody updates them because nothing says when they became untrue. BOSS's has three verbs instead of one, and the middle one is the point.

• derive: build the first version from your idea and your repo. Marked, explicitly, as derived from your repo and not from a person.
• enrich: feed it what you've learned since: notes from a call, a support thread, real research. This is the verb that makes the difference, and it's the one a document in a drive doesn't have.
• consult: ask it. Both to decide what to build, and to react to something you built: "how would she read this screen?"

Under all three is a visible ledger of how much of this person is evidence and how much is still a guess, and it starts at all guess. Enriching moves the number. Nothing else does.

And it stopped being write-only. A feature names who it's for, and the spec opens that persona when it writes, so the person you researched is in the room when the thing is designed, not filed next to it.

It is deliberately honest about one thing that flatters nobody: a persona built from online research is arguably further from real evidence than your own knowledge of your user. It sharpens the questions you take to a real person. It is never a way to skip them.

A living competitive set, not a competitor slide

Name a space and it goes looking: features, pricing, differentiators, and the honest "why they might win". But the verb that makes it a living set is the small one: you heard about a rival, so you add that one, and it gets researched into the same shape as the rest.

Adding one does not regenerate the others. Their checked dates survive, because a date that silently resets is worse than no date; it tells you something was verified recently when nothing was. That single rule is the difference between a set you keep and a report you redo.

And every claim carries a source URL and the date it was checked, or it is marked unverified. The failure mode here is specific and the reason for the rule: a confidently invented competitor price is the easiest thing in the world for a model to produce, and the hardest thing for you to notice.

Read by the things that build, which is the part that was missing

A competitive field nobody reads is a slide. This one is opened by the verbs downstream: the spec opens a rival's where it breaks when you spec something they also have; the landing page writes against the alternative people actually use; the demand test asks "would you switch?" when a real rival is in your evidence; and adding a new name tells you whether it's on anyone's shortlist or a curiosity.

It also says what to open, not just what to write (docs before marketing, the changelog, the product itself if there's a free tier) and keeps a How they do it entry for the handful of features that touch your bet, which the spec reads as design reference after you've decided to build one, never as a reason to.

It lives in the repo next to the work it informs, and it says so when it's a quarter stale; a competitor table from last winter presented as current is the slide problem wearing a date.

A roadmap that only says yes isn't a decision

So the roadmap carries a mandatory no-list. The bet-list half is short, has a fixed appetite, and gets re-cut each cycle rather than tended, because a bet-list you tend becomes a backlog. The no-list is the half that outlives the cycle. It used to be deleted with each pass, and the same declined request came back three cycles running; now it stands, and the spec reads it before writing anything.

Each bet's confidence is the evidence grade behind it, which is the part that stings usefully: a bet resting on one enthusiastic conversation displays as resting on one enthusiastic conversation.

Ending things is a product skill, and it has its own verbs

Most tools help you start. BOSS takes the other half seriously, because deciding faster includes quitting faster. That's the honest version of the speed claim.

• Ending happens at whatever size it actually is: a whole project, one shipped-then-zombie feature, or one captured idea you've decided against.
• "Deferred" and "dropped" are different words on purpose. Name a condition that would bring it back and it's deferred: a decision with a re-open trigger. Name none and it's dropped, decided on the merits, with the reasoning kept so you don't re-litigate it in four months.
• Paused work doesn't walk back in. Three questions first (still relevant, still aligned, anything changed) so you never build a zombie feature the world moved past while it sat there.

The product voice arrives before the engineering one

Day one includes a product lead and a venture mentor, and no tester or planner, because on day one the question is should this exist, not is it green. The rest arrive as the project earns them. The full roster, and how the work gets tracked.