Guest Post by: Alex Hsu (Mentee, Session 4, The Product Mentor) [Paired with Mentor, Addi Regev]
Why do I need a framework?
A research conducted by Alpha UX found that 25% of Product Manager surveyed wished for a clearer product roadmap and strategy. This was second only to increase in salary!
While salary increase is a complex subject with variables outside of our control, I believe that having a clear product roadmap and strategy is every Product Manager’s responsibility. Without a clear roadmap and strategy, a Product Manager won’t be able to make impactful decisions. And over time, this can mean the difference between a successful versus a failed product.
So to help you achieve this goal, I’ve laid-out a foundational framework that can be used to store and organize incoming product requests into repositories that describe your product’s strategy. Once implemented and properly maintained, this can help you obtain the goal of having a clearer roadmap and strategy, which should help make good product decisioning easier.
Lastly, to make the most out of this framework, it’s best if your organization has already implemented some variation of the Agile Methodology. If not, this can still be applied to most existing process with some tweaks.
To start, break down any incoming feature requests into Themes, Epics, User Stories using the following suggestions.
Themes are critical building blocks for your product’s strategy, each Theme is usually a statement describing an idea that is critical to the vision of your product. Epics are large features that together makes up a theme. Lastly, User Stories are “chewable bits” that together makes up an Epic.
To help illustrate the relationship between Themes, Epics, and User Stories and how they can be applied in practice, I’ve included an example of the hierarchy between each item and how they can be written within the context of a fictional spaceship company.
Example User Story:
A User Story is a description of a functionality written from the perspective from the person requesting the capability.
The User Story should be structured to include:
“As an Astronaut, I want an altimeter to tell me my current altitude from the surface”
For more details about writing a good User Story, refer to this article.
Each of these items are also useful when communicating your product’s strategy to various stakeholders within your organization.
Themes typically describes abstract ideas or concepts critical to your product vision. As a result, they are useful when discussing product strategy with senior management or describing your product at a higher-level without getting into details.
Epics and User Stories, on the other hand, should be concrete features or tasks that are useful when explaining and assigning work to designers or engineers. Epics are also useful when describing features to an end-user of your product or service when collecting feedback.
For more details about Theme, Epic, and User Story, refer to this article.
This document can be used to communicate quarterly objectives that you hope to achieve. Items that go into each quarter should be made up of Epics or a features you hope to achieve.
Below’s an example of how objectives can be structured:
Detachable Landing Vehicle
To maximize its potential, all Items included in this list should be shared and discussed with your business stakeholders so it’s aligned with their needs. A well understood set of quarterly goals where all business stakeholders share the same understanding of the deliverables and their priority is critical for business planning and external communications.
Second, each item under Quarterly Objectives should be traceable to a Epics or Themes so they can be worked on. If done correctly, this document can be a powerful tool that motivates your design & engineering team by setting ambitious yet achievable & well-planned goals.
Third, this will be one of the most important documents that can be used when trying to make product decisions. By looking at this list, you should be able to identify valuable requests and their priority within the overall roadmap.
Lastly, always leave room for changes in scope and timeline to account for gaps in estimation or other factors that might be out of your control. Also, shift the time period according to the context of your product or organization, as an example, an early product that’s still trying to find a market might have a shorter timeline compared to a more mature product.
Finally, you want to set achievable Milestones. Each Milestone should be a plan that contains a deadline as well as an agreed upon set of User Stories or Epics (Let’s call these scope). The scope and deadline should be understood and agreed upon by any party involved in the planning process.
To maximize their potential, tie deadlines to meaningful business events that help market your product to its intended Target Audience. Some example can include tradeshows, product summits, or client demos.
Below’s an example of how Milestones can be structured:
Try to avoid any changes in scope and timeline once agreed upon by all parties involved. Unlike the Quarterly Objectives, if done correctly, a milestones should be tied to a business event where audience should include external prospects or clients. These type of audience are typically less tolerant to changes in expectation that has been communicated to them prior.
I chose this framework because of two major reasons:
- It can be used when communicating across any layer of management or external stakeholders
- Its wide-adoption across most industries and company sizes means there are various tools and resources to choose from.
As a result of its wide adoption, there are various tools and resources built around this framework each targeted to fulfill the needs of their target market, the following research data compiled by Alpha UX shows most commonly used planning tool amongst Product Managers surveyed and can be served as a directional indicator when choosing the tool to implement within your organization.
I wrote this article hoping that it will help Product Managers stay more organized and make better product decisions.
This is not meant to be a one-size-fits-all solution, I would strong encourage you to reflect on this framework within the context of your product and organization’s need and come up with your own evolution of this framework.
For additional readings. I recommend visiting the following sites. Each of these sites contains an array of articles that dives deeper into various subject related to the Agile process & framework.
I would also like to thank Addi Regev who spent portion of her weekends providing constructive feedbacks and suggestions that helped formulate this article.
Alex is a product manager with years of experience in B2B Digital Marketing space. In addition, Alex also has made it his goal to grow and motivate teams to build better products that delights end-user.
Outside of his profession, Alex has made it his personal mission to promote cross-cultural awareness through use of cutting-edge technology. Alex maintains a blog where he writes about product, technology, and travels.
More About The Product Mentor
The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…
Better Decisions. Better Products. Better Product People.
Each Session of the program runs for 6 months with paired individuals…
- Conducting regular 1-on-1 mentor-mentee chats
- Sharing experiences with the larger Product community
- Participating in live-streamed product management lessons and Q&A
- Mentors and Mentees sharing their product management knowledge with the broader community
Check out the Mentors & Enjoy!
The Product Guy