Project Management

Product Ownership

by ,
This blog on product ownership will specifically look at how projects create products—and products deliver strategy. Topics will include delivery of value to customers, strategy execution and more!

About this Blog


View Posts By:

Peter Monkhouse
Joanna Tivig

Recent Posts

Persona to Project Webinar Q&A

Project Management Meet Product Management in the PMBOK® Guide Seventh Edition

Agility in a Nutshell Webinar Q&A

A Successful Business Strategy: Value Delivery Webinar Q&A

Welcome to the Product Ownership blog!

Viewing Posts by Peter Monkhouse

Persona to Project Webinar Q&A

On September 30th, Joanna and I held a Webinar on Persona to Product. If you want to listen to the webinar, click here.

Thank you to all those who asked questions on the live webinar. We were able to answer many of the questions, but unfortunately, we run out of time to answer all the questions. In this post, we are providing written responses to those questions that we did not answer during the webinar. If you have any further questions, please contact us. Thank you for your support and great questions and comments.

Q: Aren't there some projects for social wellbeing? not necessarily for money.

A: Yes, I believe this question was from slide 6 where we talked about Products and Customers and Value Delivery. In general, we try to be careful not to say the value is money, but the value is what the customer believes it is. You are correct in pointing out that value can be delivered to customers in many ways and does not have to involve money

Q: Can you share the names of these resources to help develop personas and story maps in the chat?

A: The resources we used in this presentation came from and

Q: Isn't satisfaction also related to the level of performance the persona desires, not just more performance?

A: Yes, there are many elements involved in satisfaction, including the performance of the product, combined with the overall experience.

Q: I've been using this for years and didn't know it had a name. I thought I had invented it because I hadn't seen it anywhere else. Must, Should, Could for deliverables. Now I can add Would.

A: Great!

Q: How do you choose which prioritization model to use shown in slide 16? For example, stacked ranking was for small number of items in backlog. How about the others?

A: This was discussed a bit in the presentation. There are several factors involved including the size of the backlog and the size of the team doing the prioritization, as well as the desired outcome of the product being developed. For example, Stack Ranking is best for a small number of items in the backlog and a small team. The Kano Model is for the features of the product that have the most impact on customers vs the amount of investment the organization is willing to put in.

Q: How do we define the iteration cycle for determining whether we categorize something as a story? Are there any industry standards for this?

A: There are two concepts here. The duration of an iteration cycle depends on many factors, including the project, the team, the product, the organization. The only standard we are aware of is the scrum agile approach the defines a sprint (iteration) to be 1 to 4 weeks. A user story needs to be sized so it can be completed in one iteration. If it is too big to fit into one iteration, then it should be split into small user stories.

Q: Why is it so important to deliver a story within an iteration?

A: The idea with an iteration is that you have a functional, working product at the end of the iteration that can be used by the customer. If a user story cannot be completed in one iteration, then you do not have a working product at the end of the iteration. The second concept to mention with iteration product development is to simplify. Breaking the user stories into small stories makes them simpler and thus easier to deliver and to accept, removing dependencies as much as possible.

Q: Is user story can be written before start of Project?

A: In general, user stories are added to the backlog as early as possible. User stories continue to be refined before each iteration planning session, so the team can accurately estimate them. In most cases, user stories are finalized during iteration planning and tasks are added to each user story.

Q: Do ALL epics and user stories have to be written before team starts?

A: Yes, but not as an exhaustive list. Epics and user stories continue to be refined, added or deleted from the backlog continuously. The backlog represents a placeholder for priority and non-priority items and does not represent a commitment that these items will be delivered.

Q: Will the acceptance criteria be covered in this webinar?

A: Sorry, we did not have time on this webinar. This is a good idea for a future webinar

Q: "Priority" should be a separate concept than "rank" which is used to order the backlog.

A: Prioritization is the process of defining high and lower-value items. The ranking is a technique that is used to determine the sequence of when an item will be pulled into the queue and considered for delivery, depending on the different additional factors.

Q: Are personas a moment in time or are they updated?

AL Personas should be updated as you learn more about them during the product life cycle.

Q: What are your thoughts on Personas vs "Jobs to be Done"?

A: We think Personas and Jobs to be Done complement each other. In the value proposition canvas, one of the key items is to identify the jobs to be done by the persona. The product cannot deliver value to the customer unless it addresses the job to be done. As an organization you cannot be success with your product unless you are able to identify the job your product is doing and for who.

Q: When cost of delay is chosen as a prioritization tool. Can you state some examples?

A: Yes, the cost of delay should be used when there is a financial advantage. For example, your products are T-shirts for your favorite sports team. Your sports team is in the championship. Think about the impact in revenue between having T-shirts ready to sell right after they win the championship and having the T-shirts ready a month later. Right after the championship, the T-shirts will sell quickly and at a premium, a month later, they will not sell. This is the cost of delay.

Q: Would you recommend creating a persona for each stakeholder?

A: In general no. Personas should represent typical groups/ archetypes of people using your product. In general, a product should have up to 5 personas, but 3 personas make the optimal number.

Q: Is Epic analogous to Work Breakdown Structure?

A: In some ways, there is a similarity in the way epics are created by decomposing features into user stories. Decomposition is a technique used for epics and WBS. However, an epic is not a deliverable, it is a large user story.

Q: How do we manage delays after they happen?

A: There are several techniques that can be used to manage delays, such as schedule compression and re-prioritization of scope.

Q: What about a product with multiple personas, say 5 major types clients? Thanks!

A: This is very typical to have a product with multiple personas. You should do a Product Value Proposition Canvas for each persona.

Q: Do you have any recommendations on how to adjust the approach if you are in a resourced constrained non-profit organization that does not have "product owners" and limited project management resources

A: Although the organization is small, we recommend that someone in the organization takes on the product owner role. It is so important that organizations ask if their products are delivering value to their customers. Happy to discuss further if you wish.

Q: In that example on the slide ... in an order of priorities ... number 7 is more important than priority 1 or 2?

A: On slide 23, Start your project, we have two columns with numbers. The first Id is just an identifier of the user story, it is not a priority. The priority column is on the right which is based on value. So user story number 8 is prioritized second.

Q: So, I am wondering when you should decide to use this approach vs. the normal business/functional requirements approach

A: In general, the approach should be determined at the start of a project. However, if the approach is not working, you should not be afraid to change the approach during the project. After all, your objective is to deliver a product that adds value to your customer.

Q: When an organization is unwilling to use prioritizations models, what suggestions for a PM to encourage use and overcome objections?

A: Explain or educate the organization on the prioritization models as early as possible. Adding the benefits of having a model that other similar organizations use will give more confidence to your organization that these models work.

Q: How can we as PM's best help the marketing team start prioritizing product requirements?  I struggle over and over with them when it comes to giving up some features over others.  They always want everything!

A: That’s where prioritization helps to identify only the necessary items. Using the iterative approach will give the business teams the confidence that things are being delivered, and that some items are no longer needed or pertinent.

Q: Value created with regard to the data in your hand. In some countries I have lived we have not got any data. Then how can we create and achieve the project done?

A: Getting feedback can be a challenge. We did an earlier webinar on December 8, 2020 Customer Feedback – Nuggets of Gold talking about the value of feedback and how to get customer feedback. The key is to start collecting feedback. You do not have feedback now, if you do not start collecting feedback, you will not have it tomorrow either.

Q: If your project is not justified by a Product, for example Regulatory conditions, (e.g. SOX compliance, Security Compliance) then User Story, Epic will have less value?

A: Interesting question, all projects create a product or service. Compliance to regulation is a product. The value of compliance may not be measured in profit but in the organization’s reputation.

Q: With the exception of non-discretionary features which must be developed, what do you think about using a scorecard to prioritize product ideas?

A: I think scorecards are good. We mentioned four techniques to priority, there are many more. You should use the approach that works for your organization and team.

Q: How do you manage new requirements from changes from Persona, market, etc. How do you reprioritize

A: One of the advantages of an iterative approach is when there are changes. The change can be added to the backlog and then prioritized in the same way as all the other items in the backlog.

Q: Do you find it useful to link a requirement in a release back to the product backlog and the user story where it originated as part of your requirements management process.

A: Yes, we find this is the best way to show your customers that their requirements have been met.

Q: What are some tactics you recommend to determine customer pain or gains to identify product or service solutions?

A: There are several techniques you can use to identify customer pains and gains. It all depends on the customers, the project team, and the budget. Some of the techniques are brainstorming, interviews, focus groups, observations, feedback surveys, etc.

Q: In your slides about story mapping you have Features >> Epics >> User Stories >> Tasks.  Do you see times where well defined epics / business cases lead to features? It feels like starting with features is the tail wagging the dog.

A: Unfortunately, at times the English language is not precise. In our case, we are using features, to describe an item that delivers significant value to a persona (customer). That feature should be decomposed into small pieces such as epics and user stories. We realize that sometimes a user story could define what some people call a feature (the tail in your question), but for us, the feature is the dog.

Q: Can you provide links to your other webinars for journey maps.

A: There a several webinars on Journey Maps on that you can check out.

Q: What type of techniques would you recommend to draft the persona information and who will participate, the entire project team, only some, stakeholders?

A: To draft personas you can use many techniques including surveys, focus groups, research, feedback, expert judgment. In general, to work on personas you want a diverse team that deals with customers so they can share their perspective: product teams, sales teams, marketing teams, customer relations teams, etc.

Q: How do we manage delays during iterations?

A: In general, if there are delays during an iteration, you need to decide with the Product Owner whether the remaining work in a user story is still applicable. If it is, a new user story will be documented and included in subsequent sprints following the prioritization exercise.

Q: WBS is focusing on the deliverables from the solution perspective – User Story Map is focusing on the deliverables from the User/Problems (solvables?) perspective?

A: WBS deliverables focus on outputs. User stories focus on outcomes, including the value for which they are created.

Q: You might rank something higher than a higher priority item

A: Yes, in that sense, you may select a lower priority item to do in an iteration, because the higher priority items are too big to fit in the remaining capacity for the iteration. For example, I have a capacity for 100 story points. I pick the 5 top items that require 95 story points. The next priority item requires 15 story points, which would put me over my capacity of 100 story points. I would go down the list until I find an item that is 5 story points and select it to reach the capacity. Now, it is not that easy, I may drop a higher priority item in the top 5 to get items 6 and 7 in.

Q: How do you chose which prioritization model to use shown in slide 16? For example, stacked ranking was for small number of items in backlog. How about the others?

A: The selection of the approach depends on the organization, the project team, product and the available data. For example, if you have features that are time-sensitive and you can quantify the time impact, then you can use the cost of delay. If you have features that are more focused on customer satisfaction than revenue, the Kano model may be better. If you are trying to do a basic sorting of a large number of items, then use MoSCoW.

Posted by Peter Monkhouse on: January 10, 2022 05:34 PM | Permalink | Comments (4)

Project Management Meet Product Management in the PMBOK® Guide Seventh Edition

On July 2, 2021, PMI released the much anticipated seventh edition of the PMBOK® Guide. I believe the seventh edition of the PMBOK® Guide is the most significant change in the Guide since 1996. In 1996, PMI published the first edition of the PMBOK® Guide that introduced process groups and knowledge areas. In the sixth edition, there was an attempt to add in more about agile, but I would say this was a force fit as the structure in the PMBOK® Guide was based on systems thinking associated with the predictive or waterfall approach to doing projects. With the growing use of agile, iterative, incremental, and continuous improvement approaches to project delivery, the PMBOK® Guide had to change.

The result, in the seventh edition of the PMBOK® Guide is the introduction of 12 principles and eight performance domains. This moves the PMBOK® Guide to a higher knowledge level and allows various approaches and methodologies to get more visibility through the PMBOK® Guide structure. The other major change is a border discussion of how projects fit into the business environment, specifically that projects are a delivery mechanism for organizations to create or enhance products and services.

This larger discussion on how projects fit into an organization is something I have been discussing for a number of years, projects deliver products and products delivery strategy. One of the keys is the inclusion of the Delivery performance domain which starts with the delivery of value to the business, customer, or other stakeholders. This recognizes a change that started over ten years ago, where PMI started talking about project managers needing to understand why projects are needed, asking ourselves why we are doing projects and what is the actual benefit. In fact, the focus on value started even before, with the introduction of the Program Management Standard and the inclusion of benefits realization in 2006. 

In addition to the discussion in the Delivery Performance Domain, the PMBOK® Guide includes an appendix on Product. Appendix X.4 provides an in-depth discussion of the relationship between project management, program management, and product management. The Appendix discusses the changes in today's business environment, in the Global Market Shifts section, and the need for organizations to move from serving products to serving the needs of the customers.. This leads to the discussion of creating a product environment that allows for continuous delivery, or as I have discussed before, practicing an iterative product development approach. The Appendix ends with a comparison of Projects, Programs, and Products on the following topics: duration, scope, change, success, and funding, topics that are fundamental for product delivery.

The final item I am grateful for is the digital version of the seventh edition of the PMBOK® Guide from the PMI website is 370 pages, down from 976 pages for the digital version of the sixth edition!

I believe the seventh edition of the PMBOK® Guide is a positive step forward in helping project managers understand how projects support organizations and are part of a larger ecosystem within organizations to deliver value to customers and benefits to their organization. Is it though an ‘enough’ step? I am looking forward to continuing to participate in the discussion of how project management and product management can work together.


Posted by Peter Monkhouse on: July 17, 2021 09:15 PM | Permalink | Comments (2)

Agility in a Nutshell Webinar Q&A

On June 17th, Joanna and I held a Webinar on titled Agility in a Nut Shell. If you want to listen to the webinar click here.

Thank you to all those who asked questions on the live webinar. We were able to answer many of the questions, but unfortunately, we run out of time to answer all the questions. In this post, we are providing written responses to those questions that we did not answer during the webinar. If you have any further questions, please contact us. Thank you for your support and great questions and comments.

Q: In my office, we work with scrum methodology (agile) to organize our activities, responsibilities, scope and teams for example, but sometimes we end up using waterfall documents and techniques to register meetings, address risk and so on. How valid is this mix of methodologies? Is it better to use one or another?

A: In general, it is better to use one or the other. However, you need to take into account the culture of the organization, the team’s preference and what is best for the customer. PMI and others have recognized there is a hybrid approach to project management, looks like you are doing an example of this. But it should be one stage to getting to a ‘one methodology’ approach

Q: That was my point from my previous question, change for change’s sake is not agility, correct?

A: Correct. Organizations need to select the approach to deliver products that will give them the best chance of success. You should never change just to change.

Q: How do you reduce requirements chaos during agile project management?

A: In our experience, requirements chaos is greater on traditional waterfall projects! In the case of agile, you need to ensure that all new requirements are added to the product backlog, not the sprint backlog, and you are rigorous in your sprint planning at the start of each sprint.

Q: What if the business is agile but aggressive with constant change and the implementation team is having a hard time keeping up?

A: Good question. This is hard to answer without knowing more information. One suggestion is to use shorter sprints for the implementation team to have small pieces. Also, remember there needs to be a partnership and the concept of one team working together towards a goal.

Q: Any suggestions on how to virtually storyboard

A: Using a video conference and sharing a tool like Mural, Miro, Jamboard or Microsoft Teams, you can set up the storyboard (templates are available for some of these tools). Start with personas, identify high-level features or epics and then user stories. Remember to define the MVP as part of the next steps. A great book to read – User story mapping, by Jeff Patton

Q: Can you suggest any reading references that help an organization move from command and control leadership to servant leadership.

A: Good questions, this is all about changing the culture. You may want to look at the information on and read Turn the Ship Around! By L. David Marquet and Team of Teams by General Stanley McChrystal.

Q: Would you agree that agile is simply software developed for businesses and agility reflects the ability of a business as a whole to respond quickly to changes, particularly external.

A: No, as mentioned in the webinar, we are talking about agility, not the agile methodology. All organizations need to be able to adapt to changes. Having agility, where you can adapt to change is important for all organizations. In terms of the agile methodology, I believe agile should be used in any section when appropriate. In particular, when the scope is not clear and cannot be defined.

Q: Is it possible to have too much leadership agility, where priorities may change to quickly? If so, how can you identify that versus healthy agility? Do you have any suggestions for how to avoid it?

A: No. If an organization's priority is changing quickly, then I would argue that the organization does not have a good strategy. If you have a good strategy, then you know where you are going. You may hit roadblocks that cause you to change your approach, but the strategy will ensure everyone knows where the organization is going.

Q: What about teams who are continuing to develop new features to the product using the waterfall model but with agile practices? in Latam a lot of companies think that are applying agile ceremonies but executing projects with waterfall methodologies.

A: Yes, we have seen this. Typically, this is a case where organizations are not willing to change. Agility needs to happen at all levels in the organization, including senior management. Senior management needs to embrace the agile approach including accepting different metrics.

Q: Insurance companies didn't do their due diligence in testing covid vaccines. Use a different example next time.

A: Insurance companies should not be testing vaccines. I take your point that not all organizations, including drug manufacturers, do not also do a good job in testing. However, in my experience, due to various regulations, the drug manufacturers are better than most.

Q: Speaking of Covid, our health organization has been very agile in delivering the vaccine. My first interaction was slow, single-person interaction. the second was a more agile process.

A: I completely agree. This is a good example of continuous learning.

Questions answered during the webinar

Q: Who should lead the transformation to Agility in the organization?

Q: Can agile create efficiencies, not just steady-state?

Q: Can a steady-state be effective, not just agile?

Q: Not to be too complicated about it, but isn't steady-state somewhat agile if everything around us is

Q: Where does production land in the triangle of agility?

Q: Can we measure Agility, is it something that we could put on a scale some can improve?

Q: How do you start agile in a company which is not projectized and does not know agile

Q: What to do for the team members or employees of the organizations when the team leader is not embracing agility?

Q: Do the organizations should work with hybrid methodologies meaning, for the c- level as predictive methodologies and the processes as agile

Q: How do we become more efficient and increase velocity for new agile teams?

Q: Before implementing the change, how to identify the concerned stakeholders to whom the change should be acknowledged?

Q: Are there statistics showing that Agility is being successful?

Q: We've found the most success in helping bring about agile change by implementing agile principles within the realm of work we control and showing others how it has been successful for us. This can be anyone implementing it within your own workflow and showing your manager how it helped just a thought :)

Q: There a number of industries where the core business is not projectized, nor processes subject to agile. Where do we stop in such a dynamic, at what level and what employee groups?

Q: Does agility create constant change, or help address constant change? I do not think there is a need to create change, I think there is a need to handle it efficiently and effectively.


If you have any other questions or comments, please reply to this blog post.


Posted by Peter Monkhouse on: June 28, 2021 09:27 PM | Permalink | Comments (2)

A Successful Business Strategy: Value Delivery Webinar Q&A

On March 31st, Joanna and I held a Webinar on titled A Successful Business Strategy: Value Delivery. If you want to listen to the webinar click here.

Thank you to all those who asked questions on the live webinar. We were able to answer many, but unfortunately, we run out of time to answer all the questions. In this post, we are providing written responses to those questions. If you have any further questions, please contact us. Thank you for your support and great questions and comments.


Q: There does not appear to be much helpful to project management itself in this presentation, but more to product management.

A: As a project manager, we would encourage you to think about what is the product or service your project is creating or enhancing. Ask the question if this product adds value to your customer? Will the product help your organization achieve its strategy? If not why is the project being done?


Q: Have you come across examples where Value has been placed and measured against "Innovation" as opposed to Continuous Improvement, e.g. under Kaizen models.

A: We believe the two are related. To get continuous improvement, especially for functionality you need to innovate.


Q: Virginia Mason healthcare organization in Seattle is well known in the area for adopting a production system similar to Toyota's. That is who they learned it from but they have adopted it into healthcare.

A: Good to hear! Congratulations to Virginia Mason healthcare.


Q: How can you tie ROI into this?  excellent presentation!!!

A: Good question, Adding value to products in general increases sales and eliminating waste cuts costs. Both of these are elements of the ROI. It is important to ensure you understand how your project supports your organization’s strategy.


Q: What webinar and what date will both of you be hosting next?

A: Our next webinar is June 17th at 2 PM ET and we will be talking about Agility and why agility is important in all aspects of life and business.


Q: How to balance between customer satisfaction and the cost of quality in poor countries?

A: We would not think of this as a balance. Instead, you need to focus on the value you are delivering to your customers where they are. Your question points out the importance to segment your customers as the value can be different for each segment. Remember to use personas to help you.


Q: How to create customer trust & advocacy in a competitive market with a low margin of profitability?

A: Good question and one that deserves a longer response. We will add it to our list of future webinar topics. Two brief comments. Look at ways to eliminate waste to create more cash to focus on value-added activities for your customers. Second, there are many things you can do to build trust that does not cost money. For example, when you talk to your customers, use activity listening and show empathy. It does not cost anything, but it goes a long way to build trust and loyalty.


Q: Would it be true that Value = Cost + Waste?

A: No, value is everything minus waste, and therefore additional cost. Because of the end of the day, you want to create more value and eliminate as much waste as possible.


Q: How can we always have a working product when deciding the business value for each customer story?

A: This comes some to writing great user stories and prioritizing them so you are delivering value with each release. Use user stories that have an outcome that produces value.


Q: Is there any recommended mechanism to align Value Mapping with Stakeholder Benefit mapping?

A: No, but they go hand in hand. When you go through the process mapping, you can align the stakeholder benefit to identify the steps that add no value to your processes.


Q: Where does Lean Six Sigma fit in?

A: Lean six sigma is another approach to eliminate waste.


Q: What is your Product Owner webinar called?

A: We have done three webinars on on product ownership:

  • Products Deliver Strategy - Projects Deliver Products, March 12, 2020

  • Product Management, The Fourth P of Project Management, July 9, 2020

  • Customer Feedback - Nuggets of Gold, December 8, 2020


Q: I am sorry but I had hoped for learning something new about project management, not product management value. No much use to me as a project manager.

A: Respectfully we disagree. As project managers, we can add value to our employer and eliminate waste in our organization by ensuring we are working on projects that deliver value to customers and benefits to our organization.


Q: Isn't the big picture included in the business case?

A: In some cases, but not all business cases are the same and used by all organizations.


If you have any other questions or comments, please reply to this blog post.


Posted by Peter Monkhouse on: April 08, 2021 10:04 AM | Permalink | Comments (1)

Welcome to the Product Ownership blog!

On this blog, I want to share my thoughts and those of my friends and colleagues about product ownership. To start this blog, let’s define what I mean by product ownership.

I view product ownership for the entire product life-cycle, from ideating, creating, developing, improving, and ultimately retiring products. Let us look at each of these concepts: product and ownership. First product. In this blog, a product is a tangible or intangible product, a service, or a result. Anything that is created by a person, a team, or an organization that is provided (sold, given, or donated) to a customer (client, or user) to meet a customer need or a demand. Ownership is a mindset exercised through feelings and attitudes toward a particular object. Product ownership means being committed to a product through the full product life cycle, from the initial idea to the end of the product. I will explore more about ownership in a later blog post.

Product ownership should be a function in any organization. This function can be done by a product owner, a product manager, a product leader, a business leader or owner, a business analyst, a project manager, an entrepreneur, or any other title where the person is concerned with product value delivery. Let’s take for example the product owner as the person doing the product ownership role. Although this role emerged in the Scrum environment, the product owner has evolved over the years beyond just being a Scrum role into a business function, with a broader view of the organization and owner of the relationship with the customer. Yes, a product owner listens to customers and shares the voice of the customer with other stakeholders in the product life cycle. But product ownership is so much more than just a role.

Let us think about Procter & Gamble (P&G), a company founded in 1837 as a consumer goods company based in the US and operating all over the world. P&G has many brands including Tide, Ivory, Downy, Charmin, Gillette, Braun, Head & Shoulders, Old Spice, Dawn, Swiffer, Cascade, Crest, Scope, Vicks, Olay, and many others. Many P&G brands are better known than P&G itself. How does P&G do this? What are the aspects of product ownership that P&G uses to create successful products?

In this Product Ownership blog series we will continue to explore how product ownership supports organizations and how it can advance your career.

Let us get started on our discussion on product ownership. Please leave your comments and questions in the comment area below.


Posted by Peter Monkhouse on: February 15, 2021 03:09 PM | Permalink | Comments (3)

A verbal contract isn't worth the paper it's written on.

- Sam Goldwyn



Vendor Events

See all Vendor Events