Moving On With a Technical Proof of Concept

Problem

Building a new prototype typically starts with developing a proof of concept that validates both the technical feasibility as well as business value. However, it is not uncommon for people to get entangled in the chicken or the egg dilemma at this stage. Usually, they would be asking themselves, “Do we know enough about technology to build it, or should we establish first that it is worth building?”

Actions taken

To overcome a somewhat paradoxical situation, I propose to start small, especially when we have scarce knowledge of technology and even scarcer understanding if a prototype is worth building. I would scope a proof of concept to be small enough and, therefore, financially a small investment.

Then I would take a leap of faith and start building something working on the proof of concept’s technical aspects. We would do our fair share of experimenting with different solutions and approaches, but we would expect the business to explore the business opportunities in the meantime. With every step we would be taking to make our solution more concrete, the business side should acquire more solid data for their own assessment and verification. Even if not complete, the technical proof of concept should serve as the starting point for any discussion on improvements. You can show it to people and ask for their feedback and suggestions on what they would like to see in your prototype. For example, what features do they think should be there or how they should be built. Having something tangible should also help you encourage the discussion around business opportunities and help you move the needle from “We don’t know” to “We have some knowledge of...”

To better illustrate the process, I would share one of our recent experiences. As a company that works with clients and businesses of different sizes and ownership structures, we wanted to build a new service but were unsure whether the targeted clients would be willing to pay for it. We did a proof of concept on what the tool would look like, which gave us an idea of what kind of technologies we could use. We wanted it to be cloud-based and accessible from everywhere. The idea we had in mind was that a person who would work with a client could sit with them and take them through the analysis.

During the first month, we only received feedback from within the organization. We were repeatedly told, “This is what a client would want to do.” However, once we had some initial mockups, we could go to clients, show them what we were building and seek their feedback. However, you should be careful with expectations because, at this point, you still would not know if you would be building the prototype. I would frame it in a strong conditional tense, “If we would do something like this, what would you like to see in it.”

Gathering feedback from clients is critical since they know best how big the market is, what are their long/short-term needs, how many users they have, etc. Relying on their feedback, we managed to understand better how many clients would be interested in paying for the additional service we were building.

Two months later, our knowledge expanded to include not only the technology side of things but business opportunities too. When you are stuck with a business or technology problem, rather than saying that you don’t know, do anything. Even if that is not the right thing to do, it will get you some reactions. If you don’t have something tangible to come before partners, you will have difficulty getting their feedback.

Lessons learned

Start doing something. Make an intelligent guess. Even if you happen to be wrong, the sooner you find it out, the better.