One part of the buying process is a POC/POV (Proof of Concept/Proof of Value). If done right, those require a significant effort from both parties – buyers and sellers – so you want to make the best out of this situation and not waste everybody’s time.

In this Shorts episode we are talking about:

  • What is a POC/POV and where does it fit into the buying cycle?
  • Have a clear objective for the POC
  • What is the typical structure of a POC?
  • Communicate clearly
  • Make it easy for the client to choose you

Please reach out to us by either sending an email to hello@whatsyourbaseline.com or leaving us a voice message by clicking here.

Additional information

There is no additional information available for this episode.

Transcript

(The transcript is auto-generated and was slightly edited for clarity)

Roland: Hey J-M, how are you doing today?

J-M: Hey Roland, I’m excited to talk about our topic today for What’s Your Baseline Shorts which is all about what makes a good POC or POV. Now first, I’m gonna ask you Roland. Where do you see a POC/POV fitting into a buying cycle for a customer for anything? What is the difference between POCs and POVs – tell me all about them because I’m interested in your perspective.

Roland: I’m so glad that you asked because it’s never good to start with some abbreviations. So a POC is known as a proof of concept, typically a technical proof of concept you know does the thing do what it’s supposed to do.

J-M: Yeah, yeah.

Roland: While a POV is a proof of value. Do we get the thing out of whatever we are evaluating that we wanted to get out of it? Do we get the desired result?

J-M: Yeah, and a POC is often something you’ll do as part of proving out that a technology actually works. Sort of like the ‘trust but verify’ old saying, you’re seeing if this vendor can actually do what they say they can do. Whereas a proof of value is way more involved because you need to actually take data. You need to actually get to an outcome. 

Roland: Can your car really drive a hundred and sixty miles an hour versus do I get faster to my grandmother?

J-M: Yeah exactly. Although I think if you’re going 160 to your grandmother’s, something’s very wrong, but ah.

Roland: Ah, fair enough. 

J-M: So where do you see this fitting into the buying cycle because a lot of people ask about that kind of thing.

Roland: So what you typically see is that it depends on the type of software that you want to sell. You typically see customers sending out what they call RFIs (requests for information) which is the first step where they just go and say ‘hey talk a little bit about what you’re offering. We’re looking for something that is this but we still don’t know exactly what we’re looking for’. 

J-M: Yeah, it’s kind of like a market scan from an analyst, which we talked to Amar about. That’s kind of that idea – tell us a little bit more about what you do, We’re not committing to anything, no contracts on the table. No obligations, just information.

Roland: Yeah, that is true. And then the next step would be an RFP – a request for proposal. And within that the request for proposal, you will have different vendors ideally being preselected. They all get the same questionnaire because you want to do an evaluation. They want to compare apples with apples and not apples with oranges. And as part of that process, they might even make a decision after the RFP and say ‘yep what you’re selling is exactly what we want. Give it to us’. And then you go to the negotiation phase. But if it’s a little bit more complex, for instance, if you sell Business Process Management / Enterprise Architecture software, for example, people typically want to see a little bit more. And this is where a POC or a POV comes into play.

J-M: And just as and as a note for you, one of the things I talk a lot about is the difference between POCs and custom demos. They are very different. They do very different things. But the biggest difference between a POC and custom demo is whether or not the person who’s touching the keyboard comes from the customer or comes from the vendor. Oftentimes POCs are things that the customers get their hands on – they work within the tool to see how it actually works and what’s behind the curtain. In custom demos, you just send us data. We present something to you. You just trust that it wasn’t that hard.

Roland: Which also means there might be a non-insignificant effort of training being involved in a POC or POV. We will talk about how a POC or POV will typically go later. So after the POC or POV, the customer goes into a big dark room and makes a big evaluation and comes back with a list of vendors and says “okay, we’re going to buy from J-M – let’s go into the negotiation phase.” Then if J-M says “oh but I want to have an arm and a leg for it”, they might say “no thank you, J-M, we’re going to buy from somebody else.” So it’s the commercial agreement that you have in the regular Enterprise software buying process.

J-M: Exactly, and the question is: why do a POC? Why do people do POCs for things and why should you or should you not? So just as a note for everyone, there’s been a trend I’ve seen in the work that I do where there are a lot of people asking “hey, let’s just go straight to a POC.” They want to go straight to a POC in the middle of the conversation around evaluation of products, and that’s not necessary. Remember that a POC is an investment; an investment on both sides, which means if you need to see the proof of how it works or if you need to have people live it and experience it to gain consensus and buy in, and get pre-training should you choose to move forward with it so you’ve had some experience with it, this is a great way to do so. But once again, it is an investment and also not all POCs are free. It’s not just POVs that aren’t free, POCs are often paid. A lot of organizations and consultancies require some upfront cost.

Roland: Yeah, but because it’s a commitment that they bring to the table. Time and effort and all these things. And we’ll talk about that in a minute. You want to have the commitment from the client that if you hit the objective of the POC that the client will buy. So they have more investment there. But to come back to your point, do I need to have a POC in any buying process? The answer is no. If you, for example, sell software that helps create BPMN Diagrams because you want to model your business architecture, typically you don’t need a POC for this. 

J-M: Yeah, what’s it going to show you?

Roland: A demo. Maybe a custom demo. You know, ‘show us how you do this and how it looks and what systems you can or information you can bring in’ and all these things. Can I import Visio Diagrams, whatever the questions might be. That can be covered with a demo. A POC or POV comes into place when you look for either something that is bleeding edge technology. You know, “I don’t trust you, J-M, I don’t believe you that it actually works, show me.”

J-M: What is process mining? Oh god I don’t even know and never heard of it – it’s brand new. That’s not that new.

Roland: Or if you’re looking to do a POV (to stick with your process mining example), we want to know if we see ideas how we can improve. And I think, in this case, it makes sense to have a POV. But hey, when do you get started with that (and put yourself into a customer’s shoes), what is the first thing that he would recommend a customer to do?

J-M: The first thing I ask every customer to define right up front is objective and success criteria. You need to know first and foremost what we just talked about – you need to clearly spell out ‘why are we doing this POC?’ and ‘what will make this POC successful for us?’. My mom has an expression that I love – you can’t think of people as clients and vendors. You think of people as partners. You’re trying to build a partnership relationship. Both people are putting their money and their people on the table. So let’s have a clear objective and success criteria, and if we are successful, we should be moving to the process of purchase and sale and partnership. And to get that clear objective you need to have hypotheses you have to think ‘here is what we’re going to be testing’, ‘here’s what we think it should do’, and ‘what do I want to know?’. This is particularly important for things like POVs you need to have hypotheses you are testing. All this has to be defined, written down and agreed upon.

Roland: That’s exactly the point. You want to have it written down. So that everybody looks at the same piece of paper when it comes to the evaluation and says ‘did I check the box?’ The second thing is, if you’re on the vendor side, once you have the objectives, you can define what the scope is. You can say ‘oh Mr Client we’re going to build this for you and does that meet your requirements?’ and you do that before you even start working on it.

J-M: But then there’s the structure from there. How do you build that structure into something that actually works.What do you do during the POC or POV?.

Roland: There’s obviously a lot of education along the way, which brings me to the next point. What is the typical structure of a POC or POV? And the first thing that comes to mind is to have a clear timeline and have a schedule.Bring in those mechanical things like provisioning of environments and training people. What’s the expectation of the client? Is it enough that you just point them to a recording or a free training, or do they want to have a little bit of handholding as part of the POC, which obviously costs time. You also want to make sure when you set up your schedule that this is not open-ended. You want to be done, say, in four weeks. So you plan backwards from that last day which typically is a final readout before the customer then goes and evaluates all the different things they’ve seen.

J-M: And that’s to protect both parties. You don’t want to be bleeding resources for six months on a POV that is consuming all the time a department does. That’s crazy. You’re just investing in something you may not use. Same with the vendors. Vendors don’t want to lose their presales and professional services people for large periods of time. They don’t have a giant bench of folks they can allocate to a bunch of POCs. Those people are juggling lots of stuff so we protect it by time boxing it and time boxing it upfront allows us to build the structure around it. So now we have constraints and constraints breed innovation.

Roland Agreed, and what you typically do is then you start with a kickoff right with a brief. So you have a formal start and you have a formal end. We’re gonna talk about that in a minute in a little bit more detail. In that brief, all the stuff that we just said will be restated for everyone to listen to. What are the objectives? What’s the evaluation? What’s the timeline? What are the artifacts that will be created? And maybe more importantly, what’s the collaboration between the two parties? Because you should avoid just throwing something over the fence. If we stick with that Process Mining example, folks may say “oh here are my SAP tables, now go make it happen.” You know that’s never good.

J-M: Yeah, yeah. Good luck.

Roland: So if you’re a vendor and you have a client who approaches you in that way, say no. Just don’t get started with it.

J-M: Yeah, not worth it.

Roland: What you want is you want to have a commitment from the client. And the better POVs that I worked in were where we as a vendor went and said “look we want to have a commitment from you, say 40 hours in the next four weeks, and these are the resources – who’s your tech guy who’s your business guy who’s your blah blah blah”. And the client agrees to it. Because then they’re invested in it.

J-M: And they’re also invested in the outcomes. And that’s something we need to do. I want to make sure we cover this, because you always need to have a big readout of the results of your project / POC / POV. You need to bring different stakeholder groups in, segment your message by who is coming in to see it, and most importantly, build that coalition of people who understand what the product is doing, understand what the practice is around the product, understand the value or the concept that you’re bringing to the company, and have a path forward to actually buy and use this as the core of what they do.

Roland: And that’s another aspect for that contribution. You do not only buy a thing. You also want to test out whether you can work with those people. Will the vendor give me the support that I expect? Are they a little bit fishy or whatever, you know, where you say “I don’t have a good feeling working with them.” So that’s something that you want to make sure of. On both sides you want to make sure that the personalities match. And then, at the end of that whole process, there’s obviously a new negotiation phase. This is where the technical team might say “okay, hey, we’ve shown you everything. I think we checked all the boxes”. And now the sales guys come in and say “okay, what can we do?” And this is a completely different topic for another shorts if you want, but that obviously can be the make or break here.

J-M: So we’ve covered a good structure here. Now, what are some best practices or lessons learned that you’ve taken from engaging in these POCs and POVs? For me, I think one of my biggest lessons learned is to always understand stakeholder needs, segment them down so you can very clearly define ‘who needs what when’. That’s having a timetable that also includes people at each point in time so that you can give them a sense of when they’re going to be needed. Help them allocate their time and resources, and ultimately make sure you’re delivering what they actually ask for.

Roland: Yeah, and I think you can summarize that under the topic of ‘communicate clearly’. Because what you also want is (like I said before) you want to have your clients involved, you want to have that participation there. You want to communicate to the stakeholders, the evaluation committee, to give your stakeholders (the people holding the purse strings) continuous feedback to say “oh this is how it’s going. We’re working with that J-M guy. He seems to be a knowledgeable and nice guy. I like working with him.” But you also want to make sure that once everything that you had on your list is accomplished, you can drill even further into what about the data to see what the tool can do above and beyond what we had as objectives.

J-M: And keeping that idea of communication, one thing I’ve really found helpful is having a knowledge repository of POC and POV artifacts. Something you can access asynchronously. So if you’re somebody at the client looking to try and make your case and you can just go “oh here’s where I’m going to go and call up the latest presentation or or demo” and if you’re somebody at the vendor looking to prove your case, you can use this as a mechanism of giving best practices, reference documentation, quick reference guides and these sorts of things. Have a repository, and use it.

Roland: Yeah, it’s not Microsoft Outlook for those of you who are curious. 

J-M: No no no, a REAL repository. Something that’s useful.

Roland: So we’re getting at the top of our allocated time, J-M. You know, ‘shorts’. The first thing to look at comes when you look at it from the vendor side. I think the one takeaway that I would give to vendors is make it easy for the client to buy from you. And that means you need to have a clear definition of the business problem. Clients don’t want to buy just software. They ideally have a ‘Big Hairy Problem’ for that POC that they want to tackle, and they’ve said “hey we need help with this. Can your software and/or services help us with that?” So that is one thing. And when we talk about process mining I have some ideas how that could look, but have this definitely together. And the second thing that I have is when you frame the solution do this also collaboratively with the client so that they are invested in it and they see that you are people too.

J-M: Yeah, and then lastly I think that the thing that I would urge all vendors here is keep your pricing simple. Minimize the number of SKUs If you’ve got a billion stock keeping units, a billion different ways of buying it, and a billion different scenarios, that’s just going to get in the way of helping to understand what you’re actually providing to them. Because you’re providing a solution. It’s as simple as that. And the harder it is to buy, the harder it is for them to actually see what they’re going to get.

Roland: I almost want to say I’ve never seen that which is obviously a lie. But be consistent when you have your actual final list of SKUs that the client is not confused. So whatever you put in your proposal should match your powerpoint presentations. That should match the experience that they have during the POC, and so on and so forth.

J-M: Well, there we have it. This was a lot of fun.

Roland: It was a pleasure talking with you about POCs and POVs, but before we let you go, dear listeners, we’d like to ask you a couple questions. Send us your feedback What were your experiences with POCs and POVs? Let us know! You can always reach us at our website or email at hello@whatsyourbaseline.com. If you’re watching this on YouTube, you can leave us a comment. And we’re happy to pick this up and give you an answer. And with that, I’m Roland Woldt.

J-M: And I’m J-M Erlendson.

Both, somewhat together: And we will see you in the next one.