During the product development process, when product requirements are being determined, certain guidelines can help a product manager ensure that the product release will meet expectations. Product managers can minimize risk and surprises even though the engineering team will take the lead on this phase of project development.

Product development guidelines

See deliverables early and often

Change occurs often throughout the product development cycle, especially after having observed the product’s functionality. The costs involved differ according to the type of development methodology used, but change itself is inevitable.

To minimize these changes, examine what is being built—do this early in the process and as often as possible throughout (for example, develop prototypes, view small deliverables). This will enable you to identify issues before they become serious problems and have been integrated into the product release.

As discussed in the article Validating product requirements, validation during the process with customers and/or prospects helps to ensure that the product will meet expectations. This may mean showing screenshots or pictures of the functionality or allowing them to try out the product under development.

Find alternative solutions

During the product development process, your team might determine that a solution will take longer to build than originally planned. If the delay is unacceptable, find alternative solutions that will affect the schedule differently. Creative and flexible problem solving will enable you to make trade-offs between a feature’s benefits and its implementation costs.

Work in parallel

While the product development team works on their deliverables, have other team members work on other items needed for the product release. This includes creating marketing documents, product documentation and training. By producing product documentation in parallel with the product development, you can identify any obstacles as you explain the functionality to potential users.

Define “done”

When delivering your product, make sure to get consensus on what “done” means to the stakeholders across your organization. Depending on the viewpoint, this designation can have different criteria.

  • For a developer: Once a developer solves the assigned technical problem (the product requirement) and they submit the solution for testing, they consider the job “done.”
  • For a tester: Once the product has been successfully tested (including unit, regression and test cases), they consider it “done.”
  • For the business owner: The release is not “done” until the product is ready, including all documentation, marketing materials and customer announcements.

Develop product release criteria

Create release criteria to clarify what “done” means for your organization. Explain to the team that the project is not done unless they complete all of the items outlined in the release criteria (for example, features, bug counts, customer feedback, documentation). Providing this information at the beginning of every project will help eliminate any confusion and will establish what constitutes the end of the project.

References

Rothman, J. (2002). Release Criteria: Is This Software Done? Rothman Consulting Group, Inc. Retrieved August 26, 2010, from http://www.jrothman.com/2002/03/release-criteria-is-this-software-done/
Sutherland, J., Dr. (2004). Agile Development: Lessons Learned from the First Scrum. Retrieved August 26, 2010, from http://www.scrumalliance.org/resource_download/35