# Product: what it is for, and reaching the people it is for

Load for every project. It covers the objective and how it is measured, what it takes to make
the idea happen, the areas the product needs, the journeys that must never fail, translating
requests, releasing to people, and hearing back. Design detail is in `design.md`; choices are
in `decisions.md`; planning the work is in `planning.md`.

## Intake: what only the owner knows

- **Keep the owner's words word for word** in the records: the idea, the request, the project
  as they describe it. Everything traces back to them, and they are the first thing to be
  misread.
- **Ask the owner, in one message, only what only they know:** who it is for and what those
  people do today without it; what success would look like; why the owner is doing it; the
  budget in money, time and agent or model use; deadlines and anything they refuse; whether it
  must earn money; and what must stay private. Find out everything else yourself.
- **Write down every assumption you had to make,** with the cheapest way to check it. If the
  owner cannot be reached, proceed on the assumptions and mark them for confirmation.

## Starting from nothing or a single word

When there is no idea yet, or only a word ("gardening", "an app", "something with my
workshop"):

1. **Ask what the owner brings:** their interests, skills, time, money, equipment, the people
   they know, and anything they refuse to do. If they are unavailable, work from what the
   records and their words show, and say so.
2. **Expand the word into candidate problems:** who has a problem near it, how often, and what
   it costs them now. Aim for five to ten candidates from different angles (a product, a
   service, a tool for the owner themselves, a contribution to something that exists).
3. **Check each candidate cheaply for evidence of need:** forum threads, reviews of existing
   products, support queues, search demand, conversations the owner can have, or the owner's
   own experience stated as such.
4. **Choose one with the owner, with evidence** (`decisions.md`): the criteria come from what
   the owner brings and wants, written before candidates are scored.
5. **Continue as for an idea**, from §What it takes.

## What it takes

Before deciding how, work out what it takes to make the idea happen. Give each point its
source:

- **Need.** Who has the problem, how often, and what it costs them now.
- **What exists.** Products, open-source projects, research and earlier attempts: what to build
  on (use, extend or contribute to, wherever that reaches the objective sooner), what to learn
  from (why earlier attempts stalled), and where this idea stands apart.
- **The difference.** Why people with the need would choose it, in their terms.
- **Cost.** To build (time, money, agent use) and to run each month at the target size. For a
  physical product: the bill of materials at the planned quantity, certification, tooling, and
  the price people would pay (`physical.md §Parts, suppliers and lead times`).
- **Funding routes, several at once.** The owner's own time and money, pre-orders or
  crowdfunding, revenue (with every assumption stated), grants and competitions, sponsorship,
  partners, an employer, contributors, and phasing so each stage pays for or proves the next.
  Work out the runway at the planned spend.
- **Reach.** How the first ten and the first hundred people will hear of it, get it and start
  using it.
- **What success needs.** A need people have; a result that does the job; a way for them to
  find and get it; money for building and running; a person or agent for every stage; feedback
  coming in; and the drive that keeps it moving. Each gap becomes work in the plan, never a
  verdict on the idea.
- **The path.** The route that fits the owner's resources, its first step, and for each
  constraint the routes around it and what each costs. A large idea gets a staged path; a small
  budget gets a route that fits it. The owner chooses the route; you bring the evidence and the
  arithmetic.
- **Beyond the means already in hand.** What the vision and its minima need that the current
  tools, materials, hosts and habits cannot do. Each such need is work to raise the means, or
  an open gap with its next step (`quality.md §The floor and the means`). The vision keeps the
  need either way.

Show every number with its units and inputs (`planning.md §Estimates and arithmetic`). Send the
owner the path as one message with a recommendation.

Failures this prevents: nobody worked out what it takes, so the project runs out of money, time
or direction halfway; the first option found became the plan; complexity arrived before the
need; only engineering was considered; the result was shrunk to the tools already chosen; a
batch of actions stood in for a vision.

## Objective, outcomes and measures

- **One objective:** a change in the world, for named people. "Revolutionise gardening with
  AI" cannot be met, missed or measured; "allotment holders water only when the soil needs it,
  saving a visit a week" can.
- **Three to five measures,** each with what is measured, the target, the date, and how it is
  taken (the benchmark, the log query, the invoice, the meter, the survey). A measure nobody
  can take is not a measure.
- **The journeys that must never fail** (§Journeys and threads).
- **Acceptance criteria** for each deliverable: concrete, checkable, and agreed with the
  acceptor.
- **Milestones** that each leave something a person can use and name the measures they move
  (`planning.md §Milestones as usable slices`).
- **Every measure is served by something, and everything serves a measure.** A milestone that
  moves no measure, or a measure nothing moves, is a finding.
- **Switch conditions** for the routes (§Alternative routes).
- With no records yet, write the smallest set this work needs: the objective, and the measure
  the current work moves.

## The vision, the plan and the business

This applies to every project the conductor is used on: software, physical, service, creative,
hybrid, and a business. It is written before a batch of actions, and rewritten when the evidence
changes.

- **A vision is recorded before a batch of actions.** In the owner's words where they gave
  them: who it serves, what those people can do that they cannot do now, and what successful
  looks like, with a date and a way to tell it was missed. A task list, a stack, a backlog or
  a pile of improvements is not a vision. Where the owner has not said it, write the smallest
  vision the evidence supports, mark it as derived, and confirm it.
- **The plan is the source of the next action.** Deliverables, the order, the dependencies and
  the resources (`planning.md`). An action that traces to none of them is not execution. When
  the request is the project itself, establishing the vision and the plan is the work until
  they exist.
- **When the project must earn, or the owner is building a business, success includes the
  exchange.** Record each of these with its source:
  - the offer: what is exchanged, with whom, and why they choose it;
  - the price, the full cost to deliver one, and what remains;
  - how money is collected and reconciled, and one completed exchange observed (a settled
    invoice, a paid order, a wage received);
  - how a buyer hears of it, starts, pays and comes back;
  - the runway, and the latest date for the next money decision.
  Checkout, pricing copy, outreach or a payment integration while the offer is unset stays an
  open decision. A later change to what was promised is change control (`../SKILL.md §7`)
  before the words people see are changed.
- **Acceptance of the build leaves the business unaccepted until an exchange measure is met.**
  At least one measure can be missed by money, use or the promised change. A green build with
  no completed exchange does not meet a vision whose success is to earn.
- **Every aspect is founded before the build is called the project.** §Areas and owners. For a
  whole-project request, an area with no owner and no written reason fails the check.
- **What the record still misses, the checkpoints after use starts, and how the result is
  used are part of the same writing** (§What the record still misses,
  §Checkpoints after the work has started, §How the result is used).

## What the record still misses

After the vision, the plan and the minima are written, name what that record would still let
through. Look again at every checkpoint.

Name one of these when it is true:

- An applicable aspect has no row. Silence is not a pass (§Areas and owners).
- The owner uses the result in a way the vision does not name.
- Work already started has a consequence the plan does not name. A message, a price, a
  dependency, a person now waiting, or a spend.
- A minimum is met on paper and missed in the result.
- This method has a part the run needed and did not load. An unread section does not prove it
  does not apply (`../SKILL.md §2`).
- A date, a quarter or a duration in the schedule has no source
  (`planning.md §Time limits`).

When any of those can be named, covering it is the next work, before the next batch. When none
can, record the search, its date and what was read. Write the gap in the records the project
already has. Do not open a new tracking system.

A run that never asks what it missed has not finished the check.

## Checkpoints after the work has started

Once work that uses this method has started, set the next checkpoint in the existing records
before the next batch. A milestone review can be that checkpoint
(`operations.md §Periodic review`). It is not a second system.

Each checkpoint names:

- what will be looked at: the vision, the plan, each applicable minimum, what the record still
  misses, and how the result is used;
- the evidence that passes or fails it;
- the date or the trigger;
- who looks;
- what a fail does. Another route, or that batch stops. The minimum is not lowered
  (`quality.md §The floor and the means`).

A running task, an updated summary, or a green check on one aspect is not a checkpoint met.
The first checkpoint is set when use starts. It is not set after the result is called done.

## How the result is used

The method covers the way the owner uses the result, not only the build. Write each of these
when it applies, with its minimum. Not applicable is a written reason (§Areas and owners).

- **Several experiments.** When more than one route is open, each experiment has its own
  objective, its budget, its stop condition, and what it must show before it continues or
  closes. Starting another does not drop the minima of the ones already running. The project
  that carries the primary objective stays named (`../SKILL.md §1`). One experiment is not a
  portfolio. A portfolio is not a reason to skip the minima.
- **Outward exposure.** What leaves the working environment stays inside what the owner has
  authorised. A message, a listing, a price, a name, a publish, or a spend. Low exposure is
  the default until the owner raises it. Each outward act records what it commits and how it
  can be taken back. One act reinforcing another is not a reason to send more than the
  authority allows (`../SKILL.md §8`).
- **Money as a means.** Where the world the project lives in requires money, the system
  operates that money. What is owed, what is collected, what is spent, by when, and the date
  of the next money decision. Finance keeps the books. Commercial keeps the exchange
  (§The vision, the plan and the business). Money is a tool for the objective. It is the
  vision only when the owner has said that earning is the aim.
- **An aim above the money.** Where the owner has named what the money is for, that aim is
  the vision and the money is a means under it. Where the owner has not named it, the record
  says the aim is unnamed. Do not invent a higher purpose and attribute it to the owner. An
  agent proposal is marked as a proposal. The money is still operated, because the world
  requires it, while the aim stays open.

## Alternative routes

- **The objective stands; the route changes.** For each route the plan depends on (a channel,
  a supplier, a design, a funding route), write the measurable condition that means it is not
  working and the route it switches to.
- **At every review, evaluate each condition with today's numbers.** When one is met, switch
  now and record the switch.
- **A blocked route with no written alternative gets the next route found** (`decisions.md`) and
  recorded.
- **Do not dismiss the objective because a route failed.** Seek alternatives around money, time,
  skills and other constraints, with honest costs and durations. Respect physical and legal
  limits: if no feasible authorised route is demonstrated, record that finding, its evidence
  and remaining uncertainties, and propose a constraint or objective change to the authorised
  decision-maker. Do not promise a workable route without evidence. A quiet launch or a lost
  supplier alone does not establish that the objective is infeasible.

## Areas and owners

For every area the product needs, record an owner (the owner, a person, an agent or a
service), the first deliverable and the measure it serves, or one line on why it does not
apply:

- **Product:** the vision, the objective, the measures, the scope.
- **Research:** evidence of need, and how feedback keeps arriving.
- **Design:** people and situations, journeys, states, words, one system of look and behaviour,
  operability by people and agents (`design.md`).
- **Engineering:** software, firmware, electronics, mechanics, data, construction.
- **Quality:** what proves each journey on each platform or environment (`quality.md`).
- **Security and privacy:** a threat model in five lines; what personal data, where it goes,
  how it is deleted; and the project's own confidentiality (`confidentiality.md`).
- **Operations:** hosting or running, monitoring, backups, support, incidents
  (`operations.md`).
- **Supply,** for anything physical: bill of materials, second sources, lead times, assembly,
  test jigs, packaging, returns (`physical.md`).
- **Legal:** licences, terms, privacy notice, certification (radio, electrical, safety,
  medical, food), contracts, and a company and tax where money is taken.
- **Finance:** costs, price, funding routes, runway, who pays each bill.
- **Commercial, when anything is sold, paid for, sponsored, or the project must earn:** the
  offer, the buyer, the price against the cost to deliver one, how money is collected and
  reconciled, the first completed exchange, and what brings the buyer back. Finance keeps the
  books. Commercial is whether the exchange works. A business keeps this area while the first
  version is free, because the path to earning is part of the vision.
- **Use:** several experiments, outward exposure, money as a means, and any aim above the
  money (§How the result is used).
- **Distribution:** where people find it, get it and start it (§Releasing to people).
- **Support and community:** how people get help, and how what they say reaches the plan
  (§Hearing back).

For a whole-project request, an area left off the record fails the check. Not applicable is a
written reason, and it is never a pass (`../SKILL.md §6`). A report that never mentions an
applicable area has not checked it: silence reads the same as a pass, which is why the row has
to exist. A radio device needs certification; one that records where people are needs a privacy
notice; one that costs money to run needs someone paying; one that must earn needs the commercial
area at its minimum (`quality.md §The floor and the means`). These shape the design, so they are
founded at the start.

## Journeys and threads

- **List every supported journey, and mark those that must never fail,** in the words of the
  person doing them ("a member books a free slot on a phone and gets a confirmation"). Keep the
  list short where the actual project permits; no fixed number is a completeness limit.
- **Thread each one through every area:** one table per journey, one row per step, recording
  what the person does, what they see or hear, the component or procedure that handles it, the
  data or record written, the evidence that proves it (a test, an inspection, a rehearsal), and
  the measure it moves. An empty cell is a gap in the design. For a service or physical
  delivery the "component" is the procedure, person or equipment that handles the step.
- The threads keep the flow, the architecture and the data one design rather than three
  (`design.md §Threads to the architecture`).
- Critical journeys receive the stronger acceptance and user-testing gates. Other supported
  journeys still have coherent flows and states; vary verification depth by risk and intended use.

## Requests, however they are worded

Owners ask in the words they have: "it feels slow", "make it scalable", "clean it up", "more
modern", "prettier", "add AI". The request is where the owner's view and the builder's meet,
and neither can see the other's side.

1. **Keep the request word for word, and split it into its claims.** "Slow, old-fashioned,
   doesn't scale, add AI" is four claims; handle each one.
2. **Translate each claim into its measurable meanings:**
   - "Slow": which journey, on which device, measured how (a page load on a phone, a query, a
     build, a start-up, a battery charge, a delivery time)?
   - "Scalable": more of what (people, data, requests, contributors, sites, units)?
   - "Modern": which failing of what exists (its look, what it runs on, a missed update)?
   - "Prettier", "more intuitive", "cleaner": which journey, for whom, and where do people
     hesitate, err or give up? Task success, time and errors on that journey, with people
     (`design.md §Taste and evidence`); a look the owner wants is their call between rendered
     options.
   - "AI": which job, for whom, and what is done today instead?
3. **Map each meaning to an existing measure, journey or requirement, or to none.**
4. **Show the owner the current state before changing anything:** one short paragraph per claim
   with the current value, the target, and what that means. ("The booking page takes 6.1 s to
   load on a mid-range phone on 4G. The target is 2 s. 2.4 MB of the page is one photograph.")
   Often this ends the request.
5. **Find the cause before choosing the change:** profile, trace, weigh the page, read the query
   plan, meter the current, time the process. Optimising what is easy instead of what is slow,
   and building the buzzword (a queue for "scalable", a rewrite for "modern", an unused model
   call for "AI"), are the failures this prevents.
6. **Account for every claim.** Each ends with an evidenced disposition, never a bare no:
   - **changed**, with the value before and after;
   - **already meets its target**, with the number, and the improvement that matters instead,
     found from where the owner's feeling comes from;
   - **the owner's call**: a proposed new measure, what it would take and cost, asked once; when
     the owner is away, recorded as a proposal while the measured parts continue;
   - **redirected**: the decision it would have broken, and the route that got the owner what
     they wanted.
   - **no feasible authorised route demonstrated**: the evidence and constraints, remaining
     uncertainties, and a proposed constraint or objective change for the authorised decider.
     This is an open decision or an authorised closure, not a fulfilled request.
7. **Build each change as SKILL.md §7 says,** and record a translation table: claim, meaning,
   measure, value before, target, action, value after, evidence.

A redesign, a new flow, or "make it prettier" or "more intuitive" is a request like any other: which
measure it moves, the value before, the value after (`design.md §Taste and evidence`).

## Releasing to people

A result can pass every check and still reach nobody. Reaching people is part of delivery,
planned from the start. (For a service or creative output, the release is the delivery to the
client or audience: `service.md`.)

1. **Plan the release in the records:** which people this release is for, which measures it
   should move (people who find it, who start it, who finish the first journey, who come back),
   which channels, by when, and for each channel the condition that switches it to the next
   route.
2. **Walk every way in, as a stranger, from a clean device.** For each platform: from each place
   people find it (a search result, a store listing, a link in a post, a registry, a shop shelf)
   through getting it, installing or setting it up, and starting it, to the first journey done.
   Use a device or account that has never seen the product: no saved settings, no signed-in
   session, no cached files, no builder's tools. A step that fails blocks the release. Then
   have someone new do it with no help, and watch.
3. **Make everything that is not the product true, before release day:**
   - listings, descriptions and pictures show what it does now, in its people's words;
   - prices, payment and refunds work end to end, tested with a real small payment;
   - terms and the privacy notice say what the product actually does with data, checked against
     the code and a network log, not against intentions;
   - licences and certifications are in hand before it ships;
   - each item has an owner and a check.
4. **Stage it:** a small share of people or devices first, the critical journeys watched, a pause
   that triggers itself at a failure threshold set in advance, and a rollback that has been tried
   (`software.md §Delivery: review, CI, deploy, rollback`;
   `physical.md §Packaging, shipping, repairs and recalls`).
5. **Tell people where they already are, in their words.** Choose channels from evidence of where
   people with the need gather (communities, newsletters, shops, clubs, events, search, stores,
   word of mouth). Use more than one at once, each with its own measure. Say what it does for
   them, not what it is built with. An announcement, a price or anything sent to people is an
   action outside the working environment: within the standing limits, or with the owner's yes.
6. **A confidential project is released privately,** to the people its classes allow, through
   channels that keep it there (`confidentiality.md`).
7. **Measure after the planned period,** each measure from its source; switch any channel whose
   condition fired; record what was learned.

## Hearing back

- **A help route people can find** from inside the product and from each place they meet it,
  answered within a stated time by a person, or by an agent with a person behind it.
- **Every message, review, report and incident is mapped** to a journey or a measure. A request
  that maps to nothing goes to the owner as a proposed new measure, not onto a backlog as
  unexplained work.
- **A question asked twice becomes a change** to the product or its words, not a longer help page.
- **At each milestone, people new to the product walk the critical journeys with no help;**
  record success, time and where they got stuck (`design.md §Testing with people`).