Moving On With a Technical Proof of Concept
10 May, 2021
null null
null at Capital One
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.
Discover Plato
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Related stories
10 December
Supporting principles on why being data led (not driven) helps with the story telling.
Vikash Chhaganlal
Head of Engineering at Xero
28 November
The impact you can have with a Growth Mindset' and the factors involved in driving orchestrated change.
Vikash Chhaganlal
Head of Engineering at Xero
30 November
When you grow fast, its normal to focus on Value delivery aka "Feature Releases". Too many releases too soon will inevitably lead to piling tech debts and before you know, inefficiencies creep in, performances goes down, and ultimately any new release takes too long. Sounds familiar? Then read on..

Ramkumar Sundarakalatharan
VP - Engineering at ITILITE Technologies
25 October
Mrunal Kapade, an Engineering leader, based in Silicon Valley, shares tips that helped reduce attrition in the remote engineering teams while leading multiple teams from startups to Fortune 500 companies.

Mrunal Kapade
Director of Engineering at Inspire Energy
14 October
Teams have tremendous impact on the products on they build. T.E.A.M definition - Together Everybody Achieves More is true. A collaborative and empowered team builds great product versus the good ones.

Praveen Cheruvu
Senior Software Engineering Manager at Anaplan