In ahtml"}]' tabindex='0' role='link'>Minimal Viable Product (html"}]' tabindex='0' role='link'>Minimum Viable Product)?" href="http://jumpstartcto.com/what-is-a-minimal-viable-product-Minimum Viable Product/"> previous post we established a working definition of the html"}]' tabindex='0' role='link'>Minimal Viable Product (html"}]' tabindex='0' role='link'>Minimum Viable Product) and argued that it is more a process within one’s product development strategy that is supported in different scenarios, than it is a definition of a goal in itself.
In this post is meant to extend the discussion of development processes that determine the html"}]' tabindex='0' role='link'>Minimum Viable Product into areas of what functionality to include, as well as what to exclude, when designing your product’s offering.
Understanding Your html"}]' tabindex='0' role='link'>Target Audience
The process of defining your product always starts by understanding who exactly your html"}]' tabindex='0' role='link'>target audience is. While there may, in fact, be several groups of audiences with different needs, your goal from the html"}]' tabindex='0' role='link'>Minimum Viable Product perspective will be to define which group you are going to primarily focus your efforts upon, and likewise which groups can be excluded or ignored at this stage of the product’s development.
Understanding your main audience’s needs can be imagined when you start by first telling a story of all the ways your html"}]' tabindex='0' role='link'>target audience will use the product. For example, ask yourself: What are the most common use cases that will be conducted by my html"}]' tabindex='0' role='link'>target audience? By doing this you will be better able to gather a list of all the requirements needed for the product.
Prioritizing requirements
While gathering this data about requirements, you will also need to prioritize them according to their importance, as this will help you later to determine what should be part of your html"}]' tabindex='0' role='link'>Minimum Viable Product and what should wait and instead be developed in the later stages.
By the end of this process you should have a list of the most important requirements which represents your html"}]' tabindex='0' role='link'>target audience’s needs and you should also be able to answer questions about the most common or important use cases that best represent your product’s value proposition. This involves an iterative process which will take some repetitive cycles in order to get to the list of the most important requirements to fit with your html"}]' tabindex='0' role='link'>Minimum Viable Product.
Testing Your Assumptions
It then becomes important to begin testing your product assumptions at this stage. Start by interviewing potential users and trying to describe the product and its use cases. Any feedback received at this stage will help to support your assumptions and aid you in determining your priorities while, in turn, adjusting others that are also impacted by the received feedback.
From Requirements to Functionality
The next stage will be to translate the requirements gathered into a model of product functionality. It helps to draw wire frames that describe your product. While drawing the wires, make sure the more important requirements are reflected correctly by their relations. And again, while you are drawing the wires, you also have the opportunity to reduce parts of the functionality of the product, enabling you to define what areas are not as important as others. Then test it again with your html"}]' tabindex='0' role='link'>target audience to receive feedback from them which will also help you refine the wires.
Iterative process
As mentioned above, the process described is an iterative process meant to refine the html"}]' tabindex='0' role='link'>Minimum Viable Product. While gathering the necessary requirements of your product, this process of iteration will help you prioritize your product’s requirements based first on importance. Second, this process will also help you focus on the core offering of your product. Once you have translated these requirements into a functionality model and have drawn the wire frames between them, the repeating of the iteration process will eventually help in clearing some of the wires by enhancing the core functionality of your product, in turn refining again the html"}]' tabindex='0' role='link'>Minimum Viable Product by removing less important features
There are of course other considerations to keep in mind. Some are described in previous post, like funding and technologies used, all of which also contribute to the decision process that happens when one defines the html"}]' tabindex='0' role='link'>Minimum Viable Product.
