What Is Agile Product Management: Guide To Processes & Roles

Monday, September 28, 2020

There’s a lot of content, guides, textbooks, courses, and certifications available on agile product management. 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 that agile takes form in are simple and easy to understand. Yet, the complexity arises through misunderstood expectations, roles, and process.

Through this guide, we’ll:

Understanding these key areas is important. It will provide you with the tools to implement or improve agile product management on 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 of how teams may effectively collaborate to work towards achieving a goal. The original agile manifesto, published in 2001, says it best:

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 their 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’ll get into talking about the practicalities of agile, it’s important to continue to keep the manifesto in mind. Processes, documentation, and planning is all great. However. if you find yourself in a position where you or your team is prioritizing it 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 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?

Effective agile teams are constantly interviewing users for feedback on their products. They’re sending out and processing surveys to drive the prioritization of new feature development. 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 less process, also comes the feeling of a lack of control for many product managers. However, they still have the 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 an approach of being a servant leader, there can be more benefits in the long-term – and ironically 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, however, it 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, understanding that they will become more clear as time progresses.

Lean

Being lean in practice is crucial. A laser-focus on the outcomes keeps agile teams moving forward with little distraction to achieve the goal. With each task, considering 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 Process Flow

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.

Strategy

Great agile development starts with good strategy and alignment. Bringing everyone on the team into a room (or Zoom meeting) for a few days can do wonders to establish a unified vision and direction.

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 starting point for the team to focus from.

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.

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.

Process

Agile is an empowering philosophy to bring teams together towards a common goal in collaborative ways not possible with overly structured processes and reporting.

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

We’ll dive into some of the more popular processes used to manifest the agile philosophy into action.

But first a word on 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 is to say, this is simply a cautionary tale on 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 is a low effort to maintain, 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.

Scrum

Scrum is perhaps the most popular agile process and for good reason: it helps guide the breaking down of commitments and learning to dedicated time blocks of effort, called “sprints.” This encourages a healthy amount of learning and opportunities to pivot 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 to achieve the goal for each sprint. In practice, this means 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:

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

What’s incredibly powerful about this, is 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 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 durations 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 well for your unique organization.

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:

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.

Product Manager

The product manager is responsible for, well, managing the product. Ensuring that everything is aligned to achieve key outcomes based on user testing, team input, and strategic planning is the key responsibility of the product management role.

However, effective product management is about 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 skill set empowers the product manager to be an empathetic and 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.

Responsibilities

Product Owner

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

Generally, the product owner is a core business role that sometimes may be 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.

Responsibilities

A common challenge is the overlap of this and the product manager role. 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 complimentary 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 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 in the product aspect of your development team, they can multiply the team’s success.

Responsibilities

Designer

Similar to how developers shouldn’t be restrained to only writing code, designers' reach on a product team should extend beyond creating 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.

Responsibilities

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.

Responsibilities

Other Roles

While the previously mentioned roles comprise of 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 empower the 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 speciality to the table, while embracing a focus on product as part of each other’s role definition.

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 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 lay 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.

Originally published on The Product Manager on September 28, 2020. This version is the original I submitted. You can read the final published version here.