![]() |
|
Getting Real
Here are the 16 chapters and 91 essays that make up the book.
Introduction chapter 1
The Starting Line chapter 2
Stay Lean chapter 3
Priorities chapter 4
Feature Selection chapter 5
Process chapter 6
The Organization chapter 7
Staffing chapter 8
Interface Design chapter 9
Code chapter 10
Words chapter 11
Pricing and Signup chapter 12
Promotion chapter 13
Support chapter 14
Post-Launch chapter 15
Conclusion chapter 16
 |
Buy your own copy of Getting Real
You've browsed the site and read some chapters, now get your own copy of the book in paperback or PDF.
"Every once in a while, a book comes out of left field that changes just about everything. This is one of those books. Ignore it at your peril."
—Seth Godin, Author
|
| Note: The text on this web site and the text in the book is identical. Buying the PDF or paperback version allow you to take the content with you and show your support for the Getting Real movement. Thanks for your business. |
All content copyright ©1999-2006 37signals, LLC. All rights reserved. No part of this book or site may be reproduced or redistributed in any form or by any electronic or mechanical means, including information storage and retrieval systems, without permission in writing from 37signals, except by a reviewer who may quote brief passages in a review.
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 is staying small and being agile.
Getting Real starts with the interface, the real screens that
people are going to use. It begins with what the customer
actually experiences and builds backwards from there. This lets
you get the interface right before you get the software wrong.
Getting Real is about iterations and lowering the
cost of change. Getting Real is all about launching,
tweaking, and constantly improving which makes
it a perfect approach for web-based software.
Getting Real delivers just what customers need
and eliminates anything they don't.
Meaningless version numbers
We build products that work
smarter, feel better, allow you to do things your way, and are
easier to use.
Here are the benefits of fixing time and budget, and keeping scope flexible:
Prioritization You have to figure out what's really important. What's going to make it into this initial release? This forces a constraint on you which will push you to make tough decisions instead of hemming and hawing.Reality Setting expectations is key. If you try to fix time, budget, and scope, you won't be able to deliver at a high level of quality. Sure, you can probably deliver something, but is "something" what you really want to deliver?Flexibility The ability to change is key. Having everything fixed makes it tough to change. Injecting scope flexibility will introduce options based on your real experience building the product. Flexibility is your friend. Our recommendation: Scope down. It's better to make half a product than a half-assed product (more on this later).
Our enemy was the Project Management Dictators and the tools they used to crack the whip. We wanted to democratize project management — make it something everyone was a part of (including the client). Projects turn out better when everyone takes collective ownership of the process.
One bonus you get from having an enemy is a very clear marketing message. People are stoked by conflict. And they also understand a product by comparing it to others. With a chosen enemy, you're feeding people a story they want to hear. Not only will they understand your product better and faster, they'll take sides. And that's a sure-fire way to get attention and ignite passion.
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
Stay flexible by reducing obstacles to change
Start with a developer, a designer, and a sweeper (someone who can roam between both worlds).
Differentiate yourself from bigger companies by being
personal and friendly
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 it exist? What makes it different than other similar products?
Your vision should be brief too. A sentence should be enough to get the idea across. Here's the vision for each of our products:
- 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
Your app should take sides
Some people argue software should be agnostic. They say it's arrogant 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. The best software takes sides. When someone uses software, they're not just looking for features, they're looking for an approach. They're looking for a vision. Decide what your vision is and run with it.
Most of the time you spend is wasted on things that just don't matter. If you can cut out the work and thinking that just don't matter, you'll achieve productivity you've never imagined.
That's why you start with no. 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.
And what do you say to people who complain when you won't adopt their feature idea? Remind them why they like the app in the first place. "You like it because we say no. You like it because it doesn't do 100 other things. You like it because it doesn't try to please everyone all the time."
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-15. Test, tweak, test, tweak, test, tweak, test, tweak...
- 16. Check to see if help text needs to be modified.
- 17. Update the product tour (if necessary).
- 18. Update the marketing copy (if necessary).
- 19. Update the terms of service (if necessary).
- 20. Check to see if any promises were broken.
- 21. Check to see if pricing structure is affected.
- 22. Launch.
- 23. Hold breath.
Build something you can manage
Build software for general concepts and encourage people to create their own solutions
Don't force conventions on people. Instead make your software general so everyone can find their own solution. Give people just enough to solve their own problems their own way. And then get out of the way.
Let your customers remind you what's important
Customers want everything under the sun. They'll avalanche you with feature requests. Just check out our product forums; The feature request category always trumps the others by a wide margin.
So what do you do with all these requests that pour in? Where do you store them? How do you manage them? You don't. Just read them and then throw them away.
Yup, read them, throw them away, and forget them. It sounds blasphemous but the ones that are important will keep bubbling up anyway. Those are the only ones you need to remember. Those are the truly essential ones. Don't worry about tracking and saving each request that comes in. Let your customers be your memory. If it's really worth remembering, they'll remind you until you can't forget.
Get something real up and running quickly
Running software is the best way to build momentum, rally your team, and flush out ideas that don't work. It should be your number one priority from day one.
Work in iterations
Don't expect to get it right the first time. Let the app grow and speak to you. Let it morph and evolve. With web-based software there's no need to ship perfection. Design screens, use them, analyze them, and then start over again.
No one is as smart as all of us.
Go from brainstorm to sketches to HTML to coding
Here's the process we use to Get Real:
Brainstorm
Come up with ideas. What is this product going to do? For Basecamp, we looked at our own needs. We wanted to post project updates. We wanted clients to participate. We knew that projects had milestones. We wanted to centralize archives so people could easily review old stuff. We wanted to have a big-picture, bird's-eye view of what's going on with all our projects. Together, those assumptions, and a few others, served as our foundation.
This stage is not about nitty gritty details. This is about big questions. What does the app need to do? How will we know when it's useful? What exactly are we going to make? This is about high level ideas, not pixel-level discussions. At this stage, those kinds of details just aren't meaningful.
Paper sketches
Sketches are quick, dirty, and cheap and that's exactly how you want to start out. Draw stuff. Scrawl stuff. Boxes, circles, lines. Get your ideas out of your head and onto paper. The goal at this point should be to convert concepts into rough interface designs. This step is all about experimentation. There are no wrong answers.
Create HTML screens
Make an html version of that feature (or section or flow, if it's more appropriate). Get something real posted so everyone can see what it looks like on screen.
For Basecamp, we first did the "post a message" screen, then the "edit a message" screen, and it went on from there.
Don't write any programming code yet. Just build a mock-up in html and css. Implementation comes later.
Code it
When the mock-up looks good and demonstrates enough of the necessary functionality, go ahead and plug in the programming code.
During this whole process remember to stay flexible and expect multiple iterations. You should feel free to throw away the deliverable of any particular step and start again if it turns out crappy. It's natural to go through this cycle multiple times.
Avoid Preferences
Decide the little details so your customers don't have to
You're faced with a tough decision: how many messages do we
include on each page? Your first inclination may be to say, "Let's
just make it a preference where people can choose 25, 50, or
100." That's the easy way out though. Just make a decision.
Preferences are a way to avoid making tough decisions
"Done!"
Decisions are temporary so make the call and move on
Done. Start to think of it as a magical word. When you get to done it means something's been accomplished. A decision has been made and you can move on. Done means you're building momentum.
But wait, what if you screw up and make the wrong call? It's ok. This isn't brain surgery, it's a web app.
Test your app via real world usage
There's no substitute for real people using your app in real ways. Get real data. Get real feedback. Then improve based on that info.
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.
Shrink Your Time
Break it down
Estimates that stretch into weeks or months are fantasies. The truth is you just don't know what's going to happen that far in advance.
Unity
Don't split into silos
Too many companies separate design, development, copywriting, support, and marketing into different silos. While specialization has its advantages, it also creates a situation where staffers see just their own little world instead of the entire context of the web app.
As much as possible, integrate your team so there's a healthy back-and-forth dialogue throughout the process. Set up a system of checks and balances. Don't let things get lost in translation. Have copywriters work with designers. Make sure support queries are seen by developers.
Even better, hire people with multiple talents who can wear different hats during development. The end result will be a more harmonious product.
Alone Time
People need uninterrupted time to get things done
Guess which part of the day we get the most work done? The alone part. It's not that surprising really. Many people prefer to work either early in the morning or late at night — times when they're not being bothered.
When you have a long stretch when you aren't bothered, you can get in the zone. The zone is when you are most productive. It's when you don't have to mindshift between various tasks. It's when you aren't interrupted to answer a question or look up something or send an email or answer an im. The alone zone is where real progress is made.
Getting in the zone takes time. And that's why interruption is your enemy. It's like rem sleep — you don't just go to rem sleep, you go to sleep first and you make your way to rem. Any interruptions force you to start over. rem is where the real sleep magic happens. The alone time zone is where the real development magic happens.
Meetings Are Toxic
Don't have meetings
Do you really need a meeting? Meetings usually arise when a concept isn't clear enough. Instead of resorting to a meeting, try to simplify the concept so you can discuss it quickly via email or im or Campfire. The goal is to avoid meetings. Every minute you avoid spending in a meeting is a minute you can get real work done instead.
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.
Seek and Celebrate Small Victories
Release something today
The most important thing in software development is motivation. Motivation is local — if you aren't motivated by what you are working on right now, then chances are it won't be as good as it should be. In fact, it's probably going to suck.
Long, drawn out release cycles are motivation killers. They insert too much time between celebrations. On the other hand, 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.
Hire Less and Hire Later
Add slow to go fast
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.
Kick the Tires
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."
Actions, Not Words
Judge potential tech hires on open source contributions
The typical method of hiring for technical positions — based on degrees, resumés, etc. — is silly in a lot of ways. Does it really matter where someone's degree is from or their gpa? Can you really trust a resumé or a reference?
Open source is a gift to those who need to hire technical people. With open source, you can track someone's work and contributions — good and bad — over a lengthy period of time.
Get Well Rounded Individuals
Go for quick learning generalists over ingrained specialists
We'll never hire someone who's an information architect. It's just too overly specific. With a small team like ours, it doesn't make sense to hire people with such a narrowly defined skill-set.
You Can't Fake Enthusiasm
Go for happy and average over frustrated and great
Enthusiasm. It's one attribute you just can't fake. When it comes time to hire, don't think you need a guru or a tech-celebrity. Often, they're just primadonnas anyway. A happy yet average employee is better than a disgruntled expert
Wordsmiths
Hire good writers
If you are trying to decide between a few people to fill a position, always hire the better writer. It doesn't matter if that person is a designer, programmer, marketer, salesperson, or whatever, the writing skills will pay off. Effective, concise writing and editing leads to effective, concise code, design, emails, instant messages, and more.
That's because being a good writer is about more than words. Good writers know how to communicate. They make things easy to understand. They can put themselves in someone else's shoes. They know what to omit. They think clearly. And those are the qualities you need.
An Organized Mind
Good writing skills are an indicator of an organized mind which is capable of
arranging information and argument in a systematic fashion and also helping
(not making) other people understand things. It spills over into code, personal
communications, instant messaging (for those long-distance collaborations),
and even such esoteric concepts as professionalism and reliability.
—Dustin J. Mitchell, developer (from Signal vs. Noise)
Clear Writing Leads To Clear Thinking
Clear writing leads to clear thinking. You don't know what you know until you try to express it. Good writing is partly a matter of character. Instead of doing what's easy for you, do what's easy for your reader.
—Michael A. Covington, Professor of Computer Science at The University of Georgia
(from How to Write More Clearly, Think More Clearly, and Learn Complex Material More Easily)
Interface First
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.
Epicenter Design
Start from the core of the page and build outward
Epicenter design focuses on the true essence of the page — the epicenter — and then builds outward. This means that, at the start, you ignore the extremities: the navigation/tabs, footer, colors, sidebar, logo, etc. Instead, you start at the epicenter and design the most important piece of content first.
Three State Solution
Design for regular, blank, and error states
For each screen, you need to consider three possible states:
- Regular
The screen people see when everything's working
fine and your app is flush with data.
- Blank
The screen people see when using the app for
the first time, before data is entered.
- Error
The screen people see when something goes wrong.
The Blank Slate
Set expectations with a thoughtful first-run experience
Ignoring the blank slate stage is one of the biggest mistakes you can make. The blank slate is your app's first impression and you never get a second...well, you know.
Get Defensive
Design for when things go wrong
Let's admit it: Things will go wrong online. No matter how carefully you design your app, no matter how much testing you do, customers will still encounter problems. So how do you handle these inevitable breakdowns? With defensive design.
Context Over Consistency
What makes sense here may not make sense there
Should actions be buttons or links? It depends on the action. Should a calendar view be in list-form or grid-form? It depends where it's being shown and how long the time period is. Does every global navigation link need to be on every page? Do you need a global search bar everywhere? Do you need the same exact footer on each page? The answer: "It depends."
That's why context is more important than consistency. It's ok to be inconsistent if your design makes more sense that way.
Copywriting is Interface Design
Every letter matters
Copywriting is interface design. Great interfaces are written. If you think every pixel, every icon, every typeface matters, then you also need to believe every letter matters. When you're writing your interface, always put yourself in the shoes of the person who's reading your interface. What do they need to know? How you can explain it succinctly and clearly?
One Interface
Incorporate admin functions into the public interface
Admin screens — the screens used to manage preferences, people, etc. — have a tendency to look like crap. That's because the majority of development time is spent on the public-facing interface instead.
To avoid crappy-admin-screen syndrome, don't build separate screens to deal with admin functions. Instead, build these functions (i.e. edit, add, delete) into the regular application interface.
Less Software
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.
Optimize for Happiness
Choose tools that keep your team excited and motivated
A happy programmer is a productive programmer. That's why we optimize for happiness and you should too. Don't just pick tools and practices based on industry standards or performance metrics. Look at the intangibles: Is there passion, pride, and craftmanship here? Would you truly be happy working in this environment eight hours a day?
Code Speaks
Listen when your code pushes back
Listen to your code. It will offer suggestions. It will push back. It will tell you where the pitfalls reside. It will suggest new ways to do things. It will help you stick to a model of less software.
Is a new feature requiring weeks of time and thousands of lines of code? That's your code telling you there's probably a better way. Is there a simple way to code something in one hour instead of a complicated way that will take ten hours? Again, that's your code guiding you. Listen.
Manage Debt
Pay off your code and design "bills"
We usually think of debt in terms of money but it comes in
other forms too. You can easily build up code and design debt.
Hack together some bad code that's functional but still a bit
hairy and you're building up debt. Throw together a design
that's good enough but not really good and you've done it again.
Open Doors
Get data out into the world via RSS, APIs, etc.
Don't try to lock-in your customers. Let them get their information when they want it and how they want it. To do that, you've got to give up the idea of sealing in data. Instead, let it run wild. Give people access to their information via rss feeds. Offer apis that let third-party developers build on to your tool. When you do, you make life more convenient for customers and expand the possibilities of what your app can do.
There's Nothing Functional about a
Functional Spec
Don't write a functional specifications document
These blueprint docs usually wind up having almost nothing to do with the finished product.
Don't Do Dead Documents
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 longwinded 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.
Use Real Words
Insert actual text instead of lorem ipsum
Lorem ipsum dolor is a trusted friend of designers. Dummy text helps people get what the design will look like once it's fleshed out. But dummy text can be dangerous too.
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 trusting? As a know-it-all? Or modest and likable?
Free Samples
Give something away for free
It's a noisy world out there. In order to get people to notice you amid the din, give something away for free.
Smart companies know giving away freebies is a great way to lure in customers. Look at Apple. They offer iTunes software for free in order to build demand for the iPod and the iTunes music store.
Easy On, Easy Off
Make signup and cancellation a painless process
Make it as easy as possible to get in — and get out — of your app.
Silly Rabbit, Tricks are for Kids
Avoid long-term contracts, sign-up fees, etc.
No one likes long term contracts, early termination fees, or one
time set-up fees. So avoid them. Our products bill on a month
to-month basis. There's no contract to sign and you can cancel
at any time without penalty. And there are never any set-up fees.
Don't try to find "tricky" ways to get more cash. Earn it.
A Softer Bullet
Soften the blow of bad news with advance notice and
grandfather clauses
Need to deliver bad news like a price increase? Make it as painless as possible by giving folks plenty of advance notice.
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 Powerful Promo Site
Go from teaser to preview to launch
The best promotional tool is a great product. Word will get out
if you've got an app that people find really useful.
Ride the Blog Wave
Blogging can be more effective than advertising (and it's
a hell of a lot cheaper)
Solicit Early
Get advance buzz and signups going ASAP
We've already touched on it but it bears repeating: Get some sort of site up and start collecting emails as soon as possible. Pick your domain name and put up a logo and maybe a sentence or two that describes, or at least hints at, what your app will do. Then let people give you their email address. Now you're on your way to having a foundation of folks ready and waiting to be notified of your launch.
Promote Through Education
Share your knowledge with the world
When a teacher appears as a contestant on Jeopardy, Alex Trebek
often comments that it's a "noble profession." He's right.
There's definitely something wonderful and rewarding about
sharing your knowledge with others. And when the subject
you're teaching is your app, it serves a dual purpose: You can
give something back to the community that supports
you and score some nice promotional exposure at the
same time.
Feature Food
They're hungry for it so serve it up
New or interesting features are a great way to generate buzz for your application. Special interest groups love to chew up "feature food" and spit it back out to the community. Alright, that's kind of an unpleasant analogy but you get the point.
For example, by using Ruby on Rails, a new development platform, we generated a ton of attention for Basecamp within the developer community.
Track Your Logs
Study your logs to track buzz
You need to know who's talking about you. Check your logs and find out where the buzz is coming from. Who's linking to you? Who's bitching about you? Which blogs listed at Technorati, Blogdex, Feedster, Del.icio.us, and Daypop are hot on your trail?
Inline Upsell
Promote upgrade opportunities inside the app
Everyone knows to pitch at the marketing site. But the sell
shouldn't stop there. If you have a tiered pricing plan (or a free
version of your app), don't forget to call out upgrade opportuni
ties from within the product.
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 ultradescriptive. 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.
Answer Quick
Use inline help and FAQs so your product doesn't
require a manual or training
You don't need a manual to use Yahoo or Google or Amazon. So why can't you build a product that doesn't require a manual? Strive to build a tool that requires zero training.
How do you do this? Well, as we've mentioned before, you start by keeping everything simple. The less complex your app is, the less you'll need to help people out of the weeds. After that, a great way to preempt support is by using inline help and faqs at potential points of confusion.
Answer Quick
Quick turnaround time on support queries should be a
top priority
Customers light up when you answer their questions quickly. They're so used to canned responses that show up days later (if at all) that you can really differentiate yourself from competitors by offering a thoughtful response right away. During business hours, we answer 90% of all email support requests within 90 minutes — and often within a half-hour. And people love it.
Tough Love
Be willing to say no to your customers
When it comes to feature requests, the customer is not always right. If we added every single thing our customers requested, no one would want our products.
In Fine Forum
Use forums or chat to let customers help each other
Forums and web-based group chat are a great way to let customers ask questions and help one another out. By eliminating the middleman — that's you — you provide an open stream of communication and save yourself time in the process.
Publicize Your Screwups
Get bad news out there and out of the way
If something goes wrong, tell people. Even if they never saw it in the first place.
One Month Tuneup
Issue a major update 30 days after launch
A quick update shows momentum. It shows you're listening. It shows you've got more tricks up your sleeve. It gives you a second wave of buzz. It reaffirms initial good feelings. It gives you something to talk about and others to blog about.
Keep the Posts Coming
Show your product is alive by keeping an ongoing
product development blog post-launch
Don't stop blogging once you launch. Show your product is a living creature by keeping a dedicated blog that you update frequently (at least once a week, more often if you can).
Things to include:
- Faq
- How-tos
- Tips & tricks
- New features, updates, & fixes
- Buzz/press
Better, Not Beta
Don't use "beta" as a scapegoat
These days it feels like everything is in beta stage forever. That's a cop out. An interminable beta stage tells customers you're not really committed to rolling out a finished product. It says, "Use this, but if it's not perfect, it's not our fault."
All Bugs Are Not Created Equal
Prioritize your bugs (and even ignore some of them)
Just because you discover a bug in your product, doesn't mean it's time to panic. All software has bugs — it's just a fact of life.
You don't have to fix each bug instantly. Most bugs are annoying, not destroying. Annoyances can be tabled for a bit. Bugs that result in "it doesn't look right" errors or other misdemeanor miscues can safely be set aside for a while. If a bug destroys your database, though, you obviously need to fix it immediately.
Ride Out the Storm
Wait until knee-jerk reactions to changes die
down before taking action
When you rock the boat, there will be waves. After you introduce a new feature, change a policy, or remove something, knee-jerk reactions, often negative, will pour in.
Resist the urge to panic or rapidly change things in response. Passions flare in the beginning. But if you ride out this initial 24-48 hour period, things will usually settle down.
Keep Up With the Joneses
Subscribe to news feeds about your competitors
Subscribe to news feeds about both your product and your competitors (it's always wise to know the ways of one's enemy). Use services like PubSub, Technorati, Feedster, and others to stay up to date (for keywords, use company names and product names). With rss, this constantly changing info will be delivered right to you so you're always up to speed.
Beware the Bloat Monster
More mature doesn't have to mean more complicated
As things progress, don't be afraid to resist bloat. The temptation will be to scale up. But it doesn't have to be that way. Just because something gets older and more mature, doesn't mean it needs to get more complicated.
Go With the Flow
Be open to new paths and changes in direction
Part of the beauty of a web app is its fluidity. You don't wrap it up in a box, ship it, and then wait years for the next release. You can tweak and change as you go along. Be open to the fact that your original idea may not be your best one.
Start Your Engines
Done!
Alright, you made it! Hopefully you're psyched to start Getting Real with your app. There really has never been a better time to make great software with minimal resources. With the right idea, passion, time, and skill, the sky's the limit.
Execution
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.
People
It's worth reemphasizing the one thing that we think is the most important ingredient when it comes to building a successful web app: the people involved. Mantras, epicenter design, less software, and all these other wonderful ideas won't really matter if you don't have the right people on board to implement them.
You need people who are passionate about what they do.
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.
|
