「Getting Real」を読んだ

投稿時刻2024年2月16日 20:48

「Getting Real」を 2,024 年 02 月 16 日に読んだ。

目次

メモ

Caveats, disclaimers, and other preemptive strikes

“You didn’t invent that idea.”
We’re not claiming to have invented these techniques.
Many of these concepts have been around in one form or another for a long time.
Don’t get huffy if you read some of our advice and it reminds you of something you read about already on so and so’s weblog or in some book published 20 years ago.
It’s definitely possible.
These techniques are not at all exclusive to Basecamp.
We’re just telling you how we work and what’s been successful for us.

“You take too much of a black and white view.”
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…” Of course there will be times when these rules need to be stretched or broken.
And some of these tactics may not apply to your situation.
Use your judgement and imagination.

Less Mass

For example, let’s imagine a lean, less-mass company that has built a product with less software and less features.
On the other side is a more-mass company that’s got a product with significantly more software and more features.
Then let’s say a new technology like Ajax or a new concept like tagging comes around.
Who is going to be able to adapt their product quicker?
The team with more software and more features and a 12-month roadmap or the team with less software and less features and a more organic “let’s focus on what we need to focus on right now” process?

Obviously the less-mass company is in a better position to adjust to the real demands of the marketplace.
The more-mass company will likely still be discussing changes or pushing them through its bureaucratic process long after the less-mass company has made the switch.
The less-mass company will be two steps ahead while the more-mass company is still figuring out how to walk.

Nimble, agile, less-mass businesses can quickly change their entire business model, product, feature set, and marketing message.
They can make mistakes and fix them quickly.
They can change their priorities, product mix, and focus.
And, most importantly, they can change their minds.

Lower Your Cost of Change

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.
And if your competitors can change faster than you, you’re at a huge disadvantage.
If change gets too expensive, you’re dead.

Here’s where staying lean really helps you out.
The ability to change on a dime is one thing small teams have by default that big teams can never have.
This is where the big guys envy the little guys.
What might take a big team in a huge organization weeks to change may only take a day in a small, lean organization.
That advantage is priceless.
Cheap and fast changes are small’s secret weapon.

And remember: All the cash, all the marketing, all the people in the world can’t buy the agility you get from being small.

When it comes to web technology, change must be easy and cheap.
If you can’t change on the fly, you’ll lose ground to someone who can.
That’s why you need to shoot for less mass.

Embrace Constraints

Let limitations guide you to creative solutions
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.

Half, Not Half-Assed

Build half a product, not a half-ass product
Beware of the “everything but the kitchen sink” approach to web app development.
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.

Stick to what’s truly essential.
Good ideas can be tabled.
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.

With Basecamp, we started with just the messages section.
We knew that was the heart of the app so we ignored milestones, to-do lists, and other items for the time being.
That let us base future decisions on real world usage instead of hunches.

Start off with a lean, smart app and let it gain traction.
Then you can start to add to the solid foundation you’ve built.

It Just Doesn’t Matter

Essentials only
Our favorite answer to the “why didn’t you do this or why didn’t you do that?” question is always: “Because it just doesn’t matter.”
That statement embodies what makes a product great.
Figuring out what matters and leaving out the rest.

Start With No

Make features work hard to be implemented
The secret to building half a product instead of a half-ass product is saying no.

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

“We Don’t Want a Thousand Features”

Steve Jobs gave a small private presentation about the iTunes Music Store to some independent record label people.
My favorite line of the day was when 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 thousand ideas for all the cool features iTunes could have.
So do we.
But we don’t want a thousand features.
That would be ugly.
Innovation is not about saying yes to everything.
It’s about saying NO to all but the most crucial features.”

—Derek Sivers, president and programmer, CD Baby and HostBaby (from Say NO by default)

Hidden Costs

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…
1.  Check to see if help text needs to be modified.
2.  Update the product tour (if necessary).
3.  Update the marketing copy (if necessary).
4.  Update the terms of service (if necessary).
5.  Check to see if any promises were broken.
6.  Check to see if pricing structure is affected.
7.  Launch.
8.  Hold breath.

Can You Handle It?

Build something you can manage
If you launch an affiliate program do you have the systems in place to handle the accounting and payouts?
Maybe you should just let people earn credit against their membership fees instead of writing, signing, and mailing a check each month.

Can you afford to give away 1 gb of space for free just because Google does? Maybe you should start small at 100 mb, or only provide space on paying accounts.

Bottom line: Build products and offer services you can manage.
It’s easy to make promises.
It’s much harder to keep them.
Make sure whatever it is that you’re doing is something you can actually sustain — organizationally, strategically, and financially.

Hold the Mayo

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, CEO, Apple (from The Seed of Apple’s Innovation)

Race to Running Software

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.

It’s ok to do less, skip details, and take shortcuts in your process if it’ll lead to running software faster.
Once you’re there, you’ll be rewarded with a significantly more accurate perspective on how to proceed.
Stories, wireframes, even html mockups, are just approximations.
Running software is real.

With real, running software everyone gets closer to true understanding and agreement.
You avoid heated arguments over sketches and paragraphs that wind up turning out not to matter anyway.
You realize that parts you thought were trivial are actually quite crucial.

Real things lead to real reactions.
And that’s how you get to the truth.

From Idea to Implementation

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
Instead of using your expertise to choose the best path, you’re leaving it in the hands of customers.
It may seem like you’re doing them a favor but you’re just making busy work for them (and it’s likely they’re busy enough).
For customers, preference screens with an endless amount of options are a headache, not a blessing.
Customers shouldn’t have to think about every nitty gritty detail — don’t put that burden on them when it should be your responsibility.

Preferences are also evil because they create more software.
More options require more code.
And there’s all the extra testing and designing you need to do too.
You’ll also wind up with preference permutations and interface screens that you never even see.
That means bugs that you don’t know about: broken layouts, busted tables, strange pagination issues, etc.

Preferences Have a Cost
It turns out that preferences have a cost.
Of course, some preferences also have important benefits — and can be crucial interface features.
But each one has a price, and you have to carefully consider its value.
Many users and developers don’t understand this, and end up with a lot of cost and little value for their preferences dollar…
I find that if you’re hard-core disciplined about having good defaults that Just Work instead of lazily adding preferences, that naturally leads the overall UI in the right direction.

—Havoc Pennington, tech lead, Red Hat (from Free software and good user interfaces)

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

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.

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.

A successful alone time period means letting go of communication addiction.
During alone time, give up instant messaging, phone calls, and meetings.
Avoid any email thread that’s going to require an immediate response.
Just shut up and get to work.

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.

So, if you’re in the middle of a months-long release cycle, dedicate a day a week (or every two weeks) for some small victories.
Ask yourself “What can we do and release in 4 hours?” And then do it.

It could be…
A new simple feature
A small enhancement to an existing feature
Rewriting some help text to reduce the support burden
Removing some form fields that you really don’t need

When you find those 4-hour quick wins, you’ll find celebration.
That builds morale, increases motivation, and reaffirms that the team is headed in the right direction.

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.

So don’t hire.
Really.
Don’t hire people.
Look for another way.
Is the work that’s burdening you really necessary? What if you just don’t do it? Can you solve the problem with a slice of software or a change of practice instead?

Whenever Jack Welch, former CEO of GE, used to fire someone, he didn’t immediately hire a replacement.
He wanted to see how long he could get along without that person and that position.
We’re certainly not advocating firing people to test this theory, but we do think Jack is on to something: You don’t need as many people as you think.

If there’s no other way, then consider a hire.
But you should know exactly who to get, how to introduce them to the work, and the exact pain you expect them to relieve.

Kick the Tires

Work with prospective employees on a test-basis first
It’s one thing to look at a portfolio, résumé, 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.”

Before we hire anyone we give them a small project to chew on first.
We see how they handle the project, how they communicate, how they work, etc.
Working with someone as they design or code a few screens will give you a ton of insight.
You’ll learn pretty quickly whether or not the right vibe is there.

Scheduling can be tough for this sort of thing but even if it’s for just 20 or 40 hours, it’s better than nothing.
If it’s a good or bad fit, it will be obvious.
And if not, both sides save themselves a lot of trouble and risk by testing out the situation first.

Actions, Not Words

Open Source Passion
What you want the most from a new hire is passion for what he does,
and there’s no better way of showing it than a trace of commitment in open source projects.

—Jarkko Laine, software developer (from Reduce the risk, hire from open source)

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.

Small teams need people who can wear different hats.
You need designers who can write.
You need programmers who understand design.
Everyone should have an idea about how to architect information (whatever that may mean).
Everyone needs to have an organized mind.
Everyone needs to be able to communicate with customers.

And everyone needs to be willing and able to shift gears down the road.
Keep in mind that small teams often need to change direction and do it quickly.
You want someone who can adjust and learn and flow as opposed to a stick-in-the-mud who can do only one thing.

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.

Find someone who’s enthusiastic.
Someone you can trust to get things done when left alone.
Someone who’s suffered at a bigger, slower company and longs for a new environment.
Someone who’s excited to build what you’re building.
Someone who hates the same things you hate.
Someone who’s thrilled to climb aboard your train.

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.

Design is relatively light.
A paper sketch is cheap and easy to change.
html designs are still relatively simple to modify (or throw out).
That’s not true of programming.
Designing first keeps you flexible.
Programming first fences you in and sets you up for additional costs.

Another reason to design first is that 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.

We start with the interface so we can see how the app looks and feels from the beginning.
It’s constantly being revised throughout the process.
Does it make sense? Is it easy to use? Does it solve the problem at hand? These are questions you can only truly answer when you’re dealing with real screens.
Designing first keeps you flexible and gets you to those answers sooner in the process rather than later.

The Orange Pen That Started Blinksale
As soon as I realized my frustration with off-the-shelf invoicing software, I decided to draw out how I would prefer my invoicing solution to work.
I pulled out an orange pen, because it was the only thing handy that evening, and had about 75 percent of the UI drawn out within a few hours.
I showed it to my wife, Rachel, who was ironing at the time, and asked, “What do you think?” And she replied with a smile, “You need to do this.
For real.”

Over the next two weeks I refined the designs, and completely mockedup static html pages for almost the entire first version of what would become Blinksale.
We never did any wireframes beyond those orangepen sketches, and getting straight into the html design helped us stay excited about how “real” the project was becoming, even though at the time we really didn’t know what we were getting into.

Once the html mockups were completed, we approached our developer, Scott, with the idea for Blinksale.
Having most of the UI designed up front was extremely beneficial on several levels.
First, it gave Scott a real vision and excitement for where we were going.
It was much more than just an idea, it was real.
Second, it helped us accurately gauge how much of Scott’s effort and time it would require to turn the design into a functioning application.
When you’re financially bootstrapping a project, the earlier you can predict budget requirements, the better.
The UI design became our benchmark for the initial project scope.
Finally, the UI design served as a guide to remind us what the application was about as we progressed further into development.
As we were tempted to add new features, we couldn’t simply say, “Sure, let’s add that!” We had to go back to the design and ask ourselves where that new feature would go, and if it didn’t have a place, it wouldn’t get added.

—Josh Williams, founder, Blinksale

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.

Whatever the page absolutely can’t live without is the epicenter.
For example, if you’re designing a page that displays a blog post, the blog post itself is the epicenter.
Not the categories in the sidebar, not the header at the top, not the comment form at the bottom, but the actual blog post unit.
Without the blog post unit, the page isn’t a blog post.

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 regular state is a no-brainer.
This is the screen where you’ll spend most of your time.
But don’t forget to invest time on the other states too (see the following essays for more on this).

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?

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.
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.

Slow down too.
Don’t take action on an idea for a week and see if it still seems like a great idea after the initial buzz wears off.
The extra marinating time will often help your brain come up with an easier solution.

Complexity Does Not Scale Linearly With Size
The most important rule of software engineering is also the least known:
Complexity does not scale linearly with size…A 2000 line program requires more than twice as much development time as one half the size.

—The Ganssle Group (from Keep It Small)

Code Speaks

If Programmers Got Paid To Remove Code…
If programmers got paid to remove code from sofware instead of writing new code, software would be a whole lot better.

—Nicholas Negroponte, Professor of Media Technology at MIT (from And, the rest of the (AIGA Conference) story)

There’s Nothing Functional about a Functional Spec

Functional specs are fantasies
They don’t reflect reality.
An app is not real until builders are building it, designers are designing it, and people are using it.
Functional specs are just words on paper.

Useless Specs
A “spec” is close to useless.
I have never seen a spec that was both big enough to be useful and accurate.

And I have seen lots of total crap work that was based on specs.
It’s the single worst way to write software, because it by definition means that the software was written to match theory, not reality.

—Linus Torvalds, creator of Linux (from: Linux: Linus On Specifications)

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.

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.

Lorem ipsum changes the way copy is viewed.
It reduces text-based content to a visual design element — a shape of text — instead of what it should be:
valuable information someone is going to have to enter and/or read.
Dummy text means you won’t see the inevitable variations that show up once real information is entered.
It means you won’t know what it’s like to fill out forms on your site.
Dummy text is a veil between you and reality.

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.

As soon as you can, use real and relevant words.
If your site or application requires data input, enter the real deal.
And actually type in the text — don’t just paste it in from another source.
If it’s a name, type a real name.
If it’s a city, type a real city.
If it’s a password, and it’s repeated twice, type it twice.

Sure, it’s easier to just run down the forms and fill the fields with garbage (“asdsadklja” “123usadfjasld” “snaxn2q9e7”) in order to plow through them quickly.
But that’s not real.
That’s not what your customers are going to do.
Is it really smart to take a shortcut when customers are forced to take the long road?
When you just enter fake copy in rapid-fire fashion, you don’t know what it really feels like to fill out that form.

Do as your customers do and you’ll understand them better.
When you understand them better, and feel what they feel, you’ll build a better interface.

Easy On, Easy Off

Also, make sure people can get their data out if they decide to leave.
We make sure customers can easily export all messages and comments in xml format at any time.
It’s their data and they should be able to do with it what they want.

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.
Also, consider a grandfather period that exempts existing customers for a certain period of time.
These folks are your bread and butter and you want to make them feel valued, not gouged.

Ride the Blog Wave

Blogging can be more effective than advertising (and it’s a hell of a lot cheaper)
Advertising is expensive.
And evaluating the effectiveness of various types of advertising can wind up being even more expensive than the advertising itself.
When you don’t have the time or money to go the traditional advertising route, consider the promote-via-blog route instead.

Start off by creating a blog that not only touts your product but offers helpful advice, tips, tricks, links, etc.
Our Signal vs. Noise blog gets thousands of unique readers a week thanks to the helpful, informative, and interesting bits and anecdotes we post on a daily basis.

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.

Also, don’t focus group or committee-ize the naming process too much.
Pick a name that’s short, catchy, and memorable and then run with it.

And don’t sweat it if you can’t get the exact domain name you want.
You can always be creative and get close with a couple of extra letters (e.g. backpackit.com or campfirenow.com).

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.

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).

Start Your Engines

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.
People who care about their craft — and actually think of it as a craft.
People who take pride in their work, regardless of the monetary reward involved.
People who sweat the details even if 95% of folks don’t know the difference.
People who want to build something great and won’t settle for less.
People who need people.
OK, not really that last one but we couldn’t resist throwing a little Streisand into the mix.
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.