Documenting the Development Process

Good product documentation serves as a contract for a product team, holding its members accountable for an agreed-upon definition of the product. Without it, the development of a realistic schedule, testing the product, creation of a user interface, and dozens of other tasks in the process become nearly impossible.

For those just starting to add documentation to the development process, here is a review of what needs to be defined to increase the quality of your product and decrease your time to market.

1.) Customer Definition

The customer is the focal point of a product. After all, a product’s success is based on its ability to meet the needs of a customer or group of customers. By looking at the needs and expectations of your customers, you should be able to make most tough decisions about your product. In defining your target customer, be careful not to cast too broad a net. Your product may eventually solve all the world’s problems, but for it to be successful for the first few months, you are better off trying to focus on the needs of a small audience.

Define:

  • The target customer (make use of demographics/firmographics)

  • The problem that the product solves (i.e., customer needs)
  • Market size (the number of potential target customers)
  • Factors necessary to meet customer needs

2.) Scope

To prevent scope creep in the middle of development (the cardinal sin), you need to make sure that all stakeholders know what is in the release as well as what didn’t make the cut. For those features that aren’t in the release, note in your documentation why they were cut and when you anticipate their launch.

Should the scope of the project change in development, make sure that you update your documentation and distribute it to all stakeholders to be certain that no one is surprised when the feature set or launch date changes.

Define:

  • What the objectives are for release

  • What’s in the release
  • What’s not in the release, why it was cut, and when it will be added in the future

3.) Metrics for Success

Define the metrics and projections/goals that you will use to measure the success of the product. Doing so will help you build consensus about the objectives of the product and set realistic expectations for its impact on the business. As part of the feature requirements, make sure that you are building the tools you need to measure the product’s success (for instance, site reporting, customer service emails, etc.).

Define:

  • Metrics to measure success

  • Projections or goals for performance
  • Features required to measure goals against performance

4.) Competitive Landscape

Most products exist within a market that includes one or more players that are offering products that attempt to meet the same needs as your product. You may approach these needs in a more effective way, but the difference won’t be clear to your customer unless you can clearly articulate it.

Define:

  • Competitors in the space

  • Positioning comparison with competitors
  • Feature-set comparison with competitors
  • Key factors to competing successfully

5.) Feature Requirements

A feature requirements document is the most important document in the development process. It defines all the feature decisions about the release. Good requirements documentation should be comprehensive (covering all features), digestible (easy for tech and marketing to read), unambiguous (leaving no room for multiple interpretations), and testable (enabling QA to determine if the product satisfies all requirements).

Define:

  • Load requirements (i.e., expected volume)

  • Integration requirements with other products
  • User interface requirements (e.g., all data entry fields must be the same size)
  • Feature requirements
  • Page flow (ideally include a flow chart)

Related reading

specs
screen-shot-2016-09-13-at-10-20-04
mike-andrews
rsz_adblock
<