Keeping Your Stakeholders Involved

They can help in surprising ways

When is a good time to update your stakeholders on your product?  If your product team is developing the requirements well, is there any reason to update your stakeholders?  The beginning of product development is the perfect time to update stakeholders.  Let's discuss why to update stakeholders when requirements are set.

Confirm Spending that Is Needed

This is your time to get approval for investments in the product.  By showing your stakeholders the benefits of working together on the next iteration of the product, platform or service, you can request that key investments continue growth.

Suppose you are a product manager on a Data Center Infrastructure Management (DCIM) product.  Your team has finalized requirements on a new network mapping view in the product.  You've struggled to get the software engineering team to review the requirements because they don't think customers will use the feature.  It turns out there is no way to monitor what customers are doing with your DCIM product.  You arrange a free trial of a leading User Activity Monitoring product and discover customers are pulling reports hourly to track their networking connections.

With this information, you update the business case to show investing in User Activity Monitoring will improve customer satisfaction and enable more use of your DCIM product.  The increase in user licenses covers the investment in the User Activity Monitoring.  The new investment is approved by the stakeholders along with support for the new network mapping feature.

Provide Visibility to Developers

The transition from requirements to development is a key point to expose development teams to stakeholders.  As the product leader, you have an opportunity to recognize the contribution of the engineering and architecture teams.  Additionally, the development teams can get the perspective of the leadership team on the quality of the product and customer feedback.

Let's suppose you have an upcoming stakeholder review of the requirements for your next software release.  You and your engineering lead are in agreement on priorities.  Your forecast in the business case is conservative and based on delivering the highest priority features in 2 quarters.  Your engineering leader presents the staffing needs for the release.  The stakeholders are concerned about product quality in the installed base and ask for increased staffing on field issues.  You need to reduce your ask to enable the engineering team to address the field issues ahead of new features. 

You and your engineering lead recover quickly together by prioritizing the field issues and you partner with marketing to increase demand for the shipping product.  Both your stakeholders and your product team align to this direction and the field issues are quickly resolved.

Conclusion

It is easy to convince yourself that your stakeholders are too busy hear about the transition from requirements to development on a product iteration.  Looking at this transition from the perspective of your stakeholders and developers, it is imperative to hold this review.  You can get approval of incremental budget and get a key insight from your stakeholders.  Closing the requirements phase is a key transition to review with your stakeholders.