We can all agree with the saying, “practice makes perfect.” Whether you are you learning your ABC’s at a very young age, or practicing free throws, backhands, bunts, or putts for hours before a big competition, practice helps us prepare.
Corrections and modifications bring us closer to achieving our goals and help us recognize failures. Similarly, Proof of Concepts (PoCs) are a good step in the process of achieving your business goal. Companies utilize this process for various reasons, such as gaining a competitive advantage or creating a better customer experience.
In my career, I have found enterprise companies struggle in executing this step-by-step process. I have been tasked with managing and running PoCs for companies many times over and have gained vital insights into how to achieve the stated goal.
What are Proof of Concepts
Wikipedia defines a Proof of Concept “POC” as the realization of a certain method or idea to demonstrate its feasibility, or a demonstration in principle, whose purpose is to verify that some concept or theory has the potential of being used. A proof of concept is usually small and may or may not be complete.
It is important not to blur the lines of PoC, demonstration (demo), and minimal viable product (MVP). An MVP is the minimal execution of a product that is released to customers. A demo or demonstration is just that, an example of a working process. No more, no less. A PoC is one step in the trial and error process that validates or invalidates a process for a given task.
A POC troubled from the start
This year one of my clients, a globally renowned brand, referred BlueFletch to an internal team to help them with a project. The project entailed helping them run a few PoCs. I was excited because the work was right in our wheelhouse. Below is a brief dramatization of our one and only conversation:
- CLIENT: Based on the requirements I sent over for the Green team, we are looking to obtain a better process capturing and reporting on important information. My goal is to define a process for running small, week-long PoCs for internal teams for a strictly defined budget. Is this possible, and how you would technically solve for this?
- BlueFletch: I have reviewed the requirements as well. Has the Green team shared their top priority with you for this project? Have they defined any metrics that would help us prioritize the features described in the requirements to obtain a better process?
- CLIENT: BlueFletch, what is really important is understanding how I can define a repeatable process for running internal PoCs.
- BlueFletch: Ok. So what does success mean to you?
- CLIENT: Can we achieve my goal or not?
- BlueFletch: I’m unclear about the goal. We can definitely work on a process for a week, but how do you know if you are successful or not when you deliver the output of the POC to the Green team?
- CLIENT: Because it will be delivered.
- BlueFletch: What if we do not finish the process in a week?
- CLIENT: Then we will give you more time. My goal is to deliver what we scoped in the requirements to the Green team.
- BlueFletch: That is not a PoC. That is an MVP.
- CLIENT: That is the process I am trying to execute here.
- BlueFletch: (face palm)
The client wanted us to deliver an MVP for a PoC price and timeframe. Even if the scope of the effort was large enough, the fact we could not agree on success from the start is a red flag that is commonly overlooked.
Successfully Manage Proof of Concepts
1. Define Success
In the exchange above, the client wanted to define a process for delivering technology to various internal teams via short PoCs. During the exchange, it was clear that the client was asking BlueFletch to deliver an MVP that was being described to the internal teams as a PoC.
BlueFletch first attempted to work through step one in running a successful PoC by defining the goal. By asking if the team had a primary goal, we could prioritize the requirements that were reviewed. From experience, we knew there was a good chance that we would not fit all of the requirements into such a small time frame. Identifying the priority of requirements together allows us to more efficiently remove requirements from the scope or add to the backlog when necessary.
When the Green team goals were not apparent, BlueFletch tried to find the client’s personal goals. This is not uncommon when working with innovation teams within enterprise companies. For example, the client could have been motivated by comparing multiple technology platforms or device forms factor in order to determine which will be the better fit for the organization.
The ultimate goal of step 1 is defining and agreeing on the definition of success. If success can be distilled down to a yes or no answer, then you are operating in the context of a PoC. E.g., can we save time by improving this process? Is this framework a good choice for our team? Is this the right device form factor?
2. Avoid Common Mistakes of Proof of Concepts
There is an infinite number of ways to poorly run Proof of Concepts. Below are a few progressive mistakes that we commonly encounter:
Defining Broad, Fuzzy Goals
While it is important to spend time defining the goal at the beginning of the PoC process, the goal needs to be very specific. For example, the goal is to measure the impact of providing safety inspectors a tablet application for inspections. What is the impact? Is it reducing inspection times? Is it increased reporting accuracy? Is it to prove that the tablet is a better form factor than a mobile device?
Sounds easy. Just remember this next time you are on a conference call or conference room full of team members with various agendas.
Confusing MVPs and POCs
The interchangeability of POC, demo, and MVP often leads to confusion, however, the responsibility of delivery falls squarely on the technology implementer. In our previous exchange, our Client was promising to deliver an MVP the Green team but wanted BlueFletch to operate in the scope of a Proof of Concept. This creates an unfair limit on BlueFletch’s ability to successfully deliver.
Creating Unfair Limits
The premise of a PoC is to be limiting in order to quickly get to a decision. Often a PoC is short in time frame, narrowly focused on very specific requirements and not meant to be permanent. With so many naturally limiting factors why create more limits that would affect the PoC’s success? It is unfair to the PoC process to demand limitations that are not core to successful delivery.
E.g.
- Integration with complex system(s).
- Need for buy-in from too many teams.
- Implementing multiple new technologies.
Know When Enough is Enough
It is ok for a PoC to miss the mark or not finish. The world is not going to end if the lesson learned was that we had a bad idea or that the proof is not technically feasible. At least it was not a fully funded project that would be pushed to production.
3. Lighten The Load To Make It Across The Finish Line
If a PoC were a running race it would be akin to the 40-yard dash. Not an official sport, but used to determine the speed of National Football League (NFL) prospects. When NFL prospects are timed they do not have on helmets, pads or uniforms. They only have the essentials so that they are able to run their best possible time. Your PoC should be an efficient sprint similar to the 40-yard dash, only focusing on the essential elements that are key to proving the concept’s goal. Do not be afraid to cut scope for the sake of keeping Proof of Concepts on track. Often times keeping extraneous ideas or features in a PoC is enough to sink its chance of success.
4. Understand Proof of Concepts Do Not Always Impress
One of my most memorable Proof of Concepts was surprisingly from a non-profit during a 24-hour hackathon. This local non-profit had a hodge-podge of technical solutions that had been donated over the years. The hackathon was a chance for some well-needed updates and the potential for new functionality.
The event took place in a large conference room with posters on the room walls listing out the pre-determined focus areas of need for the non-profit organization. When I saw the poster titled ‘Mobile Application’, I knew that was the problem my team was going to solve. After reading the requirements, my partner and I geeked out about how impressive, shiny, and slick, this application was going to be. We were definitely going to knock this out of the park.
One of the significant decisions made before this event was to have subject matter experts (SMEs) available to add valuable insight for how the organization would use our solutions. We had a very stylish, established gentlemen as our SME who was involved in the non-profit and would use the solution. We were so excited to pitch our idea and all of the leading-edge features that we were packing into our app, keeping in mind this is a competition, and will we be judged by our solution demo.
After listening patiently, he paused and said, ‘…that sounds great, and you all seem very smart. But no one is going to use it. None of us have a smartphone.’
Huh! Excuse me!?!
That was a very humbling moment, and we had to redefine what success meant very quickly. With our SMEs help, we defined a process that would meet the need of his organization. He agreed that if we could build the technology around the process that it would be well received from his team. In the wee hours of the night, we were able to prove that it was technically possible to replace our shiny smart app with a texted-based solution powered by a cloud service. With a few hours remaining, we had a demo that we could present to a panel of judges. Although we did not win first place, we still placed in the competition, which resulted in us working with the non-profit to turn our demo into an MVP that they could pilot. #Success
To wrap it up
Proof of Concepts do not need an army of people representing a horizontal section of interested groups from within an organization. A POC does not need to take six months to plan, six months to build, and another six months to figure out what happened to the pile of money that was just lit on fire.
A POC does need to involve the right people agreeing to one definition of success, how to measure it, and how long that should take. A POC is an exercise in setting up a target, taking a step back, and firing at the target. Being a good manager of a POC is being successful at sharing the valuable lessons learned and a good steward of the resources needed.
