Getting Real

Summary Written by Parin Patel
"Getting Real delivers better results because it forces you to deal with the actual problems you’re trying to solve instead of your ideas about those problems."

- Getting Real, page 2

The Big Idea

Embrace Constraints

"Let limitations guide you to creative solutions."- Getting Real, page 33

Wouldn’t it be nice to work on a project where there was no cap on budget?
Where you could hire as many people as you needed to get the job done?
Where you weren’t forced to meet hard deadlines?
Where you could spend as much time as you wanted on your projects?

Well, that might be a good thing if you didn’t care about actually bringing your idea into the real world.

Not so much if you actually do.

Having these constraints is actually a good thing. They not only force you to make decisions that move your project forward, but they also guide you throughout the project.

So constraints should be embraced. Not shunned.

“There’s never enough to go around. Not enough time. Not enough money. Not enough people. That’s a good thing. Instead of freaking out about these constraints, embrace them. Let them guide you. Constraints drive innovation and force focus. Instead of trying to remove them, use them to your advantage.”

Insight #1

Fix Time and Budget, Flex Scope

"Here’s an easy way to launch on time and on budget: keep them fixed. Never throw more time or money at a problem, just scale back the scope."- Getting Real, page 19

One of the biggest reasons for failure in any project – whether it’s a software project or not – is not a lack of boundaries and constraints, but rather a lack of commitment to these.

We set certain time and budget constraints when we start, but as we move forward, we can’t help but increase them. I know I’ve done this.

You want some more time to add that extra signup form on your blog.
You want to wait until you develop a mobile app to launch your web-based product.
You want to add scalability for millions of users right away (before you even have ten).

We have a habit of wanting more and adding more, and as a result, we have to increase our time and budget. But the sad reality is that if we wait until “we have it all ready”, we’re either not going to launch at all, or we’re going to spend unnecessary time behind features that might not even be used.

Those in the software industry will recognize this as Feature Creep or Bloatware.

So it’s important to keep your time and budget fixed, and stay flexible in scope (meaning, scope down) so you can launch on time and on budget.

“There’s always time to add stuff later – later is eternal, now is fleeting,” write the authors.

So what’s the best way to scope down? Start With No.

Join our newsletter

Sign up for the very best book summaries right to your inbox.
We care about your data in our privacy policy.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Insight #2

Start With No

"Each time you say yes to a feature, you’re adopting a child. You have to take your baby through the whole chain of events (e.g. design, implementation, testing, etc.). And once that feature is out there, you’re stuck with it. Just try to take a released feature away from customers and see how pissed off they get."- Getting Real, page 51

Your best friend in fixing time and budget, and staying flexible in scope, is to start with no.
Anytime you come up with, or are presented with, a new feature, always say no first.

“Don’t be a yes-man,” the writers advocate. “Make each feature work hard to be implemented. Make each feature prove itself and show that it’s a survivor. It’s like ‘Fight Club’. You should only consider features if they’re willing to stand on the porch for three days waiting to be let in.”

This is one of the reasons why Steve Jobs was revered as a leader and innovator.

He knew when to say no. He knew that “innovation is not about saying yes to everything. It’s about saying NO to all but the most crucial features.”

“That’s why you start with no,” explain the authors. “Every new feature request that comes to us – or from us – meets a no. We listen but don’t act. The initial response is ‘not now.’ If a request for a feature keeps coming back, that’s when we know it’s time to take a deeper look. Then, and only then, do we start considering the feature for real.”

While Getting Real is primarily targeted towards web application development, anyone working on any kind of project can still benefit from the Getting Real practices such as Embracing Constraints, Saying No, Alone Time, and many more. But if you are involved in the development of any kind of software – whether you’re a developer or not – do yourself a favor and read Getting Real.

Read the book

Get Getting Real on Amazon.

David Heinemeier Hansson

From http://david.heinemeierhansson.com:

Subscribe to digest