Field Guide 1:3 Chapter 3 Proof of Concept

Transcript

SPEAKER_00 0:00

Chapter thirteen Introduction to Proof Offerings In the sales world, proof offerings, whether proof of concepts, POCs, custom demos, or pilots, play a crucial role in demonstrating that the proposed solution will meet the customer's technical and business needs. These offerings are the tangible proof that what you're selling actually works and can solve the specific problems your customer is facing. As an SEAC plus TS professional, your role in preparing and executing proof offerings is pivotal. Not only do you have to ensure that the solution is technically feasible and that it aligns with the customer's requirements, but you also need to manage expectations, ensure that scope creep doesn't derail the process, and follow up to keep the deal moving forward. Proof offerings are also an opportunity for you to collaborate closely with the sales team to ensure that the solution being presented is not just the right fit technically, but also drives the business value the customer is seeking. This chapter will provide an in-depth look at how to prepare and execute proof offerings effectively, with practical steps you can take to drive success at each stage of the engagement. The content you'll find here has been designed to give you the tools you need to stay on track, manage risks, and measure success in your proof offering engagements. Proof offerings the bridge between concept and reality. Have you ever seen a great product fail because the buyer wasn't convinced it would work in their unique environment? Have you ever watched one of your demos from the customer's perspective and felt yourself dozing off as it devolved into a feature dump? One that left them wondering, so what? Why should I care? Have you ever been blindsided by a sales rep who offered up a free custom demonstration or worse, an integrated proof of concept during the very first client meeting without any qualification or agreement? And tell me honestly, have you ever finished a project and thought to yourself, we should have just given them the product for free? It would have been cheaper than the hundreds of hours I spent on this fruitless proof of concept. These moments are all too familiar to anyone working in technology sales, especially those of us in pre-sales roles. Proof offerings are at the heart of what we do. They are the tools that bridge the gap between concept and reality, providing customers with tangible evidence that our solution can solve their most pressing problems. Done well, proof offerings build trust, accelerate momentum, and secure the all-important technical win. Done poorly, they drain resources, erode morale, and undermine confidence, sometimes fatally. This chapter will explore how proof offerings can make or break your deals. Whether you're a sales engineer showcasing the capabilities of a cloud-based SaaS product, a solution architect navigating intricate hybrid infrastructure integrations, or a solution consultant aligning platforms to complex business needs, the right proof offering can be the difference between a stalled opportunity and a closed deal. Why proof offerings matter? In today's evolving sales landscape, proof offerings are not a one-size-fits-all exercise. A free trial or a quick demo might work wonders for a cloud-based solution, but will fall short when a customer's environment requires deep technical validation. Open source tools, on the other hand, pose entirely different challenges. They are often adopted independently by developers, which can accelerate grassroots usage but lead to misconfigurations, frustration, and missed opportunities without proper guidance. For proof offerings to succeed, they must align with the customer's needs, stage in the sales cycle, and expectations for validation. Just as importantly, they must establish a give and get value exchange. Your time and expertise are precious. If customers want you to invest in a tailored proof of concept, they must commit something in return, whether that's access to key decision makers, defined success criteria, or even financial investment. And at the heart of every successful proof offering lies one goal: achieving a technical win. The importance of achieving a technical win. If you've spent time in pre-sales, you already know this truth. The technical win is your ticket to a deal. Yes, mentioned in earlier chapters, but it is worth mentioning again here that's how important it is. It's the moment when the customer confirms that your solution meets their technical and business requirements, eliminating other contenders and paving the way for a purchase decision. A technical win doesn't guarantee the deal. Negotiations, contracts, and finance teams still lie ahead, but without it, you don't stand a chance. So how do you know when you've secured a technical win? The conversation typically sounds like this. Now that we've completed the evaluation and met your requirements, is there anything preventing us from moving forward? Is it safe to assume that you will no longer entertain other solution providers and will sponsor us to your business champions for purchase recommendations? If the customer says, yes, congratulations, you've won. But don't leave it at that. Follow up with a confirmation email to document their commitment. That written acknowledgement can be critical leverage later in the process if priorities shift or doubts creep in. Without proper qualification, however, even a technical win can be meaningless. Maybe you weren't talking to the real decision maker or there's no budget in place. Proper discovery and a clear technical close plan will ensure you don't waste time pursuing deals that won't close. Real stories lessons from the field, the Equifax debacle. Let me take you back to 2015. At Oracle, a sales rep promised Equifax a custom proof of concept POC without properly qualifying the opportunity. There were no defined success criteria, no time parameters, and no decision gates. The SE team pushed back, but leadership overruled them. What happened next was predictable scope creep, unrealistic demands, and an endless drain on resources. After 120 hours of SE time, at a conservative estimate of $200 per hour, we were already $24,000 in the hole, yet the requests kept coming. By the time we hit 300 hours of effort over eight months, we finally closed a deal worth $130,000. On paper it might look like a win, but let's be honest, it was a loss. The time and effort we spent on Equifax represented a massive opportunity cost, hundreds of hours that could have been invested elsewhere in the pipeline. Two years later there was still no upsell or cross-sell to justify that initial investment. The lesson? Don't give away your time and resources without clear boundaries, defined success criteria, and skin in the game. It's better to say no upfront than to let an unqualified opportunity bleed you dry. METLife and the power of an SOW. At Adobe in 2005, Jason Barnett and I changed the game by introducing the first proof of concept requirements document. Tested with METLife, it transformed how we approach proof offerings. We formalized the process with a statement of work, SOW, that outlined the customer's technical and business requirements, the scope of work needed to validate success, and a technical close plan embedded into the SOW itself. During the final solution demonstration, we used a simple checklist to confirm it appears we've met all requirements. Is there anything preventing us from moving forward? The brilliance of this approach was its ability to corner the customer. If they said no, we were able to respond with, what else do we need to do to secure your sponsorship? This shifted the power dynamic and put us firmly in control of the next steps. An added benefit of the SOW process was that we could pressure test the customer's seriousness by requesting NDAs and MSA agreements up front. If the problem wasn't worth their effort, we uncovered it early and moved on. Teachers Insurance charging for value. By 2008, we evolved our proof offerings further with teachers insurance. Here, we introduced a $10,000 mini baseline analysis, a deliverable that assessed their current and future state. This analysis provided value regardless of the vendor they ultimately chose, but it also gave us unparalleled access to stakeholders. After just one week on site and another week building the analysis document, we presented a clear path forward. If the client didn't want to move ahead with us, we reminded them that they now owned a high-value deliverable they had paid for. More often than not, they chose to continue. Aligning proof offerings to the customer's needs. Every proof offering should be a means to an end, the discovery of what the customer truly needs and how your solution uniquely addresses those needs. The most successful proof offerings aren't about showing what your product does, they're about proving why it matters to the customer. When your proof offerings align with these principles, customers will have that discovery of fire moment, the realization that they didn't even know such possibilities existed. Final thoughts. Proof offerings are your chance to build trust, validate your solution, and guide customers to the technical win, but they must be approached with purpose, structure, and discipline. Whether it's a free trial for a SaaS product, a functional prototype for a hybrid solution, or a workshop for open source adoption, every proof offering is a step toward closing the deal. And remember, it's okay to walk away. A quick no is far better than an endless, fruitless maybe. You'll find a table in the book that outlines the typical engagement breakdown for three common technical sales roles the sales engineer, the solution architect, and the solution consultant. I want to walk you through this table and give you some context on what these numbers mean so even if you're listening and not looking at the page, you'll still get the full picture. Let's start with the standard demo, you know, the kind of canned out-of-the-box demonstration that's often used early in the sales process. Sales engineers are almost always involved here, 100% of the time. But for solution architects, their involvement drops to about 20%. And for solution consultants, even lower, just 10%. So the SE is the main player for standard demos. Now, when it comes to a custom demo, something tailored to the client's specific environment or needs, all three roles step up. Sales engineers are still leading the charge at 100%, but now solution architects get involved 75% of the time, and solution consultants match that with 75% as well. It makes sense. A tailored demo often requires deeper architecture knowledge and consultative input. Next is the proof of concept, or POC. This is where we're actually proving out the solution in the client's real world environment. Solution. Architects take the lead here. 100% engagement. Sales engineers are involved about half the time, and solution consultants also come in at around 50%. The POC usually lives in that technical deep dive zone where architecture really matters. And finally there's the pilot. This is when a client puts money behind a limited rollout, often before a full deal is signed. Here, involvement drops across the board. Sales engineers are engaged just 10% of the time, solution architects around 20%, and solution consultants also about 20%. At this point, ownership often transitions to implementation or customer success teams. So again, if you're following along in the book, the table lays out those percentages visually. But even if you're just listening, the takeaway is clear as you move from standard demos to pilots, the mix of team involvement shifts, sales engineers dominate early, architects step in deeper through customization and validation, and consultants bridge support where needed. Keep this in mind as you plan team engagement through each phase of your sales cycle. As you follow along with this chapter, you'll find a detailed table in the book that's designed to guide you through the different types of proof offerings commonly used in enterprise sales. The table is a practical tool. It breaks down each offering by its purpose, when to use it, the give get strategy, and key considerations to keep in mind. Now, I'm not going to walk through every detail just yet. We'll unpack many of these proof strategies one by one in the sections ahead, but I wanted to let you know it's there, right in front of you if you have the book open, and it's going to serve as a reference point throughout the next part of our discussion. You'll see everything from simple discovery discussions and standard demos to more advanced engagements like prototypes, pilots, ROI focused offerings, and even co-creation efforts with the customer. The goal here is to help you choose the right type of proof for the right stage of the deal, and to make sure you're always aligning effort with expected return. So feel free to flip to that table now if you have the book in hand or just keep listening. I'll be walking you through how and when to use each of these proof strategies and how to maximize your impact in the pre sale cycle.