Proof Of Concept: What Your Product Should Look Like

When we start working with a new client we often hear quite fair questions:

  • How you usually engineer a product from the scratch?
  • How you manage risks?
  • How you collaborate with the product management team on customer’s side?..
This is indeed important questions to clarify with vendor prior to signing an agreement. And indeed software product engineering is a huge risk from many perspectives: technology, funding, revenue model, user adoption etc. And we know the simple answer to this set of questions – Proof Of Concept (or POC).

Proof of concept is a functional prototype of a product that helps you answering those important questions above. We develop POC in very tight collaboration with the client trying to capture most important but uncertain pieces, which will be validated with help of the POC. In fact POC is not always to cover exactly this set of questions. POC has it’s own lifecycle and on different stages it solves different problems and performs different functions:

  • Address technological risks. There’s not so many venture capital funds or other players these days ready to fund technological risks. Usually they want it all to be resolved by the moment you knock their door. This sort of prototypes may look indeed ugly, it can be just a bunch of SHELL/PERL/SQL scripts that never resembles a product. But that is a true fast way to determine if you algorithms will work, if computational capacities of a regular data center will be hypothetically enough, if the main product function is possible to perform overall.
  • Build a biz dev tool. This is now something else. This is zero approximation of a product, not just scripts. You can see it, you can click it, you can get some actual action out of it. This is the tool you can use for fund raising, recruiting rock stars to your team, going to potential partners with it and many more things.
  • Perform user testing. The POC at some point gives you an ability to go in front of your future users (first of all friends and family, focus groups etc) and validate product features.
The big picture of POC lifecycle in context of product development looks as the following:
004_blog_proof_of_concept_what_your_product_should_look_like_3_31_2009.png

Proof of concept is also used to validate/elaborate a new feature if it requires validation of technological feasibility or user testing or else. The difference between POC on initial stage of a product and the feature POC is that feature POC usually exploits codebase of the existent product while initial POC is really designed from the scratch. But this is not always. There may not be intersection between main product codebase and the feature POC at all. Here’s real example we had to deal with on one of the projects: the main system was supposed to help users interface with multiple different web sites thru one single site – typical user data entered once and then system takes care of dispatching it to every target web site without bothering the user. But there were web sites that didn’t provide suitable interface the system could employ and thus the decision has been made to design a Proof of Concept of a web browser add-on that would load the actual target web site in the browser and literally guide the user thru flows pointing him to different fields, providing hints and so on. To prove the idea it was quite enough to design a POC only for Mozilla FireFox. No code of the main system was used because POC was using hardcoded data to work with only one web site chosen for the experiment. We didn’t even connect to server to get the user data and thus hardcoded it inside the add-on code – connecting to web server from within an add-on is fact known for certainty and doesn’t need to be tested. Job was done and entire feature feasibility had been proved.

Finally, POC has one more useful function – sometimes it helps you realize that the feature or entire product is just impossible to build. And since POC (if planned and designed right) doesn’t cost too much, it is a good method to understand that the idea ain’t viable and that the best thing to do is to throw it away and save the budget.

Comments

Not to be published