How not to make a "poop"? Personal experience of creating a product
In this post I want to share my personal experience in creating a product from scratch. We have already passed the path “let's fill in / copy and throw into the market”. This approach almost killed our company.
According to statistics, about 50% of the features of the average product are never used and only 12% of options are actively used by customers. How to always get into these 12% of the functional? And what if I myself am not a user of this product? How to make a product simple and convenient? Finally, is it worth it to do our company? And how to understand whether the product will be in demand by the market even before its creation?
I remember this day, as if everything happened just yesterday. On Monday, January 27, 2014, I accidentally stumbled upon the document “How Spotify builds products”. This small manual put 3 previous years of development, dozens of articles and several trainings into a coherent system in the head. The scheme of the whole process from the manual is given in the title of the post.
')
In the shortest lines, we restructured our process and development approaches in accordance with the Spotify methodology. Read more about this here . The second important step, which by the way is not mentioned in this document, is Empathy (in this context, a deep understanding of clients and their problems). Empathy - just what you need to do if you yourself are not a user of the product. At the start, we did not understand anything in that subject area, where we were going to poke.
When everything was ready, we all brainstormed the whole team. We needed ideas, a lot of ideas, a lot of ideas. Each of us represented himself in the role of the buyer, in the role of the administrator, in the role of those. specialist. We invented scenarios and wrote ideas on stickers, and then grouped them along different lines. The result was the following:
As a result, the whole team was already deeply immersed in the subject area at this stage, although only I communicated with live clients.
Our next step was prototyping. We were engaged in this not specifically trained people, and each member of the team. For more convenience, we printed out templates for paper prototyping (see the end of the post) and described 3 standard scenarios: the buyer selects the product and reads reviews from other customers, the store employee moderates reviews, and the technician installs the system on the site.
Then each of us talked about our prototypes, we noted the best solutions and interesting ideas. In the end, for each scenario, we have a prototype of Frankenstein, assembled from the layouts of all the guys. Another half an hour with a pencil and we had the final versions of paper prototypes.
Ideally, one would have to go to the customers with these prototypes and let them play with this material. We decided to skip this step and immediately make a mockup. For these purposes, the Bootstrap theme was bought for $ 20 and in a few hours a pretty Mockup was created.
In a couple of hours, a presentation of a non-existent product with our mocaps was made and sent to several clients. After the questions: “When can I buy?” And “How much does it cost?” - it became clear that at least a living prototype should be done!
In total, we spent about 1.5 months on Empathy and the Think IT stage. This work was carried out in parallel with the company's main activity. I can say with confidence that this time is not wasted. We answered key questions, delved into the subject area, defined a set of functionality for MVP and prepared prototypes, checked the idea itself and found more than 15 beta testers.
Paper prototypes are good, but now they need to be in a form suitable for our developers. We are working on Scrum, so the first thing we needed to do was make a StoryMap from prototypes. To do this, we stuck flipchart sheets on the walls, and on top we stuck our paper prototypes. Then, these prototypes were cut into Targets (blue sheets), targets for tasks (orange sheets), tasks for the simplest implementation (green sheets), and then the simplest implementation were ennobled with features (yellow sheets).
We did this in the team for the first time and many questions arose. If we are doing MVP, is it necessary to make prototypes (and accordingly StoryMap) of the product for growth or is it enough that approximately it will be included in MVP? How much need to detail the Tasks and Features themselves? How does the resulting StoryMap cut into releases, and releases at iteration?
Today, we have started the fourth iteration and the initial views on the questions above have changed a bit:
1. In MVP, we included only those options that:
2. If you look at the photo above, in the first release for clients we included almost all tasks (orange sheets). Our release was very “flat” and stretched wide. In this approach, we saw the following disadvantages:
3. To avoid the risks of clause 2 and as early as possible to give customers an already working product (but not yet MVP), we cut the release wide and slightly increased the “depth”. Yes, in the first user release we will not be able to test all the hypotheses, but the advantages of this approach are much greater!
The scheme of the Build IT step itself is presented below. In fact, over the next 1.5 months, we will approach MVP and open beta test with each iteration. In our case, we are not waiting for the Ship IT stage to launch live users. Our Alpha testers will work with products already at the Build IT stage.
By the way, all the ideas that we sketched at the Think IT stage, I transferred to a separate IdeaLog document. This document presents a .xls file, where the first page contains a list of products / modules (for example: authorization, search, etc.), and the second page contains ideas in the format of JobStory (see useful links). Each idea has its author, date, type (JobStory, Epic, Theme) and which product / module it belongs to. In this form, it is easy to select all the ideas concerning the new product. Or choose new product ideas.
When we implemented Scrum, we significantly increased the speed of development. And we faced a new growth: “What the hell are we doing at such a speed”? This approach allowed converting quantity to quality. We are only at the beginning, but the results are amazing! I hope our experience will help you. I will be glad to questions and personal advice in the comments.
Useful links on the topic:
According to statistics, about 50% of the features of the average product are never used and only 12% of options are actively used by customers. How to always get into these 12% of the functional? And what if I myself am not a user of this product? How to make a product simple and convenient? Finally, is it worth it to do our company? And how to understand whether the product will be in demand by the market even before its creation?
I remember this day, as if everything happened just yesterday. On Monday, January 27, 2014, I accidentally stumbled upon the document “How Spotify builds products”. This small manual put 3 previous years of development, dozens of articles and several trainings into a coherent system in the head. The scheme of the whole process from the manual is given in the title of the post.
')
In the shortest lines, we restructured our process and development approaches in accordance with the Spotify methodology. Read more about this here . The second important step, which by the way is not mentioned in this document, is Empathy (in this context, a deep understanding of clients and their problems). Empathy - just what you need to do if you yourself are not a user of the product. At the start, we did not understand anything in that subject area, where we were going to poke.
And finally, we come to the first step of "Think IT"
- First of all, we answered the following important questions for ourselves: Why are we doing this? What benefits / benefits do we want from this venture? Why are we going to do just that, and not 10 other possible products?
- Next, we formulated key metrics that our product will improve for our customers.
- Also formulated product hypotheses (assumptions that will be tested on real customers). There are two main hypotheses: the hypothesis of the value of the product for the client and the hypothesis of growth (how this product will be distributed).
When everything was ready, we all brainstormed the whole team. We needed ideas, a lot of ideas, a lot of ideas. Each of us represented himself in the role of the buyer, in the role of the administrator, in the role of those. specialist. We invented scenarios and wrote ideas on stickers, and then grouped them along different lines. The result was the following:
As a result, the whole team was already deeply immersed in the subject area at this stage, although only I communicated with live clients.
Our next step was prototyping. We were engaged in this not specifically trained people, and each member of the team. For more convenience, we printed out templates for paper prototyping (see the end of the post) and described 3 standard scenarios: the buyer selects the product and reads reviews from other customers, the store employee moderates reviews, and the technician installs the system on the site.
Then each of us talked about our prototypes, we noted the best solutions and interesting ideas. In the end, for each scenario, we have a prototype of Frankenstein, assembled from the layouts of all the guys. Another half an hour with a pencil and we had the final versions of paper prototypes.
Ideally, one would have to go to the customers with these prototypes and let them play with this material. We decided to skip this step and immediately make a mockup. For these purposes, the Bootstrap theme was bought for $ 20 and in a few hours a pretty Mockup was created.
In a couple of hours, a presentation of a non-existent product with our mocaps was made and sent to several clients. After the questions: “When can I buy?” And “How much does it cost?” - it became clear that at least a living prototype should be done!
In total, we spent about 1.5 months on Empathy and the Think IT stage. This work was carried out in parallel with the company's main activity. I can say with confidence that this time is not wasted. We answered key questions, delved into the subject area, defined a set of functionality for MVP and prepared prototypes, checked the idea itself and found more than 15 beta testers.
Now what? Let's start coding (Build IT)!
Paper prototypes are good, but now they need to be in a form suitable for our developers. We are working on Scrum, so the first thing we needed to do was make a StoryMap from prototypes. To do this, we stuck flipchart sheets on the walls, and on top we stuck our paper prototypes. Then, these prototypes were cut into Targets (blue sheets), targets for tasks (orange sheets), tasks for the simplest implementation (green sheets), and then the simplest implementation were ennobled with features (yellow sheets).
We did this in the team for the first time and many questions arose. If we are doing MVP, is it necessary to make prototypes (and accordingly StoryMap) of the product for growth or is it enough that approximately it will be included in MVP? How much need to detail the Tasks and Features themselves? How does the resulting StoryMap cut into releases, and releases at iteration?
Today, we have started the fourth iteration and the initial views on the questions above have changed a bit:
1. In MVP, we included only those options that:
- Allow to test hypotheses.
- In the necessity of which we are 100% sure (there were cool ideas, but at the current stage it is not clear whether they will work).
- Without which it is simply impossible to use the product and which are not included in claim 1.
2. If you look at the photo above, in the first release for clients we included almost all tasks (orange sheets). Our release was very “flat” and stretched wide. In this approach, we saw the following disadvantages:
- We can provide more opportunities, but they will be terribly inconvenient and limited.
- In an effort to reach the maximum of tasks, we strongly delay the start of using the product by live customers, which means there is a risk to make an option unnecessary for customers.
3. To avoid the risks of clause 2 and as early as possible to give customers an already working product (but not yet MVP), we cut the release wide and slightly increased the “depth”. Yes, in the first user release we will not be able to test all the hypotheses, but the advantages of this approach are much greater!
The scheme of the Build IT step itself is presented below. In fact, over the next 1.5 months, we will approach MVP and open beta test with each iteration. In our case, we are not waiting for the Ship IT stage to launch live users. Our Alpha testers will work with products already at the Build IT stage.
By the way, all the ideas that we sketched at the Think IT stage, I transferred to a separate IdeaLog document. This document presents a .xls file, where the first page contains a list of products / modules (for example: authorization, search, etc.), and the second page contains ideas in the format of JobStory (see useful links). Each idea has its author, date, type (JobStory, Epic, Theme) and which product / module it belongs to. In this form, it is easy to select all the ideas concerning the new product. Or choose new product ideas.
Conclusion
When we implemented Scrum, we significantly increased the speed of development. And we faced a new growth: “What the hell are we doing at such a speed”? This approach allowed converting quantity to quality. We are only at the beginning, but the results are amazing! I hope our experience will help you. I will be glad to questions and personal advice in the comments.
Useful links on the topic:
Source: https://habr.com/ru/post/218507/
All Articles