Ideation Methods

Phase 2 chose what to attack. Phase 3 chooses how, by diverging wide before judging, converging into mechanically distinct options, and committing in advance to what would prove the choice wrong.

Mode. Standalone generates alternatives from the supplied opportunity, problem or requirements; an options-only request ends with the alternatives (step 4). The lifecycle runs every step, writes 03-solution-bet.md and gate 3. Both per operating modes. Load pressure-testing for the bet round, business-case for the value and the stake, go-to-market for how users arrive, tracking-standards (experiments) when a test design is requested. Read the ideation reference for worked examples, the scoring and kill-criteria tables, the test catalogue with cost bands, and the output template.

Procedure

1. Read the inputs. Standalone uses the supplied problem or opportunity and constraints. Lifecycle reads 02-definition.md and 00-frame.md: the selected opportunity, the success metric with its baseline and target, the riskiest assumption; options with no chosen opportunity are a brainstorm, so a missing 02-definition.md stops the phase. On the internal track 00-request.md → Need stands in for it: the job, Today as the baseline, Done when as the target. Done when you can state the opportunity, the metric and the riskiest assumption in a line each.
2. Diverge before judging. Wide first, unscored: at least eight raw ideas (five in lite mode; gate 3.5), each one line in ## Divergence with the prompt that produced it. Work the prompts in order: shift who acts (user, system, teammate, your team by hand); shift when it happens (prevention, intervention, recovery); remove rather than add; take the constraint away, then name the crude version that fits this quarter; borrow how another domain solves the same shape. In the first round ask the person for the ideas they already have and add them under their name: an idea they arrived with and never saw compared is the one they will quietly build anyway. Done when the count is met and every prompt produced at least one idea.
3. Converge into distinct options. Cluster the raw ideas by primary user action, "the user {verb}s {object}"; two ideas with the same sentence are one option with two skins, merged under the stronger skin (gate 3.1). Keep at least three distinct options, a manual or human-powered one and a removal one among them; under three, diverge again. Done when every option has a unique action sentence.
4. Score on separate axes, then put a rough value on each. Impact, Confidence, Effort, Reversibility, each 1 to 5, shown side by side with no composite. Confidence comes from the tags in 01-discovery.md: an option resting on [assumption:unvalidated] scores 1 or 2, and the score line says so. Then business-case step 2: per option, at most four, the formula, the assumption it rests on and a two-year value at the median, built from what people already do. An options-only request ends here. Done when every option has four scores, each confidence score cites its tags, and each option has a rough value.
5. Value the leading option. business-case steps 3 to 6 on the option the round will recommend: every number with its kind (data, analogy, estimate, decision), its source and P14, P50, P86; the two-year value as profit; the sensitivity that names the load-bearing assumption; the five questions. When the value resists a number, a declared judgment. On the internal track the value is time (business-case step 6) and step 6 here is skipped: the users are already there. Done when ## Value is written (gates 3.9 to 3.11).
6. Say how users arrive and who pays. go-to-market steps 1 to 5 write ## Go-to-market (gate 3.13): for a feature the audience, the message and where they meet it; for a product the trigger, the motion the price can pay for, the positioning, one channel and its test. On the product track also ## Business case (gate 3.7): the first 100 users, the cost per active user, and for a product for sale the price and the willingness-to-pay test. Read PRODUCT.md → Revenue model and Growth engine first; "not for sale" drops the money lines. Do the arithmetic aloud: price times the users the target implies, against the cost. Done when the arithmetic is written and says whether the bet can reach the product's ambition.
7. Decide whether the test runs first. The test aims at the load-bearing assumption (business-case step 7). It runs when its result can change the decision; it is skipped, with the reason written, when building is cheap and reversible, when even the pessimistic case proceeds, when strong precedents exist, or when the measure would be unreliable (gate 3.4). A test that runs carries its card, thresholds written first and set against the second idea (gate 3.12). Before PMF (PRODUCT.md → Stage) prefer concierge and Wizard of Oz: doing the outcome by hand tests value, which is the open question, while building it to scale is the work gate 3.8 rejects. Estimate the test and the build in days and what each rests on. Done when the order, its reason, and when the test runs its card, are written.
8. Size the bet. business-case step 8: the door, the confidence, the appetite in days and what is lost if wrong, the build inside the appetite, the evidence held against the bar for this stage and door, or a judgment call the person makes knowingly (gates 3.14, 3.15). Done when ## Bet size is written.
9. Pressure-test and let the person choose. For each contender, what would make it wrong, which evidence would change it, the cheapest way to find out. Then a pressure-testing round: the options with their scores, their rough value, and for the leading one its go-to-market, its test and its appetite, one line each on what choosing it means, a recommendation and its reason; reversibility breaks ties, not impact. Record **Chosen by:** with the person and their answer (gate 3.6); a standing instruction that named this scope counts, quoted with its date, and the recap still shows the alternatives so the choice can be reversed in a word. A pick other than the leading option gets its own table, go-to-market, test and size. Write the rejections, each with a reason, its value and a revisit condition. Done when the person's choice is recorded and every rejected option has its reason.
10. Write kill criteria (gate 3.2), before the build: the metric (the phase 2 success metric or a named leading indicator), two thresholds and a date, in a form someone outside the room can apply: "on {date}, below {stop} we {stop / revert / rebuild differently}; between {stop} and {keep} we iterate; above {keep} we keep". Set the keep line where the second option would have been the better bet. Done when the criterion could fail on a real number by a real date.
11. Deliver. Standalone returns the alternatives, the proposed bet or the test design as requested. Lifecycle writes .builderos/initiatives/{initiative}/03-solution-bet.md per the template, runs gate 3 and records it (scripts/bos.mjs record 3 where commands run), then starts the tests that take time (the channel test, a test-first card) so gate 4.22 can read their results against the lines written here. Done when gate 3 is recorded and every test chosen before the build has started.

Watch for

Capabilities

Option generation needs no connected data. In the lifecycle an unknown upstream baseline holds the relevant gate until it is measured or explicitly overridden. A provisional test threshold may be a design choice, labeled as such, rather than a claimed observed value.

Output Contract

## BET SELECTED with the raw ideas count, the option set with each rough value, who chose the bet, its value in three scenarios and the load-bearing assumption, the go-to-market, the kill criteria, the test decision and design, the stake and the gate result. Standalone output follows the requested format and destination; lifecycle output follows the template exactly, since gate 3 parses its headings and bold labels.