Archive for the ‘Product’ Category

One compromise at a time from proof of concept to prototype to production

Thursday, February 11th, 2010

I constantly run across entrepreneurs that have some good and some great ideas.  These concepts are vetted at a high level or have full detail specs. The entrepreneur has an in house or outsourced team building or ready to build the product.  They are looking at a high cost and lengthy implementation time line to build out their full product.

Whether the startup is bootstrapped or seed funded the founder(s) must do something that most are unwilling to do – Compromise!  Why?  Simply put, they need to take it one step at a time but each step requires compromises.  These compromises should reduce over time but the key to remember is that there are two primary drivers for these compromises:

  • Time to Market (TTM)
  • Cost

The above two factors should dictate the compromises made to build the the three main phases of the product:

  • Proof Of Concept (PoC)
  • Prototype
  • Production

Proof of Concept

This phase should focus on the core concept with many compromises and its goal is to prove that you can build the technology that delivers your idea.  In my opinion, look and feel of the user interface should not be a focus but if it applies- design should.  This phase should cost the least amount and should have the quickest turnaround.  Again the goal is to prove you can build it.  This is a true ‘”alpha” version of your product.


This phase should focus on extending the PoC so you can gauge traction of your idea.  Your focus should be User Experience Design (UED) and implementing some of the higher priority compromises made in the PoC phase to prove viability of the idea.  This will cost more than the PoC phase but TTM should remain aggressive.  You may also call this your “beta” version of your product.


This phase focuses on growth and metrics.  The prototype should be taken to the next level where you implement the remaining high priority compromises made and bring the User Interface (UI) to a close to finished look.  This is where some more compromises have to be made as you have to apply the Pareto Principle (80/20 rule) on past compromised functionality/features otherwise you will TTM for Live to Site (LTS) will be astronomical.  This phase will be your longest as far as TTM and your costliest but at this point you should have vetted out enough of the product to feel confident you can fully take it to market.

Pareto Principle

I believe this principle should be a mantra for startups for not just initial product phases but also projects post production version LTS.  I recall working on projects where the “nice to have” portions or the UI took up most of the implementation time line.  Applying the Pareto Principle and making compromises would have reduced the TTM for those projects to assess their value.  I am a firm believer that you build the base feature set that can prove viability by garnering meaningful traction by your customers.  If the base set show Return on Investment (ROI) or meaningful traction then you have the ability to phase in your remaining compromises.  In my opinion, for startups even projects should at least go through a prototype phase before they reach full production phase.

Product Consistency

Saturday, June 21st, 2008

I was at The Continental in Mid-Town Philadelphia on Friday night and ordered a Martini on the rocks.  When I ordered it at the downstairs bar, it was put in a 6 oz glass and I was fairly disappointed with what I received for the price point.  Heading to the upstairs bar, I ordered the same drink again and got the same 6oz glass but this time I got a shaker with more in it.  The product inconsistency spoke volumes to me about the training of the staff at The Continental.  Product Consistency is a theme that Restaurants live and die by and go in circles trying to achieve.  From pouring a drink to food cooking and from taking an order to serving the food- it all comes down to being consistent with what management wants.


Product Consistency is not something that just the hospitality industry struggles with, it is prevalent in almost every industry.  In the technology arena, the goal is to get consistency in coding style, naming conventions, code quality and performance.  Inconsistency will cause site crashes, poor performance and constant refactoring (rewriting) of code.  This may or may not impact a product like it does in the hospitality industry but it certainly can be counter-productive.  In the product management and user interface design world, the goal is to be consistent in design, interface, usability and functionality.  Dr. Michael Maddox, a senior scientist at HumanCentric Technologies, simply put it as- ‘If you can’t get it right, at least be consistent.’.  You can read his opinion here.  There is a fine line with regards to consistency as pointed out here.  While I agree with the argument, I believe the title is misleading.  Consistency in a product or design does not necessarily mean you want to conform with others (though it may make sense in some cases).  I believe consistency within your product offering that is more important.

cjjouhal’s twitter