For each functional area in a company, a small number of processes can go a long way (for example, doing code reviews in any engineering organization). For product management, the key processes to consider as you scale include:
1. PRD templates and product road maps
The starting point of building a product is getting agreement and clarity on what to build. While engineering owns writing the technical design documentation for how a product will be technically architected and work, product management should own writing up the set of requirements for the product itself. Who are you building this product for? What use cases does the product meet? What does it solve for and explicitly not solve for? What are the main features and what does the product do? What are the main product dependencies? A PRD may include wireframes that roughly sketch out the product user journey.
2. Product reviews
As your organization scales, so too will the number of teams and products. Many companies have a weekly product review meeting. This is attended by a common set of key executives to review progress on a given product and provide feedback on strategy, direction or launch readiness. A set of product teams will come in and present to these executives about their product development or road map.
Some companies will have projects come in as they get staffed for a baseline discussion on primary objectives, use cases, and road maps. Other companies will only focus the meeting on check-ins for major products already underway.
Product reviews are typically a mechanism to resolve uncertainty in direction or trade-offs for a given product area, or to provide cross-functional input to drive product direction or course correction. Product reviews may also be used to check in on post-launch metrics or success of the product or check in on user feedback or adoption.
The teams attending the product review usually include the product manager (who is responsible for organizing and driving the review), the design lead, the tech lead and key engineers, and then other members of the core team needed for a fruitful discussion (this may include sales, BD, support staff, legal, or other stakeholders).
3. Launch process and calendar
Some companies bundle the launch process or calendar into the product review meeting. As you scale and the number of projects skyrockets, having a stand-alone forum to discuss upcoming launches becomes useful. Many companies will have an internal web page where each product is listed with a launch date. Next to each project, each functional area can give a binary “ready to launch” or not, and add questions or issues from their function. For example, product and engineering may all think the product is ready to launch but legal may still be “not ready” due to an unresolved legal question. The launch meeting allows the executive team and functional leads to weigh in on whether a product should go out the door or if there are unresolved items.
4. Retrospectives
After each product launch a healthy practice is to get the main cross-functional members of the team who worked on it together. The purpose is to discuss what went well and should be emulated for other launches, and what went poorly. For both, you can discuss what contributed to the success or failure mode and how to deal with it for future projects.
Retrospectives serve two purposes—(1) to codify and understand what best practices are for product development and launch and (2) to allow some of the praise, as well as pressure and disagreements to vent in the open. By having a forum for non-emotional conversations around what went poorly, different teams have the opportunity to learn what to do better next time, but also to address questions or things that did not work head on.
- Twitter
- Facebook
- Linked In
- Search
Subscribe