Moving On With a Technical Proof of Concept
10 May, 2021
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?”
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.
Start doing something. Make an intelligent guess. Even if you happen to be wrong, the sooner you find it out, the better.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
William Bajzek, Director of Engineering at Sapphire Digital, compares and contrasts a team structure that utilized siloed skill sets and one where everybody’s duties overlap at the edges.
Director of Engineering at Sapphire Digital
Neelima Annam, Sr Director Information Technology at Outmatch, shares how something as minor as collaboration tools can be a BIG issue during mergers and acquisitions.
Sr. Director Information Technology at Outmatch HCM
Piyush Dubey, Senior Software Engineer at Microsoft, shares his journey of climbing up the career ladder through awkward times dealing with an introverted manager.
Senior Software Engineer at Microsoft
Piyush Dubey, Senior Software Engineer at Microsoft, shares how to understand the stakeholder communication process better and why it is essential.
Senior Software Engineer at Microsoft
Rajesh Agarwal, VP & Head of Engineering at Syncro, shares how effectively he collaborated with a newly-joined team as a diverse candidate.
VP and Head of Engineering at Syncro
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.