Product School

Agile Product Management: A Study Guide for PMs

Ellen Merryweather

Ellen Merryweather

January 09, 2023 - 18 min read

Updated: January 24, 2024 - 18 min read

So you want to learn everything you can about agile product management. Buckle up because class is in session.

Here you’ll find an overview of everything you need to know about agile as a product manager, along with videos and resources to further your learning.

(If you’re looking for a hands-on, live, instructor-led experience, check out our Product Management Certifications. There’s no better way to learn about product management than from those who do it every single day.)

What Is Agile Product Development?

Things change fast in business, and even faster in tech. Companies have to react quickly to new data insights, shifting market landscapes, and competitor disruption. Sometimes mistakes are made, or new information shows that course correction is needed.

In traditional software development, these pivots would often come at the cost of weeks, or even months of work. Agile was created as an answer to this problem, as it introduces new frameworks and methodologies that allow for quick pivots and iterative development, with minimal loss of time and resources.

The principal value of agile is to keep development user-focused, people-driven, and lean. With an ever shifting roadmap, agile allows teams to repeatedly ask themselves ‘are we going in the right direction?’ at many different stages.

Agile is about much more than simply being able to react to change. It’s about expecting that things will probably change, and embracing it. When a product team is equipped to react to change, they’re able to build the right product, at the right time, in the right way.

The main way agile achieves this, is by breaking down large tasks into smaller chunks, and intelligently distributing the work among teams that work closely with each other, rather than having one team working on one thing at a time. A policy of open communication and transparency ensures that teams aren’t working in silos, and accidentally building in different directions.

How this is done can be dictated by a variety of frameworks and methods that come under the agile umbrella.

In truth, there is more than just one way to be agile. Agile is more a mindset and a set of principles, which comes with a toolbox that businesses can pick and choose from according to their specific needs. That way, agile can be made to work for anyone and everyone.

Product History: Agile vs Waterfall

The easiest way to understand what agile brings to the table, is to see the difference between the old ways of working, and the new agile ways of working.

Before agile, there was waterfall. Waterfall hasn’t completely been thrown out of the window by the business world, as it’s still very popular in project management and traditional software companies.

The name is derived from the flow of work, which comes from the top down. Work is broken down into sequences, and development is very linear. This means that each stage of the sequence must be completed before teams can move on to the next stage.

The main problem with waterfall for digital product development is that it’s very expensive to go back and make changes. When you’re already at the verification stage, and you realize that you need some serious design changes, you’re going to have to waste a lot of work to get that done.

Another issue with waterfall for digital products, is that it’s not particularly customer-focused. Agile tries to keep the customer involved at every stage, (for example, smaller tasks for the engineers to work on are called ‘user stories’ and they’re written from the POV of the customer.)

The main pro of agile is that it comes with strong project/product documentation, and having requirements decided upon upfront makes it much easier to estimate budgets and timelines.

The Agile Manifesto: Principles

You can still find the twelve principles of the agile manifesto in detail on the original website from 2001, which in itself is an excellent time capsule! But in brief, the twelve principles of agile software development are:

  1. Customer satisfaction is the highest priority.

  2. Welcoming changing requirements.

  3. Delivering work frequently.

  4. Business and tech to work together frequently throughout.

  5. People-driven development, with maximum support for teams.

  6. Preference for face-to-face communication.

  7. Working software is the primary measure of success.

  8. Sustainable development with teams working at a constant pace throughout.

  9. Attention to detail, technical excellence, and good design.

  10. Simplicity is essential.

  11. Self-organizing teams.

  12. Teams reflect on regular intervals on what could be done better.

Agile is designed to be flexible, which is why the principles can be interpreted and implemented in a variety of ways depending on the needs of the company.

It’s like The Pirate Code – it’s a set of guidelines rather than actual rules.

Key Benefits of Agile

Agile helps companies respond quickly to change, and to actually use disruption to their competitive advantage. When something shakes up the space you’re working in, if you can quickly pivot in response to that change faster than your competitors, you’ll be the first to market.

Agile is also much more user-focused, with the customers being involved at multiple points in development. Testing new features with users before rolling them out across the entire product allows for a continuous stream of new user data, which leads to a more user-centric product.

Typical Agile Methodologies and Frameworks

Here we’ll take you through the most common agile methodologies:


Scrum is sometimes wrongly thought of as a counterpart to agile. In fact, it’s a whole methodology that comes under the agile umbrella.

Self-described as ‘simple to understand, difficult to master’, it takes years of practice to be considered adept. The core principles behind Scrum are to make complicated tasks as simple as possible, while helping the team to complete work as efficiently as possible.

The product owner manages and prioritizes the team’s backlog, which consists of user stories. A self-organizing team will then work concurrently on those stories, during a period of time known as a sprint. Using the notorious stick-notes-and-whiteboard setup, the whole team can see what everyone is working on, and keep track of the product’s progress.

Scrum whiteboard

Teams will meet once a day for about 15 minutes, which is known as a scrum. These team meetings make sure that the team keeps in touch throughout their progress, and scrums are an opportunity to workshop various problems. Keeping the teams in touch in this way helps to foster understanding, and provide a full 360 view of what the product is looking like right now.

The Scrum master is the one who organizes the whole process. They’ll manage the whiteboard, call the scrums, and basically make sure the whole operation stays on track!

Check out this great talk on What is Scrum for Product Managers by Hubspot PM:

Interested in learning more? Check out: The Difference: Agile vs Scrum


Some companies use kanban without realizing it! It’s main principles are total transparency and real-time communication, which helps teams to always be aware of a product’s progress. Tasks needed to be completed are visually represented on a kanban board, either physical or digital, which is constantly updated according to which phase the task is in. This aids in planning and time estimations.

Basic kanban flows may be a recognizable three-step process. To Do – In Progress – Done. But in the software development world, they’re often more complicated.


Kanban is particularly popular with software development teams as it’s lean, and very easy to understand. It’s also something that teams can run between themselves, without needing too much interference from higher up.

Cycle time is used to track how long tasks take to be completed, allowing for more accurate predictions of completion times for the overall product. Beloved by teams for how well it reduces bottlenecks and encourages cross-functional collaboration, kanban will often be the first agile framework a company implements in its digital transformation.

Roadmapping in agile

Product roadmaps are nothing new, but there are a few key things that make the perfect agile roadmap.

  1. Accessible: Agile roadmaps are shared with those who need it the most, but are generally accessible by everyone within the organization. Agile understands that all touchpoints of the business can benefit from understanding the development process, and keeping the roadmap available to them is a boon.

  2. Collaborative: The product manager/product owner owns the roadmap and is ultimately responsible for it, but roadmaps are seldom built in a vacuum. Collaboration is absolutely key for a successful agile roadmap.

  3. Changeable. “Don’t laminate the roadmap!” As we’ve said, agile doesn’t just allow for change, it anticipates and embraces it. So remember that the roadmap is an every changing thing. Only the vision must remain strong and solid. The journey there will be long and winding, with many unexpected turns.

Looking for a product roadmap template? Look no further!

Prioritization methods

There are many prioritization methods, but among them all three seem to pop up time and time again:

  1. MoSCoW: Building a list of features and categorizing them by whether they’re ‘Must Have’, ‘Should Have’, ‘Could Have’, or ‘Won’t Have.’ It’s a simple method that helps to communicate the priorities to stakeholders.

MoSCoW method prioritization method

2. Kano: The Kano model, created by Dr. Noriaki Kano in Tokyo in 1984, plots a feature on a graph depending on how it satisfies users, and how it meets their needs.

Kano model prioritization

3. RICE: Calculated by combining the Reach, Impact, and Confidence in a feature, and dividing by the effort (usually denoted in hours of work needed) to give a numerical score.

RICE scoring prioritization method

For a more in-depth breakdown, check out 3 Prioritization Methods All Product Manager Should Know

Using Agile at Scale: SAFe

Sometimes when we think of agile, it’s tempting to picture the worn-out image of a group of young-ish twenty-somethings in hoodies gathered around a whiteboard in their one-room coworking space. But what does it look like when a huge company uses agile at scale across the whole organization?

There’s a specific framework with the aim of maintaining cohesion in a company’s agile practices at scale: SAFe.

SAFe stands for Scaled Agile Framework, and promotes collaboration across many teams in a large-scale organization. It’s a framework that has evolved with time, and can be adapted to the needs of the company depending on the market they operate in and where they’re at in their journey.

SAFe is mostly comprised of values and principles, much like agile itself. The core values being:

  1. Alignment: Everyone understands the direction the company is going in, from low level to high level.

  2. Built-in quality: Every definition of ‘done’ is clearly stated for every project.

  3. Transparency: Team trust is built in at every level.

  4. Program execution: Work is to be delivered at a high quality and on a regular basis.

  5. Leadership: Leadership is the biggest influence over company culture, and for SAFe to work, leaders must be lean and agile.

Check out Atlassian’s guide to SAFe

Using Agile at Scale: The Spotify Model

Another model for scaling products using agile methodologies is The Spotify Model, which has exploded in popularity almost as quickly as the streaming service itself.

The model was created in 2021, when Henrik Kniberg and Anders Ivarsson released a whitepaper; Scaling Agile @ Spotify.

The paper sets out Spotify’s approach to agile product development, with a few unique features. Teams, known as Squads, each select their own framework (Kanban, Scrum, etc) and work within a group of teams known as a Tribe. Tribes are then organized into Chapters and Guilds.

It’s a system that looks complicated on paper, but in practice has helped Spotify to reach millions of users.

The main goals of The Spotify Model are to promote collaboration and autonomy within and across teams, and to cut down on the amount of bureaucracy.

Check out the whitepaper to learn more.

Undertaking an Agile Transformation

Agile is a long-term investment, and may involve a complete restructuring of how a company operates. Luckily in 2021, almost every tech company is using agile principles at least somewhere in the business. Successfully pulling off an agile transformation takes grit, determination, and a lot of trial and error. McKinsey goes into detail on how this is done, and states that a transformation touches every facet of an organization.

New startups, or companies looking to make a bigger commitment to agile development principles, can begin implementing in the following ways:

1. Define your end state

Before you even begin taking the steps towards a complete agile transformation, you need to decide on what agile looks like to you – and get everyone on board. Start from the top down, until everyone understands what the vision of your new agile organization is going to look like, in the ideal endgame.

2. Build your roadmap

This is something you should feel very familiar with! A good PM never dives into anything without a plan, which is why you need to build your plan for getting from where you are to where you want to be.

3. Establish lines of communication

When you’re disrupting the way your company operates, the first thing that can go wrong is for communications to break down. Communication within agile is transparent, regular, and comes with clear systems. Implementing that as early as possible will help your teams to adopt the right mindset for agile, and make the overall transformation process much smoother.

4. Iterate

Check-in with all teams affected by the transformation at regular intervals, and don’t be afraid to adapt and adjust your plan. After all, that’s what agile is all about.

5. Predict and measure impact on business objectives

Don’t wait until you’ve ‘completed’ your digital transformation to measure the impact on your business objectives. You can adjust these predictions as you move along your roadmap, and see the real-time impact.

The Role of the Product Manager in Agile Development

So now you might be asking yourself, “what does a product manager do in agile?”

Firstly, the product manager is the owner of the product vision, which is absolutely key in agile. When you’ve got teams working concurrently towards the same goal, the main things that can derail development is a lack of a strong product vision.

During agile development, you’re all trying to get from A to B. A being no product at all, and B being a great product which fulfils the vision. Throughout the journey, you may take different routes and unexpected detours, but as long as your vision for the destination remains solid, you’ll all find your way there.

Product Manager vs Product Owner

Thanks to agile, a new title within product management arose; product owner. But how does it differ from a PM?

A product owner is agile’s answer to the product manager. A product owner is more specifically found within the Scrum framework. A typical product manager touches almost all aspects of digital product development, and the role is incredibly varied depending on the company, the product, the size of the team, and the specific skill set of a particular product manager. (Eg, a product manager with a technical background will likely spend more time with the engineers.)

However, a product owner has a more defined role, especially within a company that uses Scrum as a framework. (We’ll get into Scrum in a second!)

Within agile, a product owner completes a certain list of tasks, such as defining the product, translating user problems into user stories, and managing the product backlog.

Can a product manager transition to product owner? Of course! It’ll naturally depend on what kind of PM experience you’ve had in the past, and how that aligns with the job that you’re applying for. The two roles use very similar skills and their tasks overlap enormously. Product management roles are subject to change and constantly in flux.

Check out our in-depth look at What Is a Product Owner?

The Skills Needed to Be an Agile Product Manager

Product managers can have varied skill sets. Each product, team, company and industry benefits from different things, so there is no one way to be a product manager.

There is of course a broad set of skills that any PM needs to succeed, such as great communication skills, technical knowledge, creative thinking, analytic skills, empathy, etc.

In addition to the typical skill set, agile product managers should always stay up to date on the latest trends in agile. New frameworks and methodologies are popping up all the time, and knowing how others are successfully implementing the twelve principles can inspire you to make positive adjustments to your own practices.

Check out our interview on Tactical Agile Executions with Nike’s Principal Director of Product

Defining a Product in Agile

Defining a product is one of the cornerstones of successful agile product development, particularly when using Scrum. It’s deceptively easy to get wrong, which can cause huge problems later down the road.

It’s important that everyone knows what ‘Done’ looks like. If you’re using Scrum as a framework, your team’s goal is to produce increments that can be defined as ‘Done.’ So you need to figure out what that looks like for your increments/features/complete product. 

You also need to define your increment/feature/product based on what value it is designed to provide. Ask yourself not just what value you’re aiming to provide, but how you’ll measure how well you achieve that, and how you’ll validate your assumptions.

The definition of a product (as well as your definitions of ‘Done’ and value) will constantly be subject to change. Shifting circumstances means that the definition of your product may often need tweaking, so be open to change. Embrace it as an opportunity to build something better!

Agile Product Development for Global Distributed Teams

One of the things that agile reinforces, is the importance of frequent face-to-face communication. So it’s normal to struggle to see how agile can lend itself to a remote work environment.

While working remotely isn’t ideal, and many product people are excited to get back into the office at least partially, it isn’t impossible to build digital products from home.

Keeping up frequent communication is important, but with Zoom fatigue being a major contributing factor to burnout, it’s important to make sure you’re not having meetings for the sake of having meetings. Make sure each Zoom call adds something that couldn’t have ‘just been an email.’

Check out this talk on Remote Product Management, by Amazon’s Product Lead

Part of being an agile PM is having great relationships with your teams, and when working in a remote setting you’ll need even more empathy than usual. (If that’s even possible!) Situations may be different across the world, and you’ll need to actively create safe spaces for teams, making sure they both understand what’s going on and that their problems are understood.

Remote work tools have made online collaboration easier than ever before, and there’s nothing about agile practices that says you’re doomed to fail if you attempt agile development from home.

Choosing Tools for Agile

Before you even begin work, you need to choose the right agile tools. There are plenty of shiny new tools out there that are brilliantly suited for agile product development. Unfortunately, that means there can be too many to choose from. When you’ve got 10 feasible roadmapping tools, how do you choose the right one?

There are a few things you can look at:

  1. Price. Obviously, a huge corporation won’t need to base its tool choices on the price tag as much as a smaller startup, but it’s often the first consideration for all companies.

  2. Functionality. Does it do everything you need it to do? Can you make life easier by having one tool that does three things, rather than three separate tools?

  3. Customer support. If there’s a tool that you would rely on fairly heavily (as in, everybody takes the morning off if this thing goes down) you’ll want something that comes with excellent customer service to get you back up and running again.

  4. Accessibility. Is this something that all of your teams who need it will be able to use? Eg, if you have product marketers who need access to data, but they’re not data scientists, maybe a tool that’s more user-friendly would be a better fit than one that’s pure SQL.

Another thing to note about choosing tools is to try to avoid switching to new tools unless necessary. It can be quite disruptive for teams to constantly have to get used to new tools, which will only slow them down. Your tool stack should provide stability as well as empower your teams with everything they need. Making solid tool choices early on is a wise investment.

How to Learn More About Agile

Zoom Learn GIF by Young UN

Agile can feel overwhelming at times. Since its conception in 2001, the tech world has had an agile frenzy, with new books, frameworks, courses, and tools coming out every week.

If this is your first foray into agile product development, we’ve cut through the noise and come up with our list of the absolute must-see resources to get you started:

Updated: January 24, 2024

Subscribe to The Product Blog

Discover Where Product is Heading Next

Share this post

By sharing your email, you agree to our Privacy Policy and Terms of Service