{"id":12116,"date":"2014-06-27T12:23:55","date_gmt":"2014-06-27T09:23:55","guid":{"rendered":"https:\/\/mozaicworks.com\/?p=7348"},"modified":"2022-02-01T18:03:52","modified_gmt":"2022-02-01T16:03:52","slug":"product-inception-tsm-article","status":"publish","type":"post","link":"https:\/\/mozaicworks.com\/blog\/product-inception-tsm-article","title":{"rendered":"Product Inception – TSM article"},"content":{"rendered":"
The first version of this article was published in Today Software Magazine, no 24<\/a>. Below it is an updated version.\u00a0<\/em>The authors: Adrian Bolboac\u0103<\/a> and Alexandru Bolboac\u0103<\/a><\/em><\/p>\n This is the purpose of this article. We will explain our concept, from a technical perspective, of starting with an idea, finding the core value of the idea and then put it into the hands of users as fast as possible.<\/p>\n In order to start one needs to have a clear idea on what would be the product. Create a simple bullet point list of the concept, the core values of the product and how it could be monetized. But then how could you understand fast if it is useful or not?<\/p>\n We all have ideas, but what if we had a system to put them into practice? The main tool of understanding if your idea can be monetized is by getting feedback from others. First it can be your friends or even your\u00a0family. Then you can start around people at public gatherings, in communities. Wherever you go, pitch your idea to people and write down their likes, concerns, improvement ideas.<\/p>\n Take each item from each person you interacted with and think well if it could be used in order to improve your product. You need to be very open when filtering the suggestions. The product may be your idea, but you are not the sole user.<\/p>\n After this process you will have a structured idea that you can continue with for the next steps.<\/p>\n The concept of Minimum Viable Product (MVP) comes from the world of Lean Startup. It describes minimum necessary of the core business idea that can be put into the market and into the hands of the real users. It needs to be useful, functional and ideally disruptive.<\/p>\n Before dealing into the intricacies of how the product works, you need to start from understanding the users and their needs. For that we usually recommend creating personas.<\/p>\n A persona is a fictional character that will have the characteristics of a real person: name, age, sex, interests, occupation, and so on. And more, the persona will have as many details attached to it\u00a0as needed to understand how it will interact with the new product.<\/p>\n From your initial idea, spiced with the suggestions from your friends, family, and other acquaintances you can have now a better picture on how the main functionalities should look like. These main functionalities are called themes. There should be just a couple of them. The themes should be independent from one another. A theme is like a main functionality of the application.\u00a0 [http:\/\/www.mountaingoatsoftware.com\/blog\/stories-epics-and-themes]<\/p>\n When you understand what are the basic directions of development of your application, you can start splitting these themes in smaller batches. The main purpose of splitting them is that we want to have fast feedback from real users. The smaller the functionality, the faster we can validate it with real users. In this way we can learn about how the users really feel about the proposed solution. An epic should be delivered to the real user in 1-2 weeks.<\/p>\n The epics are again split into several user stories. An user story should be finished, meaning that it could be added to the production environment, in 1-3 days. Usually a user story and an epic are written in the following format \u201cAs a <persona> I would like to <user’s need> so that <some reason\/business value>\u201d.<\/p>\n \u201cAs Charlotte, I would like to be able to easily send my meal preferences to my friends so that they could be able to cook dinner for us before I arrive at their place so that I will enjoy tasty meal\u201d.<\/p>\n Basically Charlotte needs a way to send what she wants to eat in that moment, and knows that her friends are happy to cook anything. This would be an application extremely useful for foodies around the world.<\/p>\n After all the themes are\u00a0split in epics and all the epics are\u00a0split in user stories we need to find a way to prioritize these functionalities. So we need to look on each of the user stories and understand how fast and efficient we could monetize the value represented by the \u201cso that <…>\u201d part of it. For doing that we need to create a scale of estimating business value. We basically need to find a way to create a hierarchy of user stories, with respect to the business value it can bring to the user. Also we need to take into account how easily is this value monetized by the business.<\/p>\n Through mapping what we would like to do is to obtain a map with\u00a0the user stories related with the epics and themes. The top part of the above picture is the generic understanding of the product, presented as themes and\/or epics. The bottom part are user stories which add details to each theme and epic.<\/p>\n This technique is extremely useful to add context for each user story. Each person involved in producing this software will always understand the whys and hows of each user story.<\/p>\n A good option would be to pick a couple of user stories from each of the epics so that you can have faster feedback on each of your ideas.\u00a0 So basically on the story map you would draw a line and everything that is above the line would be developed during the next period (1-2 weeks maybe), and the rest would wait a bit more. The user stories you would want to pick are those that have the highest business value.<\/p>\n Remember that each of the user stories is user focused, because you want to understand how the users would use this product and you want to improve the user’s experience as much as you can.<\/p>\n <\/a><\/p>\n http:\/\/commons.wikimedia.org\/wiki\/File:User_Story_Map_in_Action.png<\/p>\n [David Hussman explaining User Story Mapping https:\/\/vimeo.com\/14499975<\/a> and http:\/\/www.infoq.com\/presentations\/story-mapping<\/a> ]<\/p>\n You do not need to estimate effort. Just start doing the work and record how long\u00a0each user story takes. After a couple of weeks or a month you have data to understand your development speed for this specific product. Use this statistical data to make a forecast on what you can really deliver during the next 3 months. Estimating effort up-front is waste, to say the least, in this stage of the product development.<\/p>\nThe Beginnings<\/h2>\n
How fast could you create a software product starting from an idea?<\/h3>\n
Your idea<\/h3>\n
Feedback, the key ingredient<\/h3>\n
Your structured idea<\/h3>\n
The Minimum Viable Product<\/h2>\n
Personas<\/h3>\n
Themes<\/h3>\n
Epics<\/h3>\n
User Stories<\/h3>\n
Prioritize the business value<\/h3>\n
User Story Mapping<\/h3>\n
Do not estimate effort<\/h3>\n