Communicating Your Intentions
Requirements that inspire your design team
How do you describe the intention behind requirements without specifying architecture and design? What do you do if the requirements are technically gnarly or the requirements are for a new solution? There are a few ways to communicate about requirements without stepping on the toes of architecture and design leaders.
Basics of Requirements Intentions
When documenting requirements, communicating about the reasons for the requirements is almost as important as well written and prioritized requirements. Some basic guidelines for communicating the reasons for requirements:
Business justification backed by technical background - good product managers can cross between business and technical explanations in a way architects and designers can use for planning new solutions.
More pictures than words - communicating about relationships between key solution components help customers and your engineering team give feedback during the requirements phase of a solution.
Use present tense in requirements - this helps the team visualize the solution better than future tense.
Using these basic best practices, you can start communicating about the reasons driving your requirements. It can still be challenging to avoid specifying an architecture or design on highly technical solutions. There are a few other tactics you can use.
Discuss A Real Customer Problem
Have multiple customer conversations with architecture leaders, user experience leads and designers. Include this team in preparing open-ended questions for the customers. After the customer conversations, document the customer's problem using the customers' words:
Customer architectures highlighting the problem to be solved with the new solution - a picture showing the current customer architecture helps the product team understand the problem from the customer's perspective
Business impacts to the customer - using the architecture from the customer, you can quantify how business is impacted at the customer. For example, you can show:
Manual steps that the customer wants automated
Frequent service impacts that the customer wants to avoid
Process optimizations that lead to cost savings for the customer
Customer's priority on resolving the problem - the customer's reasoning about which requirements make the biggest improvement. For example, customers might want automatic provisioning before handling higher scale.
Even if a customer perspective doesn't match your product direction, it is helpful to accurately represent the customer conversation in terms of their architecture and business needs. You can rationalize any differences between the customer conversation and product direction when prioritizing the requirements.
Describe the Winning End State
It is very tempting to focus requirements on the urgent priorities; especially when the product team is small or overloaded. Unfortunately executives don't want to invest in a limited solution that only addresses a small customer segment. An exciting vision of an end state solution is needed to get enough resources to make progress toward the end state.
Once you summarize the customer problem in business and technical terms, you can describe the ideal end state and show incremental steps to reach the end state. This phased description can be the basis of a potential business case.
Conclusion
Writing compelling requirements that spurs organizational investment in your solution is a challenge for many product managers. Planning ahead to involve architecture leads in customer conversations and communicating about customer issues does spark incremental investment.