When it comes to finishing products on time, agile projects are twice as likely to succeed. That fact will only become more impressive when you consider that the agile framework values quality over velocity and change over rigidity.
Investing in agile product management is worthwhile, but some may be confused on what it means to be agile.
This confusion leads to teams simply mimicking “agile” processes, instead of developing systems that create an agile environment of collaboration, innovation, and customer-centric thinking.
Just because a team says they’re agile doesn’t mean they actually are. Given our experience with building, running, and coaching agile product teams, we’d like to set a few things straight.
In this post, we’re going to explain the differences between a product manager vs. a product owner, agile product management vs. traditional project management, and cover our eight tips on being a good agile product manager.
But first, let’s talk about what it means to be agile.
What Does It Mean to be Agile?
Agile methodology is a set of values and principles outlined in the 2001 manifesto by (and for) software developers.
Now you might be thinking, what do a bunch of disgruntled developers who wrote an entire manifesto inspired by their lackluster experiences in software development have to do with you and your product development and design team?
It’s simple – the writers of the agile manifesto sought to change how products were developed.
They wanted software development to be more customer-centric. These writers concluded that focusing on the customer throughout the entire product development process would lead to better results.
This may seem like a straightforward thing, and you might be wondering why so many articles and think-pieces have been written to either discredit or promote agile methodologies.
The truth is, being agile is simple in the abstract, but it becomes challenging to implement throughout an organization and just as hard to figure out at the individual level.
In our experience, getting a product team to truly adopt agile values isn’t a question of logistics or processes, but of shifting minds and hearts.
Don’t get us wrong. There are a lot of tools that get mentioned when teams talk about going agile.
Product teams will talk about frameworks like kanban, scrum, Scaled Agile Framework (SAFEe), or feature driven development (FDD) as well as tools like JIRA, Aha!, Productboard, or Roadmunk. Agile teams that have done their homework will have a visible product backlog and will be able to articulate the vision outlined in their product roadmap.
And while tools (and mechanics) are important, what’s critical is how you use them. There is no set agile tool in and of itself, but there are agile ways to use tools (and non-agile ways to use “agile” tools). Understanding this is foundational to effective agile product management.
Agile vs. Waterfall
It’s sometimes easier to explain agile by explaining its antithesis — the waterfall model. The sequential method, called waterfall, was invented by Winston W Royce in 1970.
Unlike agile’s focus on iteration, the waterfall model is a linear approach to completing projects.
Notice that when we talk about the waterfall method, we’re talking in terms of projects and not products.
This may have worked in the past (debatable), but it showed its weaknesses in software development. The world kept getting faster, and our product development processes weren’t keeping up. That’s what caused the schism, which led to the agile manifesto.
The agile approach is focused on the user and their relationship with the product, whereas the waterfall model is focused on the project itself.
Any product strategy a waterfall team may have is built around finishing the project on time, with the finished product being as close to the original idea as soon as possible.
It isn’t that the waterfall method doesn’t get you a product by the end. It’s just that the waterfall method emphasizes fixed dates and pre-set requirements.
There’s a big difference between the two methods when it comes to how teams operate, as well.
Waterfall-structured teams do not thrive off consistent communication. Team members are encouraged to work independently.
In waterfall, the systems are built to keep change out. The project has been defined; the deadlines set, now it’s time to work.
But in agile, the systems are built to encourage change. When you do this, you need to have open and honest communication between all team members.
A significant philosophical difference between waterfall and agile is their attitude towards building prototypes.
In agile, your product team is continuously building low-fidelity prototypes and using these prototypes to test potential solutions. These tests bring invaluable insights that inform the rest of the process.
In waterfall, you don’t prototype because prototyping is a harbinger for changing course. That’s unfortunate because, in product management, changing course is often the harbinger for greater success.
What is the Role of a Product Manager in Agile?
A product manager is someone who is constantly working with multiple inputs. The product manager gains insights from stakeholders, designers, developers, and of course, users.
We’ve heard product managers described as the “CEO of the product,” but we disagree with that designation. It creates an unhelpful expectation around who makes decisions, as well as the illusion of hierarchical structure on what should be a team.
That’s why we prefer to think of a product manager as a quarterback on a football team.
Product managers are working with various inputs, such as the coaches on the sidelines and their wide receivers and defensive line, to enable everyone to execute plays that adapt and change.
They orchestrate bursts of momentum (i.e. design sprints) and adapt their next steps based on the outcome of the previous play.
Product Manager vs. Product Owner vs. Project Manager vs…
Many people are confused about what a product manager does or doesn’t do and if or when you need one.
The title of “Product Manager” can mean different things at different companies. Someone could be doing the job of a Product Manager but have the title of Project Manager.
Let’s focus on the responsibilities.
A product manager is hyper-focused on the product and the user.
A product owner is a role found in a scrum, like scrum master.
Sprintwell Fun Fact: So much of what we think of as agile is actually scrum. This isn’t us attacking scrum or saying scrum won’t work for you. But by saying to use scrum is to be agile is like saying barking makes you a dog.
A project manager is typically focused more on the project meeting deadlines. He or she will make sure the project is done on time, but that’s no guarantee that consumers will be happy with the end result.
What your organization needs, if your focus is getting superior products out to market, is a product manager who understands what it means to be agile.
8 Things You Should Be Doing as an Agile Product Manager
Product Manager roles have increased by 32% in the past two years.
As the job’s popularity grows, certifications that claim to help you prepare for a future of facilitating design sprints and building products have also increased. Most of these certifications are misguided. To understand agile, you need on-the-job learning, not just a course full of downloadable content.
Here are eight tips that you can use in your current role to become more effective in agile product management.
1. Spend time with users
This is the single biggest piece of advice we can give. You can strive to do all our other steps, but if you’re not spending time with your users, then it’s all for nothing.
Only 45% of product managers are expected to spend time with their users, which is like saying only 45% of airline pilots are expected to attend flight school.
Go talk to your users, observe them, and bring your team along.
2. Make the work visible
You’ll notice plenty of our tips are direct ways of making you and your product team more collaborative and customer-focused.
That’s intentional. That’s why we say make the work visible.
To have meaningful and timely conversations, you need to make as much data as visible as possible.
Here’s a pop quiz for you. Where is your product backlog? Is it visible for every team member?
If we ask a designer to pull up the product backlog for the current design sprint, are they able to do it quickly, or do they have to click through old Trello comments on expired cards?
The right insight at the wrong time is a wasted opportunity.
3. Be ‘product-oriented’ instead of ‘project-oriented’
An agile product management guide is pretty worthless if you can read it and still think you need to be project-focused.
Project management is its own thing and needs to be filed in the part of your brain that’s completely separate from where you file product management.
Here is how different they are.
A product manager who is product-oriented is like a surgeon during an operation. They’re focused on the user, on new information as it becomes available, on working with a team. Their ego is (hopefully) removed from the situation.
A project manager who is project-oriented is like the hospital administrator who is worried that if this surgery goes too long, they’ll have to re-arrange the day’s schedule for the operating room.
Can you imagine what would happen if a surgeon started worrying about scheduling more than the life of the patient? While that seems ridiculous, we do that with critical things at work all the time.
We see plenty of product managers get blinded by the scope of the project. It’s difficult to keep your focus narrow, and the difficulty is evidence that you’re on the right path.
To help you keep the right mindset, we recommend that you . . .
4. Measure what’s happening and adjust appropriately
When product managers are focused on their user (see tip 1), changes are going to occur in product development.
A good product manager takes new data and prioritizes it effectively. This includes changes to the product backlog and roadmap.
5. Avoid the build trap
Getting caught in the build trap means you’re focusing more on shipping products than solving problems.
It’s anti-agile. When your team is in this mindset, they think the product creates the solutions.
Here’s what we mean. Let’s say your current product is at the end of its lifecycle, and you’re scrambling to revive your catalog.
Instead of using the agile product design and development process we’ve been mentioning, you take ideas from an exec brainstorm and build three products per their requirements.
And everyone hopes these products will save your organization, or at least give it enough life to endure another product design process.
The problem is you don’t know whether or not what you’re designing will work or register with your audience.
Avoid the build trap by improving your time-to-learn, instead of dwelling on your time-to-market.
6. Stay agile, especially with your remote teams
Did you know remote workers fill 29.2% of IT jobs?
How can you stay agile, which values face to face conversations, in the era of remote work?
First, you should know by now that there aren’t any easy outs. You need to make sure your remote teams are kept in the loop during the agile design process.
If any part of your team is remote, you need to practice instilling agile values that work with technology, so as to not to fall on older managing styles. It’s sometimes easier to go back to the waterfall model when you’re dealing with a team member through email.
We recommend leveraging features that specifically break down the barriers for remote work. Small things like making sure everyone has a headshot on Slack and Asana or whatever software you use can also go a long way. We make sure that videos are on by default during our zoom calls. Align on decision making by using a decision journal.
7. Stay focused on the customer, not internal politics
Sadly (very sadly), 30% of product managers said internal politics took up most of their time at work.
A product manager needs to be focused on what matters. Sometimes we’ll see an organization rely heavily on their product managers for tasks that have nothing to do with the design and development process of new products.
Maybe it’s because product managers, by their nature, are great communicators and empathizers. Maybe it’s because the company doesn’t want to pay for other jobs, like a Human Resources manager or career coaches.
Whatever the reason, it’s a costly mistake. Anything that distracts your product team from creating superior products will just cost you more in the long run.
8. Have a basic understanding of how technology works
Generally, we recommend your product team is structured as such: one product manager for every five developers and one designer for every five to ten developers.
These are rough estimates and can change depending on your product (the more technical the product, generally, the more developers you’ll need but not necessarily more product managers).
All of that is to say product managers will be spending a good amount of their time talking to developers.
Yet, only 5% of product managers know how to code.
Now we’re not saying you need to know how to code to be a good product manager, but you do need to have an understanding of how the technology works and what the technology’s limits mean for the consumer.
If there’s a language barrier between the product manager and their dev team, this will lead to costly mistakes that slow down the product design and dev process. Building trust is critical. And trust comes not just from knowing a few tricks about technology, but from having real conversations.
The product manager can’t rely on a “second in command” as a crutch that will explain concepts to them, like a translator between parties. A product manager needs to be able to talk directly to a developer and offer critical feedback and specific, pointed insight.
If you do want to learn how to code, we aren’t going to stop you. Learning to code is learning another language, and learning another language teaches you to think outside of previously held notions.
Luckily, there is so much free material online that will help you understand the basics of coding. You can use Freecodecamp, Codeschool, Treehouse, or Udemy (just to name a few) and learn at your own pace.
But the most beneficial thing you can do is ask questions and learn so that you build trust with your team.
Conclusion
We know agile product management can seem daunting.
Don’t forget that most of the key terms you probably recognize are not really agile terms, but mechanics or tools branded by companies who want to be associated with agile values and agile principles.
What it means to be agile can be found on a simple (and kind of visually unappealing) manifesto written by software developers.
Understanding effective agile product management is a much more involved conversation that puts theory into practice, so you can deliver customer-focused, economically viable, and profitable products.
Sprintwell is here to help you have that conversation.