We talked about business model validation and business development of B2B technology startups extensively before. They are pill sized articles so we will not repeat ourselves.
In this article, we will dig into the PoC (proof of concept) project from a startup’s point of view.
The PoC project is an object that we hold dear to our heart. Could be why we called our next service iteration “PoC labs”. We see that for startups which have just built their prototype and are ready to clock in some real customer experience, PoC projects are all they do. Seems simple but most PoC engagements are still born.
Below is a summary table of what to focus on and what to avoid. Under the table you can find brief explanations for each bullet.
Before Starting the PoC Project
Design and Experiment
A PoC is not the MVP. It’s the real-world application of the MVP and more. You are testing everything, the problem, your initial message to potential customers, who is the user, decision maker and buyer within the organization etc. So, the process itself is an experiment. You should aim to get paid for the PoC engagement for sure, but validating risky assumption about your business should always be the top priority. If you are not sure about how to design an experiment, below are some useful links:
WARNING
The experiment is not about the product, it’s about the business. So don’t focus on the capabilities of your MVP or prototype so much and strive for validating your assumptions
Target the Right Customer
Assuming you have designed the experiment, you know exactly the attributes of the ideal customer. The experiment would become invalid if the customer that you work with doesn’t fit the bill. Yes, you have better chances of winning a PoC project at your prior company, your friend’s company or some company some mentor has connections in, but if that company is not the right company, you will just lose valuable time and energy.
WARNING
Avoid whales. Those extremely cool looking, very valuable, highly risk averse, slow companies with freakishly long stamina and all the time in the world. They would have looked good in your credentials page, only if you had survived the never ending PoC engagement. While PoC projects are perfect for your customers to de-risk innovation, some companies won’t change. This doesn’t mean all large companies are whales though. But all slow and highly bureaucratic, too focused on optimizing their core business companies are.
During the PoC Project
Agree on Scope & Objectives 100%
Both you and your customer should realize that the PoC project will not solve all the problems there is. The project outcome will not immediately replace any production systems. The PoC engagement is to prove that the solution works and performs as expected and calls for further investment in the approach. So the scope should be limited (a sample of real life scenarios) and objectives should be meaningful and crystal clear. It’s the startup’s responsibility to make it so
WARNING
It may be tempting to jump into what you plan on achieving before really understanding the problem that your customer is facing. But that would be fatally flawed. You need to work with them to iterate your solution to their problem and then work on defining scope and objective that best demonstrate a prospective problem solution fit.
Define Success Criteria & Metrics
You should go into the PoC engagement knowing what success looks like from your customer’s point of view and how you or them or ideally both can measure it using quantifiable metrics. Like everything else about the PoC process, there should be mutual understanding on success definition. You don’t want to be in a position to debate the merits of PoC results after it ends using qualitative indicators.
Bonus tip: Agree on the actions after a PoC (contract, investment etc.) conditionally pending measurable PoC results.
WARNING
Do not overpromise and underdeliver. Be very candid about your and your solution’s capabilities from the very beginning and set realistic expectations. The work that goes into the PoC engagement should be predictable and manageable. The results should be the only variables.
Communicate and Document Everything
Ideally there is already a plan in place for the duration of the PoC engagement. Of course there will be deviations from the plan, however the plan still allows you to visualize weekly or bi-weekly sprints. It is the startup’s responsibility to track the progress and send frequent updates to stakeholders. A major part of these updates should be any risks or delays and when/how/to whom these are communicated. There are 2 benefits of communication and documenting. First is you can protect your ground where there are unforeseen events that risk the completion of the engagement. Also, you have some record to look can to when the engagement ends.
WARNING
Don’t turn communication and documentation into a non-value-added administrative task. Make sure you review and learn from each update. The plan will change as you go. Unless you learn from these updates you can’t make or suggest the required iteration and stay on top of the engagement.
After the PoC Project
Run Postmortem(s)
There are 2 levels of postmortem we are talking about here. The first one is about the singular PoC engagement that you have just completed. The second is about the portfolio of PoC’s you have completed during your journey to validate product market fit. The typical agenda items for the postmortems are what went right, what went wrong, what did we learn, what can be improve. Pivot or persevere is also a key question for postmortems.
Maybe the most crucial outcome of these postmortems is assessing whether you are closing in on product market fit and if so what the product should be. This will be the topic for the remainder of this article.
WARNING
Do not rely solely on your own data and insight. Self-assessment can have biases that could steer you in the wrong direction. You can validate things without sufficient proof. Always ask for feedback and data from outside your startups.
Shifting from PSF to PMF
The whole purpose of PoC engagements at problem solution fit stage is to collect enough evidence that the startup has found a scalable product concept which has the potential of being repeatedly marketed and sold to a target customer segment. So, this is the time to define the product.
Let’s imagine:
- Once you have a product, you are selling a standardized value proposition and feature set to your customers instead of custom-tailored solutions.
- Once you have a product, you can skip the PoC and sell directly. You don’t consider whether to pivot or persevere after each customer meeting.
- Once you have a product, you know and can calculate the ROI of your solution even better than the customers.
- So having a product is much more than clocking additional development hours. It starts with understanding what to develop. Once you have enough PoC’s under your belt, patterns and clusters appear. These are where your future product 1.0 may lie.
A few things to understand and validate during your PoC’s are:
- What are the features and functionalities that are most frequently requested and valued?
- What are the marketing and business development steps which work most frequently for targeted customer segments?
- What are the success metrics which are most frequently used and what are the expectations?
- How can you build scalability to your solution for bigger jobs and more customers?
- What are the security and compliance expectations of your customers?
- If you have documented your PoC engagements and ran postmortems after each engagement individually and collectively, you already have the answers. Ideally your MVP has transformed into product 1.0 even without you realizing.
Now it’s time to validate product market fit.