Mark Johnson

    Getting Real

    Tuesday 30th April, 2019 - 9 min read

    Getting Real

    Getting Real: The Smarter, Faster, Easier Way to Build a Successful Web Application is a book published by the founders of 37 signals that created multiple successful web apps to help business founders run their businesses more productively. As well as successfully bootstrapping themselves while releasing products like Bootcamp, Backpack and Writeboard, they also released the Ruby on Rails framework, a framework popular with the dev community for “optimizing for dev happiness”.

    Getting Real’s advice counters many common practices in large companies. Fewer features, meetings, resources, and stress, and more focus on quickly delivering a small subset of features that will delight users. Jason Fried from 37 signals puts his finger on the benefits that small companies have. You don’t have hundreds of developers, a huge marketing budget and 12-months to build a product. But these constraints force creative solutions. You build the most important features in weeks, answer customer calls directly and implement improvements in days, not months.

    The book is available as a PDF on the 37 signals website.

    I sent the book to my Kindle through Push to Kindle and found a number of sections stood out. I thought I’d go through some of the sections I highlighted below and leave my thoughts. It’s worth mentioning that this is focused on web apps, particularly for consumers and small businesses. These philosophies aren’t true for all software projects.


    On telling a better story

    “When we decided to create project management software, we knew Microsoft Project was the gorilla in the room. Instead of fearing the gorilla, we used it as a motivator. We decided Basecamp would be something completely different, the anti-Project.”

    By figuring out your apps enemy you can decide what it shouldn’t be. Having an enemy is very clear from a marketing perspective, we’re not X, we’re Y. People understand conflict and understand that you aren’t aiming to outperform your competitor in feature parity, but deliver an entirely new experience.

    “Tell a different story and persuade listeners that your story is more important than the story they currently believe [..] Persuading the consumer to switch is the same as persuading him to admit he was wrong. And people hate admitting they were wrong.

    This enables you to deliver a new experience, sets different expectations for your product, and allows customers to buy into your better vision of the world instead of admitting that they chose the “objectively-wrong” product. In 37 signals case, it was selling users on the idea that project management doesn’t need to be a top-down, management led, date-driven affair, and instead works best when all users collaborate together with no barriers to deliver a project on time. This allows 37 signals to exclude complex reporting like Gantt charts, detailed user assignment and date tracking, and focus on the core elements to deliver the story they were telling.

    On reducing scope

    “It’s better to make half a product than a half-assed product”

    The more you ship, the more you have to maintain. Removing features rarely happens and every feature has the potential to ruin the user experience, so it’s vital that only the strongest features make the cut.

    “If you try to please everyone, you won’t please anyone. When we built Basecamp we focused our marketing on design firms. By narrowing our market this way, we made it more likely to attract passionate customers who, in turn, would evangelize the product. Know who your app is really intended for and focus on pleasing them”

    This boils down to reducing the size of the problem. Build fewer features. Support a smaller set of users. And then focus on deeply meeting their specific needs. It’s better to have a small set of passionate users than a large group of users that feel no tie to your product.

    “The best designers and the best programmers aren’t the ones with the best skills, or the nimblest fingers, or the ones who can rock and roll with Photoshop or their environment of choice, they are the ones that can determine what just doesn’t matter. That’s where the real gains are made”

    Another example of reducing the size of the problem. Build a great product by throwing everything that doesn’t matter to the side.

    “Steve Jobs gave a small private presentation about the iTunes Music Store to some independent record label people. My favourite line of the day was when people kept raising their hand saying, “Does it do [x]?”, “Do you plan to add [y]?”. Finally Jobs said, “Wait wait – put your hands down. Listen: I know you have a thousand ideas for all the cool features iTunes could have. So do we. But we don’t want a thousand features. That would be ugly. Innovation is not about saying yes to everything. It’s about saying NO to all but the most crucial features”

    Again, reduce the size of the problem. And this principle can be applied at all companies, but the team at 37 signals recognised that this was a very real constraint for them. A large business can be agile. But if they’re not careful then an exec will promise a product release for the next big marketing event, they conflate increased importance with increased dev resources, and before they know it the product is 12 months delayed. A small company has no choice but to stay agile and cut scope. They have to ship early to get paid.

    On preferences

    “Preferences are a way to avoid making tough decisions. It may seem like you’re doing them a favour but you’re just making busy work for them (and it’s likely they’re busy enough). Customers shouldn’t have to think about every nitty gritty detail – don’t put that burden on them when it should be your responsibility.”

    “Preferences are also evil because they create more software. More options require more code. And then there’s all the extra testing and designing you need to do. You’ll also wind up with preference permutations and interface screens that you never even see. That means bugs that you don’t know about: broken layouts, busted tables, strange pagination issues, etc.”

    I hadn’t considered the problem with preferences before. We know we don’t have perfect knowledge of users workflows, and users may use the tools in different ways, so preferences seem like the natural way to make the product flexible to a range of needs. And I think it’s true that preferences can provide value or else they wouldn’t have become so prevalent.

    But we frequently forget the cost of adding preferences, which Jason highlights so well here. We’re bad at designing flows for blank or error states, let alone for irregular states where user preferences have made the table display 200 rows instead of 50 or all text is twice the size and is pushing the rest of the content down the page.

    On agility

    “Yes, you might make a bad call. But so what. If you do, people will complain and tell you about it. As always, you can adjust. Getting Real is all about being able to change on the fly.”

    We delay on decisions where there’s uncertainty, we don’t want to make a mistake. But we fail to realise the cost of delaying a decision. “The enemy of a good plan is a perfect one”. You lose out on information from real users by delaying decisions. You could easily make the wrong decision despite delaying it.

    “But wait, what if you screw up and make the wrong call? It’s ok. This isn’t brain surgery, it’s a web app. [..] Don’t do the ‘paralysis through analysis’ thing. That only slows progress and saps morale.

    As well as failing to realise the cost of delaying a decision, we often overestimate the cost of making the wrong decision. Software breaks all the time, your users will be surprisingly forgiving if they believe in your company and the story you’re telling.

    On design

    “We start with the interface so we can see how the app looks and feels from the beginning. [..] Programming is just implementation [..] If you just slap an implementation on at the end, the gaps will show.

    Nothing crazy here, go from low fidelity to high fidelity before coding. 37 signals start with several iterations of paper and whiteboard designs. Once they are confident with the concepts they go straight to building it in HTML. This goes through several iterations of re-design before determining if the designs are strong enough to justify coding. It is only at this point that the back-end code will be written.

    Epicenter design

    “Epicenter design focuses on the true essence of the page – the epicenter – and then builds outward. This means that you ignore the extremities: the navigation/tabs, footer, colors, sidebar, logo, etc. Instead, you start at the epicenter and design the most important piece of content first.

    Related to working in phases and delivering the most valuable piece first, understand how the most important area of your design, the area where users get most value, should be designed first. Often we focus on designs primary and secondary layers in the information architecture (nav and page) before we think about tertiary (sub-page) where users will actually spend most of their time.

    Context over consistency

    “It’s better to be right than consistent”

    37 signals take a pragmatic approach to consistency. Design decisions depends on where it’s being shown, for how long, and many other factors. Users notice when there’s significant differences between the layouts of similar pages, but they’re not robots. A global search bar doesn’t need to be present on every page, if it doesn’t make sense in the page then users won’t miss it if you remove it, they won’t be complaining that your design is inconsistent as they didn’t need that element.

    On development


    Enjoyed this post? ❤️

    Subscribe by email or RSS.