Product Owner Checklist: From Idea to Task

Product Owner Checklist: From Idea to Task

The Author:
Alyona Lubchak
Alyona Lubchak,
SAFe program consultant

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:

  • Why? Why do we create a product at hand? Who needs it?
  • What? What exactly do we need to do functionally?
  • How? How do we achieve this? At the expense of what tasks?

Why create a product?

1. Business model of the company.

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:

  • key users and market segments you target;
  • customer relations: subscription, one-time purchase, long-term contracts with tenders (for B2B segment);
  • sales channels: promotions, Internet advertising or comprehensive promotion engaged by a professional sales department;
  • the value of the product for the end user;
  • resources used;
  • activities planned for business promotion;
  • key partners;
  • income stream – the way you intend to earn;
  • cost structure.

Understanding the business model is a must for the product owner. Without it, it is impossible to generate quality ideas and implement them.

2. Concept.

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.

3. Users.

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>.

4. Customer Journey Map.

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.

What exactly are we creating?

Product vision (the vision).

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:

  • Needs — you need to describe the problem we intend to solve.
  • Target group — you can use the format of User Personas or Jobs-To-Be-Done.
  • Product — now it’s time to describe the product and its functionality.
  • The value of the product — you should outline the features of the business model, that is, decide how we’re going to make money off this product.

A significant advantage of this approach is that it provides clear input for writing User Stories.

2. Strategic topics.

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):

  • reducing the number of refusals from membership from 20% to 5%;
  • NPS growth from 35% to 60%;
  • increasing the average number of visits by active users from 5,000 to 20,000;
  • increase in organic traffic from 1,500 to 5,000;
  • improving engagement from 30% to 60%.

3. Product Roadmap.

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:

  • Strategy. Strategic goals are recorded here.
  • Tactics. It covers the research part (hypotheses, their formulation, data collection, their analysis) and software delivery work. The latter involve direct work with development teams that will implement the required functionality.

How exactly will we achieve our goals?

1. Feature Breakdown Structure

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:

  • Card — a sticker on which we record the user’s history directly;
  • Conversation — a discussion between team members during which details are clarified;
  • Confirmation — acceptance criteria, or conditions under which the story will be considered completed.

2. Working with a team

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:

  • feedback;
  • continuous process;
  • code understanding;
  • working conditions.

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.

3. Team process

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.

4. Definition of Ready

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:

  • I – independent.
  • N – negotiable (open for discussion).
  • V – valuable.
  • E – estimable.
  • S – small (small in volume).
  • T – testable (suitable for testing).

Fulfillment of these points means that the User Story you brought to your team is written with quality and according to the requirements.

5. Definition of Done

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:

  • Why create a product? Consider users and their needs.
  • What exactly do you need to create? Talk about product vision, roadmap and strategy.
  • How to achieve the goal? Pay attention to interaction with the team and the transformation of ideas into specific tasks.

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: