April 27, 2015 at 06:06Getting Real Principles (Part 2)
In the first part of the article, we touched on the first 25 principles described in Getting Real by 37signals. The book is very concentrated, and contains the entire set of recommendations necessary for the successful launch of a small team. So I had to put everything in two articles. We continue.
When we write twice as much code, this does not mean that the program will become twice as complicated. The complexity of the program is growing exponentially. How to save a small amount of code? —Lighter functions, less code, less waste. Reformulate a task that requires a lot of code, so that you can solve 80% of the requirements, spending 20% of the effort. This is a very big win.
37signals find solutions to simple problems. Instead of developing products that do more, they develop products that do less.
Encourage counter-offers from programmers. Let them tell you what is wrong and how to do it differently: faster and better. The ideal phrase of the programmer: “If you do it the way you suggest, it will take 12 hours. But I can do it in an hour. Then the program will do X, but will not do Y. Let the programmers defend their point of view on how to write the program better.
Remember: no code is more flexible than no code.
A happy programmer is a productive programmer. Choose tools based not only on standards and performance, but also on whether the tool gives programmatic happiness. For example, if you chose birt for reporting , be prepared that there will never be happiness. See if passion, pride and skill are felt in the instrument? Small details of the current work should bring joy. 37Signals found software happiness in the Ruby language and created the Rails framework.
Your code will resist inelegant decisions. Perhaps he will tell you that there is an easier way to solve it. Choose a feature that's easy to do. It may not be exactly what you imagined it at the beginning, but if it works well enough and leaves time for other things, leave it alone.
Wrote a block of code that works but is messy? - This is a duty.
Sketched the design on the principle of "and it will do"? “This is another duty.”
Actually, this is a normal approach when you make a product by a certain date to make users happy. But debts need to be closed, so regularly take time to pay off your accumulated debts. Otherwise, you will accumulate tons of crutch code, which will be very difficult to parse. You do not remember how and why it works like that?
So you make life easier for everyone. Give people the ability to share data with your product. The API will allow many developers to extend the functionality of your product. Do not underestimate the contribution that other developers can make to your product.
These are just words on paper. Instead of specifying, it’s better to write a short story in one page. Describe what the application should do. Write in plain language and do it fast. If you didn’t have enough of one page, it means you are very complicated. This process should not take more than one day.
As soon as you write this short story, start building the interface. It will be an alternative to the functional specification. Everything is visible on it and everything is clear. First draw some sketches on paper, then encode in html. The ambiguity goes away when everyone begins to see the same thing on the screen. Build an interface that people can poke with the mouse. Do this before you start worrying about the internal code.
Standard fish will help you understand how the design will look. But real words will make it clear whether a design should look that way. Text content is not just a part of visual design, but it is important and significant information. A dummy text is a curtain between you and reality.
Take the real info to see how the table will stretch. Enter the real data on the form in order to understand how convenient it will be for users. When you check the form for sending data, do not enter into the fields something like “asdf”. If you yourself are too lazy to fill out all these fields each time, then what will happen to users?
Determine the personality type of your product. It can be strict, playful, playful, unemotional, demanding, etc. When you decide on a character, follow that character and keep these traits in mind when developing a product. Whenever you make changes, think about how much the change matches the nature of your application.
Your product has a voice and speaks with your customers 24 hours a day.
Give something for free. There are a lot of things around and you won’t be noticed if you don’t give anything for free. It is customary for smart companies to give something for free / as a gift / per share to increase customer loyalty, and, along with this, profit.
37signals give free use of basecamp for 60 days. During this time, users feel enthusiasm, get used to the product and it becomes much easier for them to switch to some of the paid tariffs.
The registration process should be "for dummies." Put a big and clear button on every page of your marketing site. Tell us it's easy: 1 minute from registration to use! By itself, registration should always be free so that the user can log in and understand that he needs it. When registering, do not request information that you do not need. Just ask for an email, in most cases this is enough.
It happens that people want to close their account. This is unpleasant, but normal. Do not discourage this. Just show the link: "Close my account." Let the person upload their data so that it doesn’t turn out that they are forever imprisoned in your system because of this data. This is a critical factor that directly affects user confidence in you.
It is one thing when they demand money from us for a year in advance, and another thing when it takes for a month. This greatly affects sales. Just make payments in small portions. Basecamp deducts money from the card every month.
Connection fees are also evil. This is just a trick to collect more money from customers. Earn their money and they will use your product.
If you have bad news, tell us about it as soon as possible. When you raise tariffs, sweeten the pill to your old users. Tell us that you value them, so they can use your product at old prices for some time.
Sometimes fails happen. Admit it and give something. For example, I am a user of Yandex.Disk. When they had some kind of big jamb in one of the versions of the program, the Yandex-disk team presented users who installed this version with 250 GB of space. I must say that this place in the cloud is more than enough for me, so I'm satisfied.
Release the product in the Hollywood style. If you release a product without prior preparation, no one will ever know about it. Hollywood does this:
Advertising is expensive. A blog is only worth your time and usually it pays off. Personally, I immediately remembered the blog Fedor Ovchinnikov sila-uma.ru in which the entrepreneur describes all his steps in business. Reading this blog is entertaining and interesting.
Start by creating a blog that not only praises your product, but also provides some useful tips, solutions, links, etc. 37 signals also run their blog , which is visited by thousands of visitors a week.
Share your knowledge with others. This way you get an audience. Training is the way for your name and the name of your product to appear in front of many people. Instead of imposing your product, you get attention for the provision of educational services. Post tips and solutions on your site that readers will want to share with others. Speak at conferences and stay to talk to participants at the end. Hold seminars, write articles and books.
Adding new features is a good way to enhance the conversation about your application. Basecamp adds RSS and they start talking about it. Basecamp actively uses ajax (when it was released, ajax was a new technology) and they start talking about 37signals as one of the key ajax players, along with microsoft, google, yahoo and amazon. Integration with iCal attracts Mac users.
If they talk about you, that’s good. Keep track of what exactly is being said about you and respond in a timely manner. If you are being actively talked about in a forum, get involved in the conversation and answer the questions asked. I recalled an interesting case when a representative of JetBrains answered some questions on a root tracker in a branch dedicated to Intellij Idea. Very nice of them and it really makes a good impression.
Appreciate any feedback, including and negative. You can answer something like “we value your opinion, but we did it this way, because ...” or like this: “you raised an important issue and we are working on it.”
Offer a switch to advanced features in the application itself. Now it seems obvious, but Getting Real came out in 2006 and then there were few services offering this approach. The bottom line is that you should have several tariff plans for different categories of users. Someone needs a free version (like me with CRM bittrix24), but someone needs full functionality. Give people the opportunity to buy features. This is often done on shared hosting: this is an opportunity to purchase disk space or an additional MySQL database.
Do not make a tricky name. It should be simple and easy to remember. What is easier to say in everyday conversation: Basecamp or Active Collab? Whiteboard or CollaborEdit?
Choose a short, bright title and go. Do not get carried away by focus groups and other unnecessary things.
Do not worry if the domain name is busy. Pick up something close.
Crush the walls between engineering and support. At 37signals, the developers themselves are involved. This allows you to directly communicate with customers and understand what is happening with the product. They answer most of the requests within a few hours. Do not transfer technical support to a call center or an external organization, but do it yourself.
Make a help system built into the product. To use Yandex or Google you do not need directories. Why don't you make your product as easy to use? Start with a simple program. The less complexity, the less effort for lost users. A good help system and FAQ lists are a very good way to help.
You will be able to compete with large companies if and only if you pay attention to each user. The first users are those who will point out errors in the program and those needs that your program does not satisfy. And they will tell others about your program.
When users report errors, be sure to respond to them as quickly as possible. They expect you to listen to them and that you care about them.
Chat with people on the forum. At first you will answer all the questions yourself, but soon you will notice how more experienced users begin to give advice to less experienced ones. You will need less and less to intervene in the process, but you always need to be there and be ready to help.
Quick updates show movement and the fact that you are listening to user requests. This suggests that you still have gunpowder in the flasks and berries in the buttocks. A quick update reinforces the positive experiences associated with the product and provides additional food for discussion on blogs.
Show that your product is alive. Continue to blog the product after it is released. Do not stop writing. Include frequently asked questions, life hacks, effective ways to work with the program, unusual tricks, tips and solutions, new features, updates, corrections.
Do not use the word beta. This has already appeased everyone's eyes. When you say that you have released a beta version, you actually admit that the product is raw. It sounds something like this: “Here, hold on. This is our new product and it is in beta testing. If there are any errors, we are not to blame, because this is, after all, beta. ” It’s normal to give beta testing to a small circle of people by invitation. However, beta cannot be made publicly available. It is much better to use a different approach: a good product with minimal functionality in the first version.
Prioritizing cases is one of the most important qualities in life and this applies not only to programming, but also to any other affairs. Find out what's really important and act. When you receive a bug report, do not rush to fix it right away. Perhaps you have more important things to do. When it comes to small jambs with layout in older browsers, this is not such a big deal. If the matter concerns user data, this should be corrected immediately and perceived as an ahtung.
If you have changed something, wait this moment and do not spend some time on the reaction of users. For example, many people remember what happened when Vkontakte introduced microblogging .
This is normal. Many people will swear until they get used to it. However, those who are usually happy with everything are just silent. This is normal behavior and you will always be in a situation that there will be more negative reviews than positive ones. Do not do kickbacks based on such reviews and just continue your line if you are sure of it. Relax and don't move for a while.
Subscribe to the news about competitors and always know what they are doing. Read RSS forums. You should always know what competitors do, what functions they implement and what their users think about it.
Always be ready for new ways and changing directions. If something has changed, do not be afraid to change yourself. If you are developing a network application, you can very easily change it. Accept the fact that your initial idea might not be the best, and if it shows up, you can always change direction.
A lot of people (though, and they are becoming fewer) can read and read. But very few people do something based on what they read. Try to bring your ideas to life.
After reading Getting Real, I decided to start a project that I started thinking about a year ago. In addition, I will try to apply most of the above ideas to this project.
Please write in the comments about your experience with GettingReal, about your product blogs and rakes in use. Thanks.
26. Keep program code simple
When we write twice as much code, this does not mean that the program will become twice as complicated. The complexity of the program is growing exponentially. How to save a small amount of code? —Lighter functions, less code, less waste. Reformulate a task that requires a lot of code, so that you can solve 80% of the requirements, spending 20% of the effort. This is a very big win.
37signals find solutions to simple problems. Instead of developing products that do more, they develop products that do less.
Encourage counter-offers from programmers. Let them tell you what is wrong and how to do it differently: faster and better. The ideal phrase of the programmer: “If you do it the way you suggest, it will take 12 hours. But I can do it in an hour. Then the program will do X, but will not do Y. Let the programmers defend their point of view on how to write the program better.
Remember: no code is more flexible than no code.
27. Tools that give happiness
A happy programmer is a productive programmer. Choose tools based not only on standards and performance, but also on whether the tool gives programmatic happiness. For example, if you chose birt for reporting , be prepared that there will never be happiness. See if passion, pride and skill are felt in the instrument? Small details of the current work should bring joy. 37Signals found software happiness in the Ruby language and created the Rails framework.
28. Listen to your code
Your code will resist inelegant decisions. Perhaps he will tell you that there is an easier way to solve it. Choose a feature that's easy to do. It may not be exactly what you imagined it at the beginning, but if it works well enough and leaves time for other things, leave it alone.
29. Pay off the debts of code and design
Wrote a block of code that works but is messy? - This is a duty.
Sketched the design on the principle of "and it will do"? “This is another duty.”
Actually, this is a normal approach when you make a product by a certain date to make users happy. But debts need to be closed, so regularly take time to pay off your accumulated debts. Otherwise, you will accumulate tons of crutch code, which will be very difficult to parse. You do not remember how and why it works like that?
30. Open the API. Free in and out data
So you make life easier for everyone. Give people the ability to share data with your product. The API will allow many developers to extend the functionality of your product. Do not underestimate the contribution that other developers can make to your product.
31. No functional specifications
These are just words on paper. Instead of specifying, it’s better to write a short story in one page. Describe what the application should do. Write in plain language and do it fast. If you didn’t have enough of one page, it means you are very complicated. This process should not take more than one day.
As soon as you write this short story, start building the interface. It will be an alternative to the functional specification. Everything is visible on it and everything is clear. First draw some sketches on paper, then encode in html. The ambiguity goes away when everyone begins to see the same thing on the screen. Build an interface that people can poke with the mouse. Do this before you start worrying about the internal code.
32. Normal words, instead of lorem ipsum
Standard fish will help you understand how the design will look. But real words will make it clear whether a design should look that way. Text content is not just a part of visual design, but it is important and significant information. A dummy text is a curtain between you and reality.
Take the real info to see how the table will stretch. Enter the real data on the form in order to understand how convenient it will be for users. When you check the form for sending data, do not enter into the fields something like “asdf”. If you yourself are too lazy to fill out all these fields each time, then what will happen to users?
33. Humanize your product
Determine the personality type of your product. It can be strict, playful, playful, unemotional, demanding, etc. When you decide on a character, follow that character and keep these traits in mind when developing a product. Whenever you make changes, think about how much the change matches the nature of your application.
Your product has a voice and speaks with your customers 24 hours a day.
34. Price and registration
Give something for free. There are a lot of things around and you won’t be noticed if you don’t give anything for free. It is customary for smart companies to give something for free / as a gift / per share to increase customer loyalty, and, along with this, profit.
37signals give free use of basecamp for 60 days. During this time, users feel enthusiasm, get used to the product and it becomes much easier for them to switch to some of the paid tariffs.
35. Make registration and denial painless
The registration process should be "for dummies." Put a big and clear button on every page of your marketing site. Tell us it's easy: 1 minute from registration to use! By itself, registration should always be free so that the user can log in and understand that he needs it. When registering, do not request information that you do not need. Just ask for an email, in most cases this is enough.
It happens that people want to close their account. This is unpleasant, but normal. Do not discourage this. Just show the link: "Close my account." Let the person upload their data so that it doesn’t turn out that they are forever imprisoned in your system because of this data. This is a critical factor that directly affects user confidence in you.
36. Avoid long-term contracts, connection fees, etc.
It is one thing when they demand money from us for a year in advance, and another thing when it takes for a month. This greatly affects sales. Just make payments in small portions. Basecamp deducts money from the card every month.
Connection fees are also evil. This is just a trick to collect more money from customers. Earn their money and they will use your product.
37. Bad news
If you have bad news, tell us about it as soon as possible. When you raise tariffs, sweeten the pill to your old users. Tell us that you value them, so they can use your product at old prices for some time.
Sometimes fails happen. Admit it and give something. For example, I am a user of Yandex.Disk. When they had some kind of big jamb in one of the versions of the program, the Yandex-disk team presented users who installed this version with 250 GB of space. I must say that this place in the cloud is more than enough for me, so I'm satisfied.
38. Product Release
Release the product in the Hollywood style. If you release a product without prior preparation, no one will ever know about it. Hollywood does this:
- Announcement
Begin to hint for a few months. Tell people what you are working on, show the logo, tell about the development in your blog. Establish a website where you will collect the mail addresses of the interested public. At this stage, you will educate experts and experts, that is, those who are at the forefront. Give them the exclusive right to view the product early. - Advertising show excerpts
Hollywood shows excerpts from the film. You are previewing some features. Give some screenshots, show the main features of the product. Tell us about the ideas, principles embodied in the program. - Release
In Hollywood at this moment people go to the cinema. In your case, they will work with your product and try to use it. Launch a full-fledged marketing site. It should have a review, a tour of the product, screenshots and videos, a manifest, examples, reviews, a forum.
Spread the sermon as soon as possible. Let blogs link to you, report on your progress: how many registered users do you have, how many updates / corrections have you made? Show your forward movement.
When the release day arrives, send messages to your mailing list.
39. Start a blog
Advertising is expensive. A blog is only worth your time and usually it pays off. Personally, I immediately remembered the blog Fedor Ovchinnikov sila-uma.ru in which the entrepreneur describes all his steps in business. Reading this blog is entertaining and interesting.
Start by creating a blog that not only praises your product, but also provides some useful tips, solutions, links, etc. 37 signals also run their blog , which is visited by thousands of visitors a week.
40. Promotion through training
Share your knowledge with others. This way you get an audience. Training is the way for your name and the name of your product to appear in front of many people. Instead of imposing your product, you get attention for the provision of educational services. Post tips and solutions on your site that readers will want to share with others. Speak at conferences and stay to talk to participants at the end. Hold seminars, write articles and books.
41. Food functionality
Adding new features is a good way to enhance the conversation about your application. Basecamp adds RSS and they start talking about it. Basecamp actively uses ajax (when it was released, ajax was a new technology) and they start talking about 37signals as one of the key ajax players, along with microsoft, google, yahoo and amazon. Integration with iCal attracts Mac users.
42. Follow the mentions
If they talk about you, that’s good. Keep track of what exactly is being said about you and respond in a timely manner. If you are being actively talked about in a forum, get involved in the conversation and answer the questions asked. I recalled an interesting case when a representative of JetBrains answered some questions on a root tracker in a branch dedicated to Intellij Idea. Very nice of them and it really makes a good impression.
Appreciate any feedback, including and negative. You can answer something like “we value your opinion, but we did it this way, because ...” or like this: “you raised an important issue and we are working on it.”
43. In-app sales
Offer a switch to advanced features in the application itself. Now it seems obvious, but Getting Real came out in 2006 and then there were few services offering this approach. The bottom line is that you should have several tariff plans for different categories of users. Someone needs a free version (like me with CRM bittrix24), but someone needs full functionality. Give people the opportunity to buy features. This is often done on shared hosting: this is an opportunity to purchase disk space or an additional MySQL database.
44. Easy title
Do not make a tricky name. It should be simple and easy to remember. What is easier to say in everyday conversation: Basecamp or Active Collab? Whiteboard or CollaborEdit?
Choose a short, bright title and go. Do not get carried away by focus groups and other unnecessary things.
Do not worry if the domain name is busy. Pick up something close.
45. Feel the pain of support
Crush the walls between engineering and support. At 37signals, the developers themselves are involved. This allows you to directly communicate with customers and understand what is happening with the product. They answer most of the requests within a few hours. Do not transfer technical support to a call center or an external organization, but do it yourself.
46. Zero training
Make a help system built into the product. To use Yandex or Google you do not need directories. Why don't you make your product as easy to use? Start with a simple program. The less complexity, the less effort for lost users. A good help system and FAQ lists are a very good way to help.
47. First users
You will be able to compete with large companies if and only if you pay attention to each user. The first users are those who will point out errors in the program and those needs that your program does not satisfy. And they will tell others about your program.
When users report errors, be sure to respond to them as quickly as possible. They expect you to listen to them and that you care about them.
Chat with people on the forum. At first you will answer all the questions yourself, but soon you will notice how more experienced users begin to give advice to less experienced ones. You will need less and less to intervene in the process, but you always need to be there and be ready to help.
48. Setup in a month
Quick updates show movement and the fact that you are listening to user requests. This suggests that you still have gunpowder in the flasks and berries in the buttocks. A quick update reinforces the positive experiences associated with the product and provides additional food for discussion on blogs.
Show that your product is alive. Continue to blog the product after it is released. Do not stop writing. Include frequently asked questions, life hacks, effective ways to work with the program, unusual tricks, tips and solutions, new features, updates, corrections.
49. Not beta, but better
Do not use the word beta. This has already appeased everyone's eyes. When you say that you have released a beta version, you actually admit that the product is raw. It sounds something like this: “Here, hold on. This is our new product and it is in beta testing. If there are any errors, we are not to blame, because this is, after all, beta. ” It’s normal to give beta testing to a small circle of people by invitation. However, beta cannot be made publicly available. It is much better to use a different approach: a good product with minimal functionality in the first version.
50. Prioritize errors
Prioritizing cases is one of the most important qualities in life and this applies not only to programming, but also to any other affairs. Find out what's really important and act. When you receive a bug report, do not rush to fix it right away. Perhaps you have more important things to do. When it comes to small jambs with layout in older browsers, this is not such a big deal. If the matter concerns user data, this should be corrected immediately and perceived as an ahtung.
51. Wait the storm
If you have changed something, wait this moment and do not spend some time on the reaction of users. For example, many people remember what happened when Vkontakte introduced microblogging .
This is normal. Many people will swear until they get used to it. However, those who are usually happy with everything are just silent. This is normal behavior and you will always be in a situation that there will be more negative reviews than positive ones. Do not do kickbacks based on such reviews and just continue your line if you are sure of it. Relax and don't move for a while.
52. Keep up with your competitors
Subscribe to the news about competitors and always know what they are doing. Read RSS forums. You should always know what competitors do, what functions they implement and what their users think about it.
53. Go with the flow
Always be ready for new ways and changing directions. If something has changed, do not be afraid to change yourself. If you are developing a network application, you can very easily change it. Accept the fact that your initial idea might not be the best, and if it shows up, you can always change direction.
Embodiment
A lot of people (though, and they are becoming fewer) can read and read. But very few people do something based on what they read. Try to bring your ideas to life.
After reading Getting Real, I decided to start a project that I started thinking about a year ago. In addition, I will try to apply most of the above ideas to this project.
Please write in the comments about your experience with GettingReal, about your product blogs and rakes in use. Thanks.