Getting back to implementation of ideas this post helps to understand the relation between workflow and product roadmap and the planning process of a product roadmap.
Workflow and product roadmap
Let’s continue our journey of delivering a product from an idea. In the previous post we discussed the aim of writing a Concept Document. When the major problems, users and scenarios are identified, we can move on to the next level, where we try to conceptualize the product by describing the possible user workflows and use cases. It requires a more exact definition of roles of the possible users and the activities associated with these roles. We don't ask you to write down all possible use cases in this phase of the project. The most important use cases, those that 90% of users will do with the app, need to be described. Use cases must address the problem(s) identified in the concept document.
Although there are many great tools and methods for writing use cases and creating UML documents, we don't ask clients to learn all these from scratch or be able to do them at a professional level. We asked M and L to choose a tool they prefer to use (can be a pen or a sheet of paper, or any available drawing tool) and write a basic flowchart that describes the possible use cases.
At this point the application will also have a feature list. We asked M and L to collect all features that the application must have, should have and would be nice to have. This can be a long list of features and it will be the basis of prioritizing what to develop first.
Product Roadmap planning
When we have this list, we can start working on the product roadmap document which describes a desired velocity of the development, the main milestones and its scope. For optimal user experience and for an actual proof of concept that our idea is implementable, it is advised to create an early prototype for the core features.
After prototyping, we plan an alpha release for internal testing, a beta release for external (real user) testing, and then the Minimum Viable Product that will actually hit the market. The Minimum Viable Product (MVP) does not mean Minimum Feature Product, it has to be a fully functional product even if it has only one job to do right. The success or failure of the MVP will determine whether further development for a Full Featured Product is possible.
Together with M and L, we sat down and started to prioritize the features. Which needed to be tested in the prototype? What should be included in the alpha and beta releases? And the key question: what are the features that have to be included in the MVP? This is the hardest part, because usually clients want to have them all, otherwise their product seemingly would not be unique and couldn't compete with existing solutions. But what if the client made a few wrong decisions and did not choose the right features? This is where agile software development methodology [we use Scrum] can help startups. Without going into the details in this post, Scrum allows clients to be flexible during development. The time and resources are fixed, but the features might change while reaching MVP.
But we are not developing any product yet, just the roadmap with the milestones. There are many things to do; we are going to discuss what’s next in the next post.
