problem-decomposition

Start by restating the goal with a metric, baseline, and target number, plus a negative constraint on what must not regress. Then measure where time or complexity actually lives, and build a tree where each leaf has an owner, a size of about a day, and a numeric done condition.

Measure the latency breakdown by span first, then compute each branch's ceiling using Amdahl's law before staffing it. A branch whose maximum possible contribution is below the gap cannot succeed and should be dropped or deferred immediately.

Horizontal splitting assigns all schemas, then all services, then all UI, so nothing is demonstrable until the end. Vertical slices cut a narrow end-to-end path through every layer early, retiring integration risk in days and allowing later slices to be cut if the metric is already met.

Run a spike when a branch's feasibility is uncertain and the answer would change the plan. State a question, a timebox, and what each outcome implies; a spike that cannot change the plan is just early implementation.

Branches that look independent often share a hidden resource like a latency budget, a database table, or a deployment flag. Run the five-way check (data, schema, order, resource, deploy) and assign explicit sub-budgets per leaf instead of a single global target.