Develop through complaints
Over the past year, I have written little since I was busy developing a new tool for leading discussions . If you, following my investors, want to know why it took a whole year , I should explain exactly how I am doing the programs, or at least how we did the Stack Overflow , the Stack Exchange and, now, the Discourse :
1. Conduct a very detailed study of everything related to your subject. Successes: where did they go wrong? Failures: what did they do right? No one should know about this topic more than you. You must have a meaningful story in which you believe and, more importantly, in which others can believe.
2. Based on the research, assemble a team and make a minimally viable product that will do something useful. If you need initial financing, it's time to find it - I hope you have done all of the steps in step 1 very well and possibly also famous, and ideally you are successful, otherwise you are in the ass.
')
3. Start using this product with the whole team, every day, all day. This is not just a development: it's your whole life. If you do not live the developed program every day, the whole day ... the project inevitably awaits a deplorable outcome. And frankly, if I have to explain this to you, then you know what? You are in the ass.
4. Start a short closed beta and look at the feedback from your Special Friends from the Internet about the work already done. I know what you think: “Friends! Damn it! I knew that someday they would come in handy to me! ”Listen carefully and unbiasedly to all their comments, no matter how stupid they may be. Find and fix all serious flaws. Your product is still terrible, but a little less terrible than before, and you will be in a bit less deep ass than you would otherwise be. (Business experts call this a “competitive advantage.” Look for information about it.)
5. Quickly go to the public launch. The product will suck, but you still release it. Do not fail the launch itself. You know what I’m talking about, because you’ve seen very poor starts more than once. Do not be these companies. Do not be these teams. Do not worry, you will still have a great opportunity to fail everything in the next step.
6. Hey, remember all those brilliant ideas that you came up with on the basis of a thorough, detailed study you did in step 1? As soon as you introduce them to real, crystal honest users from the real world, it suddenly turns out that all of them ... were ... completely ... erroneous. Now spend the whole next year correcting all your idiotic failures and mistakes.
7. ???
8. Profit!
I never said that it was a good plan, but you know, this is still a plan !
Each of these steps is in itself worthy of an article, but today I will focus on step six, because, in my opinion, this is the most important part of the whole “plan.” I like to call it development through complaints :
We have not quite an honest advantage, then that Discourse is a discussion program. We post all the discussion on the disadvantages of Discourse ... on Discourse itself. But that is why we are developing an open source program for communication - I firmly believe that it is important for your business to actually hear customers.
If you have the means to communicate with customers, developing through complaints is not particularly difficult. Before making multi-year development plans, get involved with quite obvious and easily fixable complaints from users . As Steve Krug said in “ Don't make me think ”:
We, for example, launched Discourse with restrictions on the minimum length of the header and the text of the message, because we were sure that very short recordings and especially headlines did not contribute to normal communication. This is also extremely important for us from a philosophical point of view, since it is closely connected with our mission of building programs that help develop meaningful communication on the Internet.
Unfortunately, users hated him:
It was one of the most prominent examples of early reviews. So within the first 7 days after launch, we quickly added a real-time counter for the required number of characters.
I thought it would help. Did not help. Complaints about our terrible, disgusting and enslaving restrictions on the number of characters in the header and body of the message continued to flow. We tried to make these restrictions more understandable by adding a red frame or background to the text boxes:
We have installed all this and more. Complaints did not stop for a second. Now this was one of the settings and you could change it for your community right in your browser, in just a few seconds. In the end, I'm just tired of complaints about this setting.
We used thermonuclear weapons: pop-up error messages right to the right of the field as soon as it lost focus .
From this point on, I have not heard a single complaint about our horrible, disgusting, enslaving limitation on the number of characters in the text and the message header. None. Not a single one. Complaints.
These are the things we have been doing every day, every week, for the past year. It took a full year of development through complaints to make our program usable . And although we are now taking clients carefully , we are still working on complaints every day, perhaps shifting our attention slightly towards people who pay us money.
Gathering feedback from your community can be extremely hard work . And 90% of reviews can be terrible for a variety of reasons. It is much easier to imagine that some expert hero will suddenly bless you with the right answer. Well, good luck with these fantasies . In my experience, the only working method is to dive deep into the dirty work with your users, communicate with them and develop relationships . This is the only way you can identify those 10% of valuable user reviews that really shake and lead to transformations. This is the only way you can build a community that will really be interested in what you are doing - by really listening to them and making the changes they need.
Translator's Notes:
1. Development through complaints - in the original complaint driven development is similar to test-driven development
2. In the ass - in the original you are screwed, more polite analogue fuck. Quite polite options like “I have problems” clearly do not reflect the meaning of the term, the obvious “raped” in the Russian language necessarily implies the presence of another side.
Complaint-Driven Development - Coding Horror
1. Conduct a very detailed study of everything related to your subject. Successes: where did they go wrong? Failures: what did they do right? No one should know about this topic more than you. You must have a meaningful story in which you believe and, more importantly, in which others can believe.
2. Based on the research, assemble a team and make a minimally viable product that will do something useful. If you need initial financing, it's time to find it - I hope you have done all of the steps in step 1 very well and possibly also famous, and ideally you are successful, otherwise you are in the ass.
')
3. Start using this product with the whole team, every day, all day. This is not just a development: it's your whole life. If you do not live the developed program every day, the whole day ... the project inevitably awaits a deplorable outcome. And frankly, if I have to explain this to you, then you know what? You are in the ass.
4. Start a short closed beta and look at the feedback from your Special Friends from the Internet about the work already done. I know what you think: “Friends! Damn it! I knew that someday they would come in handy to me! ”Listen carefully and unbiasedly to all their comments, no matter how stupid they may be. Find and fix all serious flaws. Your product is still terrible, but a little less terrible than before, and you will be in a bit less deep ass than you would otherwise be. (Business experts call this a “competitive advantage.” Look for information about it.)
5. Quickly go to the public launch. The product will suck, but you still release it. Do not fail the launch itself. You know what I’m talking about, because you’ve seen very poor starts more than once. Do not be these companies. Do not be these teams. Do not worry, you will still have a great opportunity to fail everything in the next step.
6. Hey, remember all those brilliant ideas that you came up with on the basis of a thorough, detailed study you did in step 1? As soon as you introduce them to real, crystal honest users from the real world, it suddenly turns out that all of them ... were ... completely ... erroneous. Now spend the whole next year correcting all your idiotic failures and mistakes.
7. ???
8. Profit!
I never said that it was a good plan, but you know, this is still a plan !
Each of these steps is in itself worthy of an article, but today I will focus on step six, because, in my opinion, this is the most important part of the whole “plan.” I like to call it development through complaints :
- Submit your program to as many real users as possible.
- Listen to all complaints. They will be ... a lot.
- Identify and correct the three main problems that cause persistent complaints.
- Repeat
We have not quite an honest advantage, then that Discourse is a discussion program. We post all the discussion on the disadvantages of Discourse ... on Discourse itself. But that is why we are developing an open source program for communication - I firmly believe that it is important for your business to actually hear customers.
If you have the means to communicate with customers, developing through complaints is not particularly difficult. Before making multi-year development plans, get involved with quite obvious and easily fixable complaints from users . As Steve Krug said in “ Don't make me think ”:
No need to look for all the problems. In fact, you will never find all the problems, whatever you are testing. Still, it will not help you for the following reason:In half a day you can find more problems than you can fix in a month.
You will always find more problems than you can fix, so it is imperative that you first focus on correcting the most serious ones. And the three users are likely to discover many of the most serious problems associated with the tasks you are testing.
We, for example, launched Discourse with restrictions on the minimum length of the header and the text of the message, because we were sure that very short recordings and especially headlines did not contribute to normal communication. This is also extremely important for us from a philosophical point of view, since it is closely connected with our mission of building programs that help develop meaningful communication on the Internet.
Unfortunately, users hated him:
I am most annoyed by the fact that nowhere is shown how many characters must be entered. You can only see if the “Answer” button is turned off or not, and not all users at all understand that it is turned off. And even after that, it may not work if your record consists mainly of spaces. It just pisses me off.
It was one of the most prominent examples of early reviews. So within the first 7 days after launch, we quickly added a real-time counter for the required number of characters.
I thought it would help. Did not help. Complaints about our terrible, disgusting and enslaving restrictions on the number of characters in the header and body of the message continued to flow. We tried to make these restrictions more understandable by adding a red frame or background to the text boxes:
We have installed all this and more. Complaints did not stop for a second. Now this was one of the settings and you could change it for your community right in your browser, in just a few seconds. In the end, I'm just tired of complaints about this setting.
We used thermonuclear weapons: pop-up error messages right to the right of the field as soon as it lost focus .
From this point on, I have not heard a single complaint about our horrible, disgusting, enslaving limitation on the number of characters in the text and the message header. None. Not a single one. Complaints.
These are the things we have been doing every day, every week, for the past year. It took a full year of development through complaints to make our program usable . And although we are now taking clients carefully , we are still working on complaints every day, perhaps shifting our attention slightly towards people who pay us money.
Gathering feedback from your community can be extremely hard work . And 90% of reviews can be terrible for a variety of reasons. It is much easier to imagine that some expert hero will suddenly bless you with the right answer. Well, good luck with these fantasies . In my experience, the only working method is to dive deep into the dirty work with your users, communicate with them and develop relationships . This is the only way you can identify those 10% of valuable user reviews that really shake and lead to transformations. This is the only way you can build a community that will really be interested in what you are doing - by really listening to them and making the changes they need.
Translator's Notes:
1. Development through complaints - in the original complaint driven development is similar to test-driven development
2. In the ass - in the original you are screwed, more polite analogue fuck. Quite polite options like “I have problems” clearly do not reflect the meaning of the term, the obvious “raped” in the Russian language necessarily implies the presence of another side.
Complaint-Driven Development - Coding Horror
Source: https://habr.com/ru/post/223165/
All Articles