Materials are part of the practical ProductDo course - “Technology for Product Managers”
One of the skills of an experienced PM is to quickly formulate the main essence of the product (for whom, why, how to measure, etc.) and estimate its complexity (services, architecture, features, etc.). This allows you to process a lot of research into a simple and understandable Full Product Review document, which can already be (with varying degrees of immersion) told to stakeholders and used for approximate development modeling.
The template is applicable for projects of any size, the level of detail and the name of the document will simply change - the “complex” questions will remain the same:
In real life, the final document is either 3-5 pages of a text doc or 7-10 presentation slides. To write it, the template is just used:
| Section title | Priority | What should be written here |
|---|---|---|
| Elevator pitch | Required | A short and clear summary of the entire document. Imagine presenting a project to the director (a common situation), and you have 30 seconds. How do you highlight the main essence? Don't rush to present the essence if you can’t highlight the essence yet. |
| Context | Required | Imagine yourself in the place of someone who sees your topic for the first time. What facts must they tell him to describe the current state of affairs? Here you can talk about previous attempts to solve the problem, mention relevant neighboring projects, or, for example, tell what the team did on the same topic last year. |
| Problem/requirements | Required | What kind of user/customer problem are we solving? Why do we need to decide anything at all? Why is this a problem? What is its price (1 user or 1000, 1$ or 100000$)? Try to find the very essence. |
| Goals | Required | What do we plan to do about these problems? You can set either an OKR or make a “Before → After” slide in a more visual form. |
| Metrics/KPI | Required | How will we measure business success? Usually goes close to the target. Without metrics, any strategy is just theory. The P should be able to say something like: “The main metric will be X (because XXX), the proxy metrics will be Y and Z (because XXX), and I plan to raise X from value A to value B by the end of the year.” Scary to promise? This means the strategy has not yet been fully developed. |
| Product Roadmap | Required | It is critical to connect the goal with the tactics, otherwise no one will believe you. The trick here is to provide enough detail (for example, 20 planned experiments over the course of a year) without overwhelming the reader (for example, by breaking the experiments into categories). |
| MVP (Minimal Viable Product) | Optional | For projects with a clear structure (for example, a team that sets a goal for the next year), the MVP is simply the “left side of the roadmap”. For new launches (for example, a new product line), the MVP should answer the question: what is the absolute minimum to test the strength of the described strategy? Maybe a landing page is enough? Or do you need minimal application functionality? |
| Non-goals | Optional | What we do not plan to do as part of this project. Usually used so that you are not expected too much. |
| Strategic fit | Optional | How does the project fit in with the company's goals? |
| Background research | Optional | Usually added to the end of the doc with a link to show what research we’ve done. It is important not to reinvent the wheel and base our plans on data, and not on the illusions of an individual PM. |
| User flows | Optional | Often reinforces the requirements section visually. |
| Section title | Priority | What should be written here |
|---|---|---|
| High-level architecture | Required | We draw and describe the main elements, services and dependencies needed to implement the given business logic. See a separate checklist for Architecture creation. |
| MVP and next steps | Required | What functionality/services are included in the first iteration and what are the (approximate) further steps. If the project is simple, then the MVP definition from the business section above is enough. For complex projects, it will be necessary to further formulate the MVP in terms of technical realities (for example, describe several API methods and indicate security restrictions). |
| Main SLIs/SLOs | Required | We highlight and explain in simple language the main metrics of the service level. We associate them with the main metrics (usually in an expanded metrics tree). |
| Client-side tech requirements | Optional | We mention the features of client integration: the number of clients, their requirements, traffic. |
| Dependencies | Optional | We mention the features of dependency integration: service autonomy, dependency criticality, integration complexity. |
| Resilience requirements | Optional | What are the non-functional sustainability/monitoring requirements? |
| Technology state | Optional | Will we use new technologies (e.g. languages/frameworks)? How prepared is the team? How automated is the infrastructure? What is the current state of the architecture? What are the requirements for the future of the product? |
| Security requirements | Optional | What are non-functional security requirements: data protection, fraud appetite. |
| Other non-functional requirements | Optional | What else you need to pay special attention to: compliance, legal, operational, etc. |
| Tech Insights/ Platformisation | Optional | Do you see "shortcuts" that, with the right approach, can be used for business in the future? Can your service turn into a platform? |
| Section title | Priority | What should be written here |
|---|---|---|
| Stakeholder matrix | Optional | Who is involved in the project and in what role (developer team, client team, dependency team, etc.) |
| Launch details | Optional | Markets, dates, volumes (often confidential information). |
| Investments and resources needed | Optional | The required number of programmers, designers, money, time, etc. to implement the idea. |