Complaint development
- Transfer
Over the past year, I have written little, because I was busy developing a new tool for conducting discussions . If you, after my investors, want to know why it took a whole year , I should explain how I do the programs, or at least how we did Stack Overflow , Stack Exchange and, now, Discourse :
1. Spend extremely a detailed study of everything related to your subject. Success: what were they wrong? Failures: what did they do right? No one should know more about this topic than you. You must have a meaningful story that you believe in and, more importantly, that others can believe in.
2. Based on the research, put together a team and make a minimally viable product that will do something useful. If you need initial funding, it's time to find it - I hope you have completed all of the steps in step 1 very well and maybe also famous, but ideally also successful, otherwise you're in the ass.
3. Start using this product with the whole team, every day, all day. This is not just development: it is your whole life. If you do not live the developed program every day, all day ... the project inevitably awaits a deplorable outcome. And honestly, if I have to explain this to you, then you know what? You're in the ass.
4. Launch a short-term 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 be useful to me! ” Listen carefully and impartially to all their reviews, 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 slightly less deep ass than you would otherwise. (Business experts call this a “competitive advantage.” Look for information about it.)
5. Quickly move to a public launch. The product will suck, but you will release it anyway.Do not fail the launch itself. You know what I'm talking about, because more than once we saw very miserable launches. Do not be these companies. Do not be these commands. 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 based on the thorough, detailed research you did in step 1? As soon as you introduce them to real, crystal-clear users from the real world, it suddenly turns out that all of them ... were ... completely ... erroneous. Now spend the next year fixing all your stupid failures and mistakes.
7. ???
8. Profit!
I never said that it was a good plan, but you know, it 's still a plan !
Each of these steps is worthy of an article in itself, 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 a not entirely honest advantage, then that Discourse is a discussion program. We post all discourse discourse discussions ... on Discourse itself. But that is precisely why we are developing an open source program for communication - I am firmly convinced that it is important for your business to actually hear customers.
If you have the means to communicate with clients, developing through complaints is not particularly difficult. Before drawing up long-term development plans, deal with quite obvious and easily correctable complaints from users . As Steve Krug said in Do Not Make Me Think :
For example, we launched Discourse with a restriction on the minimum length of the title and body of the message, because we were sure that very short records and especially the headers did not contribute to normal communication. This is also extremely important for us from a philosophical point of view, as it is closely related to our mission of creating programs that help develop meaningful communication on the Internet.
Unfortunately, users hated it:
This was one of the most striking examples of early reviews. So during 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 bonded restrictions on the number of characters in the header and body of the message continued to come. We tried to make these restrictions more understandable by adding a red frame or background to the text input fields:
We set all this and much 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 the browser, in just a few seconds. In the end, I was just tired of complaints about this setting.
We used thermonuclear weapons:error pop-ups right to the right of the field as soon as it lost focus .
From this moment I did not hear a single complaint about our terrible, disgusting, bonded restriction on the number of characters in the text and message header. None. Not a single one. Complaints
These are the things we did every day, every week, for the past year. It took a whole year of development through complaints to make our program usable . And although we are now carefully accepting clients , we are still working on developing complaints every day, perhaps slightly shifting our attention to people paying us money.
Gathering feedback from your community can be extremely hard work.. And 90% of reviews can be terrible for a number of reasons. It is much easier to imagine that some expert hero suddenly bless you with the correct answer. Well, good luck with these fantasies . In my experience, the only working method is to plunge deeply into the dirty work with your users, communicate with them and develop relationships . Only in this way can you identify those 10% of valuable user reviews that really shock and lead to transformations. Only in this way can you build a community that will be truly interested in what you do - really listening to them and making the changes that they need.
Translator 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, a more polite analogue of fuck. Quite polite options like “I have a problem” do not clearly reflect the meaning of the term, the obvious “raped” in Russian necessarily implies the presence of the other side.
Complaint-Driven Development - Coding Horror
1. Spend extremely a detailed study of everything related to your subject. Success: what were they wrong? Failures: what did they do right? No one should know more about this topic than you. You must have a meaningful story that you believe in and, more importantly, that others can believe in.
2. Based on the research, put together a team and make a minimally viable product that will do something useful. If you need initial funding, it's time to find it - I hope you have completed all of the steps in step 1 very well and maybe also famous, but ideally also successful, otherwise you're in the ass.
3. Start using this product with the whole team, every day, all day. This is not just development: it is your whole life. If you do not live the developed program every day, all day ... the project inevitably awaits a deplorable outcome. And honestly, if I have to explain this to you, then you know what? You're in the ass.
4. Launch a short-term 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 be useful to me! ” Listen carefully and impartially to all their reviews, 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 slightly less deep ass than you would otherwise. (Business experts call this a “competitive advantage.” Look for information about it.)
5. Quickly move to a public launch. The product will suck, but you will release it anyway.Do not fail the launch itself. You know what I'm talking about, because more than once we saw very miserable launches. Do not be these companies. Do not be these commands. 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 based on the thorough, detailed research you did in step 1? As soon as you introduce them to real, crystal-clear users from the real world, it suddenly turns out that all of them ... were ... completely ... erroneous. Now spend the next year fixing all your stupid failures and mistakes.
7. ???
8. Profit!
I never said that it was a good plan, but you know, it 's still a plan !
Each of these steps is worthy of an article in itself, 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. There will be ... a lot.
- Identify and correct the three main issues that cause persistent complaints.
- Repeat
We have a not entirely honest advantage, then that Discourse is a discussion program. We post all discourse discourse discussions ... on Discourse itself. But that is precisely why we are developing an open source program for communication - I am firmly convinced that it is important for your business to actually hear customers.
If you have the means to communicate with clients, developing through complaints is not particularly difficult. Before drawing up long-term development plans, deal with quite obvious and easily correctable complaints from users . As Steve Krug said in Do Not Make Me Think :
No need to look for all the problems. In fact, you will never find all the problems, no matter what you test. And still, this 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 crucial to focus on fixing the most serious ones first. And three users are likely to discover many of the most serious problems associated with the tasks you are testing.
For example, we launched Discourse with a restriction on the minimum length of the title and body of the message, because we were sure that very short records and especially the headers did not contribute to normal communication. This is also extremely important for us from a philosophical point of view, as it is closely related to our mission of creating programs that help develop meaningful communication on the Internet.
Unfortunately, users hated it:
What irritates me the most is the fact that nowhere is it shown how many characters need to be entered. It is only visible whether the “Reply” 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 entry consists mainly of spaces. It just pisses me off.
This was one of the most striking examples of early reviews. So during 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 bonded restrictions on the number of characters in the header and body of the message continued to come. We tried to make these restrictions more understandable by adding a red frame or background to the text input fields:
We set all this and much 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 the browser, in just a few seconds. In the end, I was just tired of complaints about this setting.
We used thermonuclear weapons:error pop-ups right to the right of the field as soon as it lost focus .
From this moment I did not hear a single complaint about our terrible, disgusting, bonded restriction on the number of characters in the text and message header. None. Not a single one. Complaints
These are the things we did every day, every week, for the past year. It took a whole year of development through complaints to make our program usable . And although we are now carefully accepting clients , we are still working on developing complaints every day, perhaps slightly shifting our attention to people paying us money.
Gathering feedback from your community can be extremely hard work.. And 90% of reviews can be terrible for a number of reasons. It is much easier to imagine that some expert hero suddenly bless you with the correct answer. Well, good luck with these fantasies . In my experience, the only working method is to plunge deeply into the dirty work with your users, communicate with them and develop relationships . Only in this way can you identify those 10% of valuable user reviews that really shock and lead to transformations. Only in this way can you build a community that will be truly interested in what you do - really listening to them and making the changes that they need.
Translator 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, a more polite analogue of fuck. Quite polite options like “I have a problem” do not clearly reflect the meaning of the term, the obvious “raped” in Russian necessarily implies the presence of the other side.
Complaint-Driven Development - Coding Horror