The Product Owner role includes many aspects, among which are the ability to meet different levels of requirements, to maintain a balance between strategic product development, creating a vision and value, as well as working with a team on a daily basis and creating tasks that they can understand. To develop a quality product, the Product Owner must ensure that he/she has all types of requirements: strategic, tactical, and operational. To make the task easier, we offer a small checklist that will help make sure you’re moving in the right direction.
It consists of 3 main directions:
The development of each product starts with the question: what problem does it solve? Why would users need it? One of the tools that will help you find the answers is the Business Model Canvas. This is a high-level tool that allows you to understand exactly what your business is and how it works. This is a great opportunity for the IT team to get a closer look not only at the product they are developing, but also at all the components of the workflow:
Understanding the business model is a must for the product owner. Without it, it is impossible to generate quality ideas and implement them.
It can be presented in different ways. One option is the Elevator Pitch format. It provides information about the product in a very concise form (up to three minutes). It’s very often expected from the product owner when it comes to presenting the solution to the team, partners, business development and sales departments.
At this stage, it’s important to create an image of a typical user (the so-called User Personas). There can be several of them — each with its own needs, tasks it wants to solve, limitations it faces. All users are described in the User Story format: As a <user role> I want <activity>, so that <benefit>.
An alternative to User Personas is the newer Jobs-To-Be-Done tool. This approach is relevant when it’s difficult to determine who our users are, or this information doesn’t carry any value. Its task is to identify, categorize, record and organize all the needs of your customers without being tied to a specific person. It is written in the format: When <situation> I want to <motivation> so I can <outcome>.
When you already understand who your end customer is, you can move on to developing a customer journey — Customer Journey Map. Usually, this path is longer than the interaction with the product, because the customer engagement stage is also mandatory.
It must be clear and understandable for the whole team — without it, it’s impossible to move forward. Without a clear idea of what the product should be, developers are reduced to fixing bugs and introducing unnecessary features that don’t solve customers’ problems.
To structure all the information, you can use the “Product Vision Statement” template:
A significant advantage of this approach is that it provides clear input for writing User Stories.
Strategic topics should be understood as the main tasks that the management sets before the team and the product. They help guide development in a certain direction. There’re usually one to three such goals. The maximum possible is five per year, because they are quite voluminous.
Often, strategic topics are described in the OKR format — the classic format for recording business goals. It provides for the formulation of the goal and metrics, aka the indicators thanks to which we will know that the goal has been achieved. Example:
Objective: to increase user engagement on the communication platform.
Metrics (Key Results):
A roadmap differs from the classic approach to work planning (Gantt charts) in that it will change rapidly and is more of a prediction than a firm promise. It’s necessary to explain to management representatives with due courtesy that the road map is the preliminary plans of the team, and the reality may be different, and it’s okay. This gives a huge advantage — flexibility. We can change priorities.
The product roadmap provides transparency of the processes taking place on the project, ready to provide feedback and build its further work on it.
A roadmap can also be written in the format of a “Problem-Focused Product Roadmap”, i.e. a “Problem-Focused Product Roadmap” — an end-user problem we plan to solve. It consists of 2 components:
You have strategic topics that can be divided into epics or features, which can respectively be divided into user stories. In script planning, the team breaks down user stories into subtasks for frontend and backend developers, testers, etc.
If we talk about the User Story, we need to remember that when writing it, we need to remember the 3Cs:
Consider the practice of XP — Extreme Programming. It’s a development philosophy that helps teams build quality software products. As part of XP, you should pay attention to the following groups:
It’s important to establish quality communication with the team to understand whether all the above points are being fulfilled. Especially if the quality of the software doesn’t meet your expectations.
The workflow should be comfortable for all team members — you shouldn’t try to recreate the ideal Scrum described in the Scrum Guide. It should be clear to you and your team, and meet the requirements for rapid product development. You can choose any methodology convenient for you — be it Scrum, Kanban, XP (extreme programming), or FDD. The main thing is not to confuse Agile with chaos, when the workflow isn’t organized in any way.
These are your team’s requirements for the product owner and the user story, which ought to be brought along into work. The INVEST principle is used here, which illustrates how well the User Story is written. Ideally, it should be:
Fulfillment of these points means that the User Story you brought to your team is written with quality and according to the requirements.
These are the product owner’s demands on the team about what it does. These are the criteria by which it can be said that the result of the developers’ work meets the initial requirements. Readiness criteria shouldn’t be confused with acceptance criteria. The latter is different in each User Story, and the Definition of Done is common to all implemented functionality.
In summary, we can highlight a short checklist that will be useful to the product owner:
If the product owner can find the answers to these questions, he/she can outline areas for improvement and avoid many problems during software development.
More details about these roles, as well as specific templates for different levels of requirements, prioritization techniques and much more await you in our training Certified Product Owner / Product Manager with SAFe.
If your company needs to transform or build effective processes, but you don’t know where to start just contact us – [email protected] or choose a time for a free consultation:
Subscribe to our newsletter and never miss our news