Skip to content
Switch branches/tags
Go to file
Cannot retrieve contributors at this time

Getting Real

Product Development from

The smarter, faster, easier way to build a successful web application


We lowered our cost of change by always building less software. We gave people just enough features to solve their own problems their own way – and then we got out of the way. Your app should take sides: the best software has a vision.

Good apps DON'T try to be all things to all people. They have an attitude. They seek out customers who are actually partners. They speak to people who share our vision. You’re either on the bus or off the bus.

Getting Real

Want to build a successful web app? Then it’s time to Get Real. Getting Real is a smaller, faster, better way to build software.

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. It forces you to deal with reality.

Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all sentences short or avoid all detail and treat subjects only in outline, but that every word tell.

Our modus operandi We believe software is too complex. Too many features, too many buttons, too much to learn. Our products do less than the competition – intentionally.

We’re just telling you how we work and what’s been successful for us.

If our tone seems too know-it-allish, bear with us. We think it’s better to present ideas in bold strokes than to be wishy-washy about it. If that comes off as cocky or arrogant, so be it. We’d rather be provocative than water everything down with “it depends...”

The Starting Line

  • Build Less
  • What’s Your Problem?
  • Fund Yourself
  • Fix Time and Budget, Flex Scope
  • Have an Enemy
  • It Shouldn’t be a Chore

Built Less

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.

If you can’t fit everything in within the time and budget allotted then don’t expand the time and budget. Instead, pull back the scope. There’s always time to add stuff later – later is eternal, now is fleeting.

> If your app doesn’t excite you, something’s wrong. If you’re only

working on it in order to cash out, it will show. Likewise, if you feel passionately about your app, it will come through in the final product. People can read between the lines.

Stay Lean

  • Less Mass
  • Lower Your Cost of Change
  • The Three Musketeers
  • Embrace Constraints
  • Be Yourself

Mass is reduced by...

  • Just-in-time thinking
  • Multi-tasking team members
  • Embracing constraints, not trying to lift them
  • Less software, less code
  • Less features
  • Small team size
  • Simplicity
  • Pared-down interfaces
  • Open-source products
  • Open data formats
  • An open culture that makes it easy to admit mistakes

Stay flexible by reducing obstacles to change. Change is your best friend. The more expensive it is to make a change, the less likely you’ll make it.

if your competitors can change faster than you, you’re at a huge disadvantage. If change gets too expensive you’re dead.

If you can’t build your version one with three people, then you either need different people or need to slim down your initial version. Remember, it’s ok to keep your first version small and tight

Metcalfe’s Law and project teams

Keep the team as small as possible. Metcalfe’s Law, that “the value of a communication system grows at approximately the square of the number of users of the system,” has a corollary when it comes to project teams: The efficiency of the team is approximately the inverse of the square of the number of members in the team. I’m beginning to think three people is optimal for a 1.0 product release...Start out by reducing the number of people you plan to add to the team, and then reduce some more.

Explicitly define the one-point vision for your app

What does your app stand for? What’s it really all about?

Before you start designing or coding anything you need to know the purpose of your product – the vision.


Think big. Why does Lift exist? What makes it different than other similar products?

This vision will guide your decisions and keep you on a consistent path. Whenever there’s a sticking point, ask, “Are we staying true to the vision?”

Your vision should be brief. One sentence should be enough to get the idea across.

Err in favor of users.

It will guide those tricky decisions you make while building something complex. The vision, and erring in favour of users will be the laws our application development.

Your app should take sides Some people argue software should be agnostic. They say it’s ar- rogant for developers to limit features or ignore feature requests. They say software should always be as flexible as possible. We think that’s bullshit. The best software has a vision.

Feature Selection

Half, Not Half-Assed

Throw in every decent idea that comes along and you’ll just wind up with a half-assed version of your product. What you really want to do is build half a product that kicks ass.

Take whatever you think your product should be and cut it in half. Pare features down until you’re left with only the most essential ones. Then do it again.

  • Just Doesn’t Matter
  • Start With No Hidden Costs
  • Can You Handle It?
  • Human Solutions
  • Forget Feature Requests
  • Hold the Mayo

Ask people what they don’t want

Most software research asks whether something is missing or what one would add. Why not ask people what they don’t want?

“If you could remove one feature, what would it be?” “What don’t you use?” “What gets in your way the most?”

More isn’t the answer.

Sometimes the biggest favor you can do for customers is to leave something out.

Innovation comes from saying no to 1000 things to make sure we don’t get on the wrong track or try to do too much. We’re always thinking about new markets we could enter, but it’s only by saying NO that you can concentrate on the things that are really important. -Steve Jobs


  • Race to Running Software Rinse and Repeat
  • From Idea to Implementation Avoid Preferences
  • “Done!”
  • Test in the Wild
  • Shrink Your Time

From Idea to Implementation

brainstorm -> sketches -> html -> coding

1. Brainstorm

What is the product going to do? Not the nitty gritty, but high-level jobs to be done.

2. Paper Sketches

Use PAPER. Write it down! Be crude: boxes, circles, lines.

get concepts out of your head and on to paper. Focus on converting concepts into an interface

3. Brainstorm

Get something real in HTML so everyone can see what it looks like! Starting to get more concrete. Dont write any code yet, just sketch out the interface.

4. Code

If mock ups look good, and demonstate functionality, get to coding it up.

Avoid Preferences

Make decisions for your users so they don't have to! Providing options to a user is the easy way out. Options are a way to avoid making decisions, and they burden your user with busy work.

Preference are evil because they create more software. More options, more code, more testing, more designing.

Be disciplined about the defaults instead of lazily adding preferences.


Decisions are temporary. Make them and move on. Done is a magical word. Build momentum by making decisions quickly and moving on. Make the quick, simple call and move on. Execute, build momentum, move on.

Derek Sivers version of ideas are worthless:

ideas are worth nothing until executed. Ideas are a multiplier of execution.

For example:

Bad idea: -1 so-so idea: 2 Brilliant idea: 10

No execution: $1 Weak execution: $1000 So-So execution: $10,000 Good execution: $100,000 Great execution: $1,000,000 Brilliant execution: $10,000,000

To make a business, multiple the two. Obviously the key is execusion.

Test in the Wild