Feature Solution Analysis

Feature Solution Analysis

Purpose

Most feature designs are the first idea, defended. That is not always wrong — the first idea is often right — but it leaves nothing to re-open when the context changes, and it hides the fact that a simpler option existed and was never priced.

This phase costs little and buys two things: a recommendation with a reason that can be checked, and a record of what else was possible, so the choice can be reversed on evidence instead of on regret.

When there is nothing to analyse

If evidence establishes only one feasible option, name it and why alternatives were eliminated; skip a manufactured comparison. If none is feasible, expose the conflicting constraints and seek a revised option or authorized constraint change. Unknown feasibility is not a pass or a failure: identify the smallest check that could settle it and keep dependent selection conditional.

Workflow

1. State the choice as a question, not as a proposal. "How does the caller learn the work finished?" admits options; "should we use a webhook?" does not.
2. Generate options including the floor. The floor is the simplest thing that satisfies the stated requirements — often "extend what already exists", sometimes "do nothing here". It is included when feasible; if it is only a candidate, label its unresolved constraints.
3. Keep the options comparable. Describe complete alternatives for the same behavior, boundary and operating conditions. A library, pattern and service label alone are not comparable, but complete solutions using different technologies can be; split choices that can coexist.
4. Eliminate on constraints first. An option ruled out by a mandatory technology, a prohibition or a compatibility obligation is eliminated before any evaluation — record it as eliminated, with the constraint and source, not as rejected on merit. Record pass/fail/unknown; inspect target compiler/runtime, resolved dependencies and contract versions where relevant. Analysis does not authorize upgrades or new dependencies to make an option feasible.
5. Evaluate only the axes this feature is sensitive to (references/evaluation-axes.md). Scoring every axis for every option produces a table that reads the same at every company.
6. Recommend one when supported, with the decisive trade-off and evidence. Otherwise return a conditional recommendation or unresolved choice with its next check; do not manufacture a winner.
7. For each rejected option, say what would have to change for it to win. That sentence is what makes the decision re-openable rather than final.
8. Separate uncertainty from preference. If evidence cannot distinguish viable options and a bounded pass/fail experiment would change the recommendation, hand one hypothesis to feature-feasibility-experiment; do not choose by confidence or prototype enthusiasm.

Decision rules

IF two options differ only in naming or internal structure
THEN it is not a feature-level choice. Decide it while implementing.

IF the recommendation is more complex than the floor
THEN name the evidenced benefit on an accepted driver that justifies the added cost.
     Two options may both meet mandatory constraints yet differ materially in operating cost
     or risk. Without a justified benefit, prefer the floor among established feasible options.

IF an option requires a technology the project does not run
THEN include adoption and operating cost; reuse existing authorization/delegation or name the
     specific missing authority before commitment. Continue independent analysis meanwhile.

IF an option is favoured because it is more extensible
THEN name the extension that is actually expected, with who expects it. Otherwise
     the extensibility is speculative and does not count.

IF the deciding argument is what another system or another company did
THEN test whether their workload, versions and constraints transfer. Treat the case as a hypothesis
     source, not proof for this feature without applicable evidence.

IF established feasible options are otherwise equivalent on the relevant evidence
THEN compare evidenced reversal cost, then simplicity if reversal cost is comparable.
     Missing evidence is not equivalence; use a conditional choice or next check when material.

IF the choice materially affects behaviour, data, operations or cost
THEN name the role accountable for that consequence; the current participant is not automatically it.

Constraints

• No unsupported scoring totals. Do not add ordinal labels as measurements. If a numerical model materially helps, use explicit units/assumptions, weights established before results, and sensitivity analysis; no total compensates for a failed mandatory constraint.
• Expose material costs and limits. Check the recommendation's adoption, operating and reversal costs; do not invent a disadvantage or a winning scenario for a dominated option to fill a template.
• Do not evaluate against a requirement nobody stated. Every axis used must trace to a requirement, a constraint or a named risk.
• Do not present options you would refuse to implement. A straw option makes the set look considered and makes the analysis worthless.

Output

Choice           <the question>
Constraints      <what any option must satisfy, with source>

Option A  <name>   the floor
  How it works     <two lines>
  Fits because     <axis: consequence>
  Costs            <axis: consequence>
Option B  <name>
  ...
Eliminated
  <option>  <- <constraint that ruled it out>

Recommendation   <option with conditions | unresolved and next action>
Because          <the one thing that separated it from the runner-up>
Consequences     <what the project accepts by taking it, including the unpleasant part>
Reversibility    <what undoing it would cost, and where it is contained>
Would change if  <per rejected option: the observation that would make it win>
Decision needed  <existing authority/source | missing accountable decision and affected work>
Evidence         <observed checks and limits; distinguish estimates and planned validation>
Experiment       <EXP-* when a bounded experiment is warranted; otherwise next check or none>

Hand the block to the decision phase; a small choice can use a concise paragraph with the same material evidence and limits. This skill produces the analysis; it does not record acceptance.