4 Ways Portfolio Roadmap Views Help Directors Keep the End in Mind
No man—or product—is an island. Everything exists within a larger context and must fit into a bigger picture. But when it comes to product...
What does product leadership look like in an agile context? And, how is it different from leadership in traditional development environments?
For the product leaders supporting agile teams, it can be easy to get caught up in the routine of scrums, sprints, and standups. But, then, big-picture thought leadership takes a backseat to the constant drumbeat of the “little things” that need attention.
With the development team focused on the sprint at hand, you’re on the hook to provide everything they need for the next release. If you’re not careful, you risk spending the majority of your time on tactical work. Too much of this and your role as a strategic leader can fade as your responsibilities for each release cycle grow.
Today we’ll look at some of the key considerations leadership should make in regards to agile product teams. We expand upon this even further in our book, From Product Manager To Product Leader. I highly recommend the read.
One reason organizations love agile is that the amount of autonomy it gives teams. Developers, in particular, tend to have a lot of freedom to dictate the implementation of new features and functionalities themselves. Freed from overly detailed specs that break down every new widget to the pixel, they have the opportunity to take some initiative of their own and influence how things are actually built. We dive deeper into agile product management in the Ultimate Guide to Agile Product Management.
As an agile product leader, it’s important not to stifle this creative environment. It’s also important to recognize and reward the skills, talents, and ideas your technical teams have to offer. A true leader is receptive to new ideas, doles out credit and praise when deserved, and is nimble in their thinking. At the same time, they maintain their position as a thought leader.
Product leaders need to continually and consistently articulate and update the product vision driving development. Regardless of where ideas and innovations begin, it’s the product leader’s job to make sure they fit into the overall plan and to intercede when things are straying from that vision.
When the technical team understands what you’re trying to achieve (both at a big picture and granular level), they’re far more likely to make the right call for the customer and to reach out when they’re unsure of which path to pursue.
Don’t be a bottleneck. To stay agile, technical team members can’t sit around waiting for you to make decisions. They have a schedule to stick to and there’s always a deadline around the corner.
Product leadership in an agile context means being an approachable facilitator, not a standoffish bottleneck. You must respond quickly and thoughtfully to questions and concerns from team members. When a developer has a question, they need it answered promptly so they can continue with their work.
Furthermore, you need to actively promote psychological safety. No comment, question, or idea shall be dismissed. If you’re not seen as welcoming to their inquiries, clarifications, and recommendations, you run the risk of them not saying anything at all. While this might make your day a little easier, you risk technical team members “guessing” how something should work or potential problems not surfacing until post-release, at which point they’re already impacting the customer experience.
In an agile setting, a larger feature may be distributed across multiple sprints. While this may be technically necessary, it can also prevent new functionality from reaching end users for months. To counteract this, product leaders should always keep the customer front-and-center when considering what to work on when.
Break down backlog items into smaller chunks and make sure every sprint includes something for end users. This can help product leaders guarantee they see incremental improvements while the groundwork for larger features is laid.
You are – if nothing else – the voice of the customer. If the customer isn’t seeing any benefit, it’s your job to promptly address that and ensure customer satisfaction and delight are a component of every sprint.
In a waterfall world, releases usually include a new feature, some bug fixes, and improvements to existing functionality. But when you’re running on agile and completing sprints every two, three, or four weeks, you won’t get the same wow factor with each release.
The focus is on constant, incremental improvement. And there will be plenty of releases that aren’t particularly exciting. That’s why you need to ensure stakeholders focus on a big-picture view. Therefore, an effective product leader will share a product roadmap that focuses not on tiny releases but on the overall improvement of the product over time. This is why agile roadmaps and strategy are even MORE important in an agile world when it comes to communicating your vision and progress.
When you’re releasing new functionality once a quarter or so, it’s easy to take a step back for feedback. After a release, you can conduct surveys, evaluate analytics, and recommend improvements based on your findings. Feedback loops give you a platform to demonstrate your leadership and insight by presenting these results and recommendations. They also help your team make decisions.
In an agile setting, the pace is faster. You’re continually tweaking the product. You can certainly run larger, comprehensive studies of what’s working and what’s not. But, there is also a need for constant collection, analysis, and take away action items. Setting up a consistent framework and cadence to learn how each change impacts goals is critical. Not only does this help product leaders maintain their thought leadership in the organization, but also it helps them empower their teams to make better decisions.
If you keep pumping out enhancements but can’t point to their influence on key metrics, how do you know what’s making a difference and what’s superfluous? Help your team establish these feedback loops and empower them to make data-driven decisions about the product.
We all know product leaders wear many hats. But there are a few you want to be sure don’t end up on your noggin,’ because you may never get rid of them. As a “servant leader,” you should support and empower the organization. But that doesn’t mean you’re an ACTUAL servant.
Small, scrappy startup environments often lend themselves to everyone pitching in. But at a certain point in an organization’s lifecycle, everyone’s scope narrows. This is particularly important for product leaders. Often, it’s easy to get caught up with roles outside your main scope.
It may be hard to refrain from picking up extra responsibilities and stepping in when there’s a vacuum to fill. This might make you an essential team player but can hold you back in the future.
As your organization grows and your product leadership responsibilities increase, you need to remain strategic. Otherwise, you risk being pigeonholed as a “tactical” and “execution-oriented” person. And in the future, your organization may bring in someone more “strategic” above you to fulfill a true product leadership position. So don’t forget to set boundaries and limit your non-leadership activities. It is sometimes awkward, but always a necessary step.