Product Manager

Should AI coding change the Product Manager role?

Agile / / / , / Leave a Comment

Ever worked for a company that made ridiculous decisions but was still a nice place to work? For me it was Dodge Group. Beautiful office with great people where I could eat my lunch by the side of the Thames. Watching boats and dangling my feet over the water in Kingston.

I was employed as a coder but it was actually my first experience of Product Management. I went out and met customers. I prioritise the incoming asks. I got to devise solutions and think about the future of the product.

Those days are gone, for me, the company, and, if we believe the AI hype, Coders and Product Managers too.

Product Managers who code

I always advise against having hybrid Coder/Product Managers but the idea keeps resurfacing. Especially in current discussions of LLMs and AI. You can see the attraction: no need for a Product Manager to explain the ask to a Coder, no time wasted talking, no miscommunication and one vision of how it should work. Like me at Dodge.

Then for the company: no Coder means no wage costs. No bolshie programmer attitude. No failure to understand business needs or lack of appreciation for customers. Sweetness and light as ideas move directly from the Product Manager’s mind into code, into customers hands and money comes back.

A few weeks ago I got to talk this over with Peter Hilton, another coder turned Product Manager. I said I felt the desire to have managers code reflected the low status of engineers in the UK. Managers were happier with other managers and not dirty engineers with code under their finger nails. Peter saw the opposite: he saw the engineer hero worship of Silicon Valley trying to ordain everyone a coder.

The killer question for me is: what does the product manager do if they get a spare hour or two?

Underlying the belief that spare Product Manager hours should be spent coding (with or without an AI) is the assumption that there is not enough code and not enough features. More features means more sales. This immediately starts to smell like a feature factory.

Is lack of code the real problem?

I’ve always believe that a Product Manager with spare time should pick up the phone and speak to a customer. Or go and read market research, analyse incoming feature requests and support calls. Review strategy. Speak to stakeholders.

A Product Manager does not add value by building product. They add value by multiplying the value of the work done by builders. Making sure the highest value items are worked on. That the product-market fit is right. That customers are getting the expected benefits. And that everyone knows the strategy so the construction work is focused.

Today we are constantly told that AI makes Coders more productive. Thousands of lines of code can be written in a fraction of the time. Economically that means that the cost of code is less: AI makes code cheap. That might justify paying the Coders less but it means the multiplier is more important.

Why would Product Managers stop doing the high value work of strategy, customers and prioritisation to do the low value work of coding? It doesn’t make sense. Just because you can do something doesn’t mean you should.

At the same time some people are questioning why we need Product Managers at all. Why not just ask the LLM “What features should my app have?” But, if you can ask an LLM so can your competition. An LLM might be a short cut to a quick Product decision but while it delivers an instant fix it has no longevity. If you find yourself playing feature poker you need to change the game.

Competitive advantage

To gain competitive advantage your Product Managers need to find new insights which are not in an LLM. This might be from doing things LLMs can’t do, like visiting customers, watching them, talking to them, understanding their intent. Or looking at data which is not available to an LLM – feature requests coming from existing customers, talking to sales people about failed sales, or analysing your own data.

In fact, because LLMs make research from public sources easier and cheaper, it becomes more important to find things that your competitors can’t find. When you have a product in the market existing customers should be a goldmine of information.

Additionally, in a world were it is cheap and easy to identify and add functionality then products are going to become crowded and less usable. Deciding what to leave out becomes more important.

Subscribe to get Allan’s thinking + e-book

Picture copyright Robert Cook

Should AI coding change the Product Manager role? Read More »

My appology for MVPs & PoCs: why we need shared values more than ever

Agile / / / , , / Leave a Comment

Once again I find myself coming back to Reid Hoffman’s quote about early products:

“If you’re not embarrassed by the product when you launch, you’ve launched too late.” Reid Hoffman, founder LinkedIn

Reid is articulating an idea that comes up again and again, whether called a prototype, technology demonstrator, proof of concept (PoC), steel thread or walking skeleton, or, the dreaded, minimally viable product (MVP) he is calling out the value gained by early feedback.

What is different here is Reid is directly challenging us to go below our own expectations and our own beliefs of what is truly needed. At the same time he is laying a trap: the need for more work is built in.

While PoC, walking skeleton, MVP (especially) and the others terms all have their own logic for going small, they are too often in used by those in power to get what they want while downplaying other people’s wants. Oddly, the person demanding the MVP is usually happy to pass over what others want while insisting the things they want is minimal.

What all these formulation are trying to do is learn and, perhaps, start the feedback loop.

A technology demonstrator or proof of concept aim to learn what the technology can do.

A walking skeleton, aka steel thread, aims to learn how all the pieces fit together.

An MVP, should, help us learn about what the market wants from the product.

Like doing a limbo dance, all these ideas are asking “How low can you go?”

Reid is saying the same thing, and at the same time saying “Don’t kid yourself or anyone else that it is done.” A useful addition.

Similarly, when I did Product Management training with Pragmatic they had a catch phase: “You opinion, while interesting, is irrelevant.” I even have that quote on mug from a grateful product manager!

Yet in the last few weeks I’ve been feeling guilty for my part in pushing this idea. I’ve used all these formulations over the years to say to people: “Lets do something small, see what happens and learn.” But this idea is being used wrong.

When challenged that this is irresponsible I’ve been happy to point out that this approach has limits: I won’t offer a cure for cancer to test market uptake. (This was particularly relevant with a client who was actively trying to cure cancer.)

I’ve been horrified by the actions of xAI as they released a product with no safeguards at all. This was going lower than I ever imagined possible.

Their product that removed the freedom of people, particularly women, to appear as they want to appear. I, and every other person on the planet, has the right and freedom to appear fully clothed, and the freedom to restrict images of ourselves.

The same is true in other fields recently. Copyright now only seems to apply to those with the money to enforce it – as was said about the English legal system: “justice is open to all – like the Ritz Hotel”. Or consider democracy: moving fast seems to have broken it and fixing it is hard.

While I have been challenging tech builders to build less and learn more for years I have always assumed there was a level of shared values, common understanding and simple decency that formed a lower limit. Something so common that it didn’t need spelling out.

Without shared values it is very likely that one side will feel cheated by the other. I’ve seen many engineers roll their eyes and shrug their shoulders when told to build a “minimally viable product.” Without shared values these engineers feel they are being asked to cut quality while stuffing the product with features. Akin to building a car with many cup-holders but no breaks.

I’d like to say the answer is shared values. On long lasting teams that can work, but often technology teams have only just met and share very little to start with.

The answer, as is often the case, is to step back and be clear about what you are trying to achieve, ask “why?” Be clear about what is minimal in the market and clear about what technology you are demonstrating. By all means challenge yourself and others but remember there are limited, don’t claim to cure cancer.

My appology for MVPs & PoCs: why we need shared values more than ever Read More »

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 »

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 »

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 »