Buy / Boost / Build

Choose the lightest intervention that solves the real workflow problem. Custom AI is one option, not the default.

Core idea: Start with the business need and constraints. Compare buying an existing product, boosting an existing workflow, building custom, piloting first, or doing nothing yet.

01 / Decide

The decision path

Is the problem important enough?If pain is small, rare, or unmeasured, improve the baseline or process first.

Does an existing product solve most of the workflow?Compare buying or configuring it before building custom software.

Is an existing workflow missing one useful AI capability?Boost it with a bounded assistant, retrieval layer, automation, or integration.

Do differentiated needs or controls justify custom work?Build only the parts that genuinely need to be custom.

Is uncertainty still too high?Run a small pilot or discovery spike before committing.

Two legitimate outcomes: Do nothing yet, or pilot first. An idea may be premature because data, process, or adoption is not ready.

02 / Compare

What each option is good at

Option	Best when	Main tradeoff
BUY	The workflow is common, time to value matters, and a product meets most requirements.	Less control, vendor constraints, recurring cost, lock-in.
BOOST	Users already use a useful system; AI removes one bottleneck without replacing it.	Integration limits and inherited platform constraints.
BUILD	Workflow, data, controls, or differentiation justify owning the experience and behavior.	Maintenance, evals, observability, security, ongoing product ownership.

03 / Evaluate

Comparison checklist

Compare options against the same criteria, not enthusiasm.

Criterion	Questions to ask
Workflow fit	How much real work is covered, including exceptions and handoffs?
Integration	Can it connect to systems, data, identity, and actions that matter?
Data & privacy	What leaves the company? Retention, training use, residency, permissions, auditability?
Control	Can humans approve; can permissions, fallback, and prohibited actions be enforced?
Observability & evals	Can failures be inspected, quality measured, and changes verified?
Time to value	How quickly can users get meaningful improvement beyond a demo?
Total cost	Licensing, implementation, models, support, maintenance, change management?
Lock-in & portability	How hard is changing vendor, model, or architecture later?
Adoption	Does it fit current work or require a new destination and behavior?

04 / Recommend

Recommendation format

Recommend	Buy / Boost / Build / Pilot / Do nothing yet.
Because	Two or three evidence-backed reasons tied to fit, value, and risk.
Main tradeoff	The most important downside you accept.
What changes the call	Evidence, threshold, or constraint that could flip the recommendation.

Common trap and useful PM move

Common trapComparing a polished vendor product with a hypothetical build as if both are equally known. Label assumptions and uncertainty.

Useful PM moveTest the leading option on a small real workflow. Measure user effort, quality, exceptions, and operational burden.

Remember: The best option solves enough of the real problem with acceptable risk and ownership, not the one with the most AI.

GOING DEEPER

Keep the recommendation falsifiable

Tradeoffs and reversal conditions: Every recommendation should state the most important downside you accept and the concrete evidence that would change the call. Compare workflow fit, integration, data/privacy, authority, observability/evals, time to value, total cost, lock-in/portability and adoption on equal terms.

Do nothing or pilot first: Those are legitimate outcomes when pain is low, process inputs are not ready, or the evidence cannot support a responsible decision.