Workshop: Build/buy analysis
Produce artifact #3: run the portfolio's top initiatives through the framework, spec one POC with pre-written criteria, and catch the build that should be a blend.
Workshop three: sourcing decisions for the funded portfolio. Alder's three worked cases below are chosen because each one teaches a different verdict — run your own portfolio through the same sequence if you're working with your real organization.
- 1Case 1 — exception-email triage → BLEND. Apply the two-part build test: differentiating? (No — every carrier triages exceptions; speed of response differentiates, the triage plumbing doesn't.) Data advantage? (The email corpus is yours, but it tunes a platform; it doesn't justify owning one.) Verdict: blend on the existing ticketing platform's AI, own the prompts/routing/unsure-lane config (the unsure lane is the queue for items the AI isn't confident enough to handle alone). Write the verdict paragraph with both test answers explicit.
- 2Case 2 — document extraction (serving tenders + contracts + disputes) → BUY-then-BLEND, evaluated properly. This is the cluster play: one document-AI capability, three initiatives. Draft the six-dimension rubric with weights (data handling and lock-in weighted up — documents include customer terms), then spec the POC: 200 real documents including the 40 worst, error <5%, your sales-ops person driving, three weeks, scored in front of the steering group. Write the criteria now, pre-sales-call, and date the document.
- 3Case 3 — predictive ETA (the strategic bet) → the tempting BUILD that the framework flips. Differentiating? Genuinely yes (reliability is Alder's pitch). Data advantage? Yes — lane history no vendor has. So build? Run it honestly: the prediction core passes the build test, but the surrounding 80% (ingestion, serving, monitoring, dashboards) is undifferentiated plumbing. Verdict: blend the plumbing, build only the model layer — a team of two on the differentiating slice, bought infrastructure underneath. Most 'build' answers, examined, are this hybrid; write the boundary explicitly (what we own / what we rent / what breaks if the vendor dies).
- 4Sweep the rest of the portfolio in fifteen minutes: quick wins default to blend-on-existing-platforms unless something objects; options are buys by definition (you're buying information). Note any initiative whose verdict creates a shared dependency (two initiatives, one vendor) — flag it for the risk register in Module 4.
- 5Assemble artifact #3: one page per top-three case (verdict, test answers, POC spec or boundary drawing), plus the sweep table. Close with the capability-location paragraph: after these decisions, where does Alder's AI knowledge live, and are you comfortable with that answer? (If it all lives in vendors, revisit Case 3's boundary.)
INITIATIVE VERDICT OWNED BY US RENTED
1 exception triage blend prompts, routing, ticketing
unsure lane, evals platform AI
2 tender extraction \ formats, tuning, document-AI
3 contract summary > buy->blend review workflows, product (one
4 dispute drafts / the 200-doc eval set vendor, POC'd)
6 predictive ETA hybrid model layer, lane pipelines,
features, eval vs serving, obs-
dispatcher baseline ervability
8 slotting optimizer buy (probe) the decision 2-wk vendor
category eval
shared-dependency flag: initiatives 2/3/4 share one vendor -> risk registerRed-team the pass/fail criteria for this proof-of-concept before I run the pilot: [paste your POC spec - the numeric success threshold, the sample of documents/cases, who drives it, the time box]. (1) Which criterion could a vendor pass while still failing us in production? (2) What ugly real-world input did I leave out of the sample? (3) Is my threshold measuring capability or measuring the demo? (4) Rewrite the criteria so a POC that 'goes well' actually predicts our Tuesday. Assume the vendor will optimize to whatever I write.
Run this on each POC spec while your skepticism is intact — before the first sales call. A pass/fail bar the vendor can game is worse than none, because it launders a bad buy as a rigorous one.
~16 minutes to read; the real work is 3–4 weeks of elapsed time, most of it the proof-of-concept running on your data while your people drive it. DELEGABLE: assembling the six-dimension rubric, gathering the document/case sample (including the ugly ones), running the POC day-to-day, and modeling vendor pricing at 1×/3×/10×. YOU, PERSONALLY: the build-vs-buy verdict on the strategic bet, signing off the pre-written POC criteria, and the capability-location judgment (are you comfortable where your AI knowledge ends up living?).
You get a vendor's glossy POC report (their data, no criteria, 'went great'), a build proposal for an internal meeting-notes tool (fails both build tests — but was written by your best engineer, so the exercise is the conversation, not the verdict), and a pricing sheet to model at 1×/3×/10× volume where the cheap option becomes the expensive one at scale. Three documents, three traps, thirty minutes each.