Agile development has become an increasingly popular means of building product, and for good reason. It’s more of an iterative process, typically allows for faster time to market, and is far more flexible in making mid-project changes based on new insights into customer or market demands.
Unfortunately, the advantage agile development gives an organization can also be one of its biggest weaknesses.
In a more traditional product development cycle, product managers build the plan up front. They start with primary research, developing a deep understanding of what the customer needs, what problem is being solved, and how specifically your product is going to address and resolve that for the customer.
The product manager then typically builds a long-term roadmap for how the product will address a greater scope of that problem long-term, building a specific plan for what the first version of the product will look like.
This plan, if done right, is rooted in what the customer wants. What the customer needs. And although there are trade-offs in the development process (lose some features to ship faster, for example), the foundational “spec” written by the product manager helps keep the intent of the product intact.
This can be true for agile development as well. World-class agile development teams still build a plan up front, still do their primary research, and still start with a strong vision for what they’re building. But the daily trade-offs, additions of features, and constant adjustments to scope and focus make it significantly more difficult to ensure that the final product represents what the customer wants.
Too often, the final product more likely represents what a product team wants. What they determine in their daily scrums would be cool, what they think the customer would like. If the product team is itself rooted in the customer need, these daily insights might still be on target.
But that’s a very big “if.”
As more and more companies shift to an agile development methodology, it’s more important than ever for a customer advocate to be a daily part of that team. It can be the product manager, but there’s no reason it can’t be the development team directly. You’ll be far better off having the people writing the code also understand exactly how the customers think, how they act, and why they’ll buy.
But no matter how you address this challenge, make sure the advantages of agile development don’t disrupt your focus on delivering the outcomes, objectives and success stories your customers want and will pay for.
Sounds like a nifty suggestion in that there needs to be a customer representative on the team. Could be the PO, but would you suggest that it NOT be the PO and be another representative closer to the actual customer?