As a product manager, I tried many techniques and frameworks to communicate vision of the product and align team and stakeholders on what needs to be done, why and when. Some of the techniques gave great results and some were a complete mess. Over the years, going through this process of trial and error has allowed me to identify techniques with fantastic results and abandon others that were just a waste of time.
That’s how I created the HAMMER Product Planning Kit.
WTF is the HAMMER Product Planning Kit? Well, HAMMER stands for:
- Ato analyse
- Rroad map
Forgive me, but I had to name it somehow, it’s a tool after all…
The HAMMER Product Planning Kit is a resource directory to help you understand and execute product planning. It is organized in several layers of abstraction. Starting from a high-level business perspective, then gradually digging deeper into the technical details. The end result is a shared vision, a development plan, a roadmap, based on the knowledge of all the documents included.
This kit consists of 5 major documents:
- Product Vision Board (what-if analysis)
- Platform overview (mapping)
- Functional specification (Methodology)
- System Design (Engineering)
Product Vision Board
Product Vision Board is a high-level overview of the product (business layer). It provides a product vision, a description of the users, their needs, and the features required to meet those needs. It is a strategic document that should be used as a guide for setting goals and initiatives.
It acts as the overarching goal guiding all involved in the development effort. This will help you understand why you are building the product, who you are building it for, and what the expected business outcome is.
Why this document is important: to align with high-level project goals. This will help you prioritize work. What contributes to the goal matters, and other features that don’t contribute to the goal will be carried over and deprioritized. Additionally, understanding users and their needs will help you and your team solve problems by creating tailored solutions.
Presentation of the platform
This document provides a high-level overview of the product you are building. It describes the business process behind the application and each step of this process. It’s a place where you outline the user journey, workarounds, pain points, and anything else that will help in understanding the user’s steps. But to get there, you must first survey your users and test your hypothesis defined in the Product Vision Board.
Why is this document important: Understand the end-to-end scenarios (user journey) for each role, and understand the information architecture and business flow for each of the features. This will be a starting point for the development team to break down work items into epics. Understanding the process will help the team make decisions and develop better solutions.
This document describes the application and all its functionalities (application layer). These functionalities must correspond exactly to the needs described in the document Presentation of the platform. The Functional Specification contains feature descriptions along with high-fidelity mockups and UX flows.
Why is this document important:
- So developers know what to build.
- To inform QA engineers of the tests to be run.
- So stakeholders know what they’re getting.
This document contains a set of tasks (tactics) to achieve the goals described in previous documents. It contains a list of all technical tasks, user stories, job stories and diagrams in C with an overview of the architecture.
Why is this document important: it gives a clear picture of the architecture, product design, modules, interfaces and data for a system to meet the specified requirements. Essentially, this will help you build your product backlog with work items. But with all the work done so far, each work item will clearly contribute to your vision and user needs, since each work item is derived from it.
This document contains a high level release plan with proposed release milestones – releases. Each release has a “What’s in the Box” section that outlines what will be delivered to end users, emphasizing results rather than outputs. Also, there is a list of goals and tasks needed to complete each release’s goal.
Why is this document important: The document will be used as a development guide, ensuring that the team is always working on high value and high priority tasks. Additionally, it will help us track progress and measure success.
You did an amazing job bringing all the information together, understanding your users, aligning with your team and stakeholders. You have covered the five layers of abstraction and the five development phases of the roadmap.
Now share these documents with your team members, stakeholders, managers, and anyone else you see fit. Review everything you have gathered and recognize the enormous value captured in these documents. This will help you and your team create an amazing product since everyone is aligned on what needs to be built and, more importantly, why it needs to be built. Having a sense of purpose will give you a huge advantage and motivation.
Everything mentioned in this article (and more) is part of the Notion template I created for myself. This is very useful for new projects, where you have the whole structure laid out, ready for you to start rocking. You can find the model here.
I use this concept for every new project. It helps me understand what needs to be built and why. Having it in writing helps me communicate the product plan to team members and stakeholders. As a result, everyone is aligned, motivated and contributing to the common goal.
This Notion template will help you:
- Create your product hypothesis and understand user needs
- Let your team know what to build and why they’re building it
- Let your stakeholders (investors) know what they are getting