Three answers, and the third is common
Buy covers the cases where a vendor already solves the problem at a price below what building costs to run. Build covers the cases where the advantage comes from your data or your workflow and a general product cannot reach it. Wait covers everything whose expected return is real but whose inputs are not ready, and it is the answer more often than either of the others.
Naming "wait" as a legitimate outcome is what makes the other two credible. A ranking exercise that always ends in "build" is a sales process wearing a scoring rubric.
What gets scored
Expected return, stated as a range with the assumptions written down. A single number implies a confidence nobody has at this stage, and the assumptions are the part that gets revisited when reality disagrees.
Time to first evidence. An opportunity worth twice as much that takes four times as long to demonstrate is usually the weaker candidate, because the organisation has to keep believing in it for four times as long.
Data readiness, scored honestly. This is where most shortlists quietly break: the opportunity is real, the data required to serve it lives in three systems with no shared key, and the work to fix that is larger than the work to build the thing.
The cost of being wrong. A recommendation engine that misfires costs a click. A system in a clinical pathway costs something else, and it carries a governance burden that belongs in the ranking rather than in a surprise six months later.
The output is a sequence
The result is an ordered list where each entry says what it is worth, what it depends on, and what has to be true before it starts. Entries whose dependencies are not met sit behind the work that meets them.
That sequencing is most of the value. A list of twelve good ideas is a way of doing none of them; the same twelve in dependency order is a plan.
