Product Owner

Reach your North Star with a compass not a roadmap

Agile / / / , , , , ,

At the mention of product roadmaps I’m reminded of the scene in Blackadder II where he becomes a explorer. Lord Melchett hands him a scroll and says “The foremost cartographers have prepared this map of the area you will be traversing.”

Blackadder unrolls the scroll, looks at the other side and replies “But it is blank”

“Yes,” replied Melchett, “they asked if you could fill it in along the way.”

Which if you think about it, isn’t that different to what the Lewis and Clerk expedition did. Starting with what was know they explored and created better maps.

Now you don’t have to talk to a Product Manager for very long before the topic of Roadmaps comes up:

“How can I build a good roadmap?”

“How can I guarantee my roadmap is delivered?”

“How do OKRs fit with a roadmap?

“How can I make sure my roadmap is accurate?”

and so on… frankly, roadmaps drive me to despair. For a start the word “roadmap” means different things to different people, or rather, different organisations expect different things from a roadmap.

Second, most so called roadmaps are little more than a list of features with dates. Worst still, most of those dates are little more than guesses so even if the features listed didn’t change they are unreliable.

What roadmaps should be

I’ve long held that the best roadmaps are scenario plans, they are one version of how the future might unfold. Like all scenario plans they are designed to create learning, that means they need to involve multiple people. Creating a roadmap should not be a solo activity for a product manager. It should be a group activity, as is so often the case the true value is not the map itself but the process of creating a map. Another case where you want to prioritise planning over plans.

Like a good scenario plan the starting point for any roadmap should be what you know will happen. The future is uncertain but there are many events which are already programmed in.

We know how many people will turn 18 in 2030.

It is almost certain that Apple will launch an updated iPhone in 2026.

Laws don’t come out of the blue: implementation is usually months, if not years, after the law if passed by legislators.

You know the major trade shows in your industry and when they will occur. If you work in telecoms you will already be planning around WMC Barcelona, 2 March 2026. You can bet in WMC will be March 2027, then March 2028….

Only when you’ve mapped out what you know might you turn to what you want, and when you want it.

But still, roadmaps are hard. There must be a better way…

Compass over map

Leave aside those lists with dates, product development is too complex to make them worthwhile. Those who request them are misguided themselves and those who provide them are either living in fantasy land or knowingly offering up a flawed map.

What we need is direction.

What we need is purpose and intention.

Maps are not a good metaphor, what we want is a compass. We want a mechanism for pointing us in the right direction, a tool to measure deviation from our desired destination.

After all, we increasingly aim for a “North Star” (or “True North”, or the one I heard this morning “Lode Star”).

Armed with such a device, if you know where you are, and how long you have to get to your destination you can calculate how fast you need to go. Or, if you know how fast you are going you can work out when you will arrive.

Although, nobody has ever arrived at Polaris, the North Star. We have only at interim points along the journey. If we do the right thing then good things will follow.

Navigation with automomy

When you follow a roadmap you are programmed: Feature X by 1 June, feature Y by 1 September, product completion by 1 December. Miss one of the milestones and you may be called to account. Maps reduce your autonomy.

When roadmaps are used as a plan they are disempowering. Someone has decided the route your job is to follow not to question it. There may even be traffic police on hand to keep you on the route and take charge of any accidents, further removing autonomy and discretion.

Compare that with compass and North Star: you take readings, you recalibrate, you calculate how far you need to go, you adjust your direction… in other words you Inspect and Adapt!

Having a compass and following a North Start leave responsibility and decision making with those on the journey, the team. After all, the team are the experts, the team have the most knowledge, the team should be the fulcrum of making things happen.

Reach your North Star with a compass not a roadmap Read More »

The sound of #NoBacklogs

Agile / / / , , , ,

Duarte Vasco – of #NoEstimates fame – has just published a podcast I recorded with him a few weeks ago.

The podcast is available at on normal channels (Spotify, Apple, etc.) or with commentary at Duarte’s own site: Challenging the Agile Status Quo with #NoBacklogs.

Let me admit, after the firestorm that was #NoProjects I’ve avoided saying #NoBacklogs but I have to admit, if you have heard me say “Nuke the backlog” or seen my “Honey, I shrunk the backlog” presentation its natural tag to use.

Any, have a listen and let me know what you think.

The sound of #NoBacklogs Read More »

First get small, next get broad

Agile, Strategy / / / , , , , , ,

Small, small, small – I have spent a lot of my career arguing for small: small tasks, small user stories, small teams, small releases, small funding increments, small “projects”. I argue we should get good at small and optimise our systems for doing lots of small. I can justify my arguments – Project Myopia or Diseconomies of Scale. Small makes sense.

But…

While focusing on small is good for delivery it creates other problems. In truth, no solution is ever without consequences and few have no negative consequences, all we can strive for is more positive consequences than negative.

It is not enough to get good at small in delivery, one needs to couple that with an understanding of what is commonly called the bigger picture and which I prefer to think of as the broader picture.

The failure to situate small in the broader context underlies many of the problems we see in the work place today. Take work management, ignoring the broad leads to micro-management, disempowered staff, frustrated employees and collaboration failure.

It is also failure to see the broad that lies behind two of todays most common problems: Product Owner Failure and Run away Backlogs.

Product, sigh

Product Owners – I include Product Managers here – are failing because they are failing to see the broader picture: what is the problem we are trying to solve? how can we bring value to customers?

Product people are too often too focused on features. While I’ve recently seen some point the finger of blame at product owners/managers I think they are only responding to their environment. Companies are operating feature factors and sales are made on features, people think more when they should think better. Product people need to get out and meet customers and bring what they learn back to they can try and change the inside.

The feature, feature, feature attitude is also behind the backlog fetish which leads to backlogs stuffed full of ideas which are never, ever, going to be implements.

The discussion needs to be broadened. We need to get away from quick-wins and features, we need to think more broadly. We need to think about the big things: goals, objectives, purpose and even meaning.

Post pandemic it is common to hear of people seeking meaning in their work, no wonder so many people are dropping out of the workforce when the best they are offered is “more stuff to do.” In looking at broader goals we also need to recognise goals within goals, we need to uncover the hierarchy of (possibly competing) goals, call them out and work with them.

Thats is why I am keen to emphasise outcomes over outputs and its why its tempting to think of a great big funnel containing a machine for breaking the big into small (or Rock Crushing as my old friend Shane Hastie would put it.)

The challenge is to combine the need to focus on the small for delivery while also being able to think broadly. In part it is this challenge that has caused me to focus more on agility over agile.

The Strategic/Tactical Product model but it is not a complete solution.

Iteration, again

Another part of the solution is iteration: we spend a lot of our time in the small focusing on delivery, but from time to time we surface and consider the wider context. Thats why I embrace the OKR cycle, it gives everyone a chance to understand both and take part in both discussions.

Underlying so much of my work over the years has been a desire to remove intermediate pieces: like having a coder speak directly to a user rather than through a BA, its one of my objections to projects (which claim to show the big picture but actually represent a restricted view), its lurking in my dislike of estimates, and its part of my dislike of backlogs.

Asking people to carry the broad picture in their minds while working in the small is asking a lot. Thats why the cycle of thinking broad, setting goals, then switching into narrow mode for delivery works so well. Its fair, it includes everyone and it gives everyone the reason why we do what we do.

In short, we need to think broadly when deciding “what is the right thing to do”, then switch into the small to deliver. Importantly, we need to share not just that thinking but also the discussion. Everyone has a right to be heard.

First get small, next get broad Read More »

10 rules of thumb for User Stories

Hand-on / / / ,

There is a universe somewhere in which my blog is always on topic, I have a theme and I always produce posts which accord with that theme. However, in this universe my mind flits around and, for better or worse, this blog carries what is on my mind at the time. Sometimes that is grand strategy, sometimes hands-on-detail, sometimes the nature of digital work and sometimes frustration.

This week I’m dusting off my slides for next months User Stories workshop so I thought I’d share my User Stories 10 rules of thumb:

1 – Stories are usually written about a hands on user, someone who actually puts their hands on the keyboard

2 – If your story begins “As a user” then save the ink and delete the words, “as a user” adds nothing. “As a customer” isn’t a lot better. In both cases think harder, come up with a better “user”. Be as specific as you can.

3 – Stories which have systems in the user role should be rethought (“As Order Entry System I want the E-Mail System to send e-mail so that I can notify the humans”). Step back and think “Who benefits from System-E and System-F working together?” then rework the story with that person in mind seeing a combined system (e.g. “As a Branch Manager I want e-mail notifications sent when an order is entered.”)

4- Stories should be big enough to deliver business value but small enough to be complete in the near future, I’m prepared to accept a maximum of 2 weeks but others would challenge that and say “2 days is the max.” (Small and valuable actually constitute my 2 Golden Rules, where I also discuss Epics and Tasks.)

5 – There is no universal right size for a story. Teams differ widely in terms of the best (most efficient, most understandable, quickest to deliver, biggest bang for your buck…)

6 – In general the greater the gap (physical distance, cultural norms, history working in the domain, employment status, education level, etc. etc.) between the story writer (e.g. BA) and receiver (e.g. Tester or Coder) the more detail will be expected by one side or the other.

7 – If the User Story format “As a … I want to … So that …” isn’t readable then write something that it. Who, What and Why are really useful to know and he standard format usually works well but if it doesn’t write something that is. There are no prizes for “the perfect story.”

8 – Beware stories about team members: a story which begins “As a Tester I …” or “As a Product Owner …” are red flags and should be questioned. Unless you are actually building something for people like yourselves (e.g. a programming team writing an IDE) then stories should be able end users and customers. Very very occasionally it can make sense to write something for the team themselves (e.g. “As a Tester I want a log of all database action so I can validate changes”) but before you accept them question them.

9 – Stories should be testable: if you can’t see how the story can be tested think again. If you are asked to complete a story which you can’t test then simply mark it as done. If it can’t be tested then nobody can prove you haven’t done it. However, in most cases someone will soon report it as not working and you will know how to test it.

10 – Remember the old adage “Stories are a placeholder for a conversation” ? Well, if you have the conversation all sins are forgiven. No matter what the flaws are if you have the conversation you can address them.

Needless to say more about these topics in Little Book of Requirements and User Stories.

Now just because I go around saying radical things like “Nuke the backlog” does not mean I want to ditch the wonderful who-what-why structure of user stories. You might throw away a lot of user stories but when thinking about the work to be done in the post-nuclear supersprint then by all means: write user stories.

10 rules of thumb for User Stories Read More »

Product Owner car crash story

Agile / / /

A few weeks ago I was in Sweden with clients and heard a horrific Product Owner story today – one I can hardly believe… maybe I shouldn’t, this was told to me second hand but I think it serves as an useful warning.

Reportedly a local car company has told its Product Owners to split their time three ways: 25% of their time is to be spent doing product owner work, the next 25% is to be spent in line management and the rest of the time, half their time is to be spent keeping deep technical knowledge by coding and other hands on activities.

To be clear: this is a bad idea, a bad idea, a bad idea.

Let’s start with 25% product owner work: not only is the Product Owner role the most difficult role to fill it is also the most time constrained role. 100% a product owners time is not enough to fill the role properly.

Next, line management and product ownership should never mix: product owners take their authority from being experts on what is needed rather than a position on an organizational diagram.

Product Owner – even when called Product Managers – are peers of software engineers. They are both professional with specialist skills, they need to respect each other and have constructive discussions even when they don’t agree with one another. The Product Owner is the expert in what customers want, the engineers are experts in solution building, they represent the analysis-synthesis split.

Product Owners need to be able to represent what the customers want to the engineers and engage in meaningful debate between peers. This is not going to be possible is the Product Owner is also the line manager for the engineers with the power to refuse holiday, promotion and mark staff down in reviews if they don’t get their way.

Besides, when do they have the time to do line management?

Then the massive 50% of the time spent coding or other technical work. Again this conflicts with being a true product owner (representing the customer) and holding meaningful discussions with engineers. As they only spent 50% of their time on engineering issues the PO will be the least prepared engineer on the team but the one with most authority. (I’ve written before about the mistake of making a platform engineer the product owner.)

And where is the product owner to get time for all the other miscellany that lands on a Product Owner’s plate? Reporting, statistics, testing, negotiation, etc. etc.

This company has fundamentally misunderstood the Product Owner role. They are seeing the role as an old fashioned Development Manager who was expected to be the technical authority, the team manager/leader and the one to nominate what should be worked on. (Even if they never meet a customer.)

The three things the company is asking the product owner to do are not just three different things, they are three things that should be separated. Line management is an issue agile folk struggle with because in purest terms it shouldn’t exist but in the vast majority of organization that nirvana is so far off it needs. So far at moment we are still in search of a generic model and until we get it we need to keep line management outside the team if possible.

50% hands-on is the give away here, the car company really want a technical authority, call then a senior engineer, a dev lead, or even an architect. This is a legitimate ask and should be recognised as full role. In fact, I would encourage the role holder to put a lot of time into mentoring less experienced engineers. In some engineering fields such senior engineers work as a type of tester to reviewing the work of other staff.

Finally the Product Owner role is a full, legitimate role in its own right. I suspect what is happening at the car company is they have lots of teams working on small technical aspects of the car. They feel only a few people need actual customer knowledge and contact.

It might be that the company could use the strategic product owner/tactical product owner model. Sometimes the TPO role crosses over with the Tester role and it can make sense to have an experienced engineer in the role. Still, you need someone to represent the customer point of view and another person to represent the technical side so the two can have constructive disagreement.

Very occasionally, once in a while I come across a situation where is makes sense to a very technical person drive product ownership from a purely technical point of view. Such occasions are few and far between, but the majority of engineer and managers think their case is one of those exceptions. Maybe this is one such case, but why add-in in line management? and why reduce Product Ownership to a part-time role?

In short: don’t do this.

Subscribe to my blog newsletter and download Continuous Digital for free

Product Owner car crash story Read More »

Videos: ITIL & the Product Owner

Agile / / / , , ,

Last month I appeared in two videos now available on YouTube.

First I was interviewed by Adrian Reed about the Product Manager and Owner roles for The BA Fringe. My interview appears about 12 minutes into the programme and lasts about 10 minutes.

I also joined an expert panel discussing the ITIL 4 High Velocity IT – aligning agile and lean. It was a great conversation and a lot of fun to record, we hardly mentioned ITIL but #NoProjects did get a look in.

I know, ITIL is not something I’m usually associated with but digital and agile means ITIL is changing and I contributed chapters on Product Owner and Continuous Digital (aka #NoProjects) to the recent ITIL High Velocity IT book.

Videos: ITIL & the Product Owner Read More »