Product Owners in Enterprise

A former colleague of mine, David Farquhar, recently asked me for my thoughts on a problem he’s been thinking about; How do you structure the Product Owner function where you have a large application and a large number of enterprise size customers?

Here’s what I’ve come up with.

First things first

Developers* and customers**. That is what this is all about.

  • Getting developers to build the right thing
  • So that customers get some value out of it
  • All other roles support these two groups of people, including the Product Owner.

* anyone actually creating parts of the product, not just programmers

**anyone actually using it, not the infrastructure manager or the IT department etc

Agile is for everyone

Not just for developers or technology teams, when done properly it allows customers to genuinely influence the product they use  by closely guiding developers in small steps.  An agile team is cross functional with all the people needed to make the product successful.

Product Owners exist to do two things

(1) Get feedback and insight from customers (2) in order to inform development decisions made direct with the developers, both from “what should we do next” and a “what exactly did you mean when you asked for this” point of view.


But how can you manage the role of the PO in an environment where your application is too big, you have loads of large clients and too much to plan ?

Now some general advice

Apply Agile to organisational change and not just product development.

Remember, Agile is an approach, not a rule book, think about the core tenants of agile and try to embody them in every decision and every facet of your organisational structure.

DO NOT, I repeat, DO NOT big bang this change, and certainly don’t bring in a consultancy to magic up some new-fangled way of doing things and launch it in a “tada” moment to your team, any team worth having will not take this well and the new-fangled way will inevitably not take into account the practicalities of the problem.  A powerpoint does not a good organisation make.

Instead use the agile process and retrospectives; look at the options available and pick the ones most likely to help. Make small changes, review their successes and failures and keep tweaking.  Have the courage to empower the team, not to try changing everything at once, it will feel like going slower but in the long run it will pay off.

One size can not fit all

There is no setup or structure that will answer every situation, look at other organisation and how they deal with this and use what might work for you, but don’t expect to be able to copy anyone outright or for the answer to be presented as an ideal solution in a book, by some genius or even in a blog post.

You have a large product and large customer base, that’s going to mean you are less efficient than a smaller product with a smaller or more homogenise customer base.

Sorry, but you are going to have to expect to pay for your success here, not to say that you can’t make things better you can, just don’t expect everything to be right first time.  The sooner you start seeing a little back and forth as necessary and valuable the better.  If of course it’s all back and no forth, then you have a problem.

Finally I’m making some assumptions

That your product and it’s development teams are reasonably agile already and your PO function is not keeping pace.  By that I mean that you have development team is responsible for vertically sliced functional parts of the product offering, if you are still organised by discipline rather than using cross functional teams then may I politely suggest you return to chapter one!

Likewise if you don’t have a clean and painless way of deploying your application then how can you possibly expect to iterate based on timely customer feedback, you are probably engaged in water-scrum, having sprints but still keeping releases to a minimum as they are expensive and risky. Again if this is you then fix that first, or at least gently at the same time.

And finally that you cannot or have already tried to break your application down into smaller applications so that it’s easier to manage? This would make things much simpler, you might be able to apply a more standard view of agile to your applications if they were smaller, and avoid having to answer the difficult question we are talking about, worth trying if you have not already.

Expecting your PO function to cover up for out of mode business models or technology is not acceptable and sooner or later your customers will find someone who can do better.

So what could you consider?

Identify Reference Customers

Some customers will actively drive you forward, demanding change and improvement; these are the guys at the foothills of the technology adoption curve.  Other customers will sit back and either take whatever upgrades you offer them or (worse) not bother and stick with whatever they are getting by on.  If customers are not bothering to upgrade either you have a serious problem with your product roadmap or they are not early adopters.

Once you’ve identified a few key reference customers that you can work with to shape the future of the product you are in a slightly simpler world, you now only (generally speaking) have to worry about the opinions of these customers, and given that they are early adopters they should be screaming at you to go faster and get better.

So give them what they want, get them close to your development team, maybe send some of the team to work on the customers office one particular new features, with whatever support from non-developers in your organisation to make this work that’s scrummaster and product owner type people.

Find some way of getting these new features out to the customer’s production environment really fast, and iterate, improving the product for them.  This is not professional services, this is product development.  If you’ve picked the right reference customers then you can flow these golden nugget requirements out to your mid and late adopter customers, knowing that the reference customers love it, and using them as case studies to support the upgrade.

Once you have your developers with directly with customers working you’ll need a couple of things happening

  • Some way of getting the stuff developed by the developers who are working with the reference customers back together and ready for other customers, might mean merging, might have an element of reengineering
  • Some overarching function that continually reviews the work with the reference customers and the world of customers beyond them to ensure that you have the right mix of reference customers; you can’t expect the non-reference customers to stop contributing after all and the reference customer group must be balanced.

If of course you find that you can’t identify a small subset of customers that can be used as a reference for the rest I have bad news for you, you are not working on a single product, but many products in the same code base; Yikes! What mess! Rehashing your PO roles isn’t going to help you.

Split up the Product Owner role into a number of roles

Danger Will Robinson! The principle role of a PO is to be able to make informed decisions, if you carve up the role to the extent that no decision can be made without invoking a committee you have failed.

What you could consider a product facing role (or roles) that provide people on the ground in the development team(s) responsible for what those guys deliver, they have to have the responsibility and be dedicated to the development team or teams.

Then couple the product facing role with some customer facing type roles for gathering feedback from customers and channelling it through to the in team analysts.

You’d probably want a couple of high level roles in this organisation, one concerned with the overall vision for the product, who does a bit of both but lets the other people get on with it and another scrummaster type role that looks after the people and is a catalyst for change and improvement.

Crucially if that is to work the Analysts need to be dedicated to development teams working side by side to deliver the improvements to the customers, not ahead of them, not in a separate team downstairs and not behind.

In Conclusion

There is no real conclusion, I hope this helps or was at least interesting to read.  Let me know what you think!

And Finally

I found some interesting articles on Product Owner teams that go into more detail, I don’t necessarily agree completely with all the points in these articles, but they provide an interesting discussion.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: