Product Managers: Agile Is Great, But Don’t Forget to Collaborate

When I started my career in software product management, Waterfall was the prevailing development methodology. In a Waterfall system, the scope and end state were envisioned at the beginning and the project wouldn’t be complete until that entire scope was achieved. Often, it would be a long arc from requirements to delivery. That had two big pitfalls: First, the market might have evolved and what you were delivering no longer hit the sweet spot; and second, substantial  resources were invested before you ever got a market reaction.

On the plus side, Waterfall usually accommodated functional core teams in the development process – product marketing, development, customer service, operations, sales and marketing. Teams would meet at least on a weekly basis to share in detail progress on the project, providing a global view of what was being built, how it would be sold and to who, and how it would be supported. These conversations often uncovered unexpected impacts to downstream teams and partners that could be mitigated pre-launch.

The whole notion of Agile development, the prevailing methodology today, is to develop capability in smaller increments, see how it does in the market, and iterate. There’s a lot that’s good about it, but the core team and the close, cross-functional collaboration that it fosters, is not nearly as prevalent. And, while the agile process may be faster for it, it can result in products and features that do not return the investment. Taking the time to bring the broader team into evaluating the success and re-calibrating future direction could lead to better outcomes.

Agile Insularity?

What allows Agile teams to move so quickly is that they are highly focused and work in close, daily contact via scrums, and they’re in charge of their own time and resources. However, that structure and cadence precludes regular participation outside of the product management and the development teams.

That can lead to problems, both big and small. Here’s a simple example: a feature name was changed by the product team and it was only in passing that marketing found out. The problem? Marketing communications were already using the original feature name. Marketing adjusted, but it caused unnecessary rework and churn across a number of teams, which is never a good thing. What stood out for me was that it was only by chance that the disconnect was discovered. That cross-functional collaborative muscle had atrophied.

Product management might know the customer better than anybody else, but there are a myriad of other teams that participate in delivering the product. Building something customer friendly that meets a real need is obviously critical. But other parts of the organization have to market, sell and service what product puts out, and their thinking needs to be included. If it isn’t, then you might very well build something cool, but it may not get any traction because it’s too hard to explain, sell, use or support.

The feature name example above is a simple one, but what happens when the investment in a product continues though low rates of adoption would suggest that good money (and time) is being thrown after bad?  Should the organization continue down this path? That would be a good question for the broader team.

Speed, But Not Flexibility

We’re getting the speed to market that Agile promises, but the approach can be disjointed. And we’re often not taking advantage of the flexibility to make the necessary adjustments that Agile is supposed to offer.

I’m not advocating a return to Waterfall. Getting cross-functional alignment  was a challenge in that world too, but it’s even harder when you’re moving at Agile pace. But we do need to balance our approach to Agile, starting with re-establishing regular, working collaboration between product management and development and other functional teams. Here are some other best practices that help:

1. Treat data as agile.

We have more and better access to data about product effectiveness and how much things are getting used than ever, but it’s coming into play too late. If you’re building a capability that’s going to take three iterations, you might put the first one out and be building the third one by the time you have the data to know if the first iteration is even working. By then you’re already pretty far down the path and may already be off course.

2. Hold teams accountable to KPIs.

Make sure the whole cross functional team is aware of the KPIs for the project and holding each other accountable. There’s always more backlog to build than you have time for, so instead of continuing to invest when KPIs aren’t being met, look at the bigger picture, because there may be other opportunities you’re not resourcing that maybe you should.

3. Build in regular checkpoints.

A strategy can sound great on paper, but what you think is going to work and what works aren’t necessarily the same thing. Get the teams together on a regular basis to review results from all the different angles of the customer experience.

4. Candidly evaluate success.

The tendency is always to give it a little more time, try to fix it, or invest a bit more. Things can sit for a long time before someone finally says, okay, we’re wasting our time. With more stakeholders involved and regular conversations about success you could get to that understanding a lot quicker, incorporate your learnings/cut losses and move on.

5. Consider slowing down.

Bigger organizations are now pushing out moderate to substantial releases on a quarterly basis. A lot of smaller organizations try to go out monthly, biweekly, or even weekly. It’s insane. Most customers cannot absorb and adopt at that pace. Sometimes, doing less, and taking more time to do it, can pay dividends, both in the quality of the product itself and how it gets built.

As I reflect back on some of my earlier experiences where all the stakeholders were at the table, we’d have conversations that went well beyond the product features and capabilities and development schedule. We would talk about how we were going to get it in front of people, and get them to understand what it would do for them. How we would get them to try it. And if we found we couldn’t clearly convey the value, we would rethink what we were building.

Changes in technology have made it really easy to push out new releases with increasing speed, but with the faster pace, it’s easier than even to iterate at the margin on things that don’t create value. You get momentum and then you’re just going; you’re not really looking left or right, and with Agile, you’re going really, really fast. That’s exactly the goal, and to some extent the rest of the organization may need to catch up to a more Agile methodology. But that’s a whole different conversation, and until they do, it would behoove product managers to leverage the rest of the organization in identifying, building and launching new capabilities.