August 18, 2012 - No Comments!

Getting Real Excerpt

Starting Line

Build Less

  • Less features
  • Less options/preferences
  • Less people and corporate structure Less meetings and abstractions
  • Less promises

What’s Your Problem?

  • Build software for yourself

Fund yourself

  • Outside money is plan B
  • Constrains drive innovation

Launch on time and on budget

  • Prioritization
  • Reality
  • Flexibility

Stay Lean

Mass is increased by…

  • Long term contracts
  • Excess staff
  • Permanent decisions
  • Meetings about other meetings Thick process
  • Inventory (physical or mental) Hardware, software, technology lock-ins Proprietary data formats
  • The past ruling the future
  • Long-term roadmaps
  • Office politics

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

The Three Musketeers

For the first version of your app, start with only three people. That’s the magic number that will give you enough manpower yet allow you to stay streamlined and agile. Start with a developer, a designer, and a sweeper (someone who can roam between both worlds).

Now sure, it’s a challenge to build an app with only a few people. But if you’ve got the right team, it’s worth it. Talented people don’t need endless resources. They thrive on the challenge of working within restraints and using their creativity to solve problems. Your lack of manpower means you’ll be forced to deal with tradeoffs earlier in the process – and that’s alright. It will make you figure out your priorities earlier rather than later. And you’ll be able to communicate without constantly having to worry about leaving people out of the loop.

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. You’ll quickly get to see if your idea has wings and, if it does, you’ll have a clean, simple base to build on.


Whats the Big Idea

  • Basecamp: Project management is communication
  • Backpack: Bring life’s loose ends together
  • Campfire: Group chat over IM sucks
  • Ta-da List: Competing with a post-it note
  • Writeboard: Word is overkill

Make Mantra

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? What motivates you? I call this a mantra – a three or four word description of why you exist.
—Guy Kawasaki

The Devil’s in the Details

I really got over the “get into details right away” attitude after I took some drawing classes…If you begin to draw the details right away you can be sure that the drawing is going to suck. In fact, you are completely missing the point.

You should begin by getting your proportions right for the whole scene. Then you sketch the largest objects in your scene, up to the smallest one. The sketch must be very loose up to this point.

Then you can proceed with shading which consists of bringing volume to life. You begin with only three tones (light, medium, dark). This gives you a tonal sketch. Then for each portion of your drawing you reevaluate three tonal shades and apply them. Do it until the volumes are there (requires multiple iteration)…

Work from large to small. Always.
—Patrick Lafleur

It’s a Problem When It’s a Problem

People often spend too much time up front trying to solve problems they don’t even have yet. Don’t. Heck, we launched Basecamp without the ability to bill customers! Since the product billed in monthly cycles, we knew we had a 30-day gap to figure it out. We used that time to solve more urgent problems and then, after launch, we tackled billing. It worked out fine (and it forced us into a simple solution without unnecessary bells and whistles).

Don’t sweat stuff until you actually must. Don’t overbuild. Increase hardware and system software as necessary. If you’re slow for a week or two it’s not the end of the world. Just be honest: explain to your customers you’re experiencing some growing pains. They may not be thrilled but they’ll appreciate the candor.

Bottom Line: Make decisions just in time, when you have access to the real information you need. In the meanwhile, you’ll be able to lavish attention on the things that require immediate care.

Feature Selection

Half, Not Half-Assed

  • Build half a product, not a half-ass product
  • Take whatever you think your product should be and cut it in half.
  • If it doesn’t change your behavior, then it just doesn’t matter.
  • Don’t be a yes-man — 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.
  • Forget Feature Requests. Ask people what they DON’T want

Start With No

People kept raising their hand saying, “Does it do [x]?”, “DO you plan to add [y]?”. Finally Jobs said, “Wait wait — put your hands down. listen: I know you have a thousands ideas for all the cool features iTunes could have. So do we. But we don’t we a thousands features. That would be ugly. Innovation isn’t about saying yes to everything. Its about saying NO to all but the most crucial
—Derek Sivers

For every new feature you need to…

  1. Say no.
  2. Force the feature to prove its value.
  3. If “no” again, end here. If “yes,” continue…
  4. Sketch the screen(s)/ui.
  5. Design the screen(s)/ui.
  6. Code it.
  7. to 15. Test, tweak, test, tweak, test, tweak, test, tweak…
  8. Check to see if help text needs to be modified.
  9. Update the product tour (if necessary).
  10. Update the marketing copy (if necessary).
  11. Update the terms of service (if necessary).
  12. Check to see if any promises were broken.
  13. Check to see if pricing structure is affected.
  14. Launch.
  15. Hold breath.

Innovation Comes From Saying No

[Innovation] comes from saying no to 1,000 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


  • Get something real up and running quickly
  • Rinse and Repeat. Work in iterations
  • Iterations lead to liberation

Maybe you’re smarter than me

Maybe you’re a LOT smarter than me.

It’s entirely possible. In fact, it’s likely. However, if you’re like most people, then like me, you have trouble imagining what you can’t see and feel and touch.

Human beings are extremely good at responding to things in the environment. We know how to panic when a tiger enters the room, and how to clean up after a devastating flood. Unfortunately, we’re terrible at planning ahead, at understanding the ramifications of our actions and in prioritizing the stuff that really matters.

Perhaps you are one of the few individuals who can keep it all in your head. It doesn’t really matter. Web 2.0, the world where we start by assuming that everyone already uses the web, allows smart developers to put this human frailty to work for them. How? By allowing your users to tell you what they think while there’s still time to do something about it.

And that last sentence explains why you should develop this way and how you might want to promote/launch.

Get your story straight. Make sure the pieces work.Then launch and revise.

No one is as smart as all of us.
—Seth Godin

Be an executioner

It’s so funny when I hear people being so protective of ideas. (People who want me to sign an NDA to tell me the simplest idea.)

To me, ideas are worth nothing unless executed.They are just a multiplier. Execution is worth millions.


  • Awful idea = -1
  • Weak idea = 1
  • So-so idea = 5
  • Good idea = 10
  • Great idea = 15
  • Brilliant idea = 20


  • 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, you need to multiply the two.

The most brilliant idea, with no execution, is worth $20.The most brilliant idea takes great execution to be worth $20,000,000.

That’s why I don’t want to hear people’s ideas. I’m not interested until I see their execution.
—Derek Sivers

Do it quick

  1. Decide if it’s worth doing, and if so:
  2. Do it quick – not perfect. just do it.
  3. Save it. upload it. publish it
  4. See what people think

Though I’m always reluctant to add new features to things, once I have that “yeah!” moment of deciding something is worth doing, it’s usually up on the website a few hours later, flawed but launched, letting feedback guide future refinement of it.
—Derek Sivers

The Organization

People need uninterrupted time to get things done

The alone time zone is where the real development magic happens. Set up a rule at work: Make half the day alone time. From 10am-2pm, no one can talk to one another (except during lunch). Or make the first or the last half of the day the alone time period. Just make sure this period is contiguous in order to avoid productivity-killing interruptions.

Don’t have meetings

For those times when you absolutely must have a meeting (this should be a rare event), stick to these simple rules:
- Set a 30 minute timer.When it rings, meeting’s over. Period.
- Invite as few people as possible.
- Never have a meeting without a clear agenda.


Hire Less, Hire Late

There’s no need to get big early – or later. Even if you have access to 100 of the very best people, it’s still a bad idea to try and hire them all at once. There’s no way that you can immediately assimilate that many people into a coherent culture. You’ll have training headaches, personality clashes, communication lapses, people going in different directions, and more.

Work with prospective employees on a test-basis first

It’s one thing to look at a portfolio, resume, code example, or previous work. It’s another thing to actually work with someone. Whenever possible, take potential new team members out for a “test drive.”

Judge potential tech hires on open source contributions

  • Quality of work
  • Cultural perspective
  • Level of passion
  • Completion percentage
  • Social match

Get well rounded individuals.

You want someone who can adjust and learn and flow as opposed to a stick-in-the-mud who can do only one thing.

  • Designers who can write.
  • Programmers who can understand design.
  • Everyone should have an idea about how to architect information.
  • Everyone needs to have an organized mind.
  • Everyone needs to be able to communicate with customers.

Interface Design

  • Design the interface before you start programming. Too many apps start with a program-first mentality. That’s a bad idea. Programming is the heaviest component of building an app, meaning it’s the most expensive and hardest to change. Instead, start by designing first.
  • The interface is your product. What people see is what you’re selling. If you just slap an interface on at the end, the gaps will show.
  • Start from the core of the page and build outward
  • Design three state solution. Regular, blank, and error states


Keep your code as simple as possible

You’d think that twice as much code would make your software only twice as complex. But actually, each time you increase the amount of code, your software grows exponentially more complicated. Each minor addition, each change, each interdependency, and each preference has a cascading effect. Keep adding code recklessly and, before you know it, you’ll have created the dreaded Big Ball of Mud.

The way you fight this complexity is with less software. Less software means less features, less code, less waste.


There’s Nothing Functional about a Functional Spec

  • Don’t write a functional specifications document
  • Functional specs are fantasies
  • Functional specs are about appeasement
  • Functional specs only lead to an illusion of agreement
  • Functional specs force you to make the most important decisions when you have the least information
  • Functional specs lead to feature overload
  • Functional specs don’t let you evolve, change,and reassess

Eliminate unnecessary paperwork

Avoiding functional specs is a good start but don’t stop there; Prevent excess paperwork everywhere. Unless a document is actually going to morph into something real, don’t produce it.

Build, don’t write. If you need to explain something, try mocking it up and prototyping it rather than writing a long- winded document. An actual interface or prototype is on its way to becoming a real product. A piece of paper, on the other hand, is only on its way to the garbage can.

Tell Me a Quick Story.

Write stories, not details. If you do find yourself requiring words to explain a new feature or concept, write a brief story about it. Don’t get into the technical or design details, just tell a quick story. Do it in a human way, like you would in normal conversation.

It doesn’t need to be an essay. Just give the flow of what happens. And if you can include the brief story in context with screens you are developing, all the better.

Stick to the experience instead of getting hung up on the details. Think strategy, not tactics. The tactics will fall into place once you begin building that part of your app. Right now you just want to get a story going that will initiate conversation and get you on the right track.

Use Real Words.

Insert actual text instead of lorem ipsum. You need real copy to know how long certain fields should be. You need real copy to see how tables will expand or contract. You need real copy to know what your app truly looks like.

Personify your Product

What is your product’s personality type? Think of your product as a person. What type of person do you want it to be? Polite? Stern? Forgiving? Strict? Funny? Deadpan? Serious? Loose? Do you want to come off as paranoid or trust- ing? As a know-it-all? Or modest and likable?

Pricing and Signup

  • Give something away for free
  • Make signup and cancellation a painless process
  • Avoid long-term contracts, sign-up fees, etc.
  • Soften the blow of bad news with advance notice and grandfather clauses


Hollywood Launch

Go from teaser to preview to launch. If an app launches in a forest and there’s no one there to use it, does it make a noise? The point here is that if you launch your app without any pre-hype, people aren’t going to know about it.

To build up buzz and anticipation, go with a Hollywood-style launch: 1) Teaser, 2) Preview, and 3) Launch.

A few months ahead of time, start dropping hints. Let people know what you’re working on. Post a logo. Post to your blog about the development. Stay vague but plant the seed. Also, get a site up where you can collect emails from folks who are interested.

You should also start seducing mavens and insiders. These are the folks on the cutting edge. They’re the tastemakers. Appeal to their vanity and status as ahead-of-the-curves. Tell them they’re getting an exclusive sneak preview. If a site like Boing Boing, Slashdot, or Digg links up your app, you’ll get loads of traffic and followers. Plus, your page rank at Google will go up too.

A few weeks ahead of launch, start previewing features. Give people behind-the-scenes access. Describe the theme of the product. Also, tell people about the ideas and principles behind the app. You can also offer some special “golden tickets” to a few people so they can start using the app early. You’ll get the benefit of having some beta testers while they’ll feel that special glow that people get from being early adopters.

It’s release time. Now people can actually go to the “theater” and see your app. Get emails out to those who signed up. Launch your full marketing site. Spread the gospel as much as possible. Get blogs to link to you. Post about your progress: How many people have signed up? What updates/tweaks have you made? Show momentum and keep at it.

A Powerful Promo 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’s possible.
  • Buzz: Testimonial quotes from customers, reviews, press, etc.
  • Forum: Offer a place for members of the community to help one another.
  • Pricing & Sign-up: Get people into your app as quickly as possible.
  • Weblog: Blogs keep your site fresh with news, tips, etc

Name Hook

Give your app a name that’s easy to remember. A big mistake a lot of people make is thinking their app’s name needs to be ultra-descriptive. Don’t worry about picking a name that vividly describes your tool’s purpose; That usually just leads to a generic, forgettable name. Basecamp is a better name than something like Project Management Center or ProjectExpress.
Writeboard is better than CollaborEdit.


Feel the Pain

Tear down the walls between support and development. In the restaurant business, there’s a world of difference between those working in the kitchen and those out front who deal with customers. It’s important for both sides to understand and empathize with the other. That’s why cooking schools and restaurants will often have chefs work out front as waiters so the kitchen staff can interact with customers and see what it’s actually like on the front lines.

A lot of software developers have a similar split. Designers and programmers work in the “kitchen” while support handles the customers. Unfortunately, that means the software chefs never get to hear what customers are actually saying. That’s problematic because listening to customers is the best way to get in tune with your product’s strengths and weaknesses.

The solution? Avoid building walls between your customers and the development/design team. Don’t outsource customer support to a call center or third party. Do it yourself. You, and your whole team, should know what your customers are saying. When your customers are annoyed, you need to know about it. You need to hear their complaints. You need to get annoyed too.

Publicize Your Screwups

If something goes wrong, tell people. Even if they never saw it in the first place.


  • Issue a major update 30 days after launch
  • Keep the Posts Coming. Show your product is alive by keeping an ongoing product development blog post-launch. Things to include (Faqs, How-tos, Tips & tricks, New features, updates, & fixes, Buzz/press)
  • All Bugs Are Not Created Equal. Prioritize your bugs (and even ignore some of them)
  • Go With the Flow. Be open to new paths and changes in direction

Start Your Engines


Everyone can read a book. Everyone can come up with an idea. Everyone has a cousin that’s a web designer. Everyone can write a blog. Everyone can hire someone to hack together some code.
The difference between you and everyone else will be how well you execute. Success is all about great execution.


You need people who are passionate about what they do. People who care about their craft. People who take pride in the work, regardless of the monetary reward involved. People who sweat the details even if 95% of folks don’t know the difference. Anyhow, when you find those people, hold onto them. In the end, the folks on your team will make or break your project - and your company.
More than just software

More than just software

It’s also worth noting that the concept of Getting Real doesn’t apply just to building a web app. Once you start grasping the ideas involved, you’ll see them all over the place.

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.

Grab a Copy

This is one of the best books that I have enjoyed and learned from. You can buy the book from Amazon Getting Real

Published by: Seif in Uncategorized

Leave a Reply