“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.” (Click to Tweet!)
Getting Real, page 2
We all know that it’s not about ideas – it’s about what you do with those ideas. Whether you let them sit on the Post-it note in your head, or take them for a walk in the real world.
So why is it that we have so many ideas, with so little execution?
And of the ideas we act on, why is it that our projects sometimes get delayed? And perhaps more importantly, how can you stop that, and just plain execute?
How can you just get your world-changing idea out there, in the real world?
Well, as software company 37signals would say, “It’s time to Get Real.”
Founders of the widely popular Ruby on Rails open-source web application framework, 37signals is known for not only generating ideas, but also executing on them successfully. The company is led by Inc. Magazine Columnist Jason Fried, and has launched six web applications since it was founded in 1999. The most popular of which is project-management tool Basecamp.
And in their book Getting Real: The Smarter, Faster, Easier Way to Build a Successful Web Application, 37signals’ Jason Fried, David Heinemeier Hansson, and Matthew Linderman share the exact process they used to not only focus on solving the problem they actually set out to solve, but also how you can keep that focus throughout your project lifetime.
This process is called Getting Real and it all starts with embracing constraints.
“Let limitations guide you to creative solutions.” (Click to Tweet!)
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.” (Click to Tweet!)
Getting Real, page 33
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.” (Click to Tweet!)
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.
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.
“Sure, Getting Real is about building great software. But there’s no reason why it needs to stop there. Take these ideas and try applying them to different aspects of your life. You might just stumble upon some neat results.”
Getting Real, page 170