Handbook For Product Owners Oct 2022

12 Principles Consulting
Handbook for
Product Owners
Naveen Nanjundappa
Certified Product Manager
Certified Scrum Trainer
naveen@12principles.in
+91 9980505003
12 Principles Consulting https://12principles.in
Introduction
This handbook is primary reference material for participants of Certified Scrum Product
Owner Training & Certification program. This covers all the essential topics that are
required to get started as product owner and also get deeper with product thinking.
Naveen Nanjundappa is well known for his unique teaching & unconventional coaching
style, he has over 20 years of service in IT industry, practicing Scrum since 2005, following
his passion for coaching & product management, he has spent the last 9 years coaching
organisations towards agile adaptation & transformation, Implementation of Scrum
framework.
Mr. Naveen Nanjundappa has coached over 50 teams to achieve higher efficiency at their
work. Trained over 6000+ people from various organizations. Brings expertise in Scrum,
Leadership Agility, Organizational Agility, Process Agility, Team Agility, Product
Management & Project Management.
Mr. Naveen Nanjundappa, has shared his ideas and expertise in various agile conferences
across India. His certifications include Scrum Alliance’s Certified Scrum Trainer (CST),
AIPMM’s Certified Product Manager (CPM), Expired (2019) - Project Management
Professional (PMP).
This handbook should be used with other reference books described in the appendix.
Handbook for Product Owners © Naveen Nanjundappa 2021 1

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right,

we value the items on the left more.
Principles behind the Agile Manifesto

❏ Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
❏ Welcome changing requirements, even late in development. Agile processes harness
change for the customer's competitive advantage.
❏ Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
❏ Business people and developers must work together daily throughout the project.
❏ Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
❏ The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
❏ Working software is the primary measure of progress.
❏ Agile processes promote sustainable development. The sponsors, developers, and users
should be able to maintain a constant pace indefinitely.
❏ Continuous attention to technical excellence and good design enhances agility.
❏ Simplicity --the art of maximizing the amount of work not done-- is essential.
❏ The best architectures, requirements, and designs emerge from self-organizing teams.
❏ At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.
Source: http://agilemanifesto.org
Agile Manifesto Authors :
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James
Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve
Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas.

Scrum Framework
Thinking IQ: As Product Owner how much do you understand about the Scrum Framework,
refresh your knowledge before reading further. Refer to the Scrum Guide (2020)

Scrum Events on Timeline
*Product backlog refinement is a background activity and not Event in Scrum.
Strategy IQ: What is your sprint duration? Why & How was that duration chosen ?
Scrum Values
Everyone in the Scrum Team should adhere and demonstrate the Scrum Values.

The Product Owner

Yes, as the organizations tend to use agile frameworks, you would have heard this title very
frequently in recent times. In fact this is one of the roles defined in Scrum Framework and other
scaling frameworks such as Less, Scrum@Scale, Nexus, SAFe and few others continue to use this
role as defined in Scrum to a great extent. While you might see some changes in their
accountability and focus across various frameworks. In this book we will focus on product
management, ownership & product owner roles.
The Product Owner is the CEO of the product, who is accountable for the success of the product
and is responsible for maximizing the value of the product. This role is associated with one single
person in order to handle the complex zone requirements effectively. The Product Owner
manages the expectations and opportunities for delivering value through the Product Backlog.
On a high level Product Backlog management includes:

❏ Clarifying & clearly expressing Product Backlog items;
❏ Based on the goals ordering Product Backlog items;
❏ Optimizing the value of the work the Development Team performs;
❏ Ensuring that the Product Backlog is visible, transparent, and clear to all;
❏ Ensuing the Product Backlog items are ready for next upcoming sprint;
❏ Collaborate with the Development Team
Product Owner is similar to a Movie Director - who knows the big story, the purpose, their
audience and needs, the capabilities of the artists, budget constraints, latest trends,
goto market strategies and when to release their movie.
Qualities of Product Owner

In order to be effective and efficient, Product Owner demonstrates these qualities at work
❏ Visionary, ❏ Quick And Decision Maker,

❏ Expert In Product Management, ❏ Leader, Ability To Say No,
❏ Understand Product Lifecycle, ❏ Good Communicator,
❏ Strategic Thinker, ❏ Removes Product Related Impediments,
❏ Customer Focused, ❏ Empathizer,
❏ Business Oriented, ❏ Good Knowledge Of Scrum Framework,
❏ Influencing Personality, ❏ Collaborative,
❏ Good Negotiation Skills, ❏ Team Motivator,
❏ Conflict Management, ❏ Focus On Products.
so on…
Strategy IQ: Can Scrum Master assume the role of Product Owner? Can one person
handle both product owner and scrum master activities together ?

The Product Owner In Organization

As organizations work with various complexities of requirements and products, the role of
Product Owner has been used in one or more of the following ways.
❏ A Product Owner has complete ownership of target customer, problem, & solution;
In this case the Product Owner does all the activities that result in understanding the
product space, opportunity areas, solution space, users and customers, technology,
creating vision, roadmap, managing release, development and product strategies. This is
typical end to end product management activity that is/was done by Product Managers.
❏ A Product Owner owns the delivery of someone else’s idea or initiative;

In this case the Product Owner does all the activities related to solution space, managing
stakeholders, users and customers expectations, technology decisions, managing release,
development and product strategies.
❏ A Product Owner delivers a shared service to other teams in the organization;

In this case the Product Owner manages the product developed basically that focuses on
the requirements and needs of internal customers towards shared services or dependent
teams. Perform the activities related to solution space, managing stakeholders, users and
customers expectations, technology decisions, release, development and product
strategies.
❏ A Product Owner works on short-term projects that they own the outcome for, etc.
In this case the Product Owner manages the development of the functionalities associated
with the bigger product and performs the activities related to managing product backlog,
working with the development team for development activities, managing expectations,
technology decisions & release

Various other strategies that organizations use for Product Owners are:
❏ No Power by just "order taker" and execute them
❏ Focusing only on strategy and handing details off to the delivery team;
❏ Leaving everything ambiguous, letting the team figure it out with no input;
❏ Telling the team how to do their job and monitor them
❏ Proxy Product Owners that don’t have authority to take decisions
❏ Technical Product Owners for customer-facing products;
❏ Part-time Product Owner who is attempting to fill the role while doing another job.
Product Owner Anti-Patterns
Product Owner is in-effective when they have below anti-patterns.

❏ The Product Owner is an order taker;
❏ The Product Owner always says “Everything is Important”, focusing only on strategy and
handing details off to the Development Team; & Leaving everything ambiguous, letting the
team figure it out with no input;
❏ Telling the team how to do their job.
Strategy IQ: Is your Product Owner effective ? If not, which anti-pattern did you notice ?
How to avoid such an anti-pattern ?

Decision making approach for Product Owner

Product Owners might use one or more of the following strategies for decision making.
❏ Decides and informs everyone
❏ Consults everyone before taking decision
❏ Delegates decision making but owns accountability of result.
Such decision making situations might arise during requirement gathering, clarification,
roadmap, release, and any other situation where product owner decision making is essential.
Strategy IQ: Where should the Product Owner be? Product / Services company
Product Owner is Product Owner - Decision Product Owner - Decision

Accountable Making - Good to use when Making - When NOT to use
PO Decides & Tell

you don't have Capability &
Others about their Capability & you know things
you don't know things
decision
someone else has better

Someone is not SME or you
PO Consult (SME) understanding or you think
don't want too many options,
then take decision someone can give you more
you have capability to decide
information to decide
you know that someone else

PO Delegate can do this activity better If you are not sure of another
decision making to than you can. or person's capability and you
someone else you don't have time to do it can't trust them.
yourself.

Product Backlog Refinement ( Not Scrum Event )

Developers / Development Team

❏ Discuss and understand the requirement, ask questions that clarify the assumptions,
needs, purpose, and expectations of the user / customer.
❏ Create high level design or flow charts or wireframes ( or any other visualization technique)
that would help developers to get better clarity on the requirement.
❏ Identify & discuss assumptions, risks & dependencies.
❏ Estimate the size (complexity) of product backlog items if large, discuss with the product
owner and break them into smaller items so that they can be 100% done within the sprint.
❏ Refer to the mutually agreed definition of ready, if the developers agree the product
backlog item has sufficiently satisfied the readiness criteria, mark them “ready”
Product Owner
❏ Presents user / customer need and expectation described in the product backlog items.
❏ Provide clarity on acceptance criteria by answering questions, resolving
misunderstandings
❏ Invite / involve subject matter experts, customers, users, stakeholders to clarify the needs
and intents if required and provide clarity to developers
Scrum Master
● Facilitate as required
● Ensures that the event takes place and that attendants understand its purpose.
● Help team visualise the conversation and key points
● Teach tools/techniques, strategies that help the Scrum Team to keep it within the time-box.
● Ensure the development team & product owner have open discussions and mark product
backlog items ready for next upcoming sprints.

Sprint Planning

❏ Based on the capacity or historical data of the team, they pull items from the product
backlog and plan for “how*” to implement the functionalities that meet sprint goals.
❏ Discuss high level design approach, low level designs, test scenarios and other functional
implementation areas, new assumptions, risks & dependencies.
❏ Create a sprint backlog to self-organise and manage their work & reach sprint goals.
❏ The Development Team works to forecast the functionality that will be developed during
the Sprint.
❏ *Break the product backlog item into tasks, estimate them. (capacity based planning
technique)
❏ Explain to the Product Owner and Scrum Master how it intends to work as a
self-organising team to accomplish the Sprint Goal and create the anticipated Increment.
Product Owner
❏ Presents "what to do” / “goal” using the product backlog items.
❏ Provide clarity on acceptance criteria by answering questions, resolving
misunderstandings
❏ Make trade-offs, negotiates with the development team on feasible outcome and sprint
goal
Scrum Master
❏ Facilitate as required
❏ Ensures that the event takes place and that attendants understand its purpose.
❏ Keep the focus of the team on the goal of the sprint planning
❏ Teach tools/techniques, strategies that help the Scrum Team to keep it within the time-box.
❏ Ensure the development team & product owner have open discussions and plan effectively

Example #1
Topic 1 : Why is this sprint valuable

Define Sprint Goal & Scrum Team mutually agree
Sprint Goal : "This sprint is focused on accepting the new application for Issuing Driving Licence "
With this Objective we will be able to inspect and adapt new application processing steps.
Topic 2 : What can be done this sprint

Identify product backlog items that meet sprint goals, get clarification, discuss and negotiate
Developers selected Product Backlog Items to achieve the sprint goal
PBI 1 : Driving Licence process and flow information page
PBI 2 : New applicant eligibility check to apply for Driving Licence
PBI 3 : Form / Webpage to accept the information from the new applicant
PBI 4 : Upload documents related to new application
PBI 5 : Store and retrieve the information submitted by new applicant
PBI 6 : Edit Information submitted by new applicant
PBI 7 : Confirmation of submission
PBI 8 : Schedule for Driving test
PBI 9 : Payment of fees for new application processing and driving test
Topic 3 : How will the chosen work get down

Developers create just sufficient plans for each Product backlog items, small enough to inspect
and adapt, high level, low level designs during the sprint planning.
Example #2

Daily Scrum
❏ Focus on the Sprint Goal & Sprint Backlog

❏ Inspect how progress is trending toward completing the work in the Sprint Backlog
❏ Adapt to optimize their plans for the next 24 hours, to work together towards the sprint
goal.
❏ Meet after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the
Sprint’s work.
❏ Can decide on any format, time, place and use the 3 question format if required.
Product Owner
❏ Is optional but if present, be a quiet observer, don’t disturb the team.
❏ Provide clarity on acceptance criteria by answering questions & resolving conflicts, if
asked by the development team and response is short, else discuss after Daily Scrum.
Scrum Master
❏ Ensures that the Development Team has the meeting
❏ Teach tools/techniques, strategies that help the development team to keep it within the 15
min time-box.
❏ Ensure the development team plans effectively for the day.
❏ Ensures that external people do not disrupt the meeting.

Sprint Review

❏ Discusses what went well during the Sprint, what problems it ran into, and how those
problems were solved;
❏ Demonstrates the work that it has “Done” & answers questions
Product Owner
❏ Explains what Product Backlog items have been “Done” and what has not been “Done”.
❏ Discusses the Product Backlog as it stands. The Product Backlog may also be adjusted as
required
❏ Projects likely release targets and release dates based on progress so far.
❏ Collaborates with others on what to focus on during the upcoming sprint.
❏ Review of how the marketplace or potential use of the product might have changed what is
the most valuable thing to do next
❏ Review of the timeline, budget, potential capabilities, and marketplace for the next
anticipated releases of functionality or capability of the product.
Scrum Master
❏ Keep the focus of the team on the goal of the sprint review
❏ Ensure the development team, product owner, stakeholders and other participants have
open discussions and review overall product and future plans effectively

Sprint Retrospective
The Scrum Team ( Developers + Product Owner + Scrum Master)

❏ Inspect as a team and create a plan for improvements that needs to be enacted during
the next Sprint.
❏ Focus on continuous improvement in people, process, tools & techniques, strategies
❏ Plan to improve the quality of the product by inspecting and adapting Definition of Done.
Scrum Master
❏ Keep the focus of the team on the goal of continuous improvement
❏ Ensure the everyone present have open discussions and plan for improvement effectively
❏ Ensures that the meeting is positive and productive
Strategy IQ: Can the Product Owner be replaced temporarily during their absence? What
could be potential benefits and issues ?

Product Owner Working With Multiple Teams
As we start discussing the strategies that are required to work with multiple teams, in such cases
one can refer to some of the Product Owner scaling strategies described in LeSS, Scrum@Scale,
Nexus and so on.
Irrespectively we need to ensure that the Product Owner is accessible, accountable and remains
the decision maker for all product management activities.
The Product Owner is one person, not a committee. The Product Owner may represent the
desires of a committee in the Product Backlog, but those wanting to change a Product Backlog
item’s priority must address the Product Owner. For the Product Owner to succeed, the entire
organization must respect his or her decisions.
Decision Making Strategies Good to use When to Avoid
PO Decides & Tell Others about PO has Capability & has PO doesn't have Capability &
their decision information to decide no/less information
Someone else has better

Someone is not SME or PO
PO Consult (SME) then take understanding than PO or
don't want too many options,
decision someone can give PO more
PO has the capability to decide
information to decide
PO knows that someone else

PO isn;t sure of other person's
PO Delegate decision making can do this activity better than
capability and PO can't trust
to someone else they can or PO doesn’t have
the person’s capability.
time to do it themself.

Advantages of Single Product Owner Disadvantages of Single Product Owner
Single point of failure - Requires the Product

Complete ownership of everything related to
Owner to be knowledgeable and expert in all
Product
areas of product management
Not effective for products that requires multiple

Decision making - Faster & effective
teams efforts
End to end visibility of the product Difficult to find & hire such individual who is
development and activities expert in all areas of product management
Advantages of Multiple Product Owner Disadvantages of Multiple Product Owner
Very effective for large and complex product Unless the structure is not clearly defined and
development that requires huge efforts and communicated, the decision making will not be
teams easy
Different sections of Product management can

Miscommunication and delays might create
be effectively handled for complex and large
conflicts in decision making
product development
Easy to split the responsibilities between

Not effective for simple product or
business focus ( strategic )
1-3 teams to build product
and team focus ( tactical )
Strategy IQ: Challenges of being a Product Owner with multiple teams? How would you
handle them?

Cancelling a Sprint
Due to the short duration of Sprints,
cancellation rarely makes sense. In general,
a Sprint should be cancelled if it no longer
makes sense given the circumstances.
❏ A Sprint can be cancelled before the
Sprint time-box is over.
❏ Only the Product Owner has the
authority to cancel the Sprint,
although he or she may do so under
influence from the stakeholders, the
Development Team, or the Scrum
Master.
A Sprint would be cancelled if the Sprint

Goal becomes obsolete.
❏ This might occur if the company
changes direction or
❏ if market or technology conditions change.
When a Sprint is cancelled,

❏ any completed and “Done” Product Backlog items are reviewed.
❏ If part of the work is potentially releasable, the Product Owner typically accepts it.
❏ All incomplete Product Backlog Items are re-estimated and put back on the Product
Backlog.
❏ The work done on them depreciates quickly and must be frequently re-estimated.
Sprint cancellations consume resources, since everyone regroups in another Sprint Planning to
start another Sprint. Sprint cancellations are often traumatic to the Scrum Team, and are very
uncommon.
Strategy IQ: How can the Product Owner be well prepared to address the changes,
clarifications and updates that get discovered during the sprint ?

Problem Space & Solution Space
Product Owners focus on problem space more to

understand where the root of the customer problem is and
the opportunity to productize. While focusing on the
solution space results in the product owner thinking about
different technology, differentiators & additional
functionalities to the customer.
Understanding the problem space is essential and
important for product owners, else they would only be
thinking of competitor’s functionalities and biased in
thinking.
Thinking IQ: Zomato, UberEats, what's the problem

space ?

Product Lifecycle
Philip Kotler divides product life cycle into
5 stages
● Research & Development

● Introduction
● Growth
● Maturity
● Decline
Understanding product life cycle and product strategy helps Product Owners get the best out of
the market and products.
Research & Development : This is the

stage where the product is conceptualized
and development activities start; keep
looking forward to a quick entry into the
market to show the key differentiators.
During this stage of the product life cycle,
product strategy should focus on product
feasibility, viability and business benefits.
Introduction : In this stage of the product life cycle,

the product is introduced to the market for the early
adapters to experience the product and it’s key
functionalities and innovative features. Product
strategy during this stage focuses on ensuring the
product to achieve product-market fit, cross the
chasm and focus on product differentiators.

Growth : This is an important stage in the

product life cycle, where the product gets
rapidly accepted and sales/profits
increase. Early majority play a major role in
adapting the products / service resulting
in demand and growth. During this stage,
the product strategy focuses on
performance functionalities, new features,
and beats the competition in the market.
Maturity : During the maturity stage of the

product life cycle, the product functionalities
get matured and there is little or no new
functionality development, most of the users
are aware of this product and don’t notice
major innovation in the product. Product just
attracts the late majority thus the product
strategy focuses on milking the product,
introducing new products and services, thus
increasing the sales and profit.
Decline : This is the last stage of the product life

cycle, the product / service sales starts to decline.
Most of the time decline is because the product
becomes obsolete in the market or a new product
has changed the customer's focus. Thus the
product strategy should be to reduce cost and
milk profit as long as possible and plan for a new
product.

Depending on the technology & product life cycle stages, Product Owner can derive various
strategies, priorities, and focus areas.
❏ Case 1 : Product is in growth/maturity stage and use new technology
This indicates the product is market leader and the main strategy is to create the barrier for
others in the market along with important functionalities from users, stakeholders
❏ Case 2 : Product is in R&D stage, being developed using growth/maturity stage technology
This is a case where the product owner has to handle lots of competition and entry barrier
from existing products in the market
❏ Case 3 : Product is in R&D stage, being developed using new technology
Looking for high risk, and disruptive innovation that might win in the market.
❏ Case 4 : Product is in R&D/Introduction stage, being developed using technology that is in

decline
This is a typical case where as product owner one has to stay away or re-evaluate their
strategy. There is no use of developing a new product on declining product, this isn’t going to
create a desire to buy

Product Vision
Product vision is an excellent way to communicate the purpose of the product and focus on the
future of the product. Good product vision inspires people to pursue product development.
With a product vision statement, the Product Owner communicates the essence of the future
product. Product vision should be inspiring, short, engaging and broad to share the common
goal to achieve.
One of the popular templates for product vision is Elevator Pitch.

Product Vision Canvas

Product Vision Canvas is another excellent way to describe the product vision along with product
strategy that would bring more focus and help in decision making. Reference source : Roman
Pichler book Strategize: Product Strategy and Product Roadmap Practices for the Digital Age
Read more at: https://www.romanpichler.com/tools/product-vision-board/
Product Owners can also use other templates such as Lean canvas or Business Model Canvas.
Purpose of these tools is to create transparency and share the direction of the workflow.
Strategy IQ: Prepare Lean canvas and business model canvas for your product and
identify the benefits of these canvas.

Product Strategy
Doing the right thing is more important than doing the thing right. A Strategic plan that accounts
& focuses on the vision, goals, purpose of the product, product differentiators, business goals
and investment by company, is referred as product strategy. Product Strategy is not only
influenced, it also is inline with product vision and business strategy.
Elements Of Product Strategy.
● The market & customer needs.

● The key features & differentiators,
● The business goals.
The market & customer needs : Every product has a target customer and the primary focus area
to solve a problem space. Knowing the customer, the market needs is essential as we create the
product strategy. Zomato and Uber-eats focus on busy people and solve their hunger needs on
the go. while Ola cabs focus on transportation made easy.
The key features & differentiators: Every product must be competing with products that are
already existing in the market and hence the few key features and differentiators identified would
drive the product strategy, remember these are the features that can boost your product sales in
a competing market.
The business goals: Sponsor of the product, i.e company looks forward to always investing into
the best, competitive, high ROI and product that builds a brand for the company. Business goals
drive the product strategy. Uber-eats as a brand extension for Uber to offer a single platform for
transportation & food services to their existing customer base.
Product Strategy shouldn’t be fixed, and it should be reviewed to constantly accommodate the
changes in market needs, business goals and product differentiators.
With reference to Scrum framework

❏ Product Owner focus on building the “right product”
❏ Development Team focus on building the “product right”
❏ Scrum Master focus on being “effective & efficient”
The intersection of these focus areas results in an awesome product that results in higher
value, better quality and faster than competitors.

Product Roadmap
Product roadmap is a plan which describes how

the product evolves, and is built with incremental
functionalities over the period of time. The
purpose is to connect product’s vision & business
goals.
Roadmaps can be
❏ Goal based
❏ Functionality based.
Goal Based Roadmaps product evolves as the set

of goals set specific objectives or goals to achieve.
The functionalities / features of the product that
needs to be implemented are derived from the
goals. Example: Onboarding the customers,
scaling 1K users to 100K users, Porting to a new
platform.
Usually when the product is new or in the dynamic
market conditions it’s preferred to have goal
based roadmaps.
Functionality Based Roadmaps product evolves

as the set of functionalities/features identified for development. Example: Secured payments,
enabling multisearch, reports & dashboard. Usually when the product is matured or in stable
market conditions it’s preferred to have goal based roadmaps.
Thinking IQ: Should the product owner stick to only one format of product roadmap, how
frequently should the roadmap be revisited ? Which format do you use for your product
roadmap and describe why?
Product Release Strategy

Product Release strategy is the plan for when, what and how the product owner decides to give
the product increment to the users and results in value delivery.
Release Strategy falls into two major categories.
❏ Time Based
❏ Scope / Value Based
Sprint length has nothing to do with release strategy. One could have a 2 weeks sprint and
decide to release on daily cadence or monthly cadence or after the value is built into the
product increment.

Time Based Releases: When the Product

owner considers time as an important factor
for giving the product to the user, time based
releases are used. Two variants of the time
based releases are fixed time single release
and fixed time regular cadence releases. In
fixed time single release the product
increment that is 100% done, is in usable
condition and delivers an incremental value
(release criteria) is handed over to the users.
In such cases there is only one release as on
the fixed time & date. While the fixed time
regular cadence strategy is focused on
incrementally handing over the product
increment that meets the release criteria to
the users at the cadence strategically planned. In this strategy time of release matters, Time
based releases are best suited for quick time to market constraints and as the product gets into
growth & maturity stages. Time based release strategies don’t mean the value is ignored, it’s
incrementally delivered over time.
Scope / Value Based Releases: When the Product Owner considers scope /value as an important
factor over the time the scope/value based releases are used. In this case the product is given to
the user only when all the identified scope/value is 100% done and is in usable condition. Even if
one item is not 100% done, the product owner shall wait till everything is 100% done without any
worries related to time. In this strategy 100% of the scope matters not the time. Scope / value
based releases are best suited when the focus is towards the minimum viable product and
functionality focus. Best suited for products that are in the initial stages of the product life cycle.
Scope / value based release strategies don’t mean the time is ignored, time to market is always an
advantage in the competitive market and Scrum Teams should be aware of the benefits of
releasing early.
Thinking IQ: Which release strategy is used for your

product roadmap and describe why?
For every release strategy the product owner has to consider

the constraints and flexibility parameters. Inorder to inspect
and adapt the uncertainties during the product development,
the product owner should consider at least one parameter as
flexible / variable in their strategy. It’s up to the product
owner’s strategy to have more than one flexible/variable
parameter.
Product Owners should clearly understand that each variable

parameter has different impacts on the product release.

Strategy #1 Strategy #2 Strategy #3 Strategy #4
Constraint #1 Quality Quality Quality Cost
Constraint #2 Cost Cost Time Time
Constraint #3 Time Scope Scope Scope
Strategy Minimize Minimize Minimize Minimize

Variability in Variability in Variability in Variability in
Scope Time Cost Quality
Impact Minimum Viable Time to Market Return on Brand

Product (MVP) Investment
Comments Good Strategy to Good Strategy Good Strategy Good Strategy if

hit the market for MVP releases, where Time to Product brand
early and grab where Time to market is critical, doesn’t get
market share with market isn't and MVP is a impacted in the
limited critical, deciding factor market with
functionality but for releases. known quality
early to user issues
Thinking IQ: Think of other

release strategies that can be
used and describe when you
would prefer to use them &
why?

Product Owner should be clear about what is the minimum viable product (MVP)

Forecasting
Forecasting is an art and should be used for
inspecting and adapting the strategies for
release. Forecast isn’t a commitment nor a
guarantee, hence there are many different ways
to forecast.
Velocity based forecasting is one of the

popular ways and also widely misused.
Velocity is the average work done by the team

in a sprint. This average can be used to predict
the time, scope, cost variations (depending on
the release strategy) for the release.
Some of the strategies are as shown below.
Product Owners shall revise their release strategies based on the current situations and
forecasts. These forecasts and adaptations are part of Sprint Review.

Product Backlog Prioritization Techniques:

Prioritization techniques help product owners identify which product backlog item should get the
focus by the developers to deliver value and increment the product. Each prioritization technique
uses different input conditions to arrive at the priority list. Two techniques might not result in the
same priority list, hence product owners have to adapt to the technique that is best suited for
their nature of work. Multiple techniques can be used for different levels of planning.
Technique Description
This technique considers the emotions of the users for prioritizing

KANO Model the product functionalities. One can divide the requirements into
following categories - Attractive, Linear, Basic, Indifferent & Reverse.
This is one of the widely used techniques that categorize the

MoSCoW
product backlog items as Must, Should, Could & Would have.
This technique prioritizes functionality considered important but is
Opportunity Scoring /
either absent or not upto expectations of the users but considered
Analysis or Gap Analysis
important.
Cost of Delay Method What would be the cost of delaying in going to market
BUC Method Business Benefit + User Benefit - Cost
Business Value Pick up items with more business value to Customers in top priority
Stack Ranking Rank depends on Time to Market, Low hanging fruits, RoI
4 categories - Support, Features, Technical, Architectural

Quadrant Method
Development
Dot Voting Voting the most important feature
MCDA - Multiple Criteria Ratings against multiple conflicting criterias. The average is taken
Decision Analysis for consideration
RICE This technique considers the Reach, Impact, Confidence & Effort
Story Mapping USer Experience Navigation
Cost Vs Value Cost of development Vs Value delivered ( ROI)
Simple - H - M - L High, Medium, Low priority
80% customer use 20% of the features, so focus on most important

80-20 Rule (Pereto)
features
Roadmap based Focused on the evolution of the product based on roadmap

Story Mapping for Prioritization.

Kano Model:
The Kano model was developed by Prof. Noriaki Kano during the 1980s. The Kano model basically
classifies customer preferences into five categories for customer satisfaction.
For each functionality, two questions would be asked to the user/customer. How would you feel if
this functionality is “PRESENT” ? How would you feel if this functionality is “ABSENT” ? With the
following options to choose from, “I Like It”, “I Expect It”, “I’m Neutral”, “I Can Live”, “I Hate It”.
Kano Model for Product Backlog Prioritization is best when the product functionalities are direct
end user focused and interfaced. Having direct emotional feedback related to each functionality
helps product owners manage value, competitiveness and Go-To Market strategies.

Classification Of Requirements
❏ Basic / Must Have
Basic or Must Have are those functionalities that are the default expectation from the
customer. If these functionalities are absent then customers are highly dissatisfied. It’s not
a good strategy to have marketing and sales based on these Must Have functionalities as
every competitor / product has to present these must have functionalities.
❏ Attractive / Excitement
Attractive or Exciters are those functionalities that delight and are pleasant surprises.
Since these functionalities were not expected by the customer. These functionalities highly
satisfy customers. Attractive functions make a good sales strategy, since it brings the wow
& surprise factor, it increases the entry barrier for competitors / new products.
❏ Linear / Performance
Customers always look for more, in fact certain functionalities that are always in demand
and customers ask for more are Linear / Performance functionalities. These functionalities
give the competitive advantage over the other products
Over a period of time, “exciters” & “performance” functionalities before “must have”
❏ Reverse / Inverse
Presence of certain functionalities creates discomfort to the customers and they never
want to see such functionalities. They fall under the Reverse or Inverse list. Avoid these
functionalities. Remember, someone’s “reverse” could be someone else’s “must have”
Handling reverse functionalities is very tricky, they might result in very good revenue
generation when they are strategically planned.
❏ Indifferent / No Change
When the customer’s emotions and satisfaction are neutral irrespective of the functionality
present or absent. In fact these functions should be planned well, Over a period of time,
removing the functionality shall be challenging. Indifferent functionalities are very
challenging, sometimes product owners tend to prioritize these just because their
competitors have it.
Product Owner
❏ Shall strategically prioritize “attractive” & “performance” functionality.

❏ Just sufficient “must have” and “indifferent” functionalities to be relevant in the market.
These functionalities if absent might damage the buying desire.
❏ “Reverse” are double edge swords, they should be considered very carefully. Typically these
reverse category functionalities are best suited for functionality that are removed when
customers pay for them. “Pay to get rid of them” example: advertisements in the mobile
apps.

Sources of Product Backlog Items

There are many sources for product
backlog items and the product owner
has to connect with all the sources
and manage their expectations.
Ignoring any specific source shall
result in unforeseen risk and changes
in strategies
Create a schedule to meet the

sources regularly.
PO Schedule
Source ( for PBI ) Requirement Type Technique to use Frequency to meet

User Story
Requirements described as a story by the user, with a template,
“As a user, I want/need …. So that …”

Techniques to create smaller User Story

Techniques To Generate New Product Ideas

Design studio
Brainstorming
Collaborative customer games
Product discovery
The purpose of product discovery is to address these critical risks:
Will the customer buy this, or choose to use it? (Value risk)
Can the user figure out how to use it? (Usability risk)
Can we build it? (Feasibility risk)
Does this solution work for our business? (Business viability risk)
And it’s not enough that it’s just the product manager’s opinion on these questions.
We need to collect evidence. Aspects of product discovery are
User research
Customer experience design
Interaction design
Usability engineering
Visual design
Product Backlog Items formats

The description of desired outcome and value can be expressed as
User stories and acceptance criteria
User Problem Statement & Mutually Agreed Solution statements
Acceptance tests
Validation Scenarios that leads to acceptance of the product increment

and design solutions
Use cases
Describe how users will perform their activities and outlines, from a user's
point of view, a system's behavior as it responds to a request
Hypotheses

It’s a statement of expectation, prediction, an assumption or an idea that

can be tested to see if it might be true
BDD
Focuses on the behavior of the product and user acceptance criteria.

non-functional requirements
System qualities
Non-functional requirements, performance expectations
Spikes
Activities for quick need for analysis, creating proof of concept, and
validating assumptions.
Approaches to Product Backlog refinement

User story brainstorming
Brainstorming technique allows the developers and Product Owners to

discuss and agree upon a solution to the identified problem or need of the
user.
Focus on the understanding the need and solution, identify risks, and high
level designs
Customer interviews
Customer interviews are good sessions to help developers & Product

Owners understand their customers and explore the needs, opportunities in
the product.
Ask open ended questions to explore the thoughts of users, this will help
you focus on what you don’t know about user needs.
Use questions that help you identify and validate the problem. What is their
need and how do they handle the problem now ?
During the interview, explore with questions that help you collect
quantitative data for your analysis
Identify questions to understand customer’s habits, environment, problem

areas
Open planning meetings

Collaborative games
Splitting Requirement to small sizes
Split the requirements using estimation techniques, INVEST Model, or any

other suitable technique the Scrum Team is comfortable.
Techniques To Connect Customers & Teams

Job shadowing
Customer interviews
Customer observation
Collaborative customer games
Usability testing
Simulating customer experience

Product Assumptions Validation Techniques

Product creation
Customer interviews
Ethnographic research
Direct user observation
A/B tests
Collaborative games
MVPs
Paper prototypes
Functional prototypes
Product owner can use following techniques towards validation of product assumptions
Validation is completed prior to starting Sprints;

The Product Owner validates assumptions a Sprint or two ahead of the
Development Team
The Scrum Team uses the Sprint Goal to deliver results to test assumptions.
Involves customers during sprint review

Information Radiators
To create transparency, Scrum Team uses various tools/techniques to display important
Information using information radiators. Commonly used information radiators are task
board, charts, Naveen’s DOD board, kanban board and so on.
Information Radiators should be “live”, using which Scrum Team can self organize, self
manage their work
Task board
Todo In Progress Blocked Done
Charts
When the X axis is marked sprint duration it’s called “sprint burndown chart” for the parameter
marked on Y axis. Likewise if the X axis is marked release duration it’s called “release burndown
chart” for the parameter marked on Y axis.
❏ Burndown chart indicates how much is pending till now.
❏ Burnup chart indicates how much is accumulated till now.

Naveen DOD Board.

Technical Debt
As the technical debt increases the ability to focus on the new features reduces and
constant effort to reduce the technical debt is essential.
Product Owner should be cautious about technical debt as,

Technical debt impacts the capacity of the team over time;
There is an increase of cost for addressing technical debt too late;
A design strategy is adopted that isn’t sustainable in the long term
A percentage of developers capacity / focus should be towards reducing the technical

debt every sprint

Identify Value & Measure Value
Customer / User
Pain point / Problem Space / Opportunities
What is Value ? ( Define )
Key Functionality / Solution Offered
Measure this Value
Boundary Conditions ( high level, low level and Optimum range)

and action plan
Examples of value
Modeled or assumed value
Actual value to customer
Return on investment
Maximizing learning
Risk/de-risk
Acquiring new customers
Examples of techniques to measure value

Usage metrics
Net promoter score
Customer and user interviews
Social media sentiment
Direct observation
Return on investment
profitability of the product
In-bound customer feedback

Users & Customers Describing Techniques:

❏ Empathy maps
❏ Personas
Sample Empathy Maps
Buyer : Homemaker
Goal : Purchase high quality and fresh, on time for preparing food, Safety during purchase
Think Feel Do Say

Unable to shop Self shopping is good, limited shopping from Online experience
during the lockdown. to check the quality, nearby shops and has been bad with
Need to Grocery items and right quantity of have no choice but to other stores
on time to prepare items. depending on accept only the
food. others is difficult available stock
Buyer : Admin
Goal : Manage new users, stores, and operations with minimum efforts. Maintain govt rules and
regulations, safety to run business
Think Feel Do Say

Managing everything Spending too much Work more and try to very hard times to run
online is hard, simple time on operations avoid mistakes a business.
tool is required to and unable to focus Lots of safety steps to
save time and efforts, on quality take and we forgot or
lots of mistakes due overlook some items
to staff not used to
online services
Buyer : Delivery Boy

Goal : Be safe & quick while delivering the orders
Think Feel Do Say

Unable to shop Self shopping is good, limited shopping from Online experience
during the lockdown. to check the quality, nearby shops and has been bad with
Need to Grocery items and right quantity of have no choice but to other stores
on time to prepare items. depending on accept only the
food. others is difficult available stock

Outcome and Output

❏ Output is a measure of what was built
❏ Outcome is how that output impacts users and customers and the resulting
business value that this provides
Product Owner can maximize outcome and minimize output with following ways
Apply YAGNI - You Ain’t Gonna Need It to the product prioritization;

Focus on the most important features,
Learn to say NO.

To be continued

Handbook For Product Owners Oct 2022

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Handbook For Product Owners Oct 2022

Uploaded by

Copyright:

Available Formats

12 Principles Consulting

Handbook for Product Owners © Naveen Nanjundappa 2021 1

Manifesto for Agile Software Development

Individuals and interactions over processes and tools

That is, while there is value in the items on the right,

­Principles behind the Agile Manifesto

Agile Manifesto Authors :

Handbook for Product Owners © Naveen Nanjundappa 2021 2

Handbook for Product Owners © Naveen Nanjundappa 2021 3

Scrum Events on Timeline

*Product backlog refinement is a background activity and not Event in Scrum.

Handbook for Product Owners © Naveen Nanjundappa 2021 4

The Product Owner

On a high level Product Backlog management includes:

Qualities of Product Owner

❏ Visionary, ❏ Quick And Decision Maker,

Handbook for Product Owners © Naveen Nanjundappa 2021 5

The Product Owner In Organization

❏ A Product Owner owns the delivery of someone else’s idea or initiative;

❏ A Product Owner delivers a shared service to other teams in the organization;

Handbook for Product Owners © Naveen Nanjundappa 2021 6

Product Owner Anti-Patterns

Product Owner is in-effective when they have below anti-patterns.

Handbook for Product Owners © Naveen Nanjundappa 2021 7

Decision making approach for Product Owner

Product Owner is Product Owner - Decision Product Owner - Decision

PO Decides & Tell

someone else has better

you know that someone else

Handbook for Product Owners © Naveen Nanjundappa 2021 8

Product Backlog Refinement ( Not Scrum Event )

Handbook for Product Owners © Naveen Nanjundappa 2021 9

Developers / Development Team

Handbook for Product Owners © Naveen Nanjundappa 2021 10

Developers / Development Team

Handbook for Product Owners © Naveen Nanjundappa 2021 11

Topic 1 : Why is this sprint valuable

Topic 2 : What can be done this sprint

Topic 3 : How will the chosen work get down

Handbook for Product Owners © Naveen Nanjundappa 2021 12

Developers / Development Team

❏ Focus on the Sprint Goal & Sprint Backlog

Handbook for Product Owners © Naveen Nanjundappa 2021 13

Developers / Development Team

Handbook for Product Owners © Naveen Nanjundappa 2021 14

The Scrum Team ( Developers + Product Owner + Scrum Master)

Handbook for Product Owners © Naveen Nanjundappa 2021 15

Product Owner Working With Multiple Teams

Decision Making Strategies Good to use When to Avoid

Someone else has better

PO knows that someone else

Handbook for Product Owners © Naveen Nanjundappa 2021 16

Advantages of Single Product Owner Disadvantages of Single Product Owner

Single point of failure - Requires the Product

Not effective for products that requires multiple

Advantages of Multiple Product Owner Disadvantages of Multiple Product Owner

Different sections of Product management can

Easy to split the responsibilities between

Handbook for Product Owners © Naveen Nanjundappa 2021 17

A Sprint would be cancelled if the Sprint

When a Sprint is cancelled,

Handbook for Product Owners © Naveen Nanjundappa 2021 18

Principles behind the Agile Manifesto