19 min read

What Is Agile Product Management: Guide To Processes & Roles

QUICK SUMMARY

A crash course on the agile methodology—arguably the most popular framework for today's product teams.

TABLE OF CONTENTS What Is Agile Product Management? Agile Flow 2 Common Agile Approaches Agile Product Management Certifications Agile Product Development Roles

There's a lot of content, guides, textbooks, courses, and certifications available on agile product management. Honestly, you don't need all of that.

At its core, agile product management is built around a simple, people-oriented philosophy. Many of the processes in which agile forms are simple and easy to understand. Yet, the complexity arises through misunderstood expectations, roles, and processes.

In this guide, we'll:

Explore agile product management, its philosophy, and the processes in which it takes shape.
Consider the roles that make up a typical agile product development team, what they are, and how they collaborate.

Understanding these key areas is important. It will provide you with the tools to implement or improve agile product management within your team or organization.

What is agile product management?

To start with a common misconception, agile is not a process. Rather, it is a philosophy around how teams can effectively collaborate to work towards achieving a goal. The original agile manifesto, published in 2001, expresses the agile principles best:

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's the soul of agile product management. There's no mention of story points or swim lanes. No stand-ups or sprints.

While the agile manifesto doesn't prescribe the use of processes and tools, it does downplay its importance in favor of human-focused, adaptable collaboration. In the context of approaching agile product development for the first time (or even in the case of a refresher), it can be enlightening to start at the fundamentals with the manifesto.

As we get into talking about the practicalities of agile, it's important to continue to keep the manifesto in mind. Processes, documentation, and planning are all great. However, if you find yourself in a position where you or your team is prioritizing them over your team or a working product, you’ll want to pay attention to this.

Let's take a look at some of the finer points of the agile product development mindset.

People-Focused

Agile software development is focused on empowering the people that make up your product team. To practice it well, you must truly trust those you work with. Without trust, the psychological safety of your team is at risk and productive collaboration may falter.

User-Focused

Relentlessly focusing on your users is a must. After all, are they not who we build for?

An effective agile team constantly interviews users for feedback on their products. They're sending out and processing surveys to drive the prioritization of new feature development. Agile product managers are always looking for ways to split the work into small, releasable bites of effort to validate with users along the way.

Without regularly inviting the users to the table, what we plan today may be invalid tomorrow.

Challenging

Agile product management is incredibly challenging and not for the reasons you might expect.

Effective agile teams generally have less process and formal reporting than their non-agile counterparts. This is because agile focuses on an ongoing stream of work and transparency to prioritize collaboration instead of one-off milestones.

With a lack of processes also comes the feeling of a lack of control for many product managers. However, they still have a high degree of accountability that comes with the role. Balancing oneself to not overstep and throw off your team's focus is an art and something that can vary team to team, depending on the dynamic.

However, when a product manager takes the approach of being a servant leader, there can be more benefits in the long-term — and ironically more control — than otherwise. This is due to the gains that leaning into trusted agile processes can create.

It is also ideal to have a work culture that supports agile. It is possible to get started in one without support for agile, but this will be more challenging and you will find yourself going against the grain. An organization that supports agile will be comfortable with intentionally vague plans, as they understand that plans will become more clear as time progresses.

Lean

Being lean in practice is crucial. A laser-focus on the outcomes keeps agile teams moving toward the goal with little distraction. Focusing on the least amount of work that can be done to achieve its goal helps the team continue to push forward and achieve market success as quickly as possible.

Agile Flow

agile product management infographic — The general flow of the agile methodology from strategizing to experimenting to testing to validating. The process repeats to encourage continual iteration.

Before we get into a few of the specific processes you can use to adopt agile product management, let's talk about the general process flow and the agile methodology steps most processes will follow.

Strategy

Great agile development starts with good strategy and alignment. Bringing everyone on the team into a room (or Zoom meeting) can do wonders to establish a unified product vision and direction. Consider using engaging, visual collaboration software to ensure people don't tune out.

This can serve as a chance for the team to align on the business plan, visual direction, target users, and more. It serves as a key common starting point for the team to focus on.

It’s important to note that the plans and documentation created during this time are treated as assumptions. They're ready to be regularly reviewed and iterated on as time progresses.

Experiment

Everything is an experiment. Right out of the gate, the first focused chunk of work you do should be time-boxed and then tested with users. This work can be incredibly rudimentary, even as simple as crude sketches you walk someone through.

The point is to approach your work with the mindset of the scientific method. We are knowledge workers and as such, our focus isn't solely on execution. It's on knowledge creation and discovery as well.

Test

Each experiment should be tested qualitatively and quantitatively. With a regular review of the results, you will have the tools you need to confirm that what your team is building is of value and will be accepted in the market.

Validate

After you release a new feature into the wild, keep a pulse check on it. Is it being used? Are people finding it? Have other areas of your product been positively or negatively impacted by this feature being introduced?

Regularly reviewing and checking in on what you release after it is "done," will provide more tools and guidance to make even better decisions.

Repeat

This is the most important step. Continue to circle back through the agile process flow, like an engine. This flow is intentionally cyclical, not lateral, to encourage learning. Learn from it. Adapt from it. Celebrate it. Embrace the flow of change.

2 Common Agile Approaches

Agile is an empowering philosophy that brings teams together towards a common goal in collaborative ways that aren’t possible with overly structured processes and reporting.

However, some processes are good. When properly implemented and used in the consideration of a team's unique culture, processes can serve as the guardrails that keep a team focused on achieving its goals, while supporting creative freedom.

We'll dive into some of the more popular processes that put the agile philosophy into action.

Scrum

Scrum is perhaps the most popular agile process and for good reason: it breaks down commitments and learning into dedicated time blocks of effort, called "sprints." This encourages a healthy amount of learning and more opportunities to adapt to those learnings.

Central to these sprints is the scrum team itself. In scrum, there are no titles: every producer on the team has the role of "developer." This encourages an intense team focus on collaboration and achieving the goal for each sprint.

In practice, this means that if a test engineer is waiting for a feature to test, they can spend time jumping into coding a new feature. This cross-functional mindset is incredible when it works because it means a team can produce fantastic results.

Scrum works to minimize meetings in order to promote focused development time. To do this, there are a set of recurring meetings, or ceremonies:

Sprint Planning: Used to plan the work the team wants to commit to for the newsprint.
Sprint Review (Demo): A time to demo any progress to each other and stakeholders, as well as cover any learnings.
Sprint Retrospective: A candid time for the team to look back at the prior sprint and discuss what went well, what didn't, and where there could be opportunities for growth.
Backlog Grooming and Estimation: This is a recurring block of time for reviewing and prioritizing the ever-changing product backlog, based on business and technical learnings. Once there's alignment on items in the backlog, they are estimated for planning purposes.
Daily Stand-ups: A regular time each day for the team to share what they completed yesterday, what they are working on today, and if they are blocked by anything.

In order to connect the sprint-focused work to the big picture, scrum encourages the use of "story points" for estimation. These are an arbitrary level of effort that the team assigns to each backlog item.

What's incredibly powerful about this is that it supports the use of velocity tracking. That is, the average number of story points the team completes each sprint. After a few initial sprints, this number should be dialed in and can be used for targeted release forecasting and planning.

If these tools are used diligently with the team, scrum can be a powerful process that supports focused agile development and provides ample opportunity for effective iteration.

Kanban

Borrowing a lot from the scrum, Kanban includes many familiar elements such as backlog grooming, a board reminiscent of a sprint board, and more.

However, where scrum provides focus on a small amount of work, kanban emphasizes a focus on a continuous flow of work.

Central to this process is the kanban board. Items are continuously prioritized on the left and move through the team's custom process to the right, ending in "done." Often in order to balance workload, each column might have a work-in-progress (WIP) limit of how many tasks may be worked on at a time.

Kanban is great for support work or teams that have irregular availability to commit.

SAFe, XP, and Others

There are many additional flavors of agile processes, each suited for specific organizational needs and cultural norms.

SAFe is a comprehensive agile system for implementing agile at scale in an organization, typically a large enterprise. It consists of multiple "agile release trains," which are essentially individual scrum teams. There are multiple roles and ceremonies involved to see that all teams are working towards shared organizational goals and release plans.

Extreme programming (XP), DevOps, Modern Agile, and other methodologies exist to target agile use cases for specific roles or cultures.

Experimenting with different agile practices is healthy. It can lead to an effective understanding of what works for your unique organization.

Agile Product Management Certifications

You've probably seen the numerous certifications that you can earn for any particular agile process. They're marketed to make you feel that their process is the one way and without going through a costly certification, you will not truly be able to practice the process.

Ignore that.

Ideally, this guide will provide you with enough momentum to go down a learning track of your own. Agile methodologies are a practitioner's toolkit, not something that you will be tested on. Familiarity with the process, ceremonies, and documentation unique to each process is valuable, however, going back to the manifesto, it is more critical to involve your team in the implementation of your agile process of choice. There are organizations dedicated to creating and maintaining certifications; it is naturally in their best interest to promote process over people.

Is that truly agile?

All this to say that this is simply a cautionary tale as you make your own agile learning journey. Certifications can be valuable. If you take a workshop, it can be a targeted way to quickly learn all the details of a specific process. Some organizations value seeing that you're certified as a way to quickly build trust.

If pursuing a certification helps you achieve your desired outcome and involves a minimal low effort to achieve, go for it. However, if you don't need a certification, experimentation and continuous learning on implementing agile is the most effective path in your agile journey.

What are agile product development roles?

Through covering agile processes, we've started to name a set of core roles that make up an agile product development team. These roles include:

Product Manager
Product Owner
Developer
Designer
Test Engineer / QA

Each organization generally has their own approach to what these roles are. For example, a product manager's set of responsibilities at one company might be more in line with the commitments of a product owner at another. However, with this flexibility in mind, let's take a look at some of the broader definitions that illustrate the roles in a product team.

Often, there is some overlap between product owners, product managers, and project managers, and teams may have one, two, or all three. Product managers or product owners often take on project management responsibilities when there is no project manager on the team.

Product Manager

So, what does a product manager do? The product manager is responsible for, well, managing the product. The key responsibility of the product management role in ensuring that everything is aligned to achieve key outcomes based on user testing, team input, and strategic planning.

However, effective product management is about the empowerment of the product team. For this, the product manager is a generalist role. That is, they need to be able to go wide in their skill set to be effective, but not necessarily be a skilled developer or designer (although it is common for producer roles to move into product management).

A generalist skillset empowers the product manager to be an empathetic servant leader for their team. By wielding just enough understanding of what development takes, the product manager can help guide the team towards effective product definition and planning, while simultaneously not getting in the way of the team's skills.

Related Read: Why Is Product Management Important?

Product Manager Responsibilities

Product Owner

Where the product manager owns the responsibility for the tactical success of the product, the agile product owner is accountable for the business and market success.

Generally, the product owner is a core business role that sometimes maybe a core stakeholder to the product team. Their market knowledge and 50,000ft focus on the business makes them a key, knowledgeable resource to help optimize the product team for success.

Product Owner Responsibilities

Product success
Market research and knowledge
Business development
Funding
Tie breaker

A common challenge is the overlap and differences between the role of product owner vs product manager. Sometimes this role is part of the product manager role and vice-versa. When the two roles are separate, there's often role overlap. Some organizations even flip the responsibilities of the product manager and product owner roles.

However, this is ok!

Despite the challenges that may arise, when these roles work together to find a healthy balance of complementary collaboration, there can be incredible outcomes. For example, one role can be relentlessly focused on the product, while the other is focused on the business. One can be focused on the nuts and bolts of the product, while the other is focused on high-level market positioning.

Then, when these two roles are partnered together for collaboration, game-changing strategic insights may serendipitously arise that positively impact the success of the product and team. After all, two heads are better than one!

Developer

In an effective product team, the developer role isn't only writing code: they're collaborating with all roles for strategic, technical planning, and recommendations.

Developers armed with a strong knowledge of product development tools, user needs and product-market goals will be able to create a technical plan that fits the product like a glove. Empowering your development team members with this knowledge and ability to make key technical decisions can mean the difference between a one-month development timeline or a multiple of that, due to the technical tradeoffs that come with these decisions.

When your developers are integrated into the product aspect of your development team, they can multiply the team's success.

Developer Responsibilities

Product development
Technical planning and research
Tech stack consultation
Functional prototyping
Unit testing
DevOps (sometimes a separate role)
- Deployment pipeline creation and management

Designer

Similar to how developers shouldn't be restrained to only writing code, designers' reach on a product team should extend beyond creating a design. In fact, some of the best collaborations on a product team happen in the collaboration between this and the product manager role.

Designers on product teams start by strategically looking at the product strategy and business. They are often the biggest user-focused advocate on the team. These insights allow them to then design, albeit with a targeted focus.

Enabling efficiencies for development and learning is a key area of focus for design roles. Creating design systems empowers developers to quickly build new features. Building interactive, visual prototypes enables user testing before a line of code is written, to validate further investment.

Designer Responsibilities

Product design
Mockups
Prototyping
Style guide creation
Design system creation and support
User testing, in collaboration with the product manager
Ongoing user research

Test Engineer / QA

A test engineer (sometimes referred to as quality assurance, or QA) can be one of the most impactful roles on a product team. While their core focus is on testing the product's features before it goes out to users, their detailed eye can help streamline the team's focus prior to building a new feature.

Test engineers should be involved from the earliest stages of product development. This sets the role up to define acceptance criteria for the product's user stories that are used to guide the rest of the team for completing the work.

With a user-focused mindset, test engineers can forewarn any potential consequences of an upcoming release. When this role can strategically advise the product owner, it can have a tangible impact on the business success or failure of a new release to users.

Test Engineer/QA Responsibilities

Functional testing
Regression testing
Exploratory testing
Acceptance criteria definition
Ongoing risk assessments and analysis

Other Roles

While the previously mentioned roles comprise a product team, there are many roles outside the team that support the outcome-driven focus of the team.

These roles include marketing, sales, customer support, and more. Usually, these roles are brought into the organization to support the product, as success in the market is found. Typically, they are not part of the product team. However, a strong and collaborative relationship with these roles further serves to drive business success.

Collaboration

While each role has its own area of expertise on a product team, it is assumed they are all collaborating together. When each role brings a "t-shaped" mindset to the team, it allows everyone to bring their specialty to the table, while embracing a focus on the product as part of each other's role definition. Everyone goes deep into their own expertise, while at the same time going wide into all other skill sets to find success together as a unit.

Collaboration in a product team means there is a relentless focus on the product results and user experience. Everyone is brought into achieving this vision and moving forward together, as a cohesive team.

Conclusion

Key takeaways

Agile product management is a people-and-user-focused philosophy to deliver the right output, sooner.
While agile is simple at its core, complexity, and challenges are introduced with processes, organizational culture, and more.
Agile processes and roles can be guided by processes such as scrum, kanban, SAFe, and more.
Roles that make up an agile product team include developers, designers, test engineers, a product manager, and a product owner.

Agile product management is incredibly and intentionally simple. It's a powerful philosophy that can multiply the value your team is able to create. Yet the deeper you go into the processes and roles that support it, the more complex it risks becoming.

In that complexity hides opportunities for helping empower your product team and organization. It's a balancing act to use these tactics with your team while ensuring they don't create unintentional organization drag throughout normal collaboration.

However, implemented well and with a posture of experimentation, agile can drive the future of your product team's success.

Have you seen agile implemented or have experience with it? Has it been similar or different to what's explained in this guide? Let us know in the comments! Don’t forget to subscribe to our Product Manager newsletter for more insights and guides.

Or, keep learning by checking this podcast out which you can so conveniently read/watch/listen to: Alignment Through Product Roadmaps (with Brandon Blackman from Crema)

Related Reads:

Also Worth Checking Out: