Book Notes: Getting Real by 37signals

wiredniko

wiredniko

Jedi in training
Jul 20, 2010
712
26
0
New York
I thought barman posted a link to this book 3 days ago...I did a forum search and google search but I can't find the original thread...so my book notes have to be posted solo.

Note: I have heard of 37 signals before but reading this book is a must for any web developer. I am no pro in the game, but in my two years of messing around with this stuff I have had to learn half of the stuff mentioned in the book the hard way. Usually I bold things that I find very useful, but in this case my entire post would be bold. This book is gold...this book reminds me why I love to code.

Enjoy!
Evernote link: https://www.evernote.com/shard/s63/...5c67b997e60e/69901e0c8cebf1a1b9feb18525972e11


What is Getting Real?
  • It's about skipping all the stuff that represents real (charts, graphs, boxes) and actually building the real thing
  • Getting Real starts with the interface, the screens that customers will use allowing you to get the interface right before you get the software wrong
  • This book is for entrepreneurs, designers, programmers and marketers working on a big idea
  • Build, launch and tweak. Rinse and repeat
  • Build products that work smarter, feel better and allow you to do things your way...and are easier to use

The Starting Line
  • Solve the simple problems and let the competitors deal with the difficult and nasty problems
  • Do less
    • Less features
    • Less options/preferences
    • Less promises
  • Build software for yourself
  • A great way to start is to solve your own problems, you can be the target audience
  • Fund yourself. Outside funding comes with expectations that can affect your product
  • Constrains can drive innovation
  • Focus on building a quality tool that you and your customers cna live with for a long time
  • Fix Time and Budget, Flex Scope
    • Launch on time and on budget
  • By keeping time and budget fixed it allows you to
    • Prioritize better
    • Reality
    • Flexibility
  • Its better to scope down than make a half-assed product
  • Pick an enemy
    • It will allow you to shine a light on where you need to go
    • It can be another app or an idea you are trying to overcome
    • Don't get too obsessed with the competition, just take a look and then move on to your own vision and your own ideas
    • Don't follow the leader. Instead tell a different story. If your competition is cheaper you must be faster. If they sell the story of health, sell the story of convenience
  • Your passion or lack thereof will shine through

Stay Lean

  • The leaner you are the easier it is to change
  • Reduce project mass by
    • just in time thinking
    • embracing constraints
    • less software, less code
    • less features
    • small team size
    • simplicity
    • open source products
    • open data formats
  • An agile company can change its mind
  • Cheap and fast changes are a secret weapon
  • Create a well designed simple system that allows emergence
  • Keep it small. Keep it simple. Let it happen
  • For version 1.0 use a team of three
    • A developer, a designer and a sweeper (can do both)
  • If you can't build your version one with three people, you either need different people or need to slim down your initial version
  • Instead of freaking out about constraints, embrace them. They drive innovation
  • Be yourself, differentiate yourself from bigger companies by being personal and friendly
  • Smaller companies are closer to the customer by default

Priorities

  • Explicitly define the one point vision for your app
  • What does your app stand for? What's it really all about?
  • Get a vision. Think big.
  • The vision should be brief and enough to get the idea across
    • Writeboard: Word is overkill
    • Ta-da List: Competing with a post-it note
    • Basecamp: Project management is communication
  • Use your vision as a guide post for how to create and execute your app
  • Ignore the details early on, work from large to small
  • There is plenty of time to be a perfectionist, just do it later
  • You will know which details you need to address as you use your app
  • Its's a problem when its a problem
  • Don't waste time on problems you don't have yet
  • Make decisions just in time, when you have access to the real information you need. In the meantime focus on things that require immediate care
  • Hire the right customers. Find the core market for your application and focus solely on them
  • If you try to please everyone you won't please anyone
  • Scale later, you don't have a scaling problem yet
  • Create a solid app and then worry about what to do once it's wildly successful
  • Make opinionated software, your app should take sides
  • Don't try to be all things to all people, make your apps have an attitude
  • When the Wiki creators removed ownership and dates it became ego-less and time-less driven documents that allowed a community to grow

Feature Selection

  • Build half a product, not a half-ass product
  • build half a product that kicks ass
  • Take whatever you think your product should be and cut it in half
  • Pare features down util you are left with only the most essential ones
  • It just doesn't matter, keep it to essentials only
  • Does it matter
    • To show the total number of people in a chat 12 vs 16?
    • Allow colored text in a chat?
    • Timestamp every second of the conversation
  • Start with a no, make features hard to be implemented
  • Make each feature prove itself and show its a survivor. Fight Club mentality, stand on the porch for three days waiting to be let in
  • Expose the hidden price of features
  • Be on the lookout for feature loops, features that lead to more features
  • Build something you can manage
  • Build products and offer a service you can manage
  • Build software for general concepts and encourage people to create their own solutions. Don't force conventions on people
  • Create a framework by fixing the root of the problem and then people will find their own solutions
  • Forget feature requests. If its a request really worth remembering they will remind you until you can't forget
  • Hold the mayo concept. What feature can you remove that your customers would not mind? What gets in their way the most
  • Ask people what they don't want

Process

  • Get something real up and running quickly
  • Work in iterations,d on't expect to get it right the first time
  • From idea to implementation
  • Brainstorm
    • What are you making it
    • What do you want it to do
    • Talk about the big idea
  • Paper sketches
    • Create a rough interface design
    • Get your ideas out of your head and onto paper
  • Create HTML screens
    • Make an HTML version of the features and screens, don't code, just use HTML and CSS
  • Code it
    • Remember to stay flexible
  • Decide on the little details so your customers don't have to
    • How many messages should you include on each page? Just make a decision don't make people have to decide
  • Preferences are a way to avoid making tough decisions. It may seem like you are doing them a favor but you are creating busy work for them. Not to mention it complicates your code
  • Make the call. If you make a bad call people will complain about it and tell you
  • Decisions are temporary so make the call and move on. This is not brain surgery its a web app, you can revisit later
  • Get in the rhythm of making decisions
  • Test your app via real world usage
  • Get real data, get real feedback and then improve based on that info
  • Break down your time, keep breaking down time frames into smaller chunks
  • Keep dividing problems into smaller and smaller pieces until you are able to digest them

The Organization
  • Don't split into silos, kep the teams united
  • The alone time zone is where the real development magic happens
  • Setup a rule at work, make half the day alone time. Make this period continuous and avoid interruptions
  • Meetings are toxic productivity killers. The information to time ratio is too low
  • If you have to have a meeting set a 30 minute timer, invite as few people as possible and make sure to have a clear agenda
  • Release something today, celebrate small victories
  • What can we do and release in 4 hours?

Staffing
  • Add people slowly and go fast
  • Work with prospective employees on a test-basis first. you can learn a lot by how someone works on a project
  • Go for quick learning generalists over ingrained specialists
  • Small teams need people who can wear different hats
  • go for happy and average over frustrated and great. Enthusiasm is the one attribute you just can't fake
  • Hire good writers. good writes know how to communicate, they know how to make things easy to understand, what to omit and how to think clearly. Those are the qualities you need
 
  • Like
Reactions: Berto and profitordie


Interface Design
  • Design the interface before you start programming
  • Start by design first, its relative light and easy to change
  • Designing first keeps you flexible, programming first fences you in and sets you up for additional costs
  • In reality the interface is your product
  • HTML pages are easy to change, tweak and throw out and it will give you the real feel of the product
  • Start from the core of the page and build outward. In the beginning ignore the extremities, the navigation/tabs, footer, colors, sidebar, logo etc....instead design the most important piece of content first
  • Essentials first, extras second
  • Three State Solution
    • Design for regular, blank and error states
    • Regular: The screen people see when everything's working fine and the app is flush with data
    • Blank: The screen people see when they are using the app for the first time, before data is entered
    • Error: The screen people see when something goes wrong
    • The Blank Slate. Set expectations with a thoughtful first run experience
  • The blank slate is your app's first impression
  • When you fail to design an adequate blank slate, people don't know what they are missing because everything is missing
  • What should you include in a helpful blank slate?
    • Opportunity for quick tutorials and help blurbs
    • Sample screenshot of the page populated with data
    • Explain how to get started, what the screen will eventually look like
    • Answer key questions for first time users
    • Set expectations, and help reduce frustration and confusion
  • Design defensively. Design for when things go wrong
  • Context over consistency. What makes sense here may not make sense there
  • Every letter matters, copywriting is interface design
  • You need to speak the same language as your audience
  • One interface, incorporate admin functions into the public interface
  • Admin screens should be build in into the regular application interface

Code
  • Keep your code as simple as possible
  • Each time you increase the amount of code, your software grows exponentially more complicated
  • The way you fight complexity is with less software...less features, less code, less waste
  • Don't bog yourself down trying to solve phantom issues
  • Don't be afraid to say no to feature requests that are hard to do but not essential
  • Choose tools that keep your team excited and motivated
  • Code speaks, listen when your code pushes back
  • Is the new feature require weeks of time and thousands of lines of code? The code is telling you there is a better simpler way of doing it
  • Pay off your code and design "bills". At times we hack our way in design and code and it creates debt. Put aside time to fix your debt otherwise interest can bog you down (more hacks)
  • Get you data out into the world via RSS and APIs

Words
  • There is nothing functional about functional spec
  • Write a one page story about what the app needs to do. Use plain language and make it quick
  • Then begin building the interface, draw some quick and simple paper sketches and start coding it into HTML
  • Eliminate unnecessary paperwork, build don't write
  • If you need to explain something try to prototype it rather than writing a long winded document
  • Write stories, not details. Stick to the experience instead of getting hung up on the details
  • Insert actual text instead of lorem ipsum. Real copy will tell you how long fields should be, how tables will expand and contract, what your app truly looks like
  • Do as your customers do and you will understand them better
  • Create a product personality
  • Think of your product as a person. What type of person do you want it to be?
  • Always keep those personality traits in mind as the product is built, use them to guide your copywriting, interface and feature set

Pricing and Signup
  • Give something away for free in order for people to notice you among the noise
  • Freebies is a great way to lure in customers
  • Make signup and cancellation a painless process
  • Tell folks how easy it is to sign up
  • Always include free options so the customer can demo the app
  • Keep the signup form as short as possible
  • Make sure its easy for people to get out their date if they need to (XML format)
  • Avoid long term contracts, sing up fees etc
  • Don't try to find tricky ways to get more cash. Earn it
  • Soften the blow of bad news with advance notice and grandfather clauses. Give plenty of notice

Promotion
  • The Hollywood Launch. Teaser > Preview > Launch
  • Teaser: A few months ahead of time start dropping hints. Let people know what you are working on. Get a site up and collect emails from folks who are interested. Start collecting beta testers
  • Preview: a few weeks ahead of launch start previewing features. give people behind the scenes access, engage the beta testers
  • Launch. Launch your full marketing site, get blogs to link to you, post your progress. Show momentum and keep at it
  • Create a powerful promotional site
    • Overview explain your app and its benefits
    • Tour - guide people through various features
    • Screen captures and videos - show people what the app actually looks like and how to use it
    • Manifesto - explain the philosophy and ideas behind it
    • Case studies - provide real life examples that show what is possible
    • Buzz - testimonial quotes from customers, reviews, press
    • Forum - Offer a place for members of the community to help each other
    • Pricing and sign up - get people into you app as quickly as possible
    • Weblog - blogs keep your site fresh with news and tips
  • Using blogs is more effective than advertising
  • Promote through education, share your knowledge with the world
  • Feature food, new features can help generate more buzz in the community
  • Study your logs to track buzz. Participate in the communities that support you, give them early beta access to new features
  • Promote upgrade opportunities inside the app
  • Existing customers are your best bet for sales
  • Give your app a name that is easy to remember, a name hook
  • The name does not have to be utlra-descriptive, that usually makes it forgetable

Support
  • Tear downs the walls between support and development. Don't outsource it, do it yourself
  • The front lines is where the action is, get up there
  • Use inline help and FAQs so your product doesn't require a manual or training
  • Strive to build a tool that requires zero training
  • Quick turnaround time on support queries should be a top priority
  • Even if you don't have a perfect answer say something, be honest
  • Be willing to say no to your customers
  • When it comes to feature requests the customer is not always right
  • Use forums or chat to let customers help each other out. You will be surprised how much people want to help each other
  • Get bad news out there and out of the way
  • Bad news should come out in the open at once. Good news should be trickled out slowly to keep the good vibes

Post Launch
  • Issue a major update 30 days after launch
  • A quick update shows momentum and that you are listening
  • Keep the posts coming, show your product is alive by keeping an ongoing product development blog post-launch
  • Things to include in your blog
    • FAQs
    • How-Tos
    • Tips & Tricks
    • New features, updates & fixes
    • Buzz/press
    • Be personal, don't try to appear like a big company
  • Private betas are fine, public betas cheat the customer
  • Prioritize your bugs and even ignore some of them, work on what matters the most
  • After you introduce a new feature or change something there is usually an influx of knee-jerk reactions, ride out the storm, then offer a more reasoned response
  • Subscribe to news feeds about your competitors, know your enemy
  • Beware the bloat monster. More mature doesn't have to mean more complicated
  • Web based software based on the subscription model, people pay a monthly fee to use the service. You just need to provide an ongoing valuable service
  • Be open to new paths and changes in direction. Be open to the fact that your original idea may not be your best one

Conclusion
  • Success is all about great execution
  • The ingredient to build a successful web app is the people involved
  • You need people who care about their craft
  • Getting Real is not just for software, it applies to everything
 
Wiredniko, you should create the most bad ass business or self improvement book summary site.
Not that it is necessarily a great business but you appear to be doing it anyway and you may as well cash in. Give getAbstract a run for their money.
 
Is this how you guys read books? Yall musta learnedded dat in dem fancy schools
 
I want to read their ReWork book fo sho.

Although I think "Getting Real" is pretty short and sweet, so it's worth a read over reading someone's notes.
 
barman said:
I want to read their ReWork book fo sho.

Although I think "Getting Real" is pretty short and sweet, so it's worth a read over reading someone's notes.
Click to expand...

I bought ReWork yesterday from Amazon. Major complaint was that there was rehash of the Getting Real book but looking at the chapters it seems like ReWork is a lot more in depth.
 
You must log in or register to reply here.
Top Bottom
Back