Posts Tagged ‘“Proof of Concept”’

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.

Prototype

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.

Production

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.