Case study
An offering graph to choose one thing to sell
A 319-node graph built from the live product registries, used to pick a single wedge and then to kill two channels that could not carry it.
- nodes
- 319nodes
- edges
- 1,693edges
- monthly searches — why paid search was dropped
- ~700monthly searches — why paid search was dropped
Figures measured 2026-10-12.
The problem
The practice had 32 agent designs and 12 productised offers, and no basis for choosing which one to take to market first.
What was built
Generated a graph from the live registries (offers, the agents they use, and the data each depends on) so it regenerates when the catalogue changes rather than going stale as a slide.
Scored every offer on measured demand, vendor evidence, how mechanical the delivery is, and whether the outcome is countable in dollars.
Tested the winner against demand before spending: total search volume for the wedge was about 700 a month, so paid search was dropped for paid social. A referral-brokerage model was tested on paper the same way and rejected on sequence.
What changed
One wedge chosen: recovering missed calls into booked jobs for multi-location home-service businesses, priced as a share of the bookings it produces. Only 2 of the 32 offers combined a dollar outcome with a meter you can bill on.
That pursuit is in progress now. No result is claimed until there is one.
Inside your team
Pricing, packaging, and choosing what to launch is a modelling problem before it is a messaging problem. The graph kept the decision tied to evidence and made the dead ends cheap.