There was a problem sending you an sms. Check your phone number or try again later.
We've sent a link to the Scribd app. If you didn't receive it, try again.
I am fortunate enough to spend a lot of time looking at various online products and services in the development stage, mostly
of the Web 2.0 variety, meaning they use one or more of the principles in the Web 2.0 set of practices. It's been going on 4
years now and what's fascinating to me, despite the enormous amount of knowledge that we've accumulated on how to create
Wouldn't it be handy if we had a cheat sheet that combined many of these lessons into one convenient list? In this vein of
thinking, I decided to sit down recently to capture are some of the most important lessons I've learned over the last few years
along with some of the thinking that went into them.
If there's one thing that the Web has taught us it's that the network gets smarter by virtue of people using it and product
development is no exception. Not only do we have examples of great online applications and systems to point to and use for
best practices, but the latest tools, frameworks, development platforms, APIs, widgets, and so on, which are largely developed
today in the form of open source over the Internet, tend to accumulate many of these new best practices. I'vela ude d
However, most of the success of an online product, Web 2.0 or otherwise, comes from two things: Its software architecture and its product design. It's also the case that the story of any product is a story of ten of thousands of little decisions made throughout the life of the product, of which only a key -- and heartbreakingly small -- set will make much of a difference to its success on the network. The list of strategies below tells part of the story of which decisions will make that critical difference.
Software architecture determines a Web application's fundamental structure and properties: Resilience, scalability, adaptability, reliability, changeability, maintainability, extensibility, security, technology base, standards compliance, and other key constraints, and not necessarily in that order.
Doing both of these top-level product development activities well, striking a healthy balance between them (one often
dominates the other), and doing it with a small team, requires people with deep and multidisciplinary backgrounds in creating
successful products across this extensive set of practice areas. These people are often hard to find and extremely valuable.
This means it's also not likely you'll be able to easily put together a team with all the capabilities that are needed from the
online products go to market. I've decided to share these with you so we can continue to teach the network, and consequently
ourselves, a little bit more about how to make extraordinary Web applications that can really make a difference in the
This of course is just my experience and is not intended to be a complete list of Web 2.0 strategies. However, I think most
people will find it a valuable perspective and useful cross check in their product design and development. And please keep in
mind this list is for Web 2.0 applications, not necessary static Web sites, or traditional online Web presence, though there is
much that here that can be applied to them to make them more useful and successful as well.
1. Start with a simple problem. All of the most successful online services start with a simple premise and execute on it
well with great focus. This could be Google with it's command-line search engine, Flickr with photo sharing, Digg with user
generated news. State your problem simply: "I make it easier to do X". Focus on solving it elegantly and simply, only add
features carefully. Over time, complexity will become the enemy of both your product design and your software architecture,
so start with as much focus as you can muster.
2. Create prototypes as early as possible. Get your idea into a working piece of software as quickly as possible. The
longer you take to go through one entire cycle, the more unknown work you have ahead of you. Not producing software also
means that you are not getting better and better at turning the work of your team into the most important measurable output:
Functioning software. Throughout the life of your product, turning your ideas into software as quickly and inexpensively as
possible will be one of the most important activities to get right.
3. Get people on the network to work with the product prototype rapidly and often. The online world today is
fundamentally people-centric. If your product isn't about them and how it makes their lives better, your product really doesn't
matter. And if they're not using your Web application as soon as possible, you just don't know if you are building the right
product. Constant, direct feedback from real people is the most important input to our product design after your idea. Don't
wait months for this to happen; get a beta out to the world, achieve marketplace contact in weeks, or at most a few months,
and watch carefully what happens. This approach is sometimes called Web 2.0 Development .
4. Release early and release often. Don't get caught up in the massive release cycle approach, no matter how appealing it
may be. Large releases let you push off work tomorrow that should be done today. It also creates too much change at once
and often has too many dependencies, further driving an increase in the size of the release. Small releases almost always work
better, are easier to manage, but can require a bit more operations overhead. Done right, your online product will iterate
smoothly as well as improve faster and more regularly than your competitors. Some online products, notably Flickr, have been
on record as saying they make new releases to production up to several times a day. This is a development velocity that many
new startups have trouble appreciating or don't know how to enable. Agile software development processes are a good model
to start with and and these and even more extreme methods have worked well in the Web 2.0 community for years.
5. Manage your software development and operations to real numbers that matter. One often unappreciated
issue with software is its fundamentally intangible nature. Combine that with human nature, which is to manage to what you
can see, and you can have a real problem. There is a reason why software development has such a variable nature in terms of
time, budget, and resources. Make sure you have as many real numbers as possible to manage to: Who is making how many
commits a week to the source repository, how many registered users are there on a daily basis, what does the user analytics
look like, which product features are being used most/least this month, what are the top 5 complaints of customers, and so
on. All of these are important key performance indicators that far too many startups don't manage and respond to as closely
as they should.
your users do live with your product, what they click on, what do they try to do with it, what they don't use, and so on. You will
be surprised; they will do things you never expected, have trouble with features that seem easy to you, and not understand
parts of your product that seemed obvious. Gather this data often and feed it back into your usability and information
architecture processes. Some Web applications teams do this almost daily, others look at click stream analytics once a quarter,
and some don't it at all. Guess who is shaping their product faster and in the right direction?
7. Put off irreversible architecture and product design decisions as long as possible. Get in the habit of asking
"How difficult will it be to change our mind about this later?" Choosing a programming language, Web framework, relational
database design, or a software interface tend to be one-way decisions that are hard to undo. Picking a visual design, logo,
layout, or analytics tool generally is not. Consequently, while certain major decisions must be made up front, be vigilant for
seemingly innocuous decisions that will be difficult to reverse. Not all of these will be a big deal, but it's all too often a surprise
to many people when they discover their architecture isn't malleable in the places that they want it to be. Reduce unpleasant
surprises by always asking this question.
8. Choose the technologies later and think carefully about what your product will do first. First, make sure your
ideas will work on the Web. I've seen too many startups with ideas that will work in software but not on the Web. Second,
Web technologies often have surprising limits, Ajax can't do video or audio, Flash is hard to get to work with SEO for example.
Choosing a technology too early will constrain what is possible later on. That being said, you have to choose as rapidly as you
can within this constraint since you need to build prototypes and the initial product as soon as you are able.
9. When you do select technologies, consider current skill sets and staff availability. New, trendy technologies
can have major benefits including higher levels of productivity and compelling new capabilities, but it also means it'll be
harder to find people who are competent with them. Having staff learn new technology on the job can be painful, expensive,
and risky. Older technologies are in a similar boat; you can find people that know them but they'll most likely not want to
work with them. This means the middle of the road is often the best place to be when it comes to selecting technology, though
you all-too-often won't have a choice depending on what your staff already knows or because of the pre-requisites of specific
technologies that you have to use.
10. Balance programmer productivity with operational costs. Programming time is the most expensive part of
product creation up front while operations is after you launch. Productivity-oriented platforms such as Ruby on Rails are very
popular in the Web community to drive down the cost of product development but can have significant run-time penalties
later when you are supporting millions of users. I've previously discussed the issues and motivations around moving to newer
programming languages and platforms designed for the modern Web, and I encourage you to read it. Productivity-oriented
platforms tend to require more operational resources during run-time, and unlike traditional software products, the majority
of the cost of operations falls upon the startup. Be aware of the cost and scale of the trade-offs since every dollar you save on
the development productivity side translates into a run-time cost forever after on the operations side.
a 100x overall effect on product development productivity. This means that some teams can ship product in as little as 3
months and some projects won't ship ever, at least not without truly prohibitive time and resource requirements. While there
are a great many inputs to an Internet startup that will help or hinder it (take a look at Paul Graham's great 18 Mistakes That
development platform they are using. Joel Spolsky's write-up on programmer productivity remains one of the best at understanding this issue. It usually turns out that paying a bit more for the right developer can often mean tremendous output gains. One the other side of the coin, choosing a development platform not designed for creating modern Web
12. Plan for testing to be a larger part of software development process than non-Web applications. Cross
browser testing, usability, and performance/load testing are much bigger issues with Web applications than many non-Web
applications. Having to do thorough testing in a half-dozen to a dozen browser types can be an unexpected tax on the time
and cost of creating a Web product. Doing adequate load testing is another item that often waits until the end, the very worst
time to find where the bottlenecks in your architecture are. Plan to test more than usual. Insist on automated unit and
integration tests that build up over time and run without having to pay developers or testers to do it manually.
13. Move beyond traditional application hosting. Single Web-server hosting models are not going to suffice for your 2.0
applications. Reliability, availability, and scalability are essential and must be designed into your run-time architecture and
supported by your hosting environment. Solutions like3 T era, Amazon's Elastic Compute Cloud, and Google's App Engine are
three compelling, yet very different solutions to the hosting problem. Either way, grid and cloud approaches to hosting will
help you meet your growth and scalability requirements while managing your costs.
14. Have an open source strategy. This has two important aspects. One, developing and hosting a product built with
open source software (the ubiquitiousLA MP stack) is almost always much less expensive than using commercial software and
is what most online products use. There are certainly commercial licenses that have fair terms for online services, but almost
none of them will match the cost of free. This is one reason why you won't find Windows or Oracle embedded in very many
Web 2.0 services. Two, you'll have to decide whether to open source or commercial open source your product. This has
entirely to do with what your product does and how it does it, but an increasing number of Web 2.0 hosted products are
releasing their offerings as open source to appeal to customers, particularly if they are business customers. Done right, open
sourcing can negate arguments about the size of your company while enlisting many 3rd party developers to help enrich and
make your product better.
15. Consider mobile users as important as your regular browser customers. Mobile devices will ultimately form
the majority of your user base as the capability and adoption of smartphones, Internet tablets, laptops, and netbooks ushers in
mobile Web use as the dominant model. Having an application strategy as well as well-supported applications for the iPhone,
16. Search is the new navigation, make it easy to use in your application. You have 5-10 seconds for a new user to
find what they want from your site or application. Existing users want to directly access what they need without going through
layers of menu items and links. Search is the fastest way to provide random access navigation. Therefore, offer search across
data, community, and help at a minimum. A search box must be on the main page and indeed, every page of the modern Web
17. Whenever users can provide data to your product, enable them. Harnessing collective intelligence is the most
central high-level principle of Web 2.0 applications. To be a major online competitor, getting your millions of users to build a
valuable data set around the clock is the key to success. Many product designers look at this too narrowly and usually at a
small set of data. Keep a broad view of this and look for innovative ways to get information from explicit contributions to the
20. Create features to make the product distribute virally. The potency of this is similar to widgets above and
everything from simple e-mail friend invites to importing contact lists and social graphs from other Web apps are critical ways
to ensure that a user can bring the people they want into the application to drive more value for them and you
.21. The link is the fundamental unit of thought on the Web, therefore richly link-enable your applications.
Links are what make the Web so special and fundamentally makes it work. Ensuring your application is URL addressable in a
granular way, especially if you have a rich user experience, is vital to participate successfully on the Web. The Web's link
ecosystem is enormously powerful and is needed for bookmarking, link sharing/propagation, advertising, makes SEO work,
drives your page rank, and much more. Your overall URL structure should be thought out and clean, look toFl ic k r and
22. Create an online user community for your product and nurture it. Online communities are ways to engage
passionate users to provide feedback, support, promotion, evangelism and countless other useful outcomes. While this is
usually standard fare now with online products, too many companies don't start this early enough or give it enough resources
despite the benefits it confers in terms of customer support, user feedback, and free marketing, to name just three benefits.
Investing in online community approaches is ultimately one of the least expensive aspects of your product, no matter the
upfront cost. Hire a good community manager and set them to work.
Now bringing you back...
Does that email address look wrong? Try again with a different email.