Dion Hinchcliffe's fascinating series continues...below is 10 of 50 strategies:
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 where the architect should be malleable. 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.
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 where the architect should be malleable. 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.
1 comment:
This blog enlists all the important tasks involved in the development of a web site
Las Vegas Web Design
Post a Comment