Product Manager as Team Members

There is that aspect of agile approaches that emphasizes the "whole team". For more details see here, here, here, here, and here. In my opinion this includes every person that works towards a deliverable of your project. Other people may call that a cross functional team since it not only includes the developers but other professionals as well.

So you may also need subject matter experts (SME's) for different areas. Maybe your application is extremely sensitive to security. Then you may want to include a security expert. Or your system might need to process a lot of data in which case you may want to include a performance expert. Or your system needs to interact with that old mainframe application in which case you want to include a person who is sufficiently familiar with that. In all these cases you may want to add the person full time or part time on an as-needed basis.

One of the most important people on such a team is the subject matter expert (SME) for the business side of the application. E.g. for a hotel reservation system you would want to have a person on the team who is familiar with that industry.

In some companies that domain expert is equal to the product manager. OK, I'm simplifying here a bit. But stay with me as the simplification is for illustration purposes only.

So with the above mentioned concept of the "whole team" you'd assume that this product manager is part of your team as well.

Well, just until a few weeks ago I would have said yes.

In the meantime I have come to the conclusion that I have to qualify this answer. And here is the reason.

To some degree, the product manager is part of the team in that she provides the input that is required from a product perspective for example the business side of the software.

But then, the product manager is also a customer. Do we treat customers the same way as we would treat our fellow colleagues?

Sure, it definitely would be nice and desirable if the relation would be just the same. We could have Friday afternoon drinks and have all the fun by telling all the war stories from the week. But wait! Is this really what you want?

Here is something to think about: Your customer is the one with the money (or budget). So here is something that is different. Your customer wants to spend money only on items that make sense to her. Your customer doesn't want to hear about that database problem that you encountered this week because it might actually mean - in her perspective - that the project is at risk, and all the sudden this anecdote, shared over a beer on Friday, takes on a life on its own.

Does this indicate a failure of the process? Does this mean you should exclude your customer from the team? I think that would go too far.

I think, based on my experience over the last 12 months, the customer (e.g. your product manager) is probably the most valuable person on the team. That means that person needs special treatment. Does that mean you should say "yes" to everything? No, it doesn't. Does it mean that the customer gets her way all the time? No, it doesn't.

So what does it mean? It means that you can still share most of the information with your product manager that you would share with your other team members as well. But it might mean that you rethink the way how you represent things.

Depending how you communicate with the product manager you craft her perception of you and your team. Say the same things, but say them in such a way that considers how you may influence perception. Don't walk on egg shells either. You still need to be self-confident, and that means for each conversation it is good if you have prepared a view. Don't go into a meeting without a view.

I have changed my model for how I look at internal customers in that I try to provide to them the same service I would provide to external customers. Although there is no written contract, a product manager (or any other business domain expert) is a customer to you, and the way you treat your customer will have a huge impact on the outcome of your projects. Work for your customer, work with your customer, come with solutions instead of problems, and ultimately make your customer happy.

Can Agile Keep You From Being Successful?

It certainly depends on what kind of career you are looking for. But sometimes if you want to become a leader you may find that being an expert on a non-leadership subject can actually keep you from being successful.

Some authors - I don't want to give reference here since I was looking at German authors - use a model that takes different thinking styles as a starting point. The knowledge focused thinker tries to become and stay an expert on a particular subject. And a person that is an expert may even have the fear that someone comes along who is an even better expert. So they frantically work on become and staying the "best". They may start to defend their beliefs and knowledge, ultimately coming across as defensive, academic, or even arrogant. Non of these perception will help if you want to become an agile leader.

As a leader you are still a subject matter expert. However, instead of being an expert on Crystal, Scrum, XP, or the like, you become an expert on agile leadership. You can delegate the agile practices to people in your team. After all: If you have coached your team over an extended period of time there should be more than enough methodology champions in your team anyways.

So you can let go without losing influence. You are no more under the pressure to create the perfect implementation of Scrum or XP regardless of what "perfect implementation" means. If XP or Scrum doesn't work perfectly it is not you who has failed. The team as such has not yet managed to adopt and adapt it sufficiently. Depersonalize the particular area from yourself.

A question that might help you to make this change towards re-inventing yourself could be: How do you define success? Is it to get pair programming rolled out through-out the organization? Or is it something different? Maybe you want to provide the best possible service to you customers. Maybe you no longer think in terms of black and white, right or wrong, works or doesn't work. Maybe you want to introduce a third category saying: it helps.

Bottom line: To make the shift towards an agile leader you might actually have to let go of trying to be an expert on an agile methodology to be successful!