Get started
CONCEPTS

Products

The unit everything else hangs off, and the five questions it has to answer.

A product is the thing you are building. Not a folder and not a project plan - the thing itself, with a reason to exist that survives the tasks currently open under it.

The five questions

Every product carries five fields that exist to be answered in words, not filled in:

FieldThe question it answers
ProblemWhat is broken for someone today?
AudienceWho has that problem, specifically?
ValueWhat changes for them if this works?
DifferentiationWhy this and not the obvious alternative?
SuccessHow will you know, in numbers?

They are optional. Leaving them empty is a legitimate state and nothing nags you about it - but they are the first section an agent reads when it asks for a product's context, so a product that answers them gets better advice than one that does not.

Status is one axis, stage is another

Status is whether you are working on it: ACTIVE, PAUSED, ARCHIVED or SUNSET. Four values, and they mean what they say. Archiving is not deleting: an archived product keeps every task, decision and document it ever had, stops appearing in the places you scan daily, and can be restored whole.

Stage is where it is in its own life - discovery, validation, build, launch, operations. Stages are workspace data, not a fixed list, so you can name and order them the way your work actually goes. What is fixed is each stage's role, which is how the rest of the product reasons about it: a stage in the TERMINAL role means finished no matter what you called it.

Next step, focus and mode

Three things you write about a product that nothing else in the record can hold:

  • Next step - one sentence: what happens next, who does it (you, or an agent), optionally by when. Not a task and not a milestone. set_next_step writes it; complete_next_step closes it and can write the one after in the same call. Closing a step counts as movement: a product whose steps get closed is never stalled, even with an empty board - which is how work done in git reaches the record in one sentence. A step past its date raises an "overdue step" row in the attention queue; a product in development with no step wears a "no next step" flag.
  • Focus - the few products you are pushing this week. A stamp, not a score: focused products sort first everywhere, and nothing computes it for you.
  • Mode - DEVELOP (movement expected, a step asked for) or MAINTAIN (done and running: silence is healthy, incidents, renewals and money are the signals). It refines ACTIVE and is read only while the product is active.

Goal and numbers

A product can carry ONE goal: a metric from a fixed registry (MRR, monthly cost, cash, one-time revenue or cost, active users, paying users, signups), a target, optionally a date. Replacing it archives the old one; nothing is overwritten. Progress is computed from the numbers you record: an observation says "in this month the metric was this", and it is append-only - a correction is a new entry for the same month, the latest shows, every entry stays. Money is stored in minor units so yen and dinars are honest. The financial profile is a projection of the same numbers: every money field you save also records this month's observation, so history accumulates without extra work. A goal past its date is a WATCH signal in health, never CRITICAL - a goal is a promise to yourself, a release is a promise outward. The tools are set_goal, reach_goal, archive_goal, record_metric and list_metrics; money metrics ride the financials scopes.

Ideas: the funnel before a product

An idea is what you might build, before it costs anything: a name, optionally a body, and no product slot spent. Since the founder cockpit it is a funnel rather than a list. Every open idea is in one of three states - new, evaluating, parked - and looking at one (triage_idea) is a single act: pick the state, answer the two questions (why is this interesting, what would prove it), and optionally say when to look again. That review date lives in the temporal layer, and when it passes the idea appears in the inbox as one to revisit - a promise to yourself, kept by the queue. Nothing is scored: which idea to build is a Decision, with alternatives and confidence.

An idea can be for a product - a feature somebody thought of - and then it becomes an initiative on that product (convert_idea_to_initiative), never a product of its own; a free-standing idea becomes a product (convert_idea_to_product). The server refuses the wrong one of the two (IDEA_FOR_PRODUCT, IDEA_NOT_FOR_PRODUCT), and a converted idea stays, stamped with what it became. Leaving the funnel is archive_idea with a reason - dropped, merged or stale - because "we decided against it" and "it went cold" are different facts a year later.

The weekly review

Everything above is data; the portfolio review is the pass that keeps it honest. Once a week (the home says when the last one was, and when it is overdue) you walk four steps in /review: every active and paused product with what moved since the last review, its next step and what happens to it now; the ideas whose review date has passed; the numbers missing this month; a summary and the stamp. Each thing you say is recorded as an entry (record_review_entry) and executed through the same write it would use anywhere else - focus and pause go through the product, park through the idea's triage - so the review owns no logic and decides nothing for you. It is organization-wide, under its own scopes, and an unfinished one is simply resumed (start_portfolio_review returns the open one). A product absent from the last two completed reviews is flagged as not reviewed lately on the home: that is the "something slipped" the mechanism exists to catch.

Health is computed, never set

A product's health band - Healthy, Watch, Critical - is not a field you edit. It is derived, on every read, from things that are true: unresolved incidents, overdue work, gates that have been blocked for a while. Trying to write it is refused.

That is deliberate and it is a rule the whole product follows: a number you can edit is a number that will be edited to look good. Anything makermap computes, it also explains - open the health band and it names the incidents and the overdue items that produced it.

Deleting

delete_product is a soft delete: the product disappears from your lists and is recoverable with restore_product. Physically destroying it is purge_product, which is a separate, deliberate act - and one an agent principal may never perform, whatever its token allows.