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.
6. Gather usage data from your users and input it back into product design as often as possible. Watch what
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.Next
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.
6. Gather usage data from your users and input it back into product design as often as possible. Watch what
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.Next
No comments:
Post a Comment