How can product teams quickly iterate and implement feedback? How can they change course when they feel they’re going in the wrong direction? Product managers constantly wrestle with these questions, especially if their organization uses traditional methods for scoping work, strategy, and planning.
Overcoming this challenge needs to go beyond what you’re doing. You need to shift your focus to how you’re doing the work. In my interview with Chris Pegg, Director of Product Ownership at GoKart Labs, we discuss the benefits of making agile planning a part of your product strategy.
Interview with Chris Pegg
Can agile planning be at odds with digital product strategy?
Pegg: I think that question is steeped in a myth. It can seem as though agile planning methods are loose or sloppy. Or that they don’t afford teams enough time to think and to make big decisions. Some think this will manifest itself down the road, ending in uncomfortable scenarios like the team screaming for a technical refactor to be able to include a new feature that wasn’t part of their initial decision-making and assumption base. So it’s not uncommon for business and technology perspectives to have that kind of dialogue and debate, but that doesn’t mean they have to be at odds.
How does this seeming conflict affect the digital product development process?
Pegg: The approach, and even format, of product road maps can have profound impacts on the operational methodologies a team can use to create digital experiences. For example, when a team is not fully enabled by their organization to strategize, plan, and execute their work, roadmaps turn out to be extremely inaccurate and end up disappointing all kinds of stakeholders as time goes on. And the team gets frustrated, too, when they run into scenarios that require interdisciplinary collaboration, but they cannot figure out a way to focus on solving problems together.
Ward: Would you say that the effect of this is that it slows down the process or complicates it? What are the business or departmental repercussions?
Pegg: At the end of the line, you’ll hear stakeholders say, “That software doesn’t look anything like the designs that I approved.” You might hear them say, “Why didn’t *my* feature make it into the release?” You might have a conversation where the team is celebrating, “We did all the things you asked us to do,” but yet, the business results haven’t changed in any way, shape, or form.
Can the two be friends and work together?
Pegg: In a lot of ways, the emergence of agile development methods were a response that developers had to be told both what to do, as well as how to do it. Agile methods arrived as an olive branch from technologists back toward business stakeholders to say, “Why don’t you join our team?” It’s based on the assumption that a member who represents business interests has a core, critical role on the team. This gives the design and development team access to an internal stakeholder whenever really important decisions need to be made. So it really is meant to be a method that improves the partnership dynamic between technology and business perspectives.
How will combining agile planning and product strategy affect an organization?
Pegg: There are a lot of positive effects for organizations. There should be more frequent, regular, and granular visibility into the progress that high-investment teams are making. In other words, this is a great way to watch how your investment is growing, and if you don’t feel like it’s growing, you have a way to make changes to your original assumptions.
Generally speaking, the most highly-effective product teams in the world are very collaborative. Agile methods give teams the best environment for high-touch collaboration. In many ways, agile methods actually expect collaboration across the team.
This leads to an outcome-based focus instead of an output-based one. For example, if you had a looming major feature release and were underwhelmed by the response during user testing, agile would allow you to pause and find changes. The team might try another approach like improving the content or positioning, updating a workflow, or even something as simple as renaming a button on a form. Using traditional methods, you’d be incentivized to keep chasing that original solution design, no matter what. So it gives the team a chance to sense and respond based on what actual customers are saying and doing as part of initial access to pre-release versions of software.
Ward: Those are great positives. Are there any negatives that come from incorporating agile and product strategy?
Pegg: It’s definitely an uncomfortable process for people, especially those who are used to making huge high-level plans for large budget and scope projects. The human condition is such that we seek clarity so strongly that, even when it’s not there, we’ll manufacture it. Agile can be seen as a risk to clarity, which makes people feel uncomfortable.
Another challenge is that with agile methods, autonomy is a keyword and that’s a double-edged sword. Agile requires organizations to give teams a degree of autonomy, and then the teams need to reciprocate by demonstrating competency and commitment. The current status quo of power within an organization tends to be reticent to give it up, and it’s no surprise that teams who have historically been discouraged from behaving that way are hesitant to pick up that ball.
What are the benefits for companies?
Pegg: Agile methods are a great diagnostic tool for process improvements. In other words, running with Scrum isn’t going to solve all of your problems. But, it is going to help you point them out sooner than later—maybe even more sharply and painfully than in other models. This is a challenge at first because it’s a great way to see skeletons in the closet. But, ultimately, it’s a benefit.
Your teams will also be operating in a way where, if their behavior is demonstrative of a certain failure of the product outcomes, you can just stop that work. You don’t have to see it all the way through just because you’ve been afforded an allocation in a budget line item. Agility in software and in digital can actually grow to agility in finance, operations, and HR.
It also creates a controlled landscape at your company from an individual employee perspective. There’s now a psychological safety, a shared alignment, and a desire to achieve tasks with a specific outcome. When teams are operating in agile methods, they have the framework, time, space, and protection to be able to make mistakes, incorporate learnings from them, and learn how to avoid them in the future.
Changing how you approach product strategy
Incorporating agile planning into product strategy can benefit your team, product, and organization, but it will be uncomfortable. That’s the nature of change and the challenge product managers face. But, you don’t have to face this challenge alone.
GoKart Labs partners with product managers and organizations to create, implement, and run your operating system using our signature methods combined with change theory and systems thinking. To learn more, contact Nora Guerrera, Managing Director of Consulting at email@example.com.