Tool Procurement Eval

Tool Procurement Eval Skill

Tools enter stacks backwards: someone sees a demo, gets excited, and the "evaluation" becomes a justification ritual (vendor-comparison-matrix fights this at the compare stage; this skill fights it at the door). The forward order: the need stated first (which problem, whose, costing what — purchase-justification arithmetic), the stack-fit check before the trial (does something we own already do this? — the overlap audit that kills half of tool requests honestly), the trial designed with success criteria written before day one (or the trial's warm feelings decide), and the security/data review sized to what the tool touches — because the fun tool that ingests customer data is a compliance decision wearing a productivity costume.

What This Skill Produces

• The need statement — the problem, its owner, its cost, and the requirements it implies (must vs. nice — pre-demo)
• The stack-fit audit — the overlap check against owned tools, the integration reality, and the sprawl tax named
• The trial design — duration, participants, the pre-written success criteria, and the decision date
• The verdict — adopt (with owner and rollout) / decline (with the reason logged) — plus the security-review gate where data warrants

Required Inputs

Ask for these if not provided:

• The problem, not the tool — what's broken/slow/manual today, for whom, costing what; "I saw this cool tool" gets reverse-engineered into its implied need, which sometimes evaporates on contact
• The current stack — what's owned that's adjacent (the overlap audit needs the inventory — contract-renewal-tracker's list is the source); most orgs own 30% more capability than they use
• What the tool would touch — customer data? Credentials? Just public content? The security review's depth follows (skill-vetting blast-radius thinking, applied to SaaS)
• The trial population — who'd actually test it (the enthusiast and a skeptic — enthusiast-only trials always pass)

Framework: The Eval Rules

1. Need before tool: the statement — problem, owner, frequency, cost of the status quo — written before any vendor contact; requirements derive from it (must-haves gate, nice-to-haves score). Tools without a need statement are solutions shopping for problems on your budget.
2. The overlap audit runs early and honestly: does an owned tool cover 80% of the need? (The honest answer kills the request — cheaply and correctly.) Half-used owned tools get their config/training gap named instead ("we own this in Notion; nobody set it up") — the sprawl tax (another login, another admin, another renewal row, another data silo) is a real cost the shiny demo never quotes.
3. Trials have pre-written criteria and a skeptic: "success = the team's weekly report time drops below 2 hours, and 4 of 6 pilots choose to keep it" — written before day one (survey-design-basics pre-commitment), tested with the enthusiast and the skeptic (the enthusiast finds the ceiling; the skeptic finds the floor), timeboxed with a decision date. Trials without criteria are extended demos that always end in purchase.
4. The security gate scales to the data: public-content tools get the light pass (vendor's security page, the data-processing basics); anything touching customer data, credentials, or internal documents gets the real review (where's the data stored, who can access, the deletion story, the tos-decoder read of their terms) — before the trial pipes real data in, not after. "It's just a trial" is how customer data ends up in un-reviewed vendors.
5. The verdict gets logged either way: adopt → owner named, rollout planned, the renewal row created at signature ([the intake rule]) · decline → the reason in the decision-log ("evaluated [tool] July 2026 — declined: 80% covered by owned stack") — because the same tool returns with a new champion every eighteen months, and the log converts the rematch into a lookup.