The product plan is essential to a web site's success. Written before you start development work and updated along the way it outlines your site's overarching purpose, specific features, and strategic goals. So at the end of the day, you'll know whether you've accomplished what you set out to do. Different projects demand different levels of detail. So whether your plan takes you five minutes or five months is up to you. But don't start work without it. 1. nameYour site will need a name and a domain name (ideally, these will be the same). Don't put this off until the last minute. Start considering names early in the development process, and make sure the needed domains are available. Choosing a name isn't as easy as it may seem. It's a creative challenge to name any product or organization. But the web introduces its own complicating factors: When choosing a name, consider
See 3 ways to name your site, p. 33. 2. mission & goalsmission statement What's the big idea? Articulate clearly and succinctly the purpose of your site (or added feature). What is it for? Who is it for? How is it distinguished from other, similar sites? See writing a mission statement, p. 12. stated goals Along with the mission statement, it's important to articulate specific, measurable, and (hopefully) attainable goals for your project before you begin work. Over the course of development, the project team can refer back to this list, to make sure all decisions support the overarching goals. See stating your goals, p. 13. Goals may include
Stated goals are essential for every project, even those like redesigns or new features that don't require a formal mission statement. See deciding what goes on the site, p. 16. 3. target audienceprofile Describe your target audience, and be specific. Your site can't be for everyone. It's essential to know who you're targeting and build the site with them in mind. See profiling your users, p. 50. You might describe your users by
Size. Estimate the total size of your target audience and the percent of that market you expect to capture. Base your projections on the best and most accurate numbers available. If there's just no way to build an estimate with available statistics, then guess. Your best guess is always better than nothing at all. See estimating audience size, p. 52. See learning about your users, p. 46. 4. traffic patternsHow will people use your site? How often will they come, and how long will they stay? How will they find you, and how will they remember to come back? This kind of qualitative analysis will help you make quantitative traffic projections. The best way to predict usage patterns is to divide your audience into several segments you expect to behave differently. You could segment them by need (Why are they coming to your site?), experience level (New to the web? New to your product/site?), or origin (How did they find you?). See segmenting your users, p. 56. Describe each audience segment by
Given the usage patterns of your different audience segments (and the relative size of each segment) guesstimate your traffic levels. Remember, this isn't an exact science, so don't worry if you have a few gaps in your research. The purpose here is to get your best guesses in writing so you can plan accordingly. See evolving your site, p. 254. 5. revenue modelHow will your site make money? Always begin with the most obvious plan (providing leads for your existing business, for example), but also consider the full range of options that are working on the web right now. Some of the strongest business models are based on multiple revenue streams, developed over time. 5 Revenue models that work online:
As in other sections, be specific. If you plan to make money through advertising, for example, be sure to include projections for the number, size, and placement of ad banners on your site. Be sure to also include your assumptions on important variables, such as price of advertising, sales-per-customer, or sign-up rates. When any individual variable changes, it will affect your overall projections. See making money, p. 68. 6. feature setDescribe your site (succinctly), in terms of content, services, and utilities. What are the elements that make up the overall experience, and how will they fit together? Which features are essential to the site's success? Which can be phased in over time? List your site's features, including
See deciding what goes on the site, p. 16 7. competitionWrite a brief overview summarizing your competitive outlook, including the following:
In a separate document, list and describe your competitors on the web in greater detail, including the following elements:
Be sure to notice the things your competition is doing well and copy them. See sizing up the competition, p. 38. 8. marketing planHow will you get the word out about your site? What kind of budget have you assigned to site promotions, and how will it be best spent? Your marketing plan should probably include
See promoting your site, p. 278. 9. teamEvery web site needs a clear producer or product manager that is, if you want it to succeed. It's important to have a single person responsible for driving a project forward and making final decisions, but it's also important to have all the key disciplines represented from the beginning. At minimum, you should identify
This should go without saying, but it's also important to identify key decision makers before you start making decisions and certainly before you begin building the site. If a senior manager has the power to overturn decisions, she should be consulted in the earliest stages to avoid wasted work. See assembling a web team, p. 332. 10. schedule & budgetProject success is at least partially judged by completing the site on time and on budget. Be sure you know your constraints before you begin work. budget Never underestimate the importance of a budget. Everyone loves to hate them, but they're an essential tool for managing your project. "Having a budget is a really good thing," said web veteran Dave Thau, author of The Book of JavaScript. "It sounds funny, but a lot of people just don't have one. Then costs will run away from you, and if you don't have a budget, you don't realize that they're running away." You may have a budget imposed on you. But you won't be able to estimate your expenses until you've finalized your feature set. (If you don't know what you're building, you won't know what it's going to cost.) To build an estimate, start with your staff costs, both while under development and after launch. Estimate salaried staff, as well as non-salary costs, including consultant payments, licensing fees, special marketing or promotions (media buys, trade shows, and press tours), and required travel. And don't forget the backend the more complex your site, and the more popular it proves, the more expensive your servers and bandwidth will be. schedule The budget for your project often determines the people and resources you have available, and this in turn helps determine how long it will take. Before you begin work, outline project milestones with projected dates for completion. Be sure to include any dependencies built into the schedule. (Often, one phase must conclude before another can begin.) Leave time for testing and QA, and always, always, always pad the schedule to accommodate the delays that inevitably occur. See how to set a schedule that sticks, p. 324. See managing a web project & team, p. 320. 11. assumptionsWhat are the assumptions upon which you're basing your plan? Are you assuming the existence of a particular audience? Are you assuming that a particular technology will work, or scale to a larger audience? Are you assuming there's an unmet need your site will fill? Do you have any basis for these assumptions? What will make or break this product? Does it depend on being first to market? Does it depend on being cheaper, faster, or just plain better than its competitors? Does it depend on a particular technology being available, functional, or scalable? Does it depend on a particular individual? Does it depend on world events or pop culture trends? Does it depend on being seen as "cool"?
|