The roles of Product Owner and Product Manager often intersect, leading to confusion and potential conflicts. These roles play a crucial part in product delivery, yet their distinctions are not always clear-cut. Understanding the nuances between a Product Owner vs Product Manager is essential for organisations to reduce friction, optimise their product development processes, and ultimately deliver high quality outcomes for the customer, faster and more reliably.

This blog aims to shed light on the key differences and similarities between these roles, exploring the challenges they face and the misunderstandings that can arise. We'll delve into the scope of their responsibilities, decision-making processes, and approaches to stakeholder management. By examining these aspects, professionals and executives will gain valuable insights to help them navigate the complexities of product development and foster more effective collaboration within their teams.


Defining the roles: Product Owner vs Product Manager

Product Owner responsibilities

Ideally, the Product Owner role is a sponsor or entrepreneur for the product, who are in charge of the business case and budget, and have the authority to make decisions. They should be invested in the product's success and have overall strategic and management responsibility.

However, in some organisations, the Product Owner's role has been reduced to that of a scribe or proxy. There's a tendency for Product Owners to take on the role of "story writer" and "project manager," adopting a project mindset of requirement order-taking and managing scope, budget, and timeline.

Product Manager responsibilities

Product Managers have their eyes set on the horizon, focusing on vision, strategy, and communication. They gather insights, understand customer needs and plans for the future of the product, whilst also maintaining the product roadmap. Their core responsibilities are to drive innovation, meet long term business objectives, and keep the organisation’s products relevant in competitive market contexts.

It's worth noting that in some organisations, especially smaller startups, one person may perform both roles simultaneously. This approach can work, but it's important to understand the core responsibilities required to ensure effective product development.

As Dan Teo, CEO & Partner of Radically puts it, “Someone needs to manage the strategy, value, and backlog of work; everything else is open for tailoring. I would start with a blank sheet and list the core things that need to be done. Then within the context see what roles are required. In a cost-constrained environment, the concept of “hats” instead of roles is a good solution.”

 

Key Differences and Challenges

While there's significant overlap between these roles, there are key differences which are sources of common tensions.

product-owner-vs-product-manager

Scope and Time horizon: Long-term vs Short-term Goals

Product Managers are responsible for setting the overall direction of the product, which involves making strategic decisions that align with the company's long-term objectives. Product Owners, on the other hand, are more concerned with short-term goals, such as delivering specific features or improvements within a sprint.

This difference in time horizons can lead to disagreements about priorities and resource allocation. Product Managers might push for initiatives that have long-term benefits but require significant investment, while Product Owners might advocate for more immediate, tangible results that satisfy current customer needs.

Decision-making: Strategies vs Tactical Focus

Product Managers typically focus on the broader product vision and strategy, while Product Owners tend to concentrate on tactical, sprint-level decisions. This difference in focus can lead to tensions, especially when responsibilities overlap. Product Managers need to maintain a long-term perspective, overseeing the entire product lifecycle and developing the product roadmap. In contrast, Product Owners often find themselves more involved in the day-to-day aspects of product development, managing the product backlog and working closely with development teams.

Stakeholder Interactions

Product Owners work closely with development teams, and act as a bridge to other stakeholders to maximise the value of the product. A key group is the customer, as they often represent their needs and translate them into product requirements. 

Product Managers have a broad scope of stakeholder interactions. They focus on the product vision and strategy, communicating with stakeholders to ensure alignment and gather insights. They oversee the entire product lifecycle, from conception to launch and beyond. Product Managers also develop and maintain the product roadmap, outlining the future direction and planned features.

Product Managers need to balance the needs of various stakeholders, including executives, customers, and development teams. They are responsible for making higher-level strategic decisions that align with the company's long-term objectives.

 

Overcoming Tensions

Establishing clear distinctions between a Product Owner and a Product Manager’s role can help with overcoming decision-making conflicts. Some useful strategies include:

  1. Role clarity: Because these roles work together closely and responsibilities can vary greatly from organisation to organisation, it’s important to clearly articulate the scope and responsibilities of each role to minimise confusion. 
  2. Regular communication: Encourage continuous open dialogue between Product Managers and Product Owners to ensure alignment on product goals and priorities.
  3. Collaborative planning: Involve both roles in strategic planning sessions to allow both the long-term vision and short-term execution needs to be surfaced and tradeoffs be worked through.
  4. Shared metrics: Establish common success metrics that both roles can work towards, balancing short-term wins with long-term objectives.

product-manager-vs-product-owner


Conclusion

The relationship between Product Owners and Product Managers has a significant impact on the success of product development initiatives. Their distinct yet overlapping roles require clear communication and collaboration to navigate the challenges of scope definition, decision-making, and stakeholder management. By understanding the value and  responsibilities of each role,  fostering an environment of mutual respect, and addressing these challenges head-on, organisations can create a more harmonious and effective product development process.

Want to learn more?

If you’d like to learn more, feel free to get in touch at tiffany@radically.co.nz

 

In today’s business world there is a tension between flexibility and certainty, and organisations find themselves torn between predictive and adaptive approaches. Combining Agile and Traditional Project Management has become a hot topic, as businesses try to use the best parts of both methods without compromising quality. This mix aims to blend the structured planning of the waterfall model with the adaptability and ongoing improvement of agile techniques creating a strong hybrid approach that can adjust to different project needs and hurdles.

This article explores how to blend predictive and adaptive approaches to create successful initiatives. We'll look at key considerations when putting this combined approach into action, including project type, communication strategies, and tools that support both approaches. The piece will also tackle common problems that arise when mixing these different project management philosophies and offer practical ways to solve them.

 

Integrating Predictive and Adaptive approaches for successful initiatives

The integration of traditional project management with agile methodologies has become more common in large-scale organisations. This blend brings together the organisation and planning of traditional methods with Agile's quick responses and adaptability. But setting up and operating a hybrid approach has its own challenges which require careful alignment between the project team, organisational objectives, and project implementation.

To better understand the challenges associated with implementing hybrid models, interview data was collected from eight experienced Agile coaches who have implemented Agile in non-software industries. The practical actions identified for managing these challenges can be categorised into three levels: aligning planning and delivery approaches, effective risk management, and stakeholder engagement.

agile-project-management

 

Planning and Delivery

A crucial part of combining predictive and adaptive methods involves striking the right balance between planning and delivery. Traditional project management puts emphasis on detailed planning up front, while Agile focuses on iterative delivery and adaptability. To integrate these, organisations should establish a plan that provides direction and clarity of intended outcomes, while allowing for some flexibility as more information arises with each iteration. It’s important to have a plan to forecast, predict and manage dependencies, and iterative delivery with frequent feedback loops to allow projects to navigate the uncertainty inherent in today’s projects.

At the beginning of the project it’s crucial to clarify the intended outcomes of the initiative and create at least a high level plan of how they will be achieved. The optimum level of upfront planning required will be determined by the type of work and level of certainty, but in most cases the work in the near future will be more certain than the work further in the future, and the level of granularity of planning should reflect this. There is often little value in planning every detail of a task that will happen 3 years from now because it is likely to change and can be solidified closer to the time!

Once a plan is established, the iterative delivery of adaptive methods allows for the project team to react to change by checking progress on a regular cadence and making more informed decisions as the work progresses and more information is available. Ensuring that the main project plan is continually kept updated, and transparent to team members and stakeholders is crucial to ensure alignment across the project.

Risk Management

Effective risk management is crucial when combining predictive and adaptive approaches. Traditional risk management techniques such as identification, mitigation and monitoring strategies are important, but can be complemented by the proactive risk mitigation approaches of Agile practices such as limiting work in progress and increasing transparency. Regular risk reviews and retrospectives also allow teams to identify and address potential issues promptly. By fostering open communication and encouraging proactive risk management, organisations can manage the risks they can predict and navigate the ones they can’t.

Stakeholder Engagement

Engaging stakeholders is essential for the success of hybrid projects. Traditional project management often involves formal communication channels and structured stakeholder management processes. Agile, on the other hand, emphasises frequent interaction and collaboration with stakeholders. To effectively integrate these approaches, organisations should follow the valuable traditional approach of stakeholder identification and engagement planning, but also establish clear communication protocols that facilitate regular feedback loops and stakeholder involvement. This includes conducting regular demos, showcases, and review meetings to keep stakeholders informed and aligned with project progress.

By defining and aligning planning and delivery approaches, creating effective risk management practices, and meaningfully engaging stakeholders, organisations can successfully navigate the challenges associated with implementing hybrid models. The insights gained from experienced Agile coaches provide valuable guidance for practitioners seeking to effectively combine predictive and adaptive approaches in their project management practices.

 

Key Considerations

When integrating Agile and traditional project management approaches, several key considerations need to be taken into account to ensure a successful implementation. The approach taken for any project should be based on the type of work and the problems to be solved. Generally, if work is more predictable, a traditional approach may be more suitable, while if work is more uncertain and requires more flexibility, an Agile approach may be more appropriate.

Assessing Project and Programme Type

The project and programme type and requirements play a crucial role in determining the most suitable approach. It is essential to assess the nature of the project, its complexity, and the level of uncertainty involved. This assessment helps in deciding whether a predictive, adaptive, or hybrid approach would be most effective in delivering the desired outcomes.

Evaluating Team and Organisational Culture

Another critical consideration is the team and organisational culture, as well as stakeholder expectations. Agile methodologies heavily rely on collaboration, transparency, and a willingness to embrace change. The organisation's culture should support these values to facilitate a smooth transition towards Agile practices. It is important to align stakeholder expectations with the chosen approach and ensure their buy-in and support throughout the project lifecycle.

Adapting Stakeholder Engagement

Effective stakeholder engagement is often the key success factor for initiatives and can make or break a project. To ensure stakeholders are kept informed and engaged, one must consider the current expectations and mindsets of key stakeholders and tailor the stakeholder engagement and communication approaches accordingly. For example, a key stakeholder who is accustomed to traditional reporting and governance styles will expect to be engaged in this way and these practices may be required to win their trust, but involving them in regular iteration reviews and showcases can introduce them to a different way to engage.

Tailoring the Approach

When integrating Agile and traditional project management, it is essential to consider the project and programme type, team and organisational culture, and stakeholder expectations. By carefully assessing these factors and adopting a tailored approach, organisations can successfully blend the strengths of both methodologies to deliver successful initiatives.

 

Tackling Obstacles

Integrating agile and traditional project management approaches can present several challenges that organisations must navigate to ensure successful implementation. These challenges often stem from resistance to change, misalignment of processes, and stakeholder management issues.

agile-project-management

Addressing Resistance to Change

One of the primary obstacles is the resistance to change within an organisation. Transitioning from a traditional, hierarchical structure to an agile, collaborative environment requires a significant shift in mindset and culture. Employees may be hesitant to embrace new ways of working, fearing the unknown or feeling uncomfortable with increased transparency and accountability.

To overcome this resistance, organisations must invest in the change journey for their people. Training and education programmes can help employees understand the benefits of agile methodologies, but experiencing a different way of working is often required to shift mindsets. Choosing a strategically important project to pilot Agile ways of working creates focus and dedication, but often requires external support to ensure a sound application of Agile approaches. Leadership leaning in and encouraging teams to embrace change and adapt to new ways of working is also an important success factor.

Aligning Agile and Traditional Processes

Another challenge lies in the misalignment of processes between agile and traditional approaches. Providing clarity on which approaches will be adopted, how the project will operate and how roles and teams will interact is crucial for success. Investing time at the beginning of the project to agree ways of working (project structure, roles and responsibilities, forums and cadences, etc.) will ensure that team members understand how work is done and how information flows through the project.

Managing Stakeholder Expectations

Managing stakeholder expectations can be difficult when they are accustomed to one approach over the other. To overcome this mismatch in expectations, organisations must educate stakeholders on the benefits and strengths of each approach in different contexts, and how each approach requires different stakeholder engagement and behaviour.

Ensuring that stakeholders feel engaged and updated is important to win and maintain their project support. Especially if agile methodologies are new to some stakeholders, ensure that they are involved in planning and review meetings and actively elicit their input. Creating and maintaining transparent reporting practices which clearly communicate status and progress can also be a great way to ensure stakeholders stay informed and engaged.

Managing stakeholder expectations can be difficult when they are accustomed to one approach over the other. To overcome this mismatch in expectations, organisations must educate stakeholders on the benefits and strengths of each approach in different contexts, and how each approach requires different stakeholder engagement and behaviour.

Ensuring that stakeholders feel engaged and updated is important to win and maintain their project support. Especially if agile methodologies are new to some stakeholders, ensure that they are involved in planning and review meetings and actively elicit their input. Creating and maintaining transparent reporting practices which clearly communicate status and progress can also be a great way to ensure stakeholders stay informed and engaged.

Embracing a Proactive Approach

By addressing resistance to change, aligning processes, and effectively managing stakeholders, organisations can successfully overcome the challenges associated with integrating agile and traditional project management. It requires a proactive approach, clear communication, and a willingness to adapt and continuously improve. With the right strategies and support, organisations can harness the strengths of both methodologies to deliver successful projects and drive business value.

 

Quick Recap

The integration of Agile and traditional project management approaches provides a powerful toolset to tackle complex initiatives. By blending the structure of traditional methods with the flexibility of Agile, organisations can adapt to changing requirements while maintaining a clear direction. This hybrid approach has a significant impact on project outcomes, enhancing team collaboration and stakeholder engagement throughout the project lifecycle.

As the project management landscape continues to evolve, mastering this integrated approach becomes crucial for success. Teams that embrace this methodology are better equipped to navigate challenges and deliver value consistently. By adopting a balanced perspective and continuously refining their approach, organisations can unlock new levels of efficiency and innovation in their project delivery.

Want to learn more?

If you’d like to learn more, feel free to get in touch with me at ryan@radically.co.nz

 

I recently spoke with a diverse group of small-medium business owners about how to apply agile in business.  The audience was both big and small firms from almost every business sector conceivable, from manufacturing to construction, media, health care, real estate right through to a large freight and logistics firm.

They had all heard about agile but thought it was just for technology companies. To help them understand how to apply agile in business in very practical day-to-day terms, I had to strip out the jargon and show them how they could apply agile at their workplace right away.

We all found the conversation extremely valuable. They were grateful for someone who could make it real for them. I was grateful for the challenge of explaining agile to an everyday business owner, short of time but wanting to understand how they could get started without all the jargon and terminology.  This article attempts to capture that conversation for others to understand how to apply agile in business.

How to apply Agile in business

Agile’s principles, concepts and tools are applicable to a wide variety of settings, but to bring out its true potential it requires pragmatism and continual refinement, based on what is and isn't working. If you are working in a sector where agile might not feel like a clear-cut fit, here is how I suggest you can apply some basic concepts of agile to see how well it might improve how you work.

Start with Visual Management

Visual Management helps you understand how your work works. It is a simple but important core principle of agile. By visualising the work, we can better understand it and therefore improve it.

In layman’s terms, this means mapping out the steps to take a piece of work from idea to completion.  The easiest way to do this is with a whiteboard or wall space and a set of sticky notes. One useful way to getting underway is to simply start with three columns: To Do, Doing and Done. This allows you to get underway easily and get your work on a visual board. You can then break the work down into smaller steps, continually revising your board until it reflects how your work works.

Visual board to apply agile in business

Remember to avoid perfection. The point isn’t to map out exactly what happens each step of the way! That will result in a visual board for every variation of the workflow which defeats the purpose.  We are only after “good enough to get started” at this point. You will almost certainly evolve your board as you go!

Now it is time to populate your board with work. Again – don’t worry about being perfect. The objective here is to create a visualisation of how work works so you can detect patterns and trends. Let the work help learn what a suitable visual board is for your situation.

Visual board to apply agile in business

Now add a Doing and Done column to each workflow stage. The Done column of one stage becomes the To Do column of the next.

Visual board to apply agile in business

Once you have run some work through your board, start considering what sort of data might help you better understand the flow of work.  Some common things organisations track are:

  • How long a work item spends in a particular column (workflow stage). You can measure this by capturing when a piece of work enters a workflow stage and when it exits.
  • How long a piece of work waits in a workflow stage before it is worked on. This is often referred to as “wait time” and when added up across stages can be quite revealing. In many organisations, around 80% of the time taken for a piece of work to go from start to finish is wait time.
  • How many pieces of work are in each workflow stage? This is referred to as work-in-progress, or WIP. Lots of WIP can be an indicator of trying to get too much work done at once, resulting in less being achieved. A common strategy for dealing with this is WIP limits on each workflow stage.
  • Bottlenecks – the Theory of Constraints taught us that the throughput of a system is limited by the throughput of the narrowest bottleneck. WIP is often a lead indicator of bottlenecks and gives us a good indicator of where we might want to investigate further. Addressing bottlenecks improves the flow of work!

For example, in the above graphic, there appears to be a bottleneck in Editorial, given that all the Draft work is complete and waiting. This would be a great place to explore. Queues tend to indicate downstream bottlenecks!

If you are interested in further reading on visual management, I found this article on Value Stream Mapping useful.

The principles of Scrum for Agile business

Scrum is the most popular agile framework in use today and for good reason – it is an extremely powerful yet simple framework. Now that you have a visual management board underway and can visualise how your work works, try these Scrum patterns.

  • Introduce iterations – an iteration is simply a fixed, time-bound length of work, also known as Sprints in Scrum. Your Sprint length is largely determined by how frequently you want to inspect and adapt the work. The most common Sprint cadence is two weeks.
  • Set a goal for the Sprint – in business terms, what will be different at the end of each Sprint? This forms the “north star” for each Sprint. Why is this goal important? Who will benefit and how? Make this clear to the people who will be doing the work.
  • Plan a Sprint of work – get the people involved in doing the work together to break down how they can achieve the Sprint Goal. The outcome is a plan for the Sprint. It doesn’t have to perfect and don’t go to the level of who will do what, but break the work down into chunks of value and only take on what is achievable in the Sprint. Your objective is to have something 100% done that can be used by others. Rather than take on lots of work, take on less and get it 100% completed. You might have to re-negotiate the Sprint Goal in order to achieve this. In Scrum, this is called Sprint Planning.
  • Every day, everyone involved in delivering the work gets together in front of the visual board for 15 minutes to understand the current state of the work and what the most valuable thing is they can collectively do next 24 hours to progress towards the Sprint Goal. This isn’t a problem-solving meeting. It is a meeting to re-align around the plan and adjust the plan as required. In Scrum, this is called a Daily Scrum or stand-up.
  • At the end of the Sprint, hold a meeting to review what was achieved and consider what might be the best thing to do next Sprint. This should typically involve others in the business who need to understand progress or contribute.
  • Hold a continuous improvement meeting for the team who did the work in the last Sprint. Collaborate to understand what went well that we could do more of, and what areas we could improve. This should be an open meeting that discusses everything, including interpersonal relationships and teamwork.
  • Start another Sprint.

Scrum framework for agile in business The iterative, incremental nature of Scrum can help to bring focus, commitment, alignment and collaboration to the forefront of your business.

If you are finding iterations don’t add value to your work, (for example, your work is highly repetitive and pausing to regularly inspect & adapt doesn't make sense) then drop them. There is no recipe!

Remember, Scrum is based on three important inter-connected pillars – transparency, inspection and adaptation. Our ability to inspect and adapt is largely determined by the transparency of the information. If we don’t increase transparency, then our ability to make meaningful decisions and trade-offs are decreased. A great way to increase transparency is keeping your visual board up to date and having open and honest conversations.

As a Professional Scrum Trainer, I know Scrum extremely well and would caution readers about some of the material on the internet from “Scrum experts”. Credible sources of further reading include Scrum.org and Scrum Inc. In addition, the single source of truth on Scrum is the Scrum Guide, written by the creators of Scrum, Dr Jeff Sutherland and Ken Schwaber.

Minimal viable product thinking

One of the most common mistakes businesses make when learning how to apply agile in business is assuming they need to have the product or service they are developing perfect before engaging customers. Usually, the opposite is true – they introduce significant risk by not getting sufficient customer feedback early enough. A minimum viable product (MVP) is a product or service with enough functionality to obtain feedback and validate the idea as early as possible. This can significantly reduce risk and increase customer value.

To achieve this, you need to re-think the purpose behind each iteration. Is it to deliver work or is it to learn about what the customer really wants and de-risk work?

Minimal Viable Product thinking

In the above example, you can see two different approaches. In the first approach, the requestor has specified the solution - give me a painting that looks like this. The people doing the work have delivered that, one high-fidelity piece at a time. The problem with this is what happens if they are wrong? Even if they are using agile techniques, they must still deliver the wrong thing. In the second example the requestor has outlined the problem they are trying to solve and the MVP approach has been applied to reduce risk and integrate customer feedback.  Coiuld you apply a similar mindset to your work?

If you are interested in diving deeper into the MVP-type space, the books Running Lean and The Lean Start-up are both useful reading.

In summary

In this article, I have tried to share how you can apply agile in business. In my twenty years working in this space, I have learned that the best get familiar with agile is to do it. It is tempting to stand on the sidelines, watching the game play out in order to learn the rules before playing, but I can assure you that in the case of agile, more is learned by playing than watching. Just get in there and do it.

The journey to mastery is however long and difficult. The focus on transparency, visualising work and seeking continuous improvement invites you to be always asking questions of your business, evolving and improving it to be the best it can be. This can be tiring, however, don't we all strive to be the best we can be?