Roles | The Product Owner

HA #38: AMA session with Roman Pichler: The Product Owner | 58 minutes
Age Of Product | Feb 08, 2022

Stefan Wolpers’ Hands-on Agile #38: AMA w/ Roman Pichler: The Product Owner | 58 minutes

Stefan Wolpers’ AMA session with Roman Pichler on the role of the Product Owner.
Speaker: Roman Pichler | Host: Stefan Wolpers

My Notes:

Product Owner = Accountable for maximizing the value of the product
(Scrum Guide 2020)

What is a Product? An asset that creates value for
The users and customers
The company developing & providing it
(Searching for a product online = feature, not product)

What does it mean to own a product? It means
Being empowered to make strategic and tactical product decisions (own a product holistically, cf. Full Stack ownership)
Being responsible for achieving product success

Ownership Depth
Vision = what we want to achieve
Strategy = approach to get there
Tactics = information in the product backlog
Scrum Product Owner = Full stack ownership Vision/Strategy/Tactics
Product Manager in an Agile Context or Agile Product Manager
Compare w/ Partial Ownership
(SAFe = example) Product Owner = more a tactical role => product backlog, more inward facing, close to the Dev Team => Only partial ownership
(SAFe = example) Product Manager = for the Vision & strategic role

3 Scaling options
How to make it work? Get together and discuss it

About the Business Analyst

Characteristics of a great Product Owner
Professional PO (=> focus on the role of PO)
Committed to the Product, to the People, to the Process

About the Right Leadership

Backlog Management
Product Goal => only items that serve the product goal
Not too big, not too fast
Tie product backlog to product roadmap
Sometimes easier to start from scratch than try to make sense of a too large backlog (like thousand+ items)

Big products => Cascading goals
Mission statement
Challenge = Formulate the right goals & connect them in a meaningful way

Authors = Roman Pichler & Stefan Wolpers


Planning | Product Roadmap

What is a Product Roadmap? And How to Create One
Product Manager HQ | Dec 22, 2021

The purpose of a product roadmap is to identify key steps to take and when to take them.
Crafting a product roadmap is no different from planning a road trip. Think about the last trip you planned. You likely first began by identifying key destinations, key dates, and a theme of what kinds of experiences you wanted to get from your road trip.

What is a Product Roadmap?
A product roadmap is a guide that describes the steps you need to take in order to reach your product goals. It’s a plan of action that lines up a product’s short-term and long-term goals. It also outlines how you hope to achieve those product goals.
Product roadmaps can span a variety of timeframes. That’s because different companies and teams can have different timelines.

Types of Product Roadmaps

  1. The Evolutionary Roadmap = This roadmap is a great tool for keeping everyone in sync when there isn’t a lot of information about how the final product will look. This type of roadmap is a solid choice to keep developers, designers, and project managers in sync.
  2. The Release Roadmap = This is the product or marketing team’s most important tool to communicate with the customer community about what features are going to be released and when. Product managers create release roadmaps once the product team has accomplished significant work on all major features planned for the release.
  3. The Theme Roadmap = This roadmap is a logical way to communicate the next features that will be implemented in an effort to meet company goals or customer needs. This map indicates where the product is going and how it plans to get there.
  4. The Timeboxed Roadmap = This is similar to the release roadmap but has more specifics about certain features or types of releases. Similar to a release roadmap, this map is detailed. However, it does not include dates. It serves as a reminder and communication for the team that work should be completed in time for a certain date.
  5. The Capacity Roadmap = This one is similar to the release roadmap but without dates. Capacity roadmaps serve as communication tools among departments or functions and show the types of products that the team will create. Product managers tend to use this product roadmap to discuss resources needed as opposed to specific deliverables.
  6. The Market Requirements Roadmap = This roadmap helps a company steer its product and market positioning. It also shows how the plan and types of products match requirements from the customer or user base.
  7. The Opportunity Roadmap = This one is used for companies that sell to businesses. It helps align business development efforts with strategic initiatives so that customers can be acquired in a coordinated way. For example, product managers create this type of roadmap once a significant amount of work has been completed on all major features planned for the release.
  8. The Project Roadmap = Product leaders use this roadmap to align teams and individuals working on different products or projects with each other. It lets people see how their work fits in with the rest of the company’s plans for that release.

How to Build a Product Roadmap
The first step in building a product roadmap is defining the product strategy. That comes from the vision you have for the product. Then, you and your team will need to gather information from two main sources. Those are your customer support or sales team and your product users.
This will give you a good base for assigning a timeframe to your initiatives.
Keep in mind that a product roadmap should be a strong foundation for all decisions, but it should be flexible. After all, the landscape might change and you might need to re-prioritize.

Why is a Product Roadmap Important?
A powerful product roadmap is built to serve a product strategy.
In product management, you’re faced with multiple viable alternatives all of the time. A product strategy mandates that you select one viable alternative out of many and that you say ‘no’ to many other alternatives.
Because a roadmap forces you to take your journey one step at a time, it means that you will take a specific step in a specific sequence. This helps the team to have a structured plan to follow.

Product Roadmaps Serve a Larger Purpose
They’re also powerful tools for aligning internal stakeholders with the direction that your product is headed. As an example, providing sales teams with visibility on where your product is headed will enable them to sell more confidently in the field. Doing so allows you to secure the buy-in of executives from various internal departments.

Product Roadmap Template
One simple way to structure your product roadmap is to ensure that each row includes the following columns:
New product feature idea
User story and requirements
Effort required = You’ll have to work with your team to figure out the best way to define the effort required. This could be a time or $ cost
Sequence = Which items should be done first? Which items should be done later? Be sure to use prioritization to identify what will give you the strongest ROI, or return on investment.
Estimated release date = Remember to keep this high-level and either come up with or work with your engineering manager to estimate the time required to complete the feature

Best Product Roadmap Tools
While product managers tend to be tool-agnostic, you can get ahead of the curve by familiarizing yourself with these popular roadmapping tools.
ProdPad: Lets you capture ideas and feedback, create product specs, and build a product roadmap.
ProductPlan: Lets you plan and communicate your product roadmap.
ProductBoard: System of record for product management that helps teams make products people want.
Aha!: Web-based product strategy and roadmapping software for agile product managers.
Roadmunk: Visual roadmap software for product management.
Jira: A flexible and scalable issue tracker for software teams.
Excel: A straightforward way to put together your thoughts.
Google Sheets: Easy for startups to use to quickly collaborate on feature ideas.

Author = Clement Kao


Roles | Project Manager vs Scrum Master vs Product Owner

Project Manager vs Scrum Master vs Project Owner
Visual Paradigm | Undated

Role of Project Manager
The traditional Project Manager is a leader, a decision maker, a planner who manages the project and his team and is the person accountable to the business for accomplishing the project objectives. Project manager’s role is to manage the projects and ensure that the project meets the requirements.

The roles and responsibilities of the Project Manager includes:
Define project scope
Gather requirements
Identify activities, dependencies, sequencing, and time estimates.
Identify resources needed
Manages the budget
Reports to business leadership on project progress
Focuses on process
Allocates tasks
Prioritizes features
Ensure quality
Manage vendors
Manages risk

Role of Scrum Master
The Scrum Master doesn’t manage the team that produces the work, instead he supports the Product Owner, coaches the team and makes sure that Scrum processes are adhered to. The Scrum Master is responsible for the Scrum process, its correct implementation, and the maximization of its benefits.

The role of the Scrum Master is more a coaching and facilitation role, a role that sits between the project and the customer and the role includes:
Lead Sprint Planning
Lead / Organize the daily Scrum Meeting
Coaches the product owner
Monitoring the progress of the sprint
Helps team estimate and increase velocity
Promotes continuous communication
Reduce team disruptions
Monitors and helps improve team dynamics
Assist with Reporting
Motivates the team
Acts as the glue that holds the team together

Role of Product Owner
Product Owners have a huge responsibility for the project. They are responsible for maintaining a product backlog that describes the product that must continue to fit with the requirements of the business. During any project, as more becomes known about a product, about customers, or about changes in the market, a product often needs to change in order to meet these requirements. The Product Owner has to adjust and re-prioritise the backlog to fit these changes and to steer the project.

Project Owner’s role includes:
Convey a clear vision of the project
Manage and prioritize product backlog
Ensure development team understand tasks and work on the right features in the prioritized order
Provide feedback and sign off work results

Difference between Project Manager and Scrum Master
In Waterfall, the Project Manager takes a leadership role in leading the team and developing and managing the plan. But what about all those project management activities if the team is Agile?
A project manager helps manage the project timeline, resources, and scope in order to meet business requirements. A Scrum Master, however, helps ensure the scrum team is successful.
A Product Owner works with the customer and team to set direction.
A Scrum Master is a coach and facilitator and coaches the development team in executing Agile practices to complete the work the Product Owner prioritizes.
The Scrum Master works with the Product Owner and the development team to ensure the team members can move forward with development with no impediments, and that the Scrum practices are carried out.

Note That: There is a time or place for a project manager in the large projects. The Project manager can cover multiple teams and can work with other dependent teams as well. Project manager can coordinate with multiple teams, help them to meet project timelines and collaborate when resources are required.


User Stories | Acceptance Criteria

Acceptance Criteria for User Stories: Purposes, Formats, Examples, and Best Practices
altexsoft | May 18, 2021

What are the acceptance criteria and their role in projects?
Acceptance criteria (AC) are the conditions that a software product must meet to be accepted by a user, a customer, or other systems
. They are unique for each user story and define the feature behavior from the end-user’s perspective.
Acceptance criteria are the lowest-level functional requirements
Well-written acceptance criteria help avoid unexpected results in the end of a development stage and ensure that all stakeholders and users are satisfied with what they get.
An important aspect in regard to acceptance criteria is that they have to be defined before the development team starts working on a particular user story. Otherwise, there’s a decent chance the deliverables won’t meet the needs and expectations of a client.

Acceptance criteria main purposes
Making the feature scope more detailed
Describing negative scenarios
Setting communication
Streamlining acceptance testing
Conducting feature evaluations

Acceptance criteria types and structures:

(A) Scenario-oriented acceptance criteria (GWT)
As the name suggests, the scenario-oriented format is the acceptance criteria type that comes in the scenario form and illustrates each criterion. It is approached through the Given/When/Then (GWT) sequence that looks like this:
Given some precondition
When I do some action
Then I expect some result

The acceptance criteria template in this format includes the following statements:
Scenario – the name for the behavior that will be described
Given (a precondition) – the beginning state of the scenario
When (something happens) – the specific action that the user makes
Then (this the result) – the outcome of the action in “When”
And – used to continue any of three previous statements
When combined, these statements cover all actions that a user takes to complete a task and experience the outcome.

Example – User story: As a user, I want to be able to recover the password to my account, so that I will be able to access my account in case I forgot the password.
Scenario: Forgot password
Given: The user navigates to the login page
When: The user selects option
And: Enters a valid email to receive a link for password recovery
Then: The system sends the link to the entered email
Given: The user receives the link via the email
When: The user navigates through the link received in the email
Then: The system enables the user to set a new password

(B) Rule-oriented acceptance criteria format
The rule-oriented form entails that there is a set of rules that describe the behavior of a system. Based on these rules, you can draw specific scenarios
Usually, criteria composed using this form look like a simple bullet list.

Example – User story: As a user, I want to use a search field to type a city, name, or street, so that I could find matching hotel options.
Basic search interface acceptance criteria :
The search field is placed on the top bar
Search starts once the user clicks “Search”
The field contains a placeholder with a grey-colored text: “Where are you going?”
The placeholder disappears once the user starts typing
Search is performed if a user types in a city, hotel name, street, or all combined
Search is in English, French, German, and Ukrainian
The user can’t type more than 200 symbols
The search doesn’t support special symbols (characters). If the user has typed a special symbol, show the warning message: “Search input cannot contain special symbols.”

Ready-to-use acceptance criteria templates

Roles responsible and how acceptance criteria are created
Some of the criteria are defined and written by the product owner when he or she creates the product backlog. And the others can be further specified by the team during user stories discussions after sprint planning.
There are no strict recommendations to choosing the person responsible for writing the criteria. The client can document them if he or she has ample technical and product documentation knowledge. In this case, the client negotiates the criteria with the team to avoid mutual misunderstandings. Otherwise, the criteria are created by a product owner, business analyst, requirements analyst, or a project manager.

Main challenges and best practices of writing acceptance criteria
Document criteria before development.
Don’t make AC too narrow.
Keep your criteria achievable.
Keep AC measurable and not too broad.
Avoid technical details.
Reach consensus.
Write testable AC.

Follow these tips for guidance on how to phrase your AC.
Write in active voice, first-person.
Avoid negative sentences.
Write simple, concise sentences.

Final word
Don’t neglect the acceptance criteria as they – being simple and approachable – solve multiple problems at once. They document customer expectations, provide an end-user perspective, clarify requirements, prevent ambiguity, and eventually help quality assurance verify if the development goals were met. Regardless of whether you use Agile methods or not, make sure to choose the best format or experiment with your own ones. Different types of user stories and eventually features may require different formats and testing the new ones that work for you is a good practice.

Author = altexsoft


User Stories | User Stories & Epics

How to Write Epics and User Stories
Nov 16, 2018


As a product manager/owner while creating an epic include the following four things as the very basic structure.
Product requirement
Technical requirement
Design requirement

In short, your introduction can include:
summary of what the features you’re building are for and why you’re building them
what metrics you are trying to improve
links to specific documentation
marketing plans, legal requirements (if any)
early wireframes

Product requirement
An essential part of the epic where you provide with an explanation for the whole team working on it to understand what are they going to design, build, test or release. For example, if you are building a feature that the feature has to be fast or should be available in multiple languages, or should work on multiple devices like mobile, tablet and desktop should be mentioned in the product requirement section of your epic.

Design requirement
While writing the design requirement collaborate with your UX designer as much as you can. Take their input as there might be things that a designer thinks is important in order to have a better user experience which wouldn’t cross your mind. For example, a designer might think the preview should be of a certain size and the profile picture should always maintain certain resolution in order for a good experience than those kinds of requirement should be written here.

Technical requirement
Similar to the design requirement in this part of the epic try to involve the engineers or tech lead as much as possible. Their inputs in the early stage will be very useful while estimation and building it correctly. For example, the engineering team might want to build an API to integrate with some other system in order to fetch and maintain the quality of an image, those kinds of specifications and requirements should be mentioned under engineering requirements.

User Stories

User stories are basically the break down of an epic in a more user-focused way for the engineering team to understand the product requirement. In agile methodologies, everything that we build should be focused around users and hence the main purpose of the user story should be to shift the focus around a feature in a more human conversation manner.

Here is a simple template that is widely used while creating user stories:
As a (type of user), I want (some goal), so that (reason).

The point of the user story is to clearly state the feature desired from the point of view of the user.
A user story must have just the right level of detail. It should be a high-level requirement with additional detail added to the accustomed acceptance criteria.
The acceptance criteria are the clear picture for the engineering team to understand ‘what’ they are building and for the QA to clearly state the acceptance test.
The components to be included are:
User story
Acceptance Criteria
Design attached to the user story

Author = Bindiya Thakkar