Book Cover image

Getting Real by Jason Fried & David Heinemeier Hansson

Totally Scientific Rating: ā­ā­ā­ā­

Get it on Amazon.

Book cover

Getting Real by Jason Fried & David Heinemeier Hansson

Totally Scientific Rating: ā­ā­ā­ā­

Get it on Amazon.


This Book in a Minute (Or Less)

From start to finish, this book takes you through the (best) decisions needed to bring a software product from the customer's need to production. Through the lens of Basecamp founders, the lessons included are part recipe, part documentation of what worked for them. Lucky for us, general principles are many and our software should only gain from them.


Summary Notes

A successful web application starts from the customer, what they experience, and we go "backwards" from there, and into a solution. Getting Real is about accomplishing this while staying as small and agile as possible.

"Small and agile" means faster iterations around the cycle:

  • build;
  • launch;
  • tweak;
  • repeat;

The key is the learnings we get from putting our product out there, so for that to happen we actually have to ship it. Let the user be the judge.

This is not an excuse to ship poor quality software. It's an encouragement to build fewer features, but quality ones. Ship even with minor bugs as long as the core features are nailed. You get the customer feedback and at the same time you fix the bugs.

The Starting Line

Do less than your competitors. Let them wrestle with the complex problems, while you distill and build what the user really needs.

Start by scratching your own itch. Be the target audience and your own customer. By solving your problems, you're creating a tool with a stake on it, and with an extra layer of passion. And passion is key.

Embrace constraints as they are an engine for creativity. Even when money seems to be the issue, think again. Reduce the scope and stay small. Better launching something great but very small in scope, than something full of features that no one uses by necessity or crashes.

Prioritize for the first release. Keep your expectations in check. Don't try to conquer the world on version 0.1.

Understand and communicate what your product is about and what definitely isn't.

You must tell a different story and persuade listeners that yours is much more important than the story they currently believe. - Seth Godin

Always ask yourself: what is the key problem we are here to solve? How can we solve it?

Find a problem that you would love solving. That will shine through your product.

Stay Lean

ā€œWhen it comes to web technologies, change must be easy and cheapā€.

Another advantage of being small is you can actually talk with your customers and gain valuable insights in the process.

Priorities

Explicitly define the one-point vision for your app:

  • What does your app stand for?
  • What it is really about?

Start with the why. Before designing or coding anything you need to know the purpose of your product.

Organizations need guideposts. They need an outline; employees need to know each day when they wake up why theyā€™re going to work. This outline should be short and sweet, and all-encompassing: Why do you exist? - Guy Kawasaki

Ignore details early. Thereā€™s plenty of time to be a perfectionist. Solve problems when you have them, not if you predict you will.

ā€œFind the core market for your application and focus solely on them.ā€

This focus comes from a precisely defined vision from your product.

Now that we have a tightly defined audience, we can advertise where they frequent online, publish articles they might find interesting, and generally build a community around our product. - David Greiner

Don't even try to make a great app for everyone. That's the recipe for making an app for no one. Make a great app for someone.

Feature Selection

Stick to whatā€™s truly essential and build only that. Features need to work really hard to be implemented. The advantages are many, but at the front comes the more focused product you end up building and the less ground you have to cover to support it.

ā€œBuild software for general concepts and encourage people to create their own solutions.ā€

More isnā€™t always the answer.

ā€œSometimes the biggest favor you can do for customers is to leave something out.ā€

Process

ā€œWith real, running software everyone gets closer to true understanding and agreement.ā€

With a product online thereā€™s no need to ship perfection. You can update it in seconds. Trust the iterative process lets and continue to make informed decisions as you go along.

Be An Executioner: value the importance of moving on and moving forward.

Thereā€™s no substitute for real people using your app in real ways, and mistakes are exactly what youā€™re looking for.

The Organization

ā€œIntegrate your team so thereā€™s a healthy back-and-forth dialogue throughout the process.ā€

Getting in the zone takes time and it is when you are most productive.

Make meetings work hard to be scheduled. Meetings usually arise when a concept isnā€™t clear enough. Find ways to clarify things without disrupting people's flow.

ā€œQuick wins that you can celebrate are great motivators. If you let lengthy release cycles quash quick wins, you kill the motivation. And that can kill your product.ā€

Interface Design

Design the interface before you start programming: programming is the heaviest component of building an app, meaning itā€™s the most expensive and hardest to change vs design, which is relatively light.

The interface is your product. What people see is what youā€™re selling, and there are questions you can only truly answer when youā€™re dealing with real screens.

ā€œWhen someone signs up, they start with a blank slate and the customer decides if an application is worthy at this blank slate stage.ā€

ā€œGive people just what matters. Give them what they need when they need it and get rid of what they donā€™t.ā€

Code

Each minor snippet you add to your code has a cascading effect.

ā€œThe key is to restate any hard problem that requires a lot of software into a simple problem that requires much less.ā€

Donā€™t be afraid to say no to feature requests that are hard to do. If you anticipate that a new feature will cost weeks and thousands of lines of code that's probably your code telling you there's probably a better way.

Plan with the certainty that you will need to pay technical and design debt.

Words

Write a short story about what your app needs to do.

Begin building the interface, draw some quick and simple paper sketches, then start coding it into HTML. Build an interface you can look at, use, and ā€œfeelā€ before you start worrying about back-end code.

Something we are all guilty of, but when we enter fake, random, data in forms we donā€™t know what it really feels like to fill them. That's the opposite of what we want for the product we build. We want to feel as closely as possible what the user feels.

ā€œYour product has a voice ā€“ and itā€™s talking to your customers 24 hours a day.ā€

Pricing and Signup

ā€œGive something away for free. We want people to try the product, the interface, the usefulness of what weā€™ve built.ā€

Promotion

Go through these three phases: tease, preview, launch.

Teaser:

  • Stay vague but plant a seed;
  • Get a landing page up where you can collect emails of the most interested people.

Preview:

  • Give people behind-the-scenes access;
  • Describe the theme of the product;
  • Tell about the ideas and principles behind the app.

Launch:

  • Spread the message as much as possible;
  • Use the momentum and keep moving.

Find about where people are talking about your product, interact with them, diffuse potential negative views.

Give your app a name thatā€™s easy to remember. More than name that describes the product we want to be memorable.

Support

Listening to customers is the best way to get a sense of your productā€™s strengths and weaknesses. Remove as many intermediates between you and the voice of your customers.

ā€œCustomers appreciate directness and will often shift from angry to polite if you respond quickly and in a straight-shooting manner.ā€

If something goes wrong, tell people!

Good news, on the other hand, should be released slowly. If you can prolong the good vibes, do it.

Customers donā€™t expect your product to be perfect and they donā€™t expect that all of their features will be implemented. However, customers do expect that you are listening and acknowledging that you care, so show that you care. - Michael Reining

When selecting features to implement the customers is not always right. You wonā€™t love your product if itā€™s filled with stuff you donā€™t agree with.

Post-Launch

Quick updates show momentum and that you are listening to customers.

Show your product is alive by keeping an ongoing product development blog. It makes your company seem more human and not an industrial conglomerate of 100k people.

Prioritize bugs and even ignore some of them.

Don't panic and keep on your path. Just because some things might go wrong it doesn't mean you should put all your product philosophy in question.

Be open to the fact that your original idea might not be as special as you thought, or even your best one (It probably won't be).



If you enjoyed this, there are many others to come.

This Week's Worth preamble

This is my (almost) weekly newsletter.

You should consider be part of it to stay on top of new articles and other stuff I have yet to figure out. Yup, I'm improvising here.