Product Ownership in an Agile Environment

4 Dec

The technology group at Fortigent is currently undergoing some reorganization around a new group of ‘product owners’ for the various software solutions and initiatives we are working on.

In software development, the product owner’s typical responsibilities revolve around setting overall direction and ensuring that all stakeholder’s needs are addressed.  This usually involves building up requirements and setting priorities between competing features and  internal design enhancements.

But product ownership in an agile environment can be different from what people are typically accustomed to. In this system, which emphasizes rapid response to change and communication, you need to set up an iterative development cycle, with robust communication between groups, and mostly get out of the way.

It’s your job, in many ways, to simply foster the right culture. In many respects, the product is collectively ‘owned’ rather than a traditional top-down dictatorial waterfall approach.

In that vein I will layout what, in my opinion, are three most important duties of the agile product owner:


Individuals and interactions over process… Customer collaboration over contract negotiation.  This is the agile manifesto.  It’s not good enough to say ‘we gave you what you asked for’ anymore. Agile development is iterative, with constant feedback loops.  You must know as early as you can when something isn’t going the right direction. You do this with demos. You do it with conversations… phone calls… meetings.

This communication is NOT uni-directional.  It’s not just stakeholders feeding their wants and needs into engineers.  Engineers feed wants, needs and ideas to stakeholders also.  The best software comes from constant communication between these groups. Get the groups together. Encourage them to talk.  Don’t say ‘I’ll talk to Dan and get back to you’.  Instead, say ‘why don’t you go ask Dan about that’ or ‘let’s call Dan over and talk about it’. The better the engineers understand the business, and the better the business understands the engineers, the better the product.


You’ve got to be able to respond to change in an agile environment and prioritization is a constant battle. You need to have a sense of what’s most important, knowing that priorities will change and change often. Don’t get too caught up in the details.  Pick something to work on next and move on.  No one will lose any sleep if you work on A and then B… when it should have been B first. Don’t over-plan… If you trying to plan out all the way to Z you are, quite literally, wasting everyone’s time.

Recognize when engineers are going down what we call a ‘rabbit hole’… taking on a purely technical change that has no business value that takes too much time. Sometimes you have to do those things and make those choices, but sometimes you’ve bitten off more than you could chew.  These are typically difficult decisions to make.  See if you can make these changes incrementally, spreading them over multiple iterations. Involve people in the decisions. Give the business a list and say ‘one feature needs to go’ and figure out what that is. Tell the engineers when something must be released at the end of the month and they need to cut some corners. Let them figure out what can be simplified.


This is one thing the Agile Manifesto doesn’t really address when, to me, the whole business of software development is about ideas. Finding clever solutions to difficult problems. Coming up with a new way to do things that no one thought of before. It’s about creativity. Who wants to sell the same thing three other companies are selling? The name of the game is innovation.

As important as it is to listen to your stakeholders, however, they shouldn’t design your product. Sometimes the clients don’t know what they want until you show it to them. Bring your own ideas to the table, listen to your engineers and anyone else in the room. What more could the product be above and beyond what everyone has accepted as ‘the product’? Encourage this kind of thinking in the group. Don’t bring solutions to the group, bring problems. Get feedback from your end users and read it. If one thing doesn’t work, try something else.

Above all else, don’t stand still… you’ve got to move, man!  That’s what agile is all about!

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: