Back to resources

Moving On With a Technical Proof of Concept

Collaboration
Productivity

10 May, 2021

Kapil Gupta
Kapil Gupta

Product Leader at Deloitte

Kapil Gupta, Product Leader at Deloitte, elaborates how starting with an intelligent guess, one should move on with a technical proof of concept to avoid the chicken or the egg dilemma of business value validation.

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

Building and Maintaining Company Culture: How to Scale Teams Accordingly

26 May

Elwin Lau, Director of Software at Jana, advocates the importance of maintaining culture within a company when scaling teams.

Mission / Vision / Charter
Scaling Team
Building A Team
Company Culture
Collaboration
Onboarding
Sharing The Vision
Elwin Lau

Elwin Lau

Director of Software at JANA Corporation

Building and Maintaining Company Culture: How to Scale Teams Accordingly

26 May

Elwin Lau, Director of Software at Jana, advocates the importance of maintaining culture within a company when scaling teams.

Mission / Vision / Charter
Scaling Team
Building A Team
Company Culture
Collaboration
Onboarding
Sharing The Vision
Elwin Lau

Elwin Lau

Director of Software at JANA Corporation

Managing Different Time Zones: Inclusive Collaboration Methods

19 May

Jonathan Belcher, Engineering Manager at Curative, shares an unknown side of synchronous communication tools and advises managers on how to handle a team that’s spread across the globe.

Remote
Internal Communication
Collaboration
Cross-Functional Collaboration
Jonathan Belcher

Jonathan Belcher

Engineering Manager - Patient Experience at Curative

Managing Remotely: Balancing Team Cohesion and Focus Time

26 May

Jonathan Belcher, Engineering Manager at Curative, explains how to balance team cohesion and individual focus time, tapping into his experiences of working remotely for seven years.

Remote
Micromanagement
Meetings
Internal Communication
Productivity
Psychological Safety
Performance
Jonathan Belcher

Jonathan Belcher

Engineering Manager - Patient Experience at Curative

Creating a Company Culture That Balances Helpfulness and Productivity

16 May

Alexis Philippe, Vice President, Product & Engineering at Amilla, describes his one simple rule for creating a culture of helpfulness that doesn't disrupt productivity.

Mission / Vision / Charter
Company Culture
Collaboration
Cross-Functional Collaboration
Alexis Philippe

Alexis Philippe

Vice President, Product & Engineering at Amilla

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.