The term ‘html"}]' tabindex='0' role='link'>minimal viable product’ is a common buzzword these days in the realm of business start-ups and early stage ventures by product managers and developers who are trying to perfect their product offering. The html"}]' tabindex='0' role='link'>Minimal Viable Product (html"}]' tabindex='0' role='link'>Minimum Viable Product) is actually better defined as a process and not necessarily as a product goal in itself.
A Definition of the html"}]' tabindex='0' role='link'>Minimal Viable Product (html"}]' tabindex='0' role='link'>Minimum Viable Product)
The basic definition for the html"}]' tabindex='0' role='link'>Minimum Viable Product includes those features that allow the product to be deployed within the defined html"}]' tabindex='0' role='link'>target audience.
html"}]' tabindex='0' role='link'>Eric Ries, Author of 'The html"}]' tabindex='0' role='link'>Lean Startup'" href="http://en.wikipedia.org/wiki/Eric_Ries" target="_blank">html"}]' tabindex='0' role='link'>Eric Ries, the author of html"}]' tabindex='0' role='link'>Lean Startup - Get the book on Amazon" href="http://www.amazon.com/dp/0307887898?tag=lessolearn01-20&camp=213381&creative=390973&linkCode=as4&creativeASIN=0307887898&adid=004DZWTQ0HQTRCNYZJPD" target="_blank">The html"}]' tabindex='0' role='link'>Lean Startup [see also the JumpStartCTO article on html"}]' tabindex='0' role='link'>Lean Startup" href="http://jumpstartcto.com/the-lean-start-up/" target="_blank">The html"}]' tabindex='0' role='link'>Lean Startup] further explains that “The html"}]' tabindex='0' role='link'>minimum viable product is that version of a new product which allows your team to collect the maximum amount of validated learning about customers with the least effort.” The html"}]' tabindex='0' role='link'>Minimum Viable Product is therefore a process and strategy which start with launching the product at the beginning with “just enough” features and functionality to engage your html"}]' tabindex='0' role='link'>target audience and from there on continuing the product development by collecting the users feedback and enhancing the offering based on that feedback from one cycle to another.
The html"}]' tabindex='0' role='link'>Minimum Viable Product in a CTO’s Product Development Strategy
First and foremost, the ‘html"}]' tabindex='0' role='link'>minimal viable product’ is a product development strategy rather that a software development approach. The html"}]' tabindex='0' role='link'>Minimum Viable Product works well in different scenarios. For example, when not enough is known about the needs of the html"}]' tabindex='0' role='link'>target audience, ‘the html"}]' tabindex='0' role='link'>minimal viable product’ is part of the testing process as it is developed as an initial “bare-bones” version of the product that includes only the most essential features and functionality to be able to engage the users.
How Funding Determines the html"}]' tabindex='0' role='link'>Minimum Viable Product
Funding is another reason for a Chief Technology Officer to work according to the html"}]' tabindex='0' role='link'>Minimum Viable Product approach. This process usually results when a company’s seed investment can only sustain itself at a minimum in the very initial stages of the development. The html"}]' tabindex='0' role='link'>Minimum Viable Product can therefore also be referred to as the ‘proof’ of the concept and the main goal then will be to show html"}]' tabindex='0' role='link'>traction and need for the product offering. Succeeding in that will help to raise more money from investors based on the initial proof of concept conducted.
How the html"}]' tabindex='0' role='link'>Minimum Viable Product determines the Time to Market
The term ‘html"}]' tabindex='0' role='link'>minimal viable product’ suggests that one should cut development time to the minimum needed in order to reach a given html"}]' tabindex='0' role='link'>target audience as early as possible. This is done in order to collect all the needed feedback a company needs to continue with the development process.
How the html"}]' tabindex='0' role='link'>Minimum Viable Product keeps Focus
By establishing the html"}]' tabindex='0' role='link'>Minimum Viable Product as a goal, one’s development strategy is better able to focus on the main core offerings of the product, thereby making it more able to receive feedback from the html"}]' tabindex='0' role='link'>target audience promptly. Adding extra features and more functionality to your product only delays this process, and can always be achieved after the core offering has met the html"}]' tabindex='0' role='link'>target audience’s needs and should not be done beforehand.
The html"}]' tabindex='0' role='link'>Minimum Viable Product from a Technology Perspective
Another perspective why a chief technology officer has a ‘html"}]' tabindex='0' role='link'>minimal viable product’ strategy is because it focuses his processes for developing only what is needed to be developed instead of offering the product as an “out of the box” solution or service. These days, because of tight development deadlines and even tighter budgets, many features and functionalities can be exchanged for SAS (software as a service) or by using existing library codes. The advantages of doing this obvious, because getting a working and almost bug proof code which usually contains more functionality than one needs, creates a danger in trying to offer more features than are needed for your product to engage your html"}]' tabindex='0' role='link'>target audience. Since these features are already included in outside packages, one runs the risk of losing the focus of the offering and hence delays the process as a whole.
Testing the html"}]' tabindex='0' role='link'>Minimal Viable Product
As described in many previous JumpStartCTO posts, testing is an essential key in the performance of different product strategies, and the html"}]' tabindex='0' role='link'>Minimum Viable Product strategy is no exception when it comes to testing. In fact, tests need to be conducted from the early stage sketches of the product, through the versions of rough drafts, and throughout the developing and launching stages. [see User Testing Made Easy] This means that both real users from the defined html"}]' tabindex='0' role='link'>target audience as well as test users need to use the product, while an expert who is knowledgeable in the use of the product and html"}]' tabindex='0' role='link'>usability analyzing methods, collects and records the findings in order to translate them later on into prioritized requirements for further implementation in a given product’s development stages. There are of course several techniques which can be used for collecting the data and many of them have been previously discussed [see How can a CTO help me Test my Product].
