Alex is a product manager at Rally Software. He was a developer, architect, agile coach, and thoughtworker before his current role. His diverse background and experience gives him great perspective on product management issues and the implications for the whole team. Alex is also a pleasure to talk to. He will present ‘Product Owner’s Guide to Saying No’ at the 2010 Agile Roots. I hope you enjoy.

Alex, we met last year at Agile Roots, where you gave one of the talks I got the most out of, but take a minute to tell everyone about your background in the software development process and Agile.

I’ve been doing agile development for almost 10 years. I had been been doing ad-hoc development before that. I stumbled upon XP, and had great results on a couple of projects. I was telling anyone who would listen all about Agile development, so I started coaching independently. I spent some time at Thoughtworks working with a few giant companies, and then switched to Rally where I coached a much broader variety of businesses. I had a chance to move into a Product Owner role, and I really wanted a break from travel, so I jumped on it, and that’s where I’ve been for the last 4 years.

Last year, you gave a presentation on facilitating a product council. My personal experience has led me to believe that product owners have one of the most difficult and least defined roles in the software process. (perhaps it is difficult because it is less defined) The Agile community has strong ideas about technical best practices, and how the product owner interacts with the technical teams, but the actual best practice for guiding projects and prioritizing features are somewhat immature in my opinion. Do you agree or disagree with that?

I think it’s because product management is extremely context-dependent – the activities are highly variable depending on your customers, your market, and your product. Also, it’s a communication activity more than it is a production activity. I very rarely sit down and “do product management” the way a developer would sit down and write code. When I do sit down and write out acceptance criteria for a story, it doesn’t matter that much whether I write them in a consistent way. But as a developer, how you write your code really matters.

There are some good basic tools for prioritization. Most people can prioritize a backlog into Must Have/Should Have/Nice to Have buckets, but no two people are going to do it exactly alike. Most companies rely heavily on the intuition of the product owner to do this right.

In “Agile Estimating and Planning”, Mike Cohn introduces some helpful techniques, like Kano analysis, that can help. Luke Hohmann has a ton of great Innovation Games for aggregating the intuition of your customers and stakeholders. Both of these approaches involve adding some structure to your intuition.

At Rally, many of us have been reading Don Reinertsen’s “Principles of Product Development Flow”, and we actually had him come in and work directly with us. Reinertsen is a strong proponent of developing an economic model that allows you to calculate the rough cost of delay associated with not doing a feature, and prioritizing the items with the greatest cost of delay first, and this is something we’ve been exploring.

I’m not sure there’s a silver bullet for prioritization. The tools for structured intuition seem to be most helpful when you’re launching a product and trying to figure out where to focus. We launched my product years ago, so we have a different set of challenges. I would say the most important thing is to have a clear vision based on the needs of focused market you’re going after.

Where do you find ideas or inspiration for improving your own process?

I used to spend a lot of time reading and on mailing lists trying to stay on the cutting edge. But in my role, making process changes generally involve convincing the team. So lately I’m focused on helping the team dig to root causes when we have struggles or production issues. If you go deep enough looking for root causes the solution often presents itself.

Are you excited by any progressive ideas in this space?

I’m still excited about kanban. I think Reinertsen’s book got me really focused on limiting work-in-process as a way to speed cycle time and increase throughput. We’re using kanban at the portfolio level (for product planning), at the team level (shipping features) and at the scrum-of-scrums level (managing multi-team issues, process change, and the like).

It is really hard to get all of your non-development work into the kanbans. In a growing company, almost everyone has a bunch of side projects they’re working on very slowly when they get a chance. If you can make those visible and manage the WIP, things go so much faster.

This might be my bias because of what I have done so far in my career, but I feel like there is much less of a reinforcing community of practice for product owners than there is for developers. If you think that is true, why is it true, and if you don’t, where can people go to get involved? How do you know if you are doing a good job?

At Rally, we have a great team of product owners and we work really well together, so we haven’t needed to reach outside the business a lot for support. But I think a lot of product managers bounce around like pinballs from customers to stakeholders to the dev teams. The role is really focused on being an information conduit, transmitting information from one person to another. Today at work I spent every single hour interacting with other people, moving information around. So sharing information and discussing outside of work is not my first priority when I head home.

Are your customers buying your product? Are they renewing subscriptions? Are they saying good things to their friends about your product? At Rally, our revenue is almost 10x what it was when I started as a product owner, so I suppose that’s good, but there are a lot of other factors involved. It is really hard to tell whether a product owner is doing a good job. It takes a long time to see whether your prioritization bets pay off in the marketplace. I like to say that I won’t really know whether I’ve done a good job until 2015.

If someone was just starting out as a product manager, what advice would you give them?

First, know where you are in the product lifecycle. Jared Spool talks about 4 stages of product development. In Stage 1, you’re in a new market, where the technology is worth the pain, so your early adopter customers will tolerate rough edges in order to get the benefits. In Stage 2, you’re building out features in order to compete line-by-line. In Stage 3, products have become bloated and you need to focus on the experience and simplifying. In Stage 4, you’re supporting a commodity, so you need to focus on scale and efficiency.

As a product manager, you need to behave appropriately for the stage you’re in, and slightly anticipate shifts. If you keep building out features when you should be simplifying, you’ll start losing users very fast. This transition can be hard to make; if you’ve been adding features for years, and had success with that, it can be tempting to just continue the way you’ve been going.

Second, it’s easier to start things than to finish things. Sometimes you can ship a feature with just the stories you’re sure about, knowing it will satisfy half of the target users but the other half will demand a few more stories. This is not necessarily a bad strategy if you circle back and finish the lower-priority stories once you get feedback.

But compared to the next big feature, the last few stories often don’t feel that important. It’s really easy to move on. Agile invites you to constantly re-prioritize your backlog, but just because you can, doesn’t mean you should.

There’s another important recommendation I have, but I’m saving that for the talk.

Thanks Alex, looking forward to it…

Join Alex at Agile Roots