“Getting real”, by 37 signals – book review
Hi everyone, this is my very first review of the book. I’m working at “Nort” and I am excited to be involved in process of design and development of digital products. Design becomes more and more important for successful launch of product, and creators of basecamp summarized their vision of process that remains useful today.
Improving
The main point of the whole book is a fast launch of a product. A lot of designers have cases with projects that have story twists similar to this one — you agree on a specific volume of work, style, direction, terms and start the process. Then come so-called story twists.
Your customer was dazzled by numerous brilliant ideas that came to him while dreaming or looking at other competitors or simply thinking that product can be better.
Imagine that you’ve got interesting request to improve car interior.
You’ve spend time on planning, and settled up the agreement with client. After beginning of work client adds new detail. Make steering wheel more functional. The idea sounds not that bad, but it’s hard to predict the number of hours.
Customer explains his decision by desire to make product better.
The truth is — yes, product always can be better. It’s counterintuitive outcome when you agree on adding certain very “important” feature that will help customer’s product be more efficient.
One small change from a first glance can change your initial scope of work that will postpone the launch of the product.
Closer to reality
“Getting real” in simple words explains why a lot of new products are going astray by overdeveloping their concept. With unnecessary things like explicitly detailed specifications in the beginning, scheduled meetings that don’t solve anything or taking care of aspects that don’t achieve anything directly related to their business model.
Here goes valuable list that should be printed and shown to your team as reminder of how to make products better.
For every new feature you need to…
1. Say no.
2. Force the feature to prove its value.
3. If “no” again, end here. If “yes,” continue…
4. Sketch the screen(s)/ui.
5. Design the screen(s)/ui.
6. Code it.
7–15. Test, tweak, test, tweak, test, tweak, test, tweak…
16. Check to see if help text needs to be modified.
17. Update the product tour (if necessary).
18. Update the marketing copy (if necessary).
19. Update the terms of service (if necessary).
20. Check to see if any promises were broken.
21. Check to see if pricing structure is affected.
22. Launch.
23. Hold breath.
Sounds simple but it appears that a lot of customers don’t take it into account. By educating our customers we will get more interesting products with better future.
Some customers also think that developers and designers have crystal ball which helps them to see the future and name the exact terms during estimate. Well, I have bad news for them — we don’ t have any at our office and I think we are not the only one. I mean, this is the most logical explanation for their behavior.
While deliberate project planning is a good thing, you need to consider risks, and prepare to leave some of your initial functionality for future iterations.
It doesn’t make your decisions more effective if you will put them in detailed specification list, while the only tangible element in the beginning is an idea.
It’s tempting to set the deadline and detailed list of all goals which you will plan to achieve in the end. Eventually, you’ll build up something, with a slight chance of being in deadlines within previously discussed budget. Usually the real budget will be higher, and deadlines will be moved.
You don’t need to blame the team members for their incompetence. It’s more about to hold your breath and reconsider the plan. Here is good advice from Basecamp guys:
“Constraints are often advantages in disguise. Forget about venture capital, long release cycles, and quick hires. Instead, work with what you have. Instead of creating detailed list of specs customer should think about being flexible and appear on a market asap”.
This advice refers not only to the first version of a product. This kind of approach gives an opportunity to boost the speed of thoughtful changes in already launched ones. Other advice relevant to the terms of project:
“Keep dividing problems into smaller and smaller pieces until you’re able to digest them”.
Not much to add here, it’s true. Unless you aren’t huge corporation with an excessive amount of resources but even if you are, it’s still a good point. Don’t try to estimate big volume of work as an organic whole. It’s easier for people to manage small chunks of work and plan their process.
The other aspect is the time spent in search of the right decision. Based on experience in industry and gathered data clients define feature list and direction for the work. It looks fine from the beginning. We have data from marketing research, our customer has expertise in the field. Everything is arranged and will go smoothly. Not really.
There is no better way for testing your ideas rather than presenting them to users. Instead of wasting time on endless discussions with stakeholders and your team about various aspects of the product — publish it.
You will see from user’s perspective what solutions are good and what parts of design require revision. It will safe resources and help faster to change the direction of the work.
One more thing to add. Users care less about consistency than we or our customer thinks. It’s better to concentrate on points that convey the core value of the product. Because if it’s helpful and easy to operate — people will use it, and eventually, they will love your product.
There are even more great quotes. Please share your thoughts in comments I’ll be glad to read them.
If you enjoy reading this article I recommend you to read more about design from real world perspective and a few more reasons to visit Hackathon.
Thanks to Andrey for providing great cover image.
