Communicating the Product Vision

What are we supposed to build?

One of the most important responsibilities of a Product Owner is to communicate the product vision to all members of the organization. Not only is understanding the vision critical to product development and delivery, but it is also essential that everyone buys into the vision in order to contribute efficiently. For best results, spend time selecting appropriate modes of presentations per each audience type based on their needs and respective roles.

This week, I am sharing advice on techniques to present the vision and on how to maintain this information when you have adopted an agile methodology in which you are most competitive with a 'just in time' approach to planning.

Your executive team typically wants a 30ft view presentation of the product vision, but you must be prepared for a convincing dialog over all the questions related to strategy and product marketing. Pictures, numbers and colors are best for presenting any idea to an executive. Remember, this role has limited time to listen or read and you need to win enough confidence for them to entrust you with all the details. Here are some good artifacts to present:

• Roadmap with at least a 90-180 day outlook. Be sure to include some figures and milestone points for potential revenue recognition. *Note: The roadmap is maintained until the end of time.
• Business model canvas. Recently I discovered a great template from a book called "Business Model Generation," and the authors built an iPad app which has revenue stream and total cost of ownership calculations.
• Slideshow. Limit to 8 bullet points and 8 slides max. Read up on powerful visual communication with less words. Could be thought of as a pitch deck to a board of VCs.
• Elevator statement. This format is good for all audiences and should be your opening line during the presentation; however, this is not enough for the executive you intend to win buy-in from.

Upper-level management teams typically want to know how they can support your direction in their respective disciplines and learn of any impact to shared resources including the budget, if applicable. If you have a roadmap, share it. If not, don't try to talk about the future too much, since anything more than 3 months out is going to change anyway. Here are some good artifacts to present:

• Elevator statement with the following format,

"For the [target audience]
That wants/needs to [problem,opportunity], 
The [product brand] offers [feature 1-2].  
Unlike [main competitor], 
The [product brand] is [key differentiator]."

• Product advertisement. This can be the software in a box design, the SaaS webpage, and/or the app store download description.
• Press release mock up. This is more specific but highlights the 1-3 key features that differentiate your product.
• Magazine advertisement mock up. Choose the magazine most appropriate for the product, and design what and how they would highlight about the product.
• The release plan translated. They will not read all the user stories and may not even understand it so you will need to translate it to a story outlining the epics and themes.

Your Product Development/Product Management team members will have contributed to all of the items above but will need direction from the product owner on where to start and what the first release should be. The team could consist of developers, QA, product managers, architects, business analysts, and any other roles in the hierarchy of product ownership which could include C-Level executives, VPs and directors. This is where all the straight-up, no-B.S. collaboration happens daily, and the entire team is expected to maintain these artifacts real time:

• Product backlog. This is basically the roadmap broken down and in one singular column of priority. The items at the top will be more broken down with details while the items toward the bottom are epics.
• Release plan.  A collection of themes that make up a product with enough features to deliver business value that is acceptable to market. Release metrics include release burnup and burndown.
• Sprint backlog. Set of user stories from the top of the product backlog that the Scrum team has analyzed and committed to finishing by the end of any given time boxed sprint.

Finally, don't forget about your external communication to partners and clients. Any one or combination of the product vision artifacts I have mentioned above may be perfectly suitable. It simply depends on the reason for sharing information. I suggest you always maintain an internal roadmap and an external roadmap to share with partners (and maybe clients, too).

As an experienced product owner, you know all the red flags to avoid and what expectations should be set with which parties. Timeless key principles to remember when communicating the product vision are to 'under promise and over deliver' and know that anything more than 3 months into the future is going to change, so don't over think it. If you are operating in a culture where product development follows Scrum and the rest of the company does not,  then you will be forced to provide a year roadmap, and it will be nothing more than you and the team's best guess.

References:

- http://businessmodelgeneration.com/book