The first version of this article was published in Today Software Magazine, no 24. Below it is an updated version. The authors: Adrian Bolboacă and Alexandru Bolboacă
The Beginnings
How fast could you create a software product starting from an idea?
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.
Your idea
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?
Feedback, the key ingredient
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 family. 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.
Your structured idea
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.
After this process you will have a structured idea that you can continue with for the next steps.
The Minimum Viable Product
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.
Personas
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.
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 as needed to understand how it will interact with the new product.
Themes
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. [http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes]
Epics
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.
User Stories
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 “As a <persona> I would like to <user’s need> so that <some reason/business value>”.
“As 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”.
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.
Prioritize the business value
After all the themes are split in epics and all the epics are split 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 “so that <…>” 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.
User Story Mapping
Through mapping what we would like to do is to obtain a map with the 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.
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.
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. 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.
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.
http://commons.wikimedia.org/wiki/File:User_Story_Map_in_Action.png
[David Hussman explaining User Story Mapping https://vimeo.com/14499975 and http://www.infoq.com/presentations/story-mapping ]
Do not estimate effort
You do not need to estimate effort. Just start doing the work and record how long each 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.
[Vasco Duarte on #NoEstimates https://www.youtube.com/watch?v=0SD7Qk4ffPw]
Identify the financial effort willing to take
You need to balance how much it costs to product this first increment and what is your budget. You want to deliver the first increment as fast as you can because you might be able to get revenue very fast, if your idea is good.
Deliver the first increment
You need to deliver as fast as you can. This means days or weeks. Do not wait to make the things nice and perfect. Just deliver! Get feedback! If you developed less, it is easier to modify. You want to have the simplest increment possible delivered.
Get feedback on first increment
With this increment you can ask your friends, family, acquaintances. You can also go to user groups, investors and show them your idea. You have something to show. This shows to people that you really are committed to improving this product, and this helps a lot to have valuable improvement feedback for your product.
Pivot
You want to stick to the idea “fail fast, fail cheap” from Lean Startup. If the first increment does not have good feedback you can either improve it or just stop. Pivoting means changing the development path towards requirements that the users really want, need and would pay for. You might need to pivot several times until you find the good path.
Deliver the MVP
Once you understood where you need to go with the first product increment, deliver it to real users. Put it on the market as fast as you can and get feedback from the world. Think big, think globally. Try to market the MVP everywhere you go. Invest into presenting your MVP and keep your system open to any improvement feedback. This feedback from real users is so valuable that it might define the life of this product: a success or a failure.
The money
Monetize your effort
If your first MVP starts being used, it means you can start earning money. Probably not a lot, but it is enough. It is a sign that your product brings real value to real users. It means you are probably on a good path. Starting earning money means that you can reinvest it in further development. Also it means that the development team has a boost in morale: the product they are building is useful.
On the other hand, if you cannot monetize the effort you might want to continue marketing it and adding features, or you might want to pivot to some other direction from where you are.
Get feedback on the MVP
But this does not mean you do not need to improve the MVP. You always need to get feedback from users and to understand if you cannot bring even more value to your real users.
Pivot
If you fail fast you can understand that you need to change the direction of where the product is heading to. Pivoting is always a challenge and you get used to it while doing it more and more often.
Pivoting does not mean one failed, it means that one learned about the real needs of the users. And this is the best thing you can do: understand the users and their needs as fast as possible. During this process of understanding the users you might have a pretty good idea on the direction you need to pivot.
The product
As we described in this article, this is a way of developing an idea into a product that can be monetized. It might seem simple, but it is not. You need to be open to change and understand failure not as a bad thing, but as a real life fact from where one can learn so much.
This is how you can start product inception. We would be happy to guide through this process so we will be happy to answer to any questions or remarks.
