“We don’t do Science Projects.” • This should be your mantra. • This should be on your coat of arms. • If someone mentions your name internally, the next thought should be: “He doesn’t do science projects.” So far, we’ve looked at Reason and Impact. You understand why the deal exists, and you understand what it’s worth if it succeeds. A good PoV takes those business objectives and turns them into use cases. Those use cases then map to clusters of features , not the other way around. This is a top-down exercise. The guardrails for a PoV must be agreed at a senior level within the prospect organisation , where business outcomes matter, not cosmetic preferences. This is not about whether the reporting tab is orange or purple. And it is absolutely not about indulging a junior admin who wants to manage your platform from his PlayStation 5 at home. If the PoV hinges on trivia, it’s already dead. Framing a PoV properly is not about technology. It’s about discipline. The moment you agree to “just see what it can do,” you’ve already lost control. A PoV without guardrails will expand to fill all available time, goodwill, and SE sanity. Features creep in. Stakeholders drift. Success becomes subjective. And before you know it, you’re six weeks deep, solving interesting problems for free, with no clearer path to a purchase order than when you started. Guardrails force alignment up front. What are we proving? Why does it matter? What does success look like in plain English? Who agrees with that definition? And critically—what happens if we prove it? If you can’t get consensus on those questions before the PoV starts, you won’t magically get it afterwards. A well-guarded PoV has a narrow scope, explicit goals, named owners, and a shared understanding that this is not R&D, training, or consultancy. It is a commercial exercise with an outcome. When everyone agrees to the guardrails, the PoV becomes a decision-making tool. Without them, it becomes theatre—and theatre doesn’t close deals. Guardrail #1 , Only PoV What Is Pertinent to This Deal • A PoV is not a showcase of everything your product can do. • It is a focused attempt to prove one specific piece of value. If your platform has ten capabilities, but only two are required to justify this project, then those two are all that matter. Anything else is noise. Interesting noise, perhaps, but still noise. The moment you try to prove everything, you prove nothing. The PoV becomes bloated, success becomes subjective, and the conversation drifts away from decision-making and toward feature tourism. If a third capability emerges during the PoV, that’s fine , welcome, even , but it does not retroactively become part of the agreement. That’s future scope, not present proof. A PoV only works when everyone is comfortable saying, “That’s out of scope.” Without that discipline, you’re not running a PoV , you’re running a workshop with no end. Guardrail #2 , Limit the Scale (This Is Not a Deployment) A PoV must be small. Intentionally small. • A few users. • A subset of data. • A single workflow or region. Scale is not something you need to prove repeatedly , especially if your solution already operates successfully in organisations far larger than the one you’re working with. If scale is a concern, a reference call answers that question far more efficiently than a full rollout ever will. The danger zone appears when a PoV starts to resemble production: mirrored environments, full data sets, global user access. At that point, the line between proving value and delivering the job has been crossed , and it rarely gets crossed back. A PoV that grows uncontrollably isn’t ambitious. It’s unmanaged. Guardrail #3 , Named Outcomes, Not Vibes A PoV cannot succeed if success is undefined. • “We’ll know if it works” is not a success criterion. • “Everyone will feel comfortable” is not a metric. • “The technical team likes it” is not an outcome. Before a PoV begins, success must be written down in plain language. What changes if this works? What stops breaking? What improves measurably? What decision becomes possible? Ambiguity feels polite at the start, but it becomes lethal at the end. When outcomes are vague, debates replace decisions, and the PoV concludes with opinions instead of conclusions. Clear success criteria don’t make a PoV rigid , they make it fair. Everyone knows what they’re aiming for. Everyone knows when it’s been achieved. Guardrail #4 , The Right to Proceed (Commercial Intent) • A PoV is not a research grant. • It is not training. • And it is not an experiment “just to see.” Before any technical effort begins, there must be a shared understanding of what happens if the PoV succeeds. Who makes the decision? What does “go” actually mean? What changes internally if the value is proven? This doesn’t require a purchase order up front , but it does require intent. If the answer to “what happens next?” is evasive, political, or vague, then the PoV does not have the right to exist. This guardrail is the gatekeeper. If it isn’t met, the PoV should not start , no matter how exciting the technology or how enthusiastic the team. Hope is not a commercial plan. Guardrail #5 , One Owner on Their Side Every PoV needs a single accountable owner at the prospect. • Not a steering group. • Not “the team.” • Not a rotating cast of stakeholders. One person who cares if it succeeds, feels the pain if it fails, and has something to lose if it drags on. Without this, the PoV becomes a shared interest and nobody’s priority. Committees don’t drive decisions , individuals do. And PoVs without ownership don’t stall dramatically; they simply fade. If you can’t identify a real owner, you’re not short of alignment , you’re short of urgency. Guardrail #6 , Timeboxed, or It Will Rot PoVs rarely fail loudly. They die quietly. • They slip meetings. • They get “revisited.” • They become “really useful.” Every PoV must have a start date, an end date, and a decision date. Not as admin , as intent. Timeboxing forces focus. It exposes whether the project matters enough to act on. When dates move, that’s not flexibility , it’s information. And experienced SEs pay attention to information. A PoV without an end date is not a PoV. It’s a slow leak of time, energy, and credibility. Why Guardrails Matter Guardrails aren’t about being difficult. They’re about being decisive. • They protect time. • They protect focus. • They protect everyone involved from mistaking activity for progress. Without guardrails, PoVs expand, SEs stay busy, and nothing closes. With them, PoVs stay narrow, uncomfortable, and effective. And effective things lead to decisions. Not science projects.