Thoughts on bringing something new to life.
I like the idea of seeing prototyping as a generic tool for bringing ideas into reality, and turning them into product.
Regarding software, I consider a product to be a single instance of an application environment (you will need to define exactly where the application environment boundary lies for your particular software product).
For it is the application environment, after all, that goes on to service the consumer.
Prototyping is characterised by small, rapid, and iterative cycles of Plan-Do-Check-Act (PDCA). It personifies the “start small, think big, fail fast” start-up mentality, which is key to the success of most high-value, disruptive innovation & creativity.
Here are some common developmental stages / phases I have observed innovative companies move their products through, in order to reach product maturity:
Prototype –> PoC –> MVP –> Alpha release –> Beta release –> Wide release
| Stage / Phase | Characterised By |
| Prototype | A single, rapid loop iteration; used throughout. |
| Proof-of-Concept (PoC) | Demonstrates a hypothisis is true / feasible in reality. |
| Minimum Viable Product (MVP) | The smallest unit of value delivery, shippable to the product consumer. |
| Alpha release | Internal, small scale production. |
| Beta release | External, small scale production. |
| Wide/full release | Large scale production; towards meeting total demand. |
Componets of the term ‘scale’ as it is used here:
Scale = # product instances (e.g. unique application evironments) x speed/frequence of deployment
When it comes to application environments, in contrast to hardware products, a deployment or delivery can be a brand new instance OR it could just be the updating of an existing instance (e.g. replacing some sub parts or components built from newer code).
Software’s ‘bits’ are, it seems, easier to re-arrange than hardware’s ‘atoms’.
Product maturity can also be characterised as the movement from scarcity of a product, to having that product in abundance. In this way the product is able to balance supply against the total demand that exists (assumes people want or need the product).
In addtion, I find the concept of using prototyping-as-a-tool, when it comes to introducing new product functionality, does align well with both the Agile (i.e. easy to change/adapt) and DevOps (i.e. you build it, you run it) movements.
Dev-Doc-Ops 