Agile development methodologies are very much in vogue at the moment. And for many good reasons. That said, sometimes it can make sense to reflect on the “waterfall” approach.
This article is not intended to address the agile vs. waterfall debate, or to suggest that waterfall is better than agile. I present it here because, in cases where it is appropriate, there is some value in having a template to consider.
Product planning with a waterfall model assumes that much can be predicted or anticipated up front, before the development process begins in earnest. It assumes that functional requirements can be known and articulated, that software development productivity and results can be predicted, and that dependencies and resource requirements can be figured out in advance. As with most organizational approaches, it also assumes that the main participants are willing to follow the methodology’s principles (and are effective at playing the roles expected of them).
In circumstances where these assumptions hold, then it can be helpful to have a template for organizing the product plan. Below is an outline that I've used successfully with Development teams in the past.
<< Explain what this release / product is aiming to achieve >>
<< Put the project in context with the overall market >>
<< Explain the design of the overall UI / application. Screen shots, workflow diagrams and mockups very useful. >>
<< More details on the core architecture and what the functional groups do and how they relate to each other >>
<< Lowest level description of the feature set >>
<< Use a new section for each group of functional feature set >>
<< List here major new areas of new R&D and other notes that relate to the development process. This is good for identifying risks and also possible patent opportunities. Often it is useful to explain why R&D in certain areas is being prioritized (e.g. invention / innovation; customer feedback; competitive advantage (or addressing gap), etc. >>
<< List here major items of work on existing code to address bugs, missing functionality, design and workflow issues, etc. Often it is useful to explain why items are prioritized (e.g. reported by customers, source of competitive disadvantage, etc.) >>
<< List here what documentation is required (Help, Release Notes, Tutorials, User Guide, API documentation, etc.) plus in-product non-code content such as templates, sample data, sample code, etc. >>
<< What do you need from outside the core team, from developers not directly assigned to the project? >>
<< What do you need from outside third-parties that you need to license? >>
<< What other software or systems developed or located inside of the core team do you need to integrate with / be interoperable with? >>
<< What external software and hardware do you need to integrate with? >>
<< What target systems is the software designed to run on? (operating systems, browsers, devices / system requirements, etc.) >>
<< In which languages is the UI (strings, hints, tooltips, etc.)? In which languages is the documentation? (Help, etc.) >>
<< Explain here key information about the installer. List what will be on the CD or in the download package, including any requirements for an Autorun. Will the product have an autoupdater, and if so, explain it. >>
<< List here details on how the software (or other assets) will be licensed, whether license files or serial numbers will be used, what license types are supported (perpetual: node, floating, dongle; time-limited: trial, eval, NFR, subscription), whether the user is encouraged to / required to activate or register, etc. >>
<< What input file types will be allowed? What output file formats will be supported? Will the application “take ownership” of certain file extensions? >>
<< Will tools be required to assist supporting users / debugging problems? E.g. logging, diagnosis tools, system information collection tools, etc. >>
<< Note here significant work / investment in tools, processes and infrastructure that relates to enabling / making more efficient QA (e.g. automation, code coverage analysis, bug database, etc.), Dev (e.g. IDE, source code management) and Build (e.g. build tools / server). >>
<< List here key concepts behind branding (splash screen, colors, icon design, fonts, look and feel, etc.) >>
<< List here any research required (user visits, focus groups, competitive analysis, technical research, etc.) and skills development / acquisition (that the team doesn't have but will need) >>
<< Who is on the team? (developer, QA, product manager, etc.) >>
<< Will equipment need to be purchased? >>
<< What support is needed from IT? >>
<< Information about when the project got started / will get started, team assembled, requirements fleshed out, etc. >>
<< Information about when code that will actually ship in the product starts to be written by developers >>
<< When will customers be engaged to verify key assumptions, etc. during the Development process? >>
<< Information on when feature set is complete, but necessarily fully stable >>
<< Information on when feature set is complete, and stable enough for people outside of Geomagic to start playing with and giving feedback >>
<< Information on when there will be no more changes to the UI, enabling translation and documentation to be finalized >>
<< Information on when, subject to a final round of full testing, we have a candidate of suitable quality to ship >>
<< Information on when the final installer and CD master is ready >>
<< Date on which a customer first takes delivery of the release >>