DevOps - the Product Owner

We seem to be finally waking up to the fact that DevOps is more than a few deployment tools. In my view DevOps is what agile should always have been. Consequently I am getting interested in it again and I thought I'd write these notes about the role of the Product Owner in a DevOps setting.

My experience of product owners is bad enough that I could write a horror film based on it. Or at least a Malcolm Tucker style satire. But the fact that so many people do it badly is just indicating how subtle and difficult the role of the modern product owner is.

Caveat - this is about Product Owners in a business context, making money is the focus. There are other contexts in which you still need Product Owners, I don't have much experience of them and so I won't even pretend to talk about them.

What does a product owner do?

The classic agile definition of what a product owner does is as the onsite customer.

I don't like that definition though. I prefer to think the product owner should be the onsite salesman. The person responsible for selling the product to the customer. I find this useful, when I talk to the PO about stuff I imagine sending her out to the market selling what I'm talking about. It helps me empathise with them and their responses to me.

It's this idea, of the PO taking software to market, of being responsible for selling it, that I think is key to everything they do. If they see themselves like that, they do a better job.

The second important thing about the Product Owner is that they own the product. As a hacker, don't argue with the Product Owner much. They're in charge.

Properties of the Product Owner

It's easy to say "onsite salesman". It doesn't necessarily mean much though, so let me break it down. A Product Owner:

Optionals:

Doing the job

Product Owners need to carry, in their heads, the dissonance between the target vision state and the current state now. That sounds complicated, so I'll explain.

The reason you're building a product is the vision, the end state. But the end state is also quite vague. Product visions are things like:

No specifics there. Clearly, people will start imagining all sorts of things to get to the end state. The important thing is, what can we do now, right this minute, to move us forward?

Likely those things, that we can do right now, take a bit of imagination to link back to the vision. And that's what I mean by dissonance. Sometimes, it might even be that the next thing we want to do, tactically, seems diametrically opposed to where the vision wants to go to. The Product Owner needs to be able to hold onto that and be OK with it, or not OK and able to correct it. Sometimes, we see that tactics start to take us away from the vision. The Product Owner needs to be carrying that understanding of the gap so they can either adjust the vision, or they can adjust the tactics to move back to the original vision.

Developing the vision

Sometimes people come to you with something more vague with a vision and ask you to do something. What can you do?

At one project I worked on the Product Owner spent little time engaging with users and lots of time wire framing his ideas of things that we should do that matched how he wanted the customers to behave. Our CEO spent a lot of time hanging out on the site, watching how people used it and developing ideas about the stuff they told him. Sometimes they were mad, but they were always valid experiments. The moral? The CEO was the real Product Owner. You don't get to be one by just saying you are.

Communicating the vision

Product Owners need to be able to explain what the product is and what it does. Drawings are a great way of communicating, as a Product Owner you should maybe get good at doing sketches about ideas.

Numbers help as well, can you back up your vision with numbers?

I'd go so far to say it doesn't matter what particular numbers you use as long as they explain something about your vision.

Coming up with MVP

The first thing you need on a new project is a Minimum Viable Product. There's a lot of chatter about what this is. Personally I think it's well, the minimum you have to do before you have something you could give to customers.

This seems to be a really hard thing for a lot of people. Most people seem to want to have a finished product before they go live to customers. But that's kind of hard. Software takes a long time to make. The more software you're asked to make the longer it takes.

And if there are incumbents, and there almost always is someone doing something like you want to do, then waiting until you have the perfect match for every feature is just a way to give them more time to beat you.

The thing is, an MVP is not really about making a sale at all. It's just for checking that you're doing the right thing. Are your asking the right questions? Have you made the right assumptions about product placement?

So you need something fast. As fast as possible preferably. And you need something measurable. Something you can release that people can try and see whether they like it or not. If a lot of people try it at least you know you're onto something. Whatever that might be.

As a Product Owner on a new project you probably have a list of stuff from all sorts of people. How can you turn that list into a serious MVP? I think the key to this is to imagine yourself selling it. Take what you're comfortable with and then cut it in half. Can you imagine yourself selling that? Why not? Be honest with yourself about it. If you can cut it in half can you cut it in half again? If you can then can you cut it in half again? Keep going till you have the smallest thing you can't imagine yourself being able to sell it anymore. That's your MVP.

If you can't build your MVP in a reasonable time frame (2 weeks?) then stop your project because it's unlikely you'll get anywhere.

It's a bit like the rule that goes if you can't explain what something is in a sentence then you don't understand it.

Get delivering

If you have a product vision and an idea for an MVP you need to get a development team to realise it.

Getting a DevOps team is probably not the responsibility of the Product Owner, though I've known a few who thought it was their job. I think Product Owner's should take a lively interest in the make up of the dev team, especially the senior members though it's worth bearing in mind that probably the most important thing is to hire critical thinkers, who are not necessarily going to agree with you very much.

There are 3 other concrete things that a Product Owner can do to positively affect delivery:

It's worth expanding on these a little bit. As the owner of the product you can be expected to care passionately about the product. You have to stand up and sell it to the client. You can be demanding.

It's just not good management to use those demands as a way of beating people down. You have to beat people up. Trite, I know. But I'm serious, talking about stretch goals a lot is a good thing, you can temper that with consoling words about how hard it is now but you can let people know where you want to get to.

Developers and Ops people often fear failure. So help them stop fearing failure. Get them to discuss their problems, they nearly always boil down to something you can understand, even if you are not technical: lack of resources, politics, etc... Talking about them exposes them and then you can discuss how to attempt to solve them. Stress on attempt. Failure should be OK. Eventual success is what you're after, even if you fail to solve a problem 20 times.

Keep going, lift people to get there.

Use a process

Unless there are just 2 or 3 of you delivering your product you'll likely want to have some sort of agile process for making sure you do the right things, at least most of the time.

Agile software delivery is full of misinformation and down right shamsters so take care that you test that what you're doing is working and is not too heavyweight.

Here's a silly guideline list for processes:

Again, trite. KanBan is not a software development process. I'm making a serious point, a single named process is probably not right for you or your product. You probably need elements of the various agile processes:

The most important point about any of this is that your process should be changing as you deliver because sure as hell your circumstances will be.

One of the things you'll hear from a lot of agile consultants is "It's all about working software"... and they're absolutely right. It is. If you find yourself doing or measuring stuff that's not working software then what on earth are you doing? Why would you do or measure that?

Measuring success

If you're lucky enough to deliver software then you need to start measuring how successful you are at it.

You need to define metrics about what is and what is not success. You need to communicate to the DevOps team about how to measure that success.

One big theme of DevOps has been metrics tools, things like Ganglia and Munin and Splunk and Loggly and these all make it easy to monitor your objectives.

Clearly, the first thing to do is state your objectives, inside whatever process you have. In my view the best thing to do is have a very clear stated objective for everything you do:

That sort of thing.

If you can do that, then measuring whether you met that success becomes quite easy. Well, most of the time. Sometimes maybe you don't quite have the data to answer the question. If that happens maybe you should ask your DevOps team to change the system to collect the data. If you still aren't seeing what you need to answer the question then you're failing... deal with that in the normal way. Maybe you decide it's impossible to find the answer, so throw away that objective and find a new way of stating it or aiming for it.

Delivering change

This is a bit controversial, but I believe that in the end you are trying to get your team to deliver, not features or bug fixes, but changes.

Web teams, particularly it seems, tend to focus on delivering features, or bug fixes, in whatever time they have. But the key to making a product better is to think about just delivering changes. This change affects the users in this way, this change affects the users in that way. These changes combine for a good effect. These other changes combine for a bad effect.

If you have the right approach to testing and the right approach to managing your team than delivering change over features or bug fixes is the single thing that will move you to continuous improvement.

Remember me linking to that KanBan article before?

there IS a time and place for Kanban - a correct context, if you will. If you've been reading closely, that context is as a change management process, which is 'complicated' work, and requires that there be already existing processes in place

Dealing with change should change your process for the improvement you want to make. You want to get feedback quicker? so deliver quicker and adapt your process so that you can.

Care about quality

A key to going very quickly is being safe. Making sure you and your team know that what you'll deliver live will actually do what you think it's going to do is key.

Making change, instead of features is a big part of getting this right because it's easier to test that a change is correct than testing the whole feature is correct.

What can a Product Owner do to increase quality? Mainly you have to care about it, keep asking about automated testing, don't accept manual testing, it isn't giving you quality. You must have a reproducible test and that means a computer doing it. If there are things your team say are hard to test then talk about changing them to make them easier. My view is that you should sacrifice almost everything else to achieve predictable results because users really hate unpredictability.

Ask your team about quality metrics. Do not accept code coverage as a metric because it's deeply flawed. Instead, look for test hygiene. How many tests are they creating? how many tests are they throwing away? How much test code is being created? and thrown away?

Tests should be being thrown away because otherwise the test suite will grow and grow to the point that it's not useful.

Ask about test hygiene a lot. Make it part of stand-up or whatever your regular review with the team is.

What could possibly go wrong?

If you're on the watch for classic mistakes in your or your teams behaviour or situation, you can maybe avoid them.

Danger #1 - no Product Owner

If the Product Owner is absent you've lost. You'll likely end up with multiple people doing it, not sharing any direction or vision and consequently going in many directions at once. You're likely to be unable to afford the designers, developers, operations staff, managers to handle them and offices to hold them in, to deliver multiple visions at once.

If you're in this situation you might:

Danger #2 - blowing with the wind

It's all too easy to do. You're not doing well meeting the vision, you've got some feedback that feature X is doing well, let' try doing more of feature X even though it's not really getting us anything, maybe it's not earning any cash or maybe it's costly to do.

Listening to feedback is important but you do need to stick to your vision or make sure you're on the way to making money (or whatever your success criteria is).

Jeff Atwood has excellent advice about collecting and acting on feedback; go read it.

Roman Pilcher's Product Ownership test is also good on this.

Danger #3 - huge backlog you step through

If you're stepping through a huge backlog you came up with at some point you're likely doing it wrong. Why would a backlog stay relevant over time? It's unlikely if you're collecting feedback and responding to it.

A very real problem is that people have ideas, good ideas often and they think those ideas should be implemented. But that's not necessarily the case. A good backlog is a source of ideas that may be relevant to the situation at hand, not a source of ideas that must be implemented.

This situation is not helped by our backlog management tools (or at least the ones I've seen) which rarely allow us to meaningfully differentiate between a fuzzy idea, a more concrete idea and something we've got evidence to show will be the best next thing to do.

The Product Owner can fix this by owning the backlog and making it clear by non-systemic communication which are fuzzy tasks and which are concrete. Constantly reinforcing that there is a difference is a help.

Summary

In the end, I think a Product Owner is someone who can answer this question:

What single thing should we do next to add value to the product?

Get that right, everything else flows from it.