Free — no signup required

The RFP Process (The "Bake-Off")

3 min read

Running a Fair Fight

A Request for Proposal (RFP) is a structured document you send to multiple vendors asking them to demonstrate — in a controlled, comparable way — that they can solve your specific problem. Without an RFP, the vendor with the best sales team wins. With an RFP, the vendor with the best product wins. The RFP is how you remove charisma from the equation.

The RFP Lifecycle

Phase 1 — Requirements Gathering (Week 1–2)

Interview your own team before talking to any vendor. Ask:
- What problem are we actually solving? (Not "what tool do we want?")
- What are the absolute must-haves? (Non-negotiable requirements)
- What are the nice-to-haves? (Differentiators, not blockers)
- What does failure look like? (Define your SLA expectations upfront)

Document these as a requirements matrix. This becomes the backbone of your RFP document.

Phase 2 — Vendor Shortlisting (Week 2–3)

Send the RFP to 4–6 vendors. Based on written responses, narrow to the top 2–3 for a live evaluation. Eliminate vendors who cannot answer basic compliance or data portability questions in writing.

Phase 3 — The Proof of Concept / "Bake-Off" (Week 3–6)

Run a 2-week hands-on PoC with your top 2 vendors. Critical rules:
- Use your own data, not their demo data. Demo data is curated to make the product look good. Your data will expose edge cases.
- Involve the engineers who will use it daily. Their friction is real signal.
- Time-box it strictly. A vendor who cannot onboard you in 2 weeks will not onboard your team in 2 months.

Phase 4 — Scoring and Decision (Week 6–7)

Use a weighted decision matrix (see the Lab) to score each vendor mathematically. This produces a defensible, documented rationale for your choice — essential when justifying spend to leadership or a finance committee.

Staff Insight: Roadmap Promises Are Worthless

Vendors routinely promise features "coming in Q3." Treat every roadmap commitment as fiction unless it is written into the contract with a penalty clause. Evaluate only what exists and works today. If a missing feature is critical, either negotiate a contractual delivery commitment with a price reduction clause if it slips, or eliminate the vendor.

Interview Tip

Interviewers at Staff+ level often ask: "How do you evaluate and select a new vendor?" The weak answer is "I look at features and pricing." The strong answer is: "I start with a requirements matrix built from stakeholder interviews, run a time-boxed PoC on real data, score vendors on a weighted matrix covering security, cost, functionality, and support, and only then negotiate contracts — with exit terms defined before I sign." This demonstrates process maturity, not just technical judgment.

This is one of 18 chapters

Every chapter is free — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

Sign up free