I’m getting lots of questions from friends who are teaching workshops on being more entreprenurial for journalists, non-profits who need to build tools, and just random folks I run into about what a product developer does and what the elements are to build a requirements document, whether you are building the product yourself or budding it out to a vendor.
I just wrote a check list, in email, for one of the friends with above said request, and it occurred to me that I might share it with everyone, in case it was useful.
So, when you are writing a product plan, what are the essential areas to include?
n my world, we would be calling these project management and product development.
Project management is scheduling and sequencing and project development is building a business case and getting what you want.
The classics are
* What is this project?
* What is the problem it is going to solve?
* Who is it for (audience)?
* If it is successful, what will its impact be?
* What else is out there like it-aka who is the competition?
* Who is it different or better?
* What is the business rationale, how will it make money or be self sustaining?
* Is there a market, what % of the market will it capture?
* Is it going to create a new market? How?
* How will you reach people/acquire customers (aka distribution)
* What are the key features (this is a high level product spec)
* What is the budget–cost of the build and operations, typicall over a 3 year period
* What does the revenue look like (revenue projects and assumptions, also 3 year period)
* How will you measure success? What are the metrics of success?
* Who are the key people and what is their background?
* Do you have investors? Partners? Advisors?
If you are seeking investment dollars, you may also want to answer the following:
• What is the exit strategy?
• Who are potential acquirers and why?
Listing out the features and ranking them is essential, but putting your product build into a context around problem solving, the audience it serves, and how you will acquire users are essential–and following this structure will keep you from getting so long in your organization’s who-ha that you build something only the bureaucrats can love. In other words, put some effort into articulating what the overall strategy is and how this build fits into executing on it, you will get MUCH better results.
The other area where it pays to be ruthless is in rating features you add to a spec.
P0 (which not everyone uses) is foundational/platform
P1 is can’t launch without it
P2 is have to have
P3 is nice to have
Remember that you’re going to be arguing with engineering anyway, so be sparing and realistic with the P0s and P1s–don’t bloat your plan.