How fast could you create a software product starting from an idea? This is the purpose of this article. We will explain our concept 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.
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 if it is useful or not?
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 of all, your friends and 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.
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 these ideas. This 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 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.
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 all the characteristics of a real person: name, age, sex, interests, occupation, and so on. And more, the persona will have as many details as needed to understand how it will interact with the new product.
From your initial idea, spiced with the suggestions from your friends, family, and other acquaintances you can have an idea 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.
When you understand what the basic directions of development of your application are, 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 application. An epic should be delivered in 1-2 weeks to the real user.
These epics are again split into several user stories. A 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
"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".
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 extremely useful application for foodies around the world.
After all the themes were split in epics and all the epics were 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 efficiently 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 this value is monetized by the business.
What we would like to do is to map these user stories 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 is the 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 can1.
You do not need to estimate effort. Just start doing the work and record how much each user story takes you and your team. 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 development2.
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.
As fast as you can, you need to deliver. 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.
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.
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.
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.
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.
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.
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.
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 you through this process, so we will be happy to answer to any questions or remarks.
by Cristian Pup
by Alin Luncan
by Corina Pip
