Dont try to one-up your competitor.

If you want to build a company that follows, then ape the features of your competitor.

Less features, less options/preferences, less people/employees, less promisses, less meetings

You are like the 100,000 people across the world. You are the target-audience of your application.

If you have a problem, its likely that others will also face it.

When you solve your own problem, you create a tool that you’re passionate about. And passion is key. Passion means you’ll truly use it and care about it. And that’s the best way to get others to feel passionate about it too.

If you get external funding, you are no more your own boss. You cant take decisions.

There’s a myth that goes like this: we can launch on time, on budget, and on scope. It almost never happens and when it does quality often suffers.

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.

It’s better to make half a product than a half-assed product

Dont get scared of your big competitors. Use it as a motivator. Make your application an anit to that of your competitor.

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.

However, dont spend too much time on your enemy. Focus on what you want to do. Remember, you hate your enemy; so dont think too much about him.

The less your app is a chore to build, the better it will be.

Less software, less code, Less features, Small team size, Simplicity, Open-source products, Multi-tasking team members

Long term contracts, Excess staff, Permanent decisions

All it takes to build a great application is a developer, a designer and a sweeper (someone who can roam between both worlds). But all got to be passionate and talented.

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

Why does it exist?

What makes it different than other similar products?

Believe it or not, the bigger problem isn’t scaling, it’s getting to the point where you have to scale. Without the first problem you won’t have the second.

When someone uses software, they’re not just looking for features, they’re looking for an approach.

Your app should have a vision. If people dont like it, let them go else where. Dont change your vision because people ask for it.

Example: Wiki Design. Ward Cunningham and friends deliberately stripped the wiki of many features that were considered integral to document collaboration in the past. Instead of attributing each change of the document to a certain person, they removed much of the visual representation of ownership. They made the content ego-less and time-less. They decided it wasn’t important who wrote the content or when it was written. And that has made all the difference. This decision fostered a shared sense of community and was a key ingredient in the success of Wikipedia.

Keep only whats truly essential. Take whatever you think your product should be and cut it in half. Then do it again.

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.

Q: why didn’t you do this or why didn’t you do that? A: because it doesnt matter

Figure out what matters and leaving out the rest.

A feature addition may be small by itself. But there are other changes that will need to be implemented. FAQ/support docs, tour pages, screenshots, etc.

Dont force conventions on people.

People know their problem better than you do. They are smart enough to find a solution to their problem.

Do the best job you can with the root of the problem then step aside. People will find their way from there.

Ask customers: “If you could remove one feature, what would it be?” What don’t you use?”

Create HTML Screens

Code It

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.

Decide the little details so that your customer doesnt have to.

The advantage is that there is less code to write therefore faster to build and change. Anyway, how often are these preferences actually modified by the user?

Dont waste time in lab testing. Test in the real world with real people. Thats the best way to test.

Release a beta version, dont wait for it to be perfect. Get feedback from users and then perfect it. It will be a lot more perfect

Break up 6 week long tasks to 6 one-weekkong tasks. That way you will get the joy of completing 4 to 6 tasks rather than hopefully completing 1 tasks.

As far as possible try and employ people with multiple talents. If you have someone who does only designing, and someone else who does only coding, they will not be able to understand each others problem. The team will not be harmonious.

You are most productive when you are alone.

The alone time zone is where the real development magic happens.

Avoid meetings like drugs

As far as possible, avoid hiring people.

Adding people to a late software project makes it later

It is best practice to hire people based on their contribution to the open source world, never degrees or recommendation.

Only a programmer who really has a passion for programing will *waste* his time in open source projects.

In a small team, there are no specialists (such as Information Architects). Everyone in the team should be able to do multiple things.

More importantly they should have the willingness to adjust and learn rather than be a stick-in-the-mud who can do only one thing.

Choose to hire an average but enthusiast person over a frustrated tech-celebrity.

Pick someone who is enthusiast about your project. He will deliver far more that the tech-guru.

Hire good writers. Good writers are count more than their words. They know how to communicate. How to make things simpler to understand for the others. This quality spills over into their code or design.

Dont start out with coding before you have the interface of your application ready.

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 designing the core section of the page. Dont start with the header or side bar. Start by putting in the essentials and then add the extras.

Regular

People say that cinsistency is the secret to great UI and UX. That might be true for software, but not on the web.

Give the user what is required for her to go to the next step, and get rid of what could confuse her.

Consistency is good, but in context, is better

Speak the language that your audience speaks.

Avoid technical jargon. Dont sound like an engineer speaking to another engineer.

Use icons with names, form fields with examples, and buttons with indicative labels

When it comes to designing CMSs or Admin pages, people dont waste time on design, and make crappy looking pages.

Instead of wasting time making 2 different designs, use the same look for the admin pages as for the pages that are viewed by the public.

Keep your codebase as small as possible. It is far easier to maintain than a complex codebase.

Solve todays problem. Dont worry about tomorrows woes.

Choose the tools and frameworks that the team loves and is passionate about. Dont follow industry standards.

Code offers suggestions. 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.

Just like you can have monetory debt, you have code and design debt.

Spend some time cleaning up the portions of code that work, but are clunky. It will pay off when you get back to this code later.

Dont seal you data. Let people access their data when they are not using your application also.

Send data out into the world via RSS feeds and open up APIs to your application.

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.

Functional specs don’t let you evolve, change,and reassess

Writing functional specs is the single worst way to write software, because it by definition means that the software was written to match theory, not reality.

Write a one page story about what the app needs to do. Use plain language and make it quick. If it takes more than a page to explain it, then it’s too complex. This process shouldn’t take more than one day.

Then begin building the interface – the interface will be the alternative to the functional spec. Draw some quick and simple paper sketches. Then start coding it into HTML. Unlike paragraphs of text that are open to alternate interpretations, interface designs are common ground that everyone can agree on.

If you absolutely need to write about a new feature, write the story, not the details.

Tell your strategy, not the tactics. Those will fit into place when you code.

Imagine you are conversing with someone. Write that way, not as though you are writing the presidents independence day speech.

Give out a free sample of your application so that people get an idea of what it is all about. Only then do they become actually potential customers.

Keep signing up as simple as possible. Put a big "Sign Up" button on all your markteing page. Also keep the cancellation as simple as possible.

Go from teaser to preview to 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.

A few weeks ahead of launch, start previewing features. Give people behind-the-scenes access. Describe the theme of the product.

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

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.

Traditional advertising is extremely expensive. And evaluating the effectiveness of the different types of advertisements can double or triple your cost. When you dont have the money to go with the traditional advertising route, consider taking a ride on the promote-via-blogs route.

Get a site up ASAP. Put the logo with a few sentences describing what your app will do. Start collecting email addresses of visitors. When you launch, shoot out mails to these people.

Another advantage of having a site up early is that search engines will start spidering your site early. When you launch your app, it will come up in the top 3 or 4 hits in Google.

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?

Collect positive praise and create a “buzz” page at your site. Testimonials are a great way to promote your app since third-party praise is more trustworthy to most people.

If the comments are negative, still pay attention. Show you’re listening. Respond to critiques thoughtfully. Something like: “We appreciate the feedback but we did it this way because...” Or “You raise a good point and we’re working on it.” You’ll soften up your critics and put a human face on your product. It’s amazing how much a thoughtful comment on a blog can diffuse naysayers and even turn complainers into evangelists.

Give your app a name that’s easy to remember. Dont try to be ultra-descriptive. If the name is too general (like MS Project for a project management app), people will tend to forget. Pick a name thats catchy (like Loosestitch over Sproutliner :)

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

Tear down the walls between support and development

Don’t outsource customer support to a call center or third party.

It can be tempting to rely on statistical analysis to reveal your trouble spots. But stats aren’t the same as voices. You need to eliminate as many buffers as possible between you and the real voices of your customers.

Use inline help and FAQs so your product doesn’t require a manual or training.

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.

Customers light up when you answer their questions quickly.

Answering customer queries should be top prioirty. If you cant solve their problem immediately, write honestly to them like: "We understand what you say, and we are working on it. It might take some time ..."

Be willing to say no to features that your customers ask for. If you say yes to all of them, then you wont satisfy the first request: "Keep the application SIMPLE".

Add a feature not because a customer asked for it, but because you really like it.

Use forums and chats to let customers help each other.

Youll be surprised to see how much people want to help each other.

Even if you have a downtime in the middle of the night, appologize to your customers. Be as honest as possible. Your customers wont mind the downtime, instead they will like your honesty.

After your launch, come up with an update within 30 days. It will give you another opportunity to speak about your app and others to blog about it.

It also allows you to come launch your app earlier.

Blog about your app as often as possible (at least one post a week)

Blogs also give the company a more human interface. Customers can approach the developers like friends, rather than customers.

Dont use beta as a scapgoat

Calling your app beta, means "Use this, but if its not perfect, its not our fault."

Priority your bugs (even ignore some of them)

When you add a new feature, change a policy or remove something, negative reactions will pour in. Resist the urge to panic and revert the change you just made. Wait for the critisism to die down, and for your team to cool down. You will then be able to take a more reasoned decision.

New doesnt always means improved.

Dont just add features because its been a long time since you added a feature

Sometimes theres a point where you should just let a product be.

Part of the beauty of a web app is its fluidity. You dont have to wrap it up in a box, ship it and then wait a year for the next update. You can tweak and change as you go along,

Example:Flickr began as a multiplayer online game called The Game Neverending. Its creators soon realised the photo-sharing aspect of the game was more a more plausible product that the game itself. They soon shelved the game and worked on Flickr.

Sucess is all about good execution. Brilliant ideas dont pay.

The key is balance. Good copy. Good UI. Good code.

You need people who are passionate about what they do.

People who care about their craft.

People who take pride in their work, regardless of the monetary rewards involved.

People who want to build something great and settle for nothing less.

The folks on your team will make or break your project - and hence your company.