Principles of Getting Real (Part 1)
We continue to read good books from this list from Milfgard and I continue to write notes. Today it is perhaps one of the most important books in the life of an IT specialist: Getting Real from 37signals. It turns brains and gives excellent working principles for the organization of small companies.
While reading this book, I felt right by a soft spot that I was doing wrong, and saw how the same could have been done much better. By the way, I planned to fit the whole summary into one article, but the book turned out to be so concentrated that it was not possible to simply remove the water and highlight the main thing. The book is structured as follows: {principle + description of principle + example}. And so many, many times, so I didn’t have much to cut and had to break the material into two articles. So let's get started.
Do less than your competitors. If your competitors have 1000 functions, make 100 or even 50. Solve basic simple problems and leave the solution difficult for everyone else. It means:
If you solve your own problems and become a potential client for yourself, respectively, you also have knowledge of what you need. Know that you are not alone: ​​if you have a problem, then hundreds or thousands of people have the same problem. When you solve your own problem, you make an instrument with a soul. And this means that the product will definitely be successful.
')
If you attract investors, you are responsible to them. Investors will quickly want to get their money back and, as a result, you will think more about quick money than a good product. To meet the minimum budget, you just need to start working not with 10 people, but with three. Set priorities and think about what you can do with three people? It really will be the main functionality, which, in fact, is needed.
"FFF" - fix time, fix budget, flex scope. To make a project with the planned functionality by a certain date for a certain money is unrealistic. Which exit? Fix only two of the parameters. The guys from 37signals offer to fix the time and money and leave open skoup. If you cannot make the settings screen in time, get rid of this screen and do not make it. More details about the use of FFF in the studio of Artyom Gorbunov can be read here .
To successfully work on FFF, you need to prioritize and determine what is really important for the product. Well, flexibility is also useful.
Find monstrous software from competitors and do the opposite. When the 37signals decided to work on Basecamp, they chose MS Project as a “monster” and tried to do much less, but much better.
When you choose an enemy, it gives you the opportunity to say what exactly your product is better than how it differs. People will compare and believe you if your product is really good. Carefully analyze other software and only then move on to your own vision and your own ideas.
The less routine your application has, the better. Routine is uninteresting actions that you perform only because you have to. For example, if you are sharing a file, you must click a button, select a file in the dialog box and wait for it to load. If you attach a file by dragging the mouse, you will make people a little happier by simplifying the routine operation.
Make a product with the soul and it will be noticed. Nothing is as upset as a soulless product. On the other hand, when you see that the developers made the product with soul and paid enough attention to your user happiness, you will be satisfied. This, by the way, is very clearly seen in the instructions. Compare the basecamp tour with the MsProject tour and feel the difference in the attitude of the authors to their work.
In order to remain a small company, you should avoid the following :
Reduce the company allow:
Smaller sizes allow you to quickly change direction, listen to your customers and respond to them quickly.
In your product may suddenly appear new properties. They are not designed or built; they just happen. Cultivate the environment to allow this to happen. Many software development methodologies formalize everything so much that they do not allow randomness or sudden ideas to occur. A reasonable system will allow the product to evolve giving opportunity to change. The more rigid installations, the less space for creativity.
Use a team of three people in the first version. This is a sufficient resource that allows you to be fast and agile. You can start with a developer, designer and a person who understands both. Talented people do not need endless resources, they have enthusiasm.
Lack of people will create limitations for you at the very first stage, and rightly so. It makes you think about priorities earlier. If you cannot develop a product with three people, then you either work with the wrong people, or you need to reduce the requirements.
Keep the team as small as possible. The effectiveness of a team is inversely proportional to the square of the number of its participants. Start by shortening the list of people you want to invite to the team, and then shorten the list again.
Relationships in a small team are much easier. If you are one person in a team, the communication takes place only between you and the client. If the number of people increases, the number of necessary connections increases many times.
When the 37signals did Basecamp they had a lot of limitations. They started as a design company with a current customer base with a 7-hour time difference with one of the developers. They had a small team without external funding. But they took restrictions, took big tasks and divided them into small pieces to try to complete them one at a time. The time difference became a serious factor in communication, and instead of meeting, they were contacted almost exclusively via instant messengers and email.
Good customer service is a must have. And no matter what business you are in. Make it so that customers can contact you on any issue. Indicate your mail and phone numbers on the site. Focus on the fact that customers can reach you and contact at any time. 37signals customers appreciate this level of trust and no one has ever abused them.
Clearly and accurately define the vision for your application. What should it do? Why should it exist? What are the differences from analogs? This vision will lead you along the right path and every time you have doubts, look at the vision and see what to do. The vision of Basecamp is: “Project management is communication.” This vision allowed Basecamp to become as open and transparent as possible. Instead of imposing restrictions in Basecamp, they gave access to customers.
Spreadsheets, graphs, charts, statistics could be made, but they focused on communication priorities: comments, lists, and file distribution.
37signals write that details are very important to them: the space between objects, perfect color, perfect words, four lines of code, instead of seven, etc. etc. Success and satisfaction are in the details, but there you will also find stagnation, disagreements, meetings and delays. These things can destroy the whole project. If you are sitting on one line of code for a whole day or the work done for the whole day did not make any progress, it means that you are too early to focus on the details. Do not worry about pixels, font size and perfect shadow, but just put the material on the page and make sure it works. Later you can improve everything.
If you get into details in advance, you can be sure that the drawing will be bad. In fact, you do not fully understand the essence of the matter. You must first make a sketch of the whole, then small objects and only then small ones.
Always work from bigger to smaller. Is always.
And what will happen when 100,000 people visit our service? Do we need 12 servers if only two are enough? No need to solve problems that you do not yet have. You just need to focus on the main thing, and if the growth in the number of users will be only in two years, do it after 1 year and 9 months. This means that you just need to make decisions on time, having all the necessary information for that. Know that in any case you will have to rewrite the west code sooner or later.
Case from own practice. When we tried to make a t-menu project (e-menu for restaurants) and successfully overwhelmed it, one of the reasons for the failure was a focus on non-existent problems. For example, we have developed our own protocol for guaranteed packet delivery directly between tablets. We thought that this was necessary for restaurants with poor WiFi coverage, however, the restaurant needed an electronic menu, and not these programming problems of ours. And this is just one of the points.
You need to find the main market for your product and concentrate solely on it. If you are targeting everyone, you are not targeting anyone. Basecamp is made for design studios. By narrowing the market, 37signals increased the likelihood of attracting passionate customers who, in turn, preached the product as the gospel.
Create half the product, but let it be the finished product. You can not release something in the release, but all the most important, the heart of the product, should work. In Basecamp, they started with messages, because this is the heart of the application. So, for the time being there were no milestones, todolist and other pieces in the basecamp. But it allowed to create a future basis for real use. Start writing and publishing the app. Then you can add features.
Make adding features a difficult task. Every time you decide to add a new feature or opportunity, you take the child. If the request for the function is constant, you can listen, but do not act immediately. As soon as there is a vision of how this new feature will work in a real environment, you can do it.
You must understand the hidden costs of new features. For example, you add an encounter table to a basecamp. To do this, you need to know the place, time, list of people, make invitations by e-mail, calendar, integrate with gmail, update the documentation, tell technical support how it works. We'll have to update the screenshots in the manuals, tour pages, terms of service, etc. Think how much this little function will bring headaches. So for each new function you have to go through the following steps:
Generally, forget about feature requests. Those. not just forget it, just take it, read it, but do nothing until the function is ripe. If the function is really important, users will not let you forget about it. Instead of asking people what they want, ask them what they don't want. “Tell me, what functions do you not use?” Or “If you could remove one feature, what would it be?”. More "no" in questions.
Do not impose your decisions on people. Provide people with a tool that simply solves their own problems. For example, if you want to add a category to the todo title, you can simply add it in square brackets: [Request]. If you want the performer to write how much time he spent on the task, let the executor write the time spent in parentheses at the end of the todo title: “Layout of the main page (8h)”.
Make basic tasks, and people will find their own solutions within your overall structure.
Do not expect to understand and do everything right the first time. Let the application grows in combat mode. Design, use, analyze, redesign and launch again. You will make informed, informed decisions; you always have a feedback and a real understanding of what needs your attention.
If you know that you are going to redo everything again, you do not need to aim at improving on the first attempt. Here is the approach used in 37signals:
Settings is a departure from the path of making tough decisions. You are here to make decisions in your product. Settings is an evil that creates a headache for the client and inflates the code. But in reality, no one uses the settings. Settings suggest that you know little about how things should work.
There are so many settings in the text editor of EmEditor that you want to cry: 15 tabs with 10-15 controls each.
Just make your choice and make simple decisions. The number of messages per page is 25, messages are sorted in chronological order, the last five projects are displayed on the dashboard. There are no options for selecting settings.
You may make a bad choice, but this is not fatal: people will complain and you will find out very quickly. You can always adjust and do the right thing. Getting Real is the ability to change on the fly.
Break the project into ten small pieces if it requires 10 weeks of work. If you can't keep a big problem in your head, break it into parts that fit easily in your head.
But organizationally better to combine. Separation by department and specialization gives the fact that each expert sees only his aspect of the application and does not see the big picture. Mix the command as much as possible to establish a dialogue. Make sure the developers know how support works; that support knows how designers make decisions; That the designer knows how the framework on which programmers write works.
You should have a single time to work. This is especially true in a team distributed across time zones. Set the time in which you will work, without any distractions. Make half the working day a time when you will not answer the phone, waste talking with colleagues, reading mail, etc. Avoid any interruptions at this time. Each break distracts so much that it is then necessary to delve into the work again.
If you needed a meeting, then there is some ambiguity. Once there is ambiguity, then you have no clear understanding of the task. This results from fuzzy goals, fuzzy statements or “translation difficulties”. Meetings break your work day into pieces and knock out of the process.
No need to hire many people too soon. If you are planning sales, it makes no sense to hire an account manager, which will be needed only in 3-4 months. If you cope, cope.
If you have the ability to quickly hire a lot of very good people, this is also a bad idea: you cannot quickly make a good solid team out of them. There will be a lot of headache, and in the early stages of development it is fatal.
If you cannot cope with something, consider whether it is necessary to do it at all? Are there any workarounds? Only there is no other way out - hire.
[Note:] It is interesting that this statement contradicts the book Good to Great that I read earlier, which says that first hire the coolest people, and then decide what you will do together.
Remember that the staff needs to be checked. Assign probation workers to potential employees. Assign a test task: in the process it will be clear how the person leads the project, how it communicates, how it works, etc. Do not close your eyes to potential problems; Remember, this is a test run.
Look for potential employees among Open Source developers. So you follow what this person has been doing for a long time and it will be clear what he is capable of. You will appreciate a person by what was done, not what was said. Look at his vision, which can be determined by comments and correspondence in the project. His vision should not contradict yours.
Your employee must also have enthusiasm, ask questions, be a master of the word (good to write), erudite.
Create an interface design before programming. Starting with programming is not very good, because programming is the most difficult and expensive part of the job. Having created the code it will be difficult and expensive for you to change it. If you start with interface drawings on paper, you don’t need to do almost anything to redo them.
On the other hand, the interface is your product. You sell it to end users. 37signals start with the interface and it is constantly being reviewed.
Design for ordinary, empty, and erroneous program states. In most cases, we see the product when it is full. We have test data, scripts that fill the database automatically and so on. But a registered user just sees a completely different picture. For him, your product is a clean sheet. Help him to figure out quickly and learn how to work, what to add in the first place. Make tips that will guide users.
PS: I will finish the first part with this. Ahead of the second part of the review of this very useful book, but for now, if you have any experience of applying the above, write below. If there is a rake, also write, usually it is especially interesting.
While reading this book, I felt right by a soft spot that I was doing wrong, and saw how the same could have been done much better. By the way, I planned to fit the whole summary into one article, but the book turned out to be so concentrated that it was not possible to simply remove the water and highlight the main thing. The book is structured as follows: {principle + description of principle + example}. And so many, many times, so I didn’t have much to cut and had to break the material into two articles. So let's get started.
1. Do less
Do less than your competitors. If your competitors have 1000 functions, make 100 or even 50. Solve basic simple problems and leave the solution difficult for everyone else. It means:
- Fewer features
- Less settings
- Smaller company
- Fewer meetings
- Fewer promises
2. Do software for yourself
If you solve your own problems and become a potential client for yourself, respectively, you also have knowledge of what you need. Know that you are not alone: ​​if you have a problem, then hundreds or thousands of people have the same problem. When you solve your own problem, you make an instrument with a soul. And this means that the product will definitely be successful.
')
3. Finance yourself
If you attract investors, you are responsible to them. Investors will quickly want to get their money back and, as a result, you will think more about quick money than a good product. To meet the minimum budget, you just need to start working not with 10 people, but with three. Set priorities and think about what you can do with three people? It really will be the main functionality, which, in fact, is needed.
4. Use FFF
"FFF" - fix time, fix budget, flex scope. To make a project with the planned functionality by a certain date for a certain money is unrealistic. Which exit? Fix only two of the parameters. The guys from 37signals offer to fix the time and money and leave open skoup. If you cannot make the settings screen in time, get rid of this screen and do not make it. More details about the use of FFF in the studio of Artyom Gorbunov can be read here .
To successfully work on FFF, you need to prioritize and determine what is really important for the product. Well, flexibility is also useful.
5. Think of an enemy
Find monstrous software from competitors and do the opposite. When the 37signals decided to work on Basecamp, they chose MS Project as a “monster” and tried to do much less, but much better.
When you choose an enemy, it gives you the opportunity to say what exactly your product is better than how it differs. People will compare and believe you if your product is really good. Carefully analyze other software and only then move on to your own vision and your own ideas.
6. No routine
The less routine your application has, the better. Routine is uninteresting actions that you perform only because you have to. For example, if you are sharing a file, you must click a button, select a file in the dialog box and wait for it to load. If you attach a file by dragging the mouse, you will make people a little happier by simplifying the routine operation.
7. Passion
Make a product with the soul and it will be noticed. Nothing is as upset as a soulless product. On the other hand, when you see that the developers made the product with soul and paid enough attention to your user happiness, you will be satisfied. This, by the way, is very clearly seen in the instructions. Compare the basecamp tour with the MsProject tour and feel the difference in the attitude of the authors to their work.
8. Stay small
In order to remain a small company, you should avoid the following :
- Long-term contracts
- Large staff
- Permanent solutions
- Meetings on other meetings
- Long process
- Extensive inventory (physical or mental)
- Binding to hardware or software
- Private data formats
- Managing the future based on the past
- Long term goals
- Office policy
Reduce the company allow:
- Decisions made as needed
- Multitasking team members
- Setting restrictions instead of trying to overcome them
- Reduced software, less code
- Fewer product features
- Small team
- Simplicity
- Open source
- Open data formats
- Free atmosphere in which it is easier to admit mistakes
Smaller sizes allow you to quickly change direction, listen to your customers and respond to them quickly.
9. Unpredictability
In your product may suddenly appear new properties. They are not designed or built; they just happen. Cultivate the environment to allow this to happen. Many software development methodologies formalize everything so much that they do not allow randomness or sudden ideas to occur. A reasonable system will allow the product to evolve giving opportunity to change. The more rigid installations, the less space for creativity.
10. Three Musketeers
Use a team of three people in the first version. This is a sufficient resource that allows you to be fast and agile. You can start with a developer, designer and a person who understands both. Talented people do not need endless resources, they have enthusiasm.
Lack of people will create limitations for you at the very first stage, and rightly so. It makes you think about priorities earlier. If you cannot develop a product with three people, then you either work with the wrong people, or you need to reduce the requirements.
Keep the team as small as possible. The effectiveness of a team is inversely proportional to the square of the number of its participants. Start by shortening the list of people you want to invite to the team, and then shorten the list again.
Relationships in a small team are much easier. If you are one person in a team, the communication takes place only between you and the client. If the number of people increases, the number of necessary connections increases many times.
11. Accept restrictions
When the 37signals did Basecamp they had a lot of limitations. They started as a design company with a current customer base with a 7-hour time difference with one of the developers. They had a small team without external funding. But they took restrictions, took big tasks and divided them into small pieces to try to complete them one at a time. The time difference became a serious factor in communication, and instead of meeting, they were contacted almost exclusively via instant messengers and email.
12. Always and at any time.
Good customer service is a must have. And no matter what business you are in. Make it so that customers can contact you on any issue. Indicate your mail and phone numbers on the site. Focus on the fact that customers can reach you and contact at any time. 37signals customers appreciate this level of trust and no one has ever abused them.
13. Priorities
Clearly and accurately define the vision for your application. What should it do? Why should it exist? What are the differences from analogs? This vision will lead you along the right path and every time you have doubts, look at the vision and see what to do. The vision of Basecamp is: “Project management is communication.” This vision allowed Basecamp to become as open and transparent as possible. Instead of imposing restrictions in Basecamp, they gave access to customers.
Spreadsheets, graphs, charts, statistics could be made, but they focused on communication priorities: comments, lists, and file distribution.
14. Neglect the details at the beginning.
37signals write that details are very important to them: the space between objects, perfect color, perfect words, four lines of code, instead of seven, etc. etc. Success and satisfaction are in the details, but there you will also find stagnation, disagreements, meetings and delays. These things can destroy the whole project. If you are sitting on one line of code for a whole day or the work done for the whole day did not make any progress, it means that you are too early to focus on the details. Do not worry about pixels, font size and perfect shadow, but just put the material on the page and make sure it works. Later you can improve everything.
If you get into details in advance, you can be sure that the drawing will be bad. In fact, you do not fully understand the essence of the matter. You must first make a sketch of the whole, then small objects and only then small ones.
Always work from bigger to smaller. Is always.
15. Do not waste time on problems that do not yet exist.
And what will happen when 100,000 people visit our service? Do we need 12 servers if only two are enough? No need to solve problems that you do not yet have. You just need to focus on the main thing, and if the growth in the number of users will be only in two years, do it after 1 year and 9 months. This means that you just need to make decisions on time, having all the necessary information for that. Know that in any case you will have to rewrite the west code sooner or later.
Case from own practice. When we tried to make a t-menu project (e-menu for restaurants) and successfully overwhelmed it, one of the reasons for the failure was a focus on non-existent problems. For example, we have developed our own protocol for guaranteed packet delivery directly between tablets. We thought that this was necessary for restaurants with poor WiFi coverage, however, the restaurant needed an electronic menu, and not these programming problems of ours. And this is just one of the points.
16. Work with the right customers.
You need to find the main market for your product and concentrate solely on it. If you are targeting everyone, you are not targeting anyone. Basecamp is made for design studios. By narrowing the market, 37signals increased the likelihood of attracting passionate customers who, in turn, preached the product as the gospel.
17. Selection of functions
Create half the product, but let it be the finished product. You can not release something in the release, but all the most important, the heart of the product, should work. In Basecamp, they started with messages, because this is the heart of the application. So, for the time being there were no milestones, todolist and other pieces in the basecamp. But it allowed to create a future basis for real use. Start writing and publishing the app. Then you can add features.
Make adding features a difficult task. Every time you decide to add a new feature or opportunity, you take the child. If the request for the function is constant, you can listen, but do not act immediately. As soon as there is a vision of how this new feature will work in a real environment, you can do it.
You must understand the hidden costs of new features. For example, you add an encounter table to a basecamp. To do this, you need to know the place, time, list of people, make invitations by e-mail, calendar, integrate with gmail, update the documentation, tell technical support how it works. We'll have to update the screenshots in the manuals, tour pages, terms of service, etc. Think how much this little function will bring headaches. So for each new function you have to go through the following steps:
- Say no
- Force the function to prove its value. If no again, then no need to do. If yes, continue.
- Sketch the screen / interface
- Design your screen / interface
- Encode
- Test
- Help text verification
- Update product introduction tour
- Update marketing copy
- Update the terms of service
- Check if previous promises have been affected.
- Check out how this affects the overall structure.
- Run and hold your breath
Generally, forget about feature requests. Those. not just forget it, just take it, read it, but do nothing until the function is ripe. If the function is really important, users will not let you forget about it. Instead of asking people what they want, ask them what they don't want. “Tell me, what functions do you not use?” Or “If you could remove one feature, what would it be?”. More "no" in questions.
18. Create software for common solutions.
Do not impose your decisions on people. Provide people with a tool that simply solves their own problems. For example, if you want to add a category to the todo title, you can simply add it in square brackets: [Request]. If you want the performer to write how much time he spent on the task, let the executor write the time spent in parentheses at the end of the todo title: “Layout of the main page (8h)”.
Make basic tasks, and people will find their own solutions within your overall structure.
19. Work iteratively.
Do not expect to understand and do everything right the first time. Let the application grows in combat mode. Design, use, analyze, redesign and launch again. You will make informed, informed decisions; you always have a feedback and a real understanding of what needs your attention.
If you know that you are going to redo everything again, you do not need to aim at improving on the first attempt. Here is the approach used in 37signals:
- Brainstorming . What will this product do? What are the needs? How will we know when this is useful? What exactly are we going to do?
- Paper sketches . Quick and simple sketches are good and economical. Purpose: to turn thoughts into a sketch of the interface.
- HTML layouts. Do something that will remotely resemble a program on the screen.
- Encode. Make HTML heal and work. The main thing is to immediately eliminate the bad and ill-conceived code. For the rest, be guided by the fact that you are waiting for multiple repetitions.
20. Avoid settings
Settings is a departure from the path of making tough decisions. You are here to make decisions in your product. Settings is an evil that creates a headache for the client and inflates the code. But in reality, no one uses the settings. Settings suggest that you know little about how things should work.
There are so many settings in the text editor of EmEditor that you want to cry: 15 tabs with 10-15 controls each.
Just make your choice and make simple decisions. The number of messages per page is 25, messages are sorted in chronological order, the last five projects are displayed on the dashboard. There are no options for selecting settings.
You may make a bad choice, but this is not fatal: people will complain and you will find out very quickly. You can always adjust and do the right thing. Getting Real is the ability to change on the fly.
21. Separate and merge
Break the project into ten small pieces if it requires 10 weeks of work. If you can't keep a big problem in your head, break it into parts that fit easily in your head.
But organizationally better to combine. Separation by department and specialization gives the fact that each expert sees only his aspect of the application and does not see the big picture. Mix the command as much as possible to establish a dialogue. Make sure the developers know how support works; that support knows how designers make decisions; That the designer knows how the framework on which programmers write works.
22. UT and no meetings
You should have a single time to work. This is especially true in a team distributed across time zones. Set the time in which you will work, without any distractions. Make half the working day a time when you will not answer the phone, waste talking with colleagues, reading mail, etc. Avoid any interruptions at this time. Each break distracts so much that it is then necessary to delve into the work again.
If you needed a meeting, then there is some ambiguity. Once there is ambiguity, then you have no clear understanding of the task. This results from fuzzy goals, fuzzy statements or “translation difficulties”. Meetings break your work day into pieces and knock out of the process.
23. Staff. Hire less and later
No need to hire many people too soon. If you are planning sales, it makes no sense to hire an account manager, which will be needed only in 3-4 months. If you cope, cope.
If you have the ability to quickly hire a lot of very good people, this is also a bad idea: you cannot quickly make a good solid team out of them. There will be a lot of headache, and in the early stages of development it is fatal.
If you cannot cope with something, consider whether it is necessary to do it at all? Are there any workarounds? Only there is no other way out - hire.
[Note:] It is interesting that this statement contradicts the book Good to Great that I read earlier, which says that first hire the coolest people, and then decide what you will do together.
Remember that the staff needs to be checked. Assign probation workers to potential employees. Assign a test task: in the process it will be clear how the person leads the project, how it communicates, how it works, etc. Do not close your eyes to potential problems; Remember, this is a test run.
Look for potential employees among Open Source developers. So you follow what this person has been doing for a long time and it will be clear what he is capable of. You will appreciate a person by what was done, not what was said. Look at his vision, which can be determined by comments and correspondence in the project. His vision should not contradict yours.
Your employee must also have enthusiasm, ask questions, be a master of the word (good to write), erudite.
24. Interface before programming
Create an interface design before programming. Starting with programming is not very good, because programming is the most difficult and expensive part of the job. Having created the code it will be difficult and expensive for you to change it. If you start with interface drawings on paper, you don’t need to do almost anything to redo them.
On the other hand, the interface is your product. You sell it to end users. 37signals start with the interface and it is constantly being reviewed.
25. Three program states
Design for ordinary, empty, and erroneous program states. In most cases, we see the product when it is full. We have test data, scripts that fill the database automatically and so on. But a registered user just sees a completely different picture. For him, your product is a clean sheet. Help him to figure out quickly and learn how to work, what to add in the first place. Make tips that will guide users.
PS: I will finish the first part with this. Ahead of the second part of the review of this very useful book, but for now, if you have any experience of applying the above, write below. If there is a rake, also write, usually it is especially interesting.
Source: https://habr.com/ru/post/289498/
All Articles