Getting Real Principles (Part 1)

    We continue to read good books from this list from Milfgard and I continue to write notes. Today, this is perhaps one of the most important books in the life of an IT professional: Getting Real from 37signals. She turns brains and gives excellent working principles for organizing the work of small companies.



    While reading this book, I felt in a soft spot what I was doing wrong, and saw how the same could be done much better. By the way, I planned to fit the entire compendium into one article, but the book turned out to be so concentrated that it simply didn’t work out that it was easy to separate the water. The book is structured this way: {principle + description of principle + example}. And so many, many times, so much to reduce failed 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 complex to everyone else. It means:
    • Less opportunity
    • Less settings
    • Smaller company
    • Less meetings
    • Less promises

    2. Make software for yourself


    If you solve your own problems and become a potential client for yourself, respectively, you also have the knowledge about what you need. Know that you are not alone: ​​if you have some kind of problem, then a hundred or a thousand people have the same problem. When you solve your own problem, you make a tool with the 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 fast money than about 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? This will really 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 amount of money is unrealistic. Which exit? Only fix two of the parameters. The guys from 37signals offer to fix time and money and leave open scopes. If you cannot make the settings screen in time, get rid of this screen and do not do it. You can read more about the use of FFF in the studio of Artyom Gorbunov 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 37signals decided to work on Basecamp, they chose MS Project as the “monster” and tried to do much less, but much better.
    When you choose an enemy, this gives you the opportunity to say exactly what 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 in your application, the better. Routine is an uninteresting action that you perform only because you are forced to. For example, if you share a file, you must click the button, select the file in the dialog box and wait for it to load. If you make the attachment of the file by dragging the mouse, you will make people a little happier by simplifying the routine operation.

    7. Passion


    Make a product with soul and it will be noticed. Nothing upsets like a soulless product. On the other hand, when you see that the developers made the product with a soul and paid enough attention to your user happiness, you will be satisfied. This, by the way, is very clearly visible in the instructions. Compare tour basecamp with a tour of MsProject and feel the difference in relation to the authors of the work.

    8. Stay small


    In order to remain a small company you need to avoid the following :
    • Long term contracts
    • Large staff
    • Immutable solutions
    • Other meeting meetings
    • Long process
    • Extensive inventory (physical or mental)
    • Binding to hardware or software
    • Closed Data Formats
    • Managing the future based on the past
    • Long term goals
    • Office policy

    Reduce the company allow:
    • Decisions as required
    • Multitasking Team Members
    • Setting limits instead of trying to overcome them
    • Reduced software, less code
    • Fewer product features
    • Small team
    • Simplicity
    • Open source
    • Open data formats
    • A free atmosphere that makes mistakes easier to recognize


    Smaller sizes allow you to quickly change direction, listen to your customers and respond to them quickly.

    9. Unpredictability


    New features may suddenly appear in your product. They are not designed and 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 chance to happen or the sudden appearance of ideas. A smart system will allow the product to evolve, enabling change. The more rigid the settings, the less space for creativity.

    10. Three Musketeers


    Use a team of three in the first version. This is a sufficient resource that allows you to be quick 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 restrictions for you at the very first stage, and rightly so. This will make 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 requirements.



    Keep the team small as long as possible. The effectiveness of the 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.

    Relationship paths in a small team are much simpler. If you are one person in a team, 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 client base with a 7-hour time difference with one of the developers. They had a small team without external funding. But they accepted the limitations, took the big tasks and divided them into small pieces in order to try to complete them one at a time. The time difference became a serious factor in communication and instead of meeting, they contacted almost exclusively through instant messengers and electric mail.

    12. Always and anytime


    Good customer service is a must have. And no matter what business you are in. Make sure that customers can contact you on any issue. Indicate your mail and phone numbers on the site. Emphasize that customers can reach you and contact you at any time. 37signals customers value this level of trust and no one has ever abused it.

    13. Priorities


    Clearly and precisely define the vision for your application. What should it do? Why should it exist? What are the differences from analogues? This vision will lead you on the right path, and every time you have doubts, look at the vision and you will see what to do. Basecamp's vision is: “Project management is communication.” This vision made it possible to make Basecamp as open and transparent as possible. Instead of imposing restrictions in Basecamp gave access to customers.

    One could make spreadsheets, graphs, charts, statistics, 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, the perfect color, the perfect words, four lines of code, instead of seven, etc. etc. Success and satisfaction are in the details, but there you will find stagnation, disagreement, meetings and delays. These things can destroy an entire project. If you sit on one line of code for a whole day or work done in a whole day has not made any progress, it means that you focused on the details too early. Do not worry about pixels, font size and perfect shadow, but simply put the material on the page and make sure it works. Later you can improve everything.

    If you get involved in the details in advance, you can be sure that the pattern will be bad. In fact, you do not fully understand the essence of the matter. You must first sketch 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 are not yet


    But 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 don’t have yet. You just need to focus on the main thing, and if the growth in the number of users is only in two years, do it in 1 year and 9 months. This means that you just need to make decisions on time, having all the necessary information for this. 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 the t-menu project (an electronic menu for restaurants) and successfully failed it, one of the reasons for the failure was the focus on non-existent problems. For example, we have developed our own protocol for guaranteed package delivery directly between tablets. We thought it was necessary for restaurants with poor WiFi coverage, however, the restaurant needed an electronic menu, and not our programming troubles. 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 exclusively on it. If you focus on everyone, you do not focus on 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 a finished product. You may not release something in the release, but the most important thing, the heart of the product, should work. Basecamp started with messages, because that is the heart of the application. So, for the time being in the base camp there were no milestones, todolist and other things. But this allowed us to create a future foundation for real use. Start writing and publishing the app. Then you can add features.

    Make adding features a daunting task. Each time you decide to add a new feature or opportunity, you accept the child. If the function request is constant, you can listen, but not immediately act. Once there is a vision of how this new function will work in a real environment, you can do it.

    You must understand the hidden costs of new features. For example, you add a meeting table to basecamp. To do this, you need to know the place, time, list of people, make invitations by e-mail, calendar, integration with gmail, update documentation, inform technical support how it works. You will have to update screenshots in manuals, tour pages, terms of service, etc. Think about how much this little function will bring a headache. So for each new function you must 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 a screen / interface
    • Design Screen / Interface
    • Code
    • Test
    • Check help text
    • Update Product Tour
    • Update your marketing copy
    • Update Terms of Service
    • Check if previous promises have been affected.
    • Check out how this affects the overall structure.
    • Run and hold your breath

    In general, forget about feature requests. Those. not just forget it, but just accept them, read, but don’t do anything until the function has matured. 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 features do you not use?” Or “If you could remove one feature, what would it be?”. More “no” in questions.

    18. Build software for common solutions


    Do not impose your decisions on people. Provide people with a tool that can easily solve their own problems. For example, if you want to add a category to the name todo, you can simply add it in square brackets: [Request]. If you want the contractor to write how much time he spent on the task, let the contractor write the time spent in parentheses at the end of the todo name: “Layout of the main page (8h)”.

    Make solutions to basic problems, and people will find their own solutions within your overall structure.

    19. Work iteratively


    Do not expect that you will understand and do everything right the first time. Let the application grow in combat mode. Design, use, analyze, remake and run again. You will make informed informed decisions; you always have feedback and a real understanding of what needs your attention.

    If you know that you are going to redo everything all over again, you do not need to aim for improvement at the first attempt. Here is the approach used in 37signals:
    1. Brainstorming . What will this product do? What needs? How will we know when it is helpful? What exactly are we going to do?
    2. Paper sketches . Quick and easy sketches are good and economical. Purpose: turn thoughts into a sketch of the interface.
    3. HTML layouts. Do something that will remotely resemble a program on the screen.
    4. Encode. Make HTML Heal and Make Money. The main thing here is to immediately eliminate the bad and ill-conceived code. For the rest, focus on the fact that you are waiting for repeated repetitions.


    20. Avoid settings


    Settings are 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 EmEditor text editor that I want to cry: 15 tabs of 10-15 controls.

    Just make a 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 choosing settings.

    You may make a bad choice, but it’s not fatal: people will complain and you will know about it very quickly. You can always adjust and do it right. Getting Real is the ability to change on the fly.

    21. Separate and merge


    Break the project into dozens of small pieces if it requires 10 weeks of work. If you cannot keep a big problem in your head, break it down into parts that fit easily in your head.

    But organizationally better to combine. The division into departments and specializations gives the fact that each specialist sees only his own aspect of the application and does not see the big picture. Mix the team as much as possible to establish a dialogue. Make sure 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. Single time and no meetings


    You should have one time to work. This is especially true in a team distributed by time zones. Set the time at which you will work, not being distracted by anything. Make half a day work time when you will not answer phone calls, talk in vain with colleagues, read mail, etc. Avoid any breaks during this time. Each break is so distracting that then you need to delve into the work again.

    If you need a meeting, then there is some kind of ambiguity. Since there is ambiguity, then you do not have a clear understanding of the problem. This stems from fuzzy goals, fuzzy formulation, or “translation difficulties.” Meetings break your work day into pieces and knock them out of the process.

    23. The staff. Hire Less and Later


    There is no need to hire many people too early. If you have planned sales, it makes no sense to hire an account manager, which will be needed only after 3-4 months. If you can do it, do it.

    If you have the opportunity to quickly hire many very good people, this is also a bad idea: you cannot quickly make a good, united team out of them. There will be a lot of headache, and in the early stages of development it is fatal.
    If you can’t cope with something, think about whether you need to do this at all? Are there any workarounds? Only ate there is no other way out - hire.

    [Note:] it is interesting that this statement contradicts the Good to Great book I read earlier, which says that first hire the coolest people, and then decide what you will do together.

    Remember that staff must be checked. Assign a probationary period to potential employees. Assign a test task: in the process it will be clear how the person conducts the project, how he communicates, how he works, etc. Do not close your eyes to potential problems; remember that this is a test run.

    Look for potential employees among Open Source developers. So you will follow what this person has been doing for a long time and it will be clear what he is capable of. You will evaluate a person by what has been done, and not by what has been said. Look at his vision, which can be determined by the comments and correspondence in the project. His vision should not contradict yours.

    Also, your employee should be enthusiastic, ask questions, be a master of the word (write well), is erudite.

    24. Interface before programming


    Create an interface design before programming. Getting started with programming is not too good, because programming is the most difficult and expensive part of the job. Creating the code will be difficult and expensive for you to change it. If you start with the drawings of the interface on paper, remaking them costs you almost nothing.

    On the other hand, the interface is your product. You sell it to end users. 37signals begin with an interface and it is constantly being revised.

    25. Three program states


    Make a design for the normal, empty and erroneous states of the program. In most cases, we see the product when it is full. We have test data, scripts that fill the database automatically and all that. But the newly registered user sees a completely different picture. For him, your product is a blank sheet. Help him to figure it out quickly and learn how to work, what to add first. Make hints that will guide users.

    PS: on this I will finish the first part. Ahead of the second part of the review of this very useful book, but for now, if you have any experience with the application of the above, write below. If there is a rake - also write, usually this is especially interesting.

    Also popular now: