Have a Customer Advocate in Agile

Agile is all about bringing value to the customer, whether that customer is internal or external. What makes Agile so great is the ability  to change the plan. 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.

Matt Heinz states that:

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.

While I agree with Matt that it’s essential to have a Customer Advocate within the team, I’m not so sure I’m on the same page to say that the developers are the best representative for this. It can work, but I would say that having a definitive person in a role that intimately understands the customer is what matters most.

Agile Customer Advocate Tips

  1. Intimately aware of the customer needs
  2. Is frequently receiving feedback from the customer base
  3. Works closely with the Product Owner
  4. Works closely with the development team as needed

[HT: Heinz Marketing]

11 Replies to “Have a Customer Advocate in Agile”

  1. Point D, “as needed” I really think that the Advocate would be part of the team even when they are not needed. With Dev Teams, they tend to get wrapped up in their own ideas quickly, having the Customer Advocate be a presence all of the time, I think the Teams will feel a better connection to the Advocate and ultimately, the Customer.

    The Customer Advocate is also a great role/model even when not on a development team. As the teams are closer or more connected to the Customer, the better the outcome is going to be for the customer.

    I bet the best example is gaming companies where many of the team members ARE customers, and the team members are always thinking, is this what I would want in my game experience.

  2. We called that role Subject matter expert on our side.
    It was a dedicated role, so we could ensure it was done. Our product owner was a top manager or directly the client in some cases. So the SME was in charge of doing the bridge between the business and the dev team, she was in “the team” was part of the planning, daily meeting and retros and available all time for the team. that person was reponsible of doing some document sot help developers understand (ex: mockup, test cases, scenarios with example, small business analysis) but more important the reference to answer any question comming from the dev team.

    That worked well and let more time to the product owner to decide value while implementation details are managed by someone else. I think that this role could also be played by an architect that also develop in the dev team. The important thing is that the team need a bridge with the product owner so communications are well done and everyone understand the goals and objectives of the value to deliver.

    My 0.02$

      1. It’s already the case anyway, we often see SM doing the PM.

        In fact I seen it in our project, the SME was too busy and the PM played the SME for some time and it worked well because the SM was knowledgeable of the business logic (3 years in this business).

        But after all it’s helping developers get ride of impediments. So whatever it takes do it.

Leave a Reply