Allan Kelly's Blog

Sorry. I’ve deliberately avoiding the click-bait “Agile is Dead” topic, until now.

For the last few years I’ve delivered a lecture on Agile to Oxford University students and this year the tutor specifically asked me to say something about the state of agile. When I looked over last years slides I see I was already talking about this. I’ll write more about this soon, if you can’t wait checkout “Xanpan 2021” from Frug’Agile en Arménie.

So, is Agile Dead?

Clearly not. (Albeit agile mania probably is.)

Agile is all around us. Teams work in sprints, hold daily “stand up” meetings, tools like Jira continue to sell, requirements documents are full of user stories, business journals regularly talk about “agile” and “agility” without any reference to software.

That doesn’t mean the result is perfect. The “agile” which prevails today falls short of what I and others in the community dreamed. As I’ve said before, Agile won the war but lost the peace.

Right now, agile isn’t getting attention because AI is. AI is soaking up all the discretionally time and budget so agile is squeezed out. Ironically, to get the most from AI you need the learning processes embedded in Agile to find better ways. Right now we don’t now the best way to use AI. We are in a vast experimental phase and we need more of the learning and feedback in agile.

Back to the question, is Agile Dead?

The common agile that prevails is a watered down, corporately acceptable version that is still a lot better that went before.

But then, most people don’t remember before agile. The Big Up Front practices which gave massive requirements and functional specifications; the defined process and ISO-9000 process audits, the guilt of “not doing it properly” and the inability of those doing the work to influence how it was done.

While many of those problems have resurfaced under other names in the agile world things are still a lot better. If we had stayed with that approach there would be no automatic updates to the apps on your phone, no digital business, nor much of the other technology that surrounds us. Maybe Apple and Google would be OK but legacy banks, airlines, telecos and Governments would be even worse than they are now and a million start-ups would never have started.

In truth, many of the “waterfall” processes were never followed. I worked on exactly one project that did it by the book, Railtrack Aplan. Officially it was a success, it went live. But what went live was a shadow of what was supposed to be delivered.

Everywhere else did something that (kind of) worked and then felt guilty for not doing “properly”. When I was at Reuters they tried to force us to work by the book, they destroyed much of their own capability in the process.

What has agile ever given us?

Agile showed there was another way and added democracy by opening the debate on “how we work”. The Internet help agile spread and opened up the debate in a way that had never been possible before.

If nothing else Agile gave us a better reference model, a better way of describing our work.

Actually, it gave us several reference models, Scrum, XP, DSDM, etc. Always, and everywhere, people adapt, when processes work they use them, when defined process don’t work they work around them. For a while agile licensed that working around, experiments were everywhere.

Agile was not so much new in itself as a new combination of ideas which were lying around.

The engineering practices in XP descend from the 1970s quality movement based on the work by Phil Crosby and W.Edwards Deming.

The self-organizing teams in Scrum drew on the sociotechnical systems. First recognised in the 1940s and 1950s by the Eric Trisk – then at P&G and Topeka and the genesis of Senge’s organizational learning.

The inspect and adapt philosophy in Tom Gilb’s Evo and then Scrum comes from Stafford Beer and management cybernetics.

Lean thinking draws on many of these ideas directly but lean also begat its own software process in Kanban.

As for the Frankenstein’s monster that is SAFe… you can decide for yourself whether SAFe is agile but it is definitely not lightweight. Because of its size alone it is hard to adapt SAFe and involve the workers.

The return of Agile?

Can we expect Agile to return to its previous permanence? Will the day come when everyone wants to hire a Scrum master? No.

That has passed. Organisations have ticked the Agile box – if only because they have moved on to AI. The days of big agile transformations are largely over because companies have declared success.

Put it another way: Management fads don’t return.

Imperfect agile is here, hopefully enough of it has been adopted that companies will continue to improve.

More importantly, those ideas underlying agile – quality, sociotechnical, cybernetics, learning – are still valid and will continue to have influence. Some companies will embrace them and get a lot from them, some will continue to reject and most will dip-in-and-out. These ideas will return, albeit in a different package and with a different name.

But none of that means agile is dead. Agile mania might be over but agile is continuing to evolve out of sight. Agile wasn’t the first coming of these ideas and it won’t be the last. Next post I’ll talk more about how I see it evolving.

Signup for the my latest posts by e-mail and download a free book

Thanks to Fritz Geller-Grimm for the parrot picture under CC license

The post Agile: not Dead, but evolving first appeared on Allan Kelly.

My Top-5 tips for using OKRs – the podcast!

Rael Bricker has just published his latest Top Five podcast in which I discuss my Top-5 tips for working with Objectives and Key Results.

You can listen on Rael’s website. Or get it from Apple, Spotify, Amazon and many more all via Rael’s page.

To tempt you (or perhaps to give the game away?) the top tips I talk about are:

1) OKRs are a feedback mechanism

2) Involve as many people as possible in setting OKRs

3) OKRs are not a to-do list, they describe a desired outcome

4) Decide where Business as Usual fits in: BAU is boring but it can still badly disrupt to delivery

5) Ambition or predictable? The OKR hype machine makes a lot of ambition but sometimes you will want to be boring and predictable

This is probably a good time to remind everyone that I’m always available to advise, mentor or train on OKRs. Right now I’m offering my subscribers the change to get 30 minutes of my time for free, just book me and pick my brains.

The post Listen to my Top-5 intriguing tips for using OKRs first appeared on Allan Kelly.

Before I published Succeeding with OKRs in Agile I worried that my message about OKRs was different. Many people see OKRs as a blunt tool of management to enforce evil plans. I see OKRs as an enabling constraint, a liberating structure and a mechanism for bring about a better way of working.

The way I see OKRs may be different to some but I am far from alone. Many people who work with OKRs tend towards my view. Like so many tools OKRs can be used for good or evil – agile too can be used for good or evil. In my book OKRs are less of an end point and more of a starting point, implementing OKRs should drive other changes in an organisation.

Here are 6 ways I see OKRs as an enabler – or perhaps six ways OKRs are misinterpreted.

1. OKRs harness the power of problem solving teams

OKRs do not tell teams what to do. An OKR described a problem the team is tasked with solving. It might not be a problem, it might be a challenge or a opportunity. Ultimately it is an desired outcome.

Deciding, designing and delivering that solution if the job of the team. This is akin to the military idea of mission command: the team have a mission to achieve the OKR using the resources at their disposal.

2. OKRs define the acceptable outcome

OKRs define the desired outcome – hence I wish they were called OACs, . Think of it as Test First Management: the objective is the desired outcome, the key results define the measurements used to define success.

It should be obvious from this that key results are not a to-do list. Nor are key results a work breakdown which when executed will deliver the desired outcome. When the probably is set the solution is probably unknown. Even it is there are few details. The team are problem solvers, not instruction takers, their job is to solve the problem.

The NASA moon landings are possibly the great example of a problem solving team deciding the solution and delivering it. When John F. Kennedy set the “man on the moon” objective nobody knew how it was to be achieved. It took several years before the lunar orbit rendezvous method was agreed.

3. Aspirations optional

The moon landings are a great example of setting an ambitious, inspiring, goal and then looking for people to make the impossible happen. It is not for nothing that the likes of Google talk about “moonshot” projects.

That is great, I love the idea of such goals and people surprising themselves. But… not every organisation is ready for this approach yet. Before people rise to moonshot performance they need to be secure, they need psychological safety and they need to feel that failure is will not hurt them or their career.

Most organisations are far from that. Most want predictability, even certainty. There are those who will say “Put psychological safety in place before OKRs.” I say no, put OKRs in place, accept routine, predictable, results, and work towards building both psychological safety and ambition.

4. Bottom up over top-down builds improvement

Many see OKRs as something that are set by senior people and gifted to workers for them to deliver. I don’t.

I want those doing the work – that problem solving team – to have a voice in setting the OKRs. In my mind the leadership describe the ultimate destination, the ultimate purpose and mission of the company or programme, and they ask the teams for help. The teams reply with OKRs.

The team has a voice and this way their knowledge into play. The team will know more about what technology can do, and they probably know more about customer needs and competitor products than the executives. So the team reply with their interpretation of how all these things fit together.

Thus starts a feedback loop were both the team and executives contribute. This builds a strategy debugger and make for alignment between teams and bigger goals.

5. Business as usual is welcome

There are those who say OKRs are about aspirations and projects. I’m happy to go with that if the problem solving team have no other responsibilities.

But if the team are expected to do other, “business as usual” or “keeping the lights on” work then that needs to be reflected in their OKRs – I write a OKR Zero to catch it. This is necessary to make others – execs and teams – aware of the work, that allows for the strategy debugger and alignment discussion, it also opens the door to saying “No, we’ll stop doing that” or “We’ll give that to someone else.”

6. OKRs are everything, OKRs are the management method

Finally, if you are going to adopt OKRs then you don’t other objectives, side projects, business as usual, and competing demands, getting in the way. It is no use establishing a problem solving team, focusing them on an OKR and then saying “By the way, don’t forget your personal goals agreed with HR”.

OKRs summarise the aims of a team. That is why they are discussed with others, why they include work which might get in the way and why they are used to debug the company strategy and operation.

Thoughts? Let me know, or book a call for a chat.

The post 6 ways my OKRs are different first appeared on Allan Kelly.

I’ve been teaching planning lately and once again it seems to me that the PDCA cycle – aka Shewhart or Deming cycle – is pretty much the core of all planning. Or rather, it is the basis for all mutli-pass planning – when iteration is allowed. (One-pass planning, big-up-front-design “BUFD”, is fine for trivial situations but alway has problems in complex situations.)

So, again I’m reminded of why I don’t like PDCA. Two reasons.

Adjust over Act

When the fourth step is labeled “Act” it fails to speak to me. “Act?” I ask, “Didn’t we just DO?” Easily fixed, label step-4 “Adjust” – many people do. Now it says, “Plan a bit, do a bit, check the results, now adjust the plan or the way you are working.” That makes more sense to me.

4 unequal steps

Secondly, the typical presentation – like my diagram above – makes it look like the four steps are equal and that is not the case. Just in terms of the time they take the fourth is almost always the shortest. Which of the other steps dominate is going to depend both on the planning culture where you are and the amount of work that needs doing.

Many places will put a lot of time and effort into planning. While this can entirely justified if you are building something that lives depend on, planning suffers from diminishing returns. It is often far better to plan a little, run around the circle and plan some more. Planning is learning but so is doing, you can learn more by a few minutes of doing than hours of planning.

Other places will skip planning altogether and launch into doing. While over-planning is problematic jumping straight in is also a problem. Either way, in terms of the PDCA cycle, planning is not an equal element.

Now when planning is skipped or rush the doing phase is going to expand. In fact, on a really big endeavour which needs a lot of planning the doing phase can also be very large. Of course, its entirely possible that your planning is so excellent that you see an quick way to deliver. But again, doing is not an equal quarter.

Test-fix-test-fix-test doom loop

The same does for the check (or test) phase. It can be long or short. If your planning was good, and your doing was quality then you can hope that the check phase is really small. It does happen. But too often there is little quality in planning so you actually end-up with a short-circuit as the checks fail and more doing is needed to fix things. (This is the test-fix-test cycle that can destroy any schedule.)

I wouldn’t expect Plan, Do and Check to be equal sizes, depending on your organisation, culture and the nature of the thing you are doing I would expect one to dominate.

But I don’t see that in Adjust. Adjust is the forgotten child. Indeed, in many projects, especially at the end, everything just goes hell for leather do-check-do-check-…. Adjust, and even planning, goes out the window.

Using PDCA successfully

Even in the best places Adjust is always going to be the shortest of the four. The irony is that it is probably the most important. It is the step where reflection and improvement happen.

The truth is I’ve always struggled to apply the PDCA cycle formally. But when I look back at almost every single engagement the actual work can be mapped to the PDCA. It is fundamental, whether building product, running sprints, setting and executing OKRs or almost any other non-trivial work. Its just that the steps are not equally time consuming or equally respected.

And the secret to making it work well? Simple, go around fast. A little planning, a little doing, quick check, small adjustments and go again. Learn in the planning, learn in the doing, learn all the way round and put that learning into action.

The post What I’ve been getting wrong about PDCA first appeared on Allan Kelly.

I sometimes feel I’m the only person not making a song and dance about Artificial Intelligence. I even feel guilty that I haven’t shared my thoughts with my loyal readers. Let me fix that now.

Part of my lack of comment is because, despite the claims, I don’t’ see AI changing the fundamentals. Work still needs to be done, work still needs to flow from one place to another, decisions and action are still needed. Throughout my entire career I have seen a steady advancement of technology: as technology becomes more powerful the problems it can address increase. But we still need to know what problem, or opportunity, we are addressing.

Still asking: “What is the problem?”

Rather than running around saying “We must add AI, just ass AI” and so on, the question we should be asking is: “What do we need to fix/improve/change?” Only then think about the technologies. True, to some degree we won’t see an opportunity until we know what the technology can do but our starting point needs to be the problem/opportunity.

Down the years I have regularly heard “business” types say “Engineers need to stop putting technology first and consider the business need.” Right now it feels like positions are reversed.

AI is three technologies

Behind “AI” there are at least 3 very promising technologies: GPUs, neural networks and (large) language models (LLMs). These build on on another to create today is called AI but each has makes possible solutions and systems which address problems which could not be addressed before.

Ever since computers were first invented (and possibly even before that) people have talked of “electronic brains”. People looked at the early electronic calculators and thought them intelligent. (I suspect many products now labeled “AI” don’t use these 3 technologies and use older technologies which are still pretty impressive.)

Perhaps part of today’s AI boom is simply because these three have arrived at almost the same time.

Individually these technologies are impressive whether it is GPU graphics, crypto currencies or neural networks; neural networks themselves for image recognition, non-deterministic problem solving and language models.

Notice I say Language Models, not Large Language Models. While the synthetic text generation of LLMs is stunningly impressive I increasingly suspect the real future if Small Language Models. These use the same technology but address a specific problem.

What can AI do?

Looking at “AI” as several complementary technologies makes it easier to say: “What problem needs solving?” – and ask “does a GPU change this?” “Is an neural network applicable?” and “Can an LM help?”

Right now the world is running lots of experiments to understand how these technologies can help. It is difficult to disentangle what is real and what is hype but I keep coming back to a few points: processes, Jevon’s paradox and, of course, agile.

Processes

Even if “AI” can revolutionise the way we work there is still the need to move from where we are today to that new world. That requires time and effort.

As always technology is only part of the solution: we need new processes and new ways of working to get the real benefits. Thus more experimentation and human learning.

In particular, even with a brilliant new AI we probably still need to look at the work flow: how does work get to that system? and where does it go afterwards? Improving the whole needs work.

More work

Jevon’s paradox is already visible: Making work more efficient means we do more.

In a recent Blog post Duncan Brown (and an Agile Cambridge I didn’t see) recounts how AI allowed his team to create more prototypes more quickly. However, this made more work because each on required usability testing.

All those models require data: and many corporations have very poor data management. Lots of work required.

One forecast: AI code writing will lead to more code, more code which then needs testing. Much of that code will be end-user (shadow IT) systems which is good. These are great examples of innovation and make peoples work better. But simultaneously they create problems. They should be tested but more won’t, consequently individuals will become more attached to their roles.

These systems will raise cyber security questions and make more work for regular IT departments. The departments already struggle support or extinguish end-user IT.

And Agile?

Finally, there is an irony that the current Agile-winter is largely the result of discretionary corporate spending going into AI not agile. Yet if these tools are going to pay back we need more learning, and most likely ways of working which allow workers using AI tools to work effectively. In other words: to get the most from AI we need MORE AGILE thinking not less.

Regular readers will remember that I have long argued that Agile is the process change that maximises the benefit of Digital tools. AI is next iteration of those tools.

The post If AI is the solution, what is the problem? first appeared on Allan Kelly.

The question is: “What do companies who learn actually do to learn?“

Yes, we all know about retrospectives but there is a lot more too it than that. This was the question Tsvetelina Plummer and I set out to answer in what became our paper to EuroPLoP this year: “Learning to learn: patterns for building the learning organisation”

While we know this isn’t a complete answer – there is more work to do – I’m immensely proud of the patterns here. We put a lot of effort in before the conference, first by ourselves and then with MaryLynn Manns as our shepherd. And in the last few weeks a lot more effort to incorporate the workshop comments and get the paper ready for the proceedings.

So here is the paper, we’d love to know what you think.

Even better, if you have example of what you and your company do, a case study, an activity, anything really, then please please please get in touch and tell us about it.

The official version will appear in a few months in the conference proceedings by Springer Nature but only the formatting changes really (and this version is better.)

The post Patterns for building a learning organization first appeared on Allan Kelly.

I have been working with a coach recently to think about what I do. Odd as it might sound I have real trouble articulating what I do. This is particularly true when I’m employed to work on team performance and processes. In my mind I turn up, I talk to people and they then makes things better. Can I take the credit for that?

One of the reoccurring comments I get from clients is that I bring order from chaos. While I’m immensely proud of that it is a hard sell when trying to articulate the value companies can get from hiring me. That is because it implies you already have chaos, and who wants to admit that?

Whether chaos or not I’ve been running over my past engagements and a few things stand out. These are things that I have repeatedly done with teams, things which have made work better (and therefore more productive, efficient and fulfilling.)

Most of these suggestions are quick fixes: you can introduce them pretty quickly and see results. But they do not detract from long term improvement. Even if you have time these are a good place to start.

Triage processes

These come in various shapes and sizes. Typically this means appointing one or two people to quickly review work requests and decide if they need immediate action, can wait a little while or be pushed back.

In one case this mean that all urgent support requests or bug fixes were added to the teams work board in a special column. A few minutes before the daily “stand-up” the Product Owner and Team Lead would review these and decide if it was immediate action, push-back or hold for the next regular planning meeting.

(In the most urgent cases work might begin as soon as the request was made but that decision was reviewed just before the stand-up the next day.)

In another case I convened a weekly meeting to review all the urgent work requests which had some in in the last week (mostly things people called bugs.) Collectively we would agree the prioritisation (1, 2, … 5) and then, for just the priority 1s list them in priority order. Unless the customer service manager and myself (as Development Manager) agreed something new became more important during the week we stuck to this order.

There are plenty of other examples I can give but you get the idea. These triage processes work wonders at controlling task switching, confused priorities, decibel management and other sins. Consequently they boost productivity, work order and satisfaction.

Sacrifice one

Hand-in-hand with triage I often sacrifice one team member to urgent but unplanned work: bug reports, customer service requests, and so on. Even on a team of 3 or 4 having one person designated at the urgent work or fixer can payback both in addressing issues and allowing others to work uninterrupted. This designated person isn’t assigned to any other work, or at least nothing time critical.

There are a few engineer who relish this role and love nothing more than a stream of “small fixes.” Most engineers would rather work on bigger items and stick with them for a few days. So unless you are blessed with one of these people rotate the role between team members.

Routines

I’ve no claim to originality here, this is 101 in the agile processes playbook. Still it is effective. Choose the routines and ceremonies that make sense for your team: daily stand-up, regular planning/replenishment (I prefer weekly, most teams do it fortnightly, just please avoid 3-week sprints), retrospectives (not necessarily every iteration, perhaps monthly, at least quarterly) and regular releases. I’d love to work with a high performing team who do many releases a day but the only time I’ve seen teams doing such is with bug fixes. Again, weekly, fortnightly, monthly, these can all bring more structure than you have now.

And of course, if you are using OKRs create a cadence and put the dates in your calendar.

Create focus

Taken together those three suggestions: triage, sacrifice and routines all aim to create more team focus. Focus is one of the most powerful tools you can use. These three changes start to create focus.

Beyond them there is so much more that can be done to create focus: backlog structuring and prioritisation, OKRs, testing approaches, various graphs and measurements, …

Statistical forecasting

Even if a team is making effort estimates – in time, story points, tea bags or whatever – start collecting data. Actually, since most teams these days are using electronic tracking systems you probably have an archive of data which you can mine today.

Go and analyse the data.

How many “stories” do you do a week?

What is the cycle time for a story? What is the average? The longest? The shortest?

What is the average time a story spends in the backlog?

How many things are in flight at the same time?

What is the bug count? And what direction is it going in?

What is the team “velocity” ? More importantly, what is the backlog growth rate?

There are many more question you can ask your data. Not infrequently you find that the data you have is not good enough to answer these questions but that itself is information.

When you start to answer these questions you can start to forecast based on data not guesswork.

And by the way: I’m more than happy to help you analyse your data, just get in touch and we can work something out.

Quality

So far all my suggestions can be done relatively quickly. The next one is a longer burn: improve quality.

When you quality is low a defect – a bug – can raise a hand at any time and create chaos: disrupt a release, distract and engineer, panic a customer, etc. etc, Defects can be high profile, very disruptive and difficult to close. Defects can destroy any schedule or plan no matter how carefully constructed.

The solution is simple: improve initial quality.

To do this install test-first working, code reviews, frequent customer review, shorten feedback cycles, etc. The catch is these can take a little time before they pay back.

Two I haven’t mentioned

Now there are two things I haven’t mentioned so far and will have some readers wondering why I haven’t: reduce work-in-progress and introduce outcome oriented working.

Reducing WIP can have wonderful effects but explicitly reducing WIP requires authority or credibility – and usually the credibility is required to persuade someone with authority. Introducing triage, sacrifice and routines will have the effect of reducing WIP but without the overhead of persuading people that “doing less produces more”.

So I only target WIP directly once I have picked some other low-hanging fruit. Plus, having the data to back up my case will really help. Attempts to reduce WIP usually start with a screening of Stockless Production.

Similarly, outcome driven working requires a certain credibility and trust to pull off. So often people are just drowning in work which OBVIOUSLY NEEDS DOING. Even if the engineers aren’t then there are plenty of other people saying “Just F…ing do it!” So asking people to take a step back and think about the desired outcome can be hard. Better build up some credibility first.

That is my list, what would you suggest I add to it?

And if you would like to discuss these ideas further please let me know.

The post 4 quick fixes to bring order out of choas first appeared on Allan Kelly.

Even before I published my Product Management model I knew the model demanded more explanation to explain why it fitted the diversity of product manager roles. As luck would have it I had coffee with Peter Hilton on Friday where we compared and contrasted our recent experiences working as Product Managers. That conversation demonstrated to both of us just how difficult it is to pin down both Product Management and the Product Manager role. While both Peter and I reached Product Management from an early career as coders, and while we could recognise we had the same role we could also see a vast different in how we worked in that common role.

The thing is: coding is very similar everywhere, The coding role at a bank is not unlike the coding at an automotive supplier, which isn’t that different from coding at an ISV like Adobe or Microsoft. But the further removed you are lines of code the greater the difference in role.

So it is with Product Management – the environment you work in, the supporting roles present (or absent) and the stage in the product life cycle make it a very variable role.

Although the model I presented last time showed a hexagon with six equal sides that isn’t how it is going to be. Some Product roles will emphasis users and needs, consequently there will be less tie for strategy, communications, delivery working an value, the hexagon will look more like the one above.

Conversely, in my recent work it has looked more like this:

I found myself spending little time on user requirements and value but a lot more time on strategy, stakeholders and communications.

The interesting question to ask here is: what are the forces that shape the product managers role?

The obvious one is corporate environment: Peter has been working in a start-up while I’ve been in a big corporate environment. Peter had more reason to look at customers and how meeting their needs delivered value. Conversely, the needs of my “customers” were pretty limited but there were many other non-user stakeholders who needed attention and that meant a lot of strategy discussions.

The second force to call out is the stage of the product life cycle. In a typical start-up there is a search for market fit which means much more work on value in the market plus user needs and value. (I imagine the market fit discussion wrapping around the right hand side of the original hexagon.)

Perhaps the biggest variable in the mix is: the supporting roles present or absent in the organisation.

For example, if the company employs specialist user researchers then the Product Manager doesn’t need to spend so much time collecting and thinking about needs. Plus some of the inbound communication will be offloaded so those two dimensions are reduced.

Similarly, if the company employees user experience designers and project/delivery managers then the here and tomorrow work will be reduced. While in early stage start-up the Product Manager may need to cover outbound marketing communications (especially go-to-market) but in an established company there are likely to be dedicated “MarComs” staff.

In the early stage start-up the CEO is probably a founder and it they who hold the strategy. In a multi-product company individual product managers may be responsible for product strategy while the CEO owns the corporate strategy each must align to.

When supporting roles are absent it either means the work is not done – which might not be an immediate problem – or, someone else has to cover the role, even if it is minimal cover. If no one else is available it is going to be the Product Manager, which is why the role can become a catch-all role of all the work nobody else wants to do.

The post What makes Product Managers hetrogenous first appeared on Allan Kelly.

Does this work for you? – what do you think?

Regular readers will know my last two posts have been thinking about “what do product managers do?” Right now this is a pressing issue for me. Having returned to product management I’m trying to define just what it is I do. This is the model I’ve come up with (so far).

One of the things I’m keen to get away from is the idea that a Product Manager is just another version of a requirements gatherer. Yes, knowing what people want is an important part of the role and that may well mean going out and gathering them yourself. But there is more to it than that.

I’m also keen to think about the lifetime aspect of Product Management: often it is associated with the introduction of new products – all those startups! But Product is about the product.

There is a school of thought that says Product Managers replace Project Managers. While I can see why that is the two roles are not symmetrical. They address different questions so while they are both about delivering product to customers the raison d’être is different – so too are the skills and techniques they employ.

Thinking about lifetime also leads you to realise that the skills needed are going to change depending on where the product it in its life. Most obviously at the begining there is the question of market fit and at the end there is the question of end-of-life.

What does the model say?

Ultimately it is about Product Outcomes – how the product changes the world, makes it a better place. However there are at least six dimensions here. I’ve labelled them above and hinted at some of the more obvious aspects of the dimension but for completeness:

• Wholeness: the Product Manager has to think about the whole product both as a thing but also over its lifecycle, that introduces time and demands strategy.
• Stakeholders: the product is only going to be meaningful if it satisfies stakeholders. For most product managers that means customers – buyers – but it also includes others in the creating organization, it might include others like regulators, ultimately it might include the whole of society. (If your strategy is move fast and break things, what happens when you break democracy?)
• Needs: product need to satisfy stakeholders needs, exactly how they satisfy those needs and whether the product is the thing that satisfies them or whether it is just a tool in a process or services needs to be understood.
• Value: if a product satisfies needs then it is valuable, that value needs to be greater than the cost of making the thing, or at least, greater than the next best thing. Value is not always money.
• Now and tomorrow: it is not enough to uncover needs, devise a strategy and write a paper on value. There is a hands on element too, this goes back to wholeness, product managers can’t be hands-off, if their brilliant ideas are going to fulfil their dreams then they can’t afford to hand-off everything. The way a product is created and delivered, the way the origanization is structured are all going to need attention. (Don’t forget Conway’s Law is lurking in the background).
• Communication: last but not least, product managers need to gather information – what do customers want? who are the competitors? what is technology doing? – and share it – what will the product do? where can you buy it? why is it better than anything else?

At the moment I think these six dimensions sum it up but I’m not sure, maybe there are just five? Or maybe there are seven? Please send me your thoughts.

An no two product managers are going to see this hexagon differently. The product itself, where it is in the lifecycle, the organization and many other factors mean that some product managers will spend most of their time in one or two dimensions, say strategy and communication, and little in others, say now & tomorrow.

Obviously, product managers working in a commercial setting are going to have very different (probably simpler) stories of how a product meets needs, generates value and satisfy customers. Those working in other settings need to be even clearer on how that all happens.

Role model?

The question on my mind at the moment is: what jobs/roles can provide a role model for product management?

(OK, this is a trick question, the role model for a product manager is another product manager but that doesn’t necessarily help generate insights.)

So far there are two that I’m attracted to and plan to write more about. For now…

First is the Toyota Chief Engineer as described in The Toyota Product Development System (Morgan and Liker, 2006).

Second up is: Poet. Yes, poet.

I’m reminded of Dick Gabriel’s description of poetry and what the poet does: it is about compressing an idea to its purest form to communicating it. Of course Dick was thinking of programming when he write about this in Patterns of Software but my intuition says it fits with product management. I’ll write more about this sometime, in the meantime you can buy Patterns of Software, or just download it for free from his DreamSongs site. (And checkout Worse is Better while you are there, a classic.)

The post Does this Product Management model work for you? first appeared on Allan Kelly.

I said in my last post that I don’t think what I have been doing as Product Manager for the last year really marries up with what people think Product Managers do. So while I feel guilty I don’t have imposter syndrome because a) my books alone show I know what I’m talking about, b) I’m told I’m doing a good job.

So, what should a Product Manager be doing?

The good news is that while there is some agreement (its about the product, stupid) there is less consensus on exactly what.

That itself creates a problem, I remember Gabriel Steinhardt of Blackblot pointing out a whole back that the role sometimes becomes a dumping group for work that should be done elsewhere. There are several reasons why that is still true.

First off the role is poorly understood so is open to interpretation. Second, it can be hard to pin the role down to what it is. Third, Product Manager have fingers in many pies so the casual observer they see a product manager doing different things and thinks they do it all: discussing requirements, presenting strategy, planning or working with an engineering team and more. Then there are marketing discussion, and sometimes sales calls or customer visits. (Check out my prelude in Art of Agile Product Ownership.)

Not Project Management

So in an effort to untangle this I went on a search. I started with Wikipedia

“A product manager (PM) is a professional role that is responsible for the development of products for an organization, … Product managers own the product strategy behind a product (physical or digital), specify its functional requirements, and manage feature releases. Product managers coordinate work done by many other functions (like software engineers, data scientists, and product designers), and are ultimately responsible for product outcomes.” Wikipedia, September 2025 (my emphasis)

That is quite broad, and although Wikipedia notes “Not to be confused with Project manager” the mention of “coordinating work with other function” itself adds that confusion. The last bit is the part that resonates with me most: “responsible for product outcomes” – that fits in with my outlook and my enthusiasm for (aka OKRs).

Looking again at this definition I can’t help but think that plenty of Project Managers (and Delivery Leads, and even Scrum Masters) would also claim to managing releases, co-ordinating work and responsibility for outcomes. It seems to me that exactly what a Product Manager does will depend on what supporting roles exist: without a Delivery Manager they may need to co-ordinate workers, without a BA or User Researcher they may need to spend a lot more time with users/customers, and while a Product Manager may own the strategy it is also possible that they are give it and told to execute.

Inbound & outbound

Blackblot was next up, they have a nice little video explainer which situates the role within their product management framework. To summarise, Blackblot see the role as Product Planning (what does the customer want/need, something I call inbound marketing) and Product Marketing (telling people the product is here, or outbound marketing to me.)

That is not the same as Wikipedia but its not too far away.

Lifecycle

Next I fished out my Product Manager training manuals from the Pragmatic Marketing course from years ago. While Pragmatic acknowledge a lot of work for the Product Manager the course itself was heavily oriented towards requirements and understanding external customer. Pragmatic Marketing are now Pragmatic Institute and on their website they offer this summary:

“product management oversees a product’s development and life cycle. The ultimate goal is to create and deliver a product that meets customers’ needs and generates revenue for the company.” Pragmatic Institute, September 2025

Again, similar but different to both Wikipedia and Blackblot. I really like the reference to “life cycle”. It is important to acknowledge that product management doesn’t just happen at creation: it should be there for the life of the product. It will change over time – new products have different priorities to retiring ones – but it still needs to be there.

Having said that, the “life cycle” reference is a little vague. True, this is not the only thing on their website so I shouldn’t quibble. If I look at the training they offer I get the feeling that for Pragmatic still emphasise the customer requirements side.

Celebrity

Finally, Silicon Valley Product Group: if Product Management has a superstar it is SVPG founder Marty Cagan. Here I found:

“In the product model, product managers are a key member of a cross-functional, durable team that is empowered to solve problems in a way customers love, yet also works for their business.” SVPG, Sept 2025

Like Blackblot SVPG are situating the Product Manager within a framework. While this makes sense it also leaves one asking “What if the company doesn’t use that framework?” In other posts I find SVPG are not always kind about other frameworks, or absent frameworks. The attitude can feel a bit elitist, “If you aren’t following this framework you are not doing it properly.” While that might be true it isn’t very helpful.

The same SVPG post goes on to lists things the Product Manager should not be doing. Some of these, like project management and requirements gathering seem contrary to what others say or imply. (The whole project/product manager/management issue is worth a post in its own right if I could only work out how to distill the issues.)

Where now?

So where does this leave us? What does a Product Manager do?

There is something to like in all these definitions and there is common agreement around its product centricity (if there wasn’t it would be very problematic!).

Product centricity is something about ensuring valuable outcomes which meet needs and deliver value. While some of these definitions note that there are multiple groups to deliver to (e.g. users and buyers) others emphasis customers. This begs the question: how do you define a customer? and what about internal “customers” who don’t really have choice?

Now if we agree Product Management is about ensuring valuable outcome we still haven’t answered the “What do they do?” question. So I go back: how they deliver those outcomes is going to depend on where the product is in the life cycle, how the organisation is set up (structure? frameworks?) and what, if any, supporting roles there are.

If I’m a Product Manager in company following one of the patent frameworks, supported by Business Analysts, Marketeers, User Researchers, with a Delivery Manager and Scrum Master then my job is going to be very different to if… I am at a small company with random management, no analysts or researchers, teams lead by coders who think they know what they are doing and no advertising people.

But in both cases, I should be delivering valuable outcomes, if I can’t persuade the company to adopt a framework and hire people to help me.

I’m hoping that before long I can come up with a model of what I think Product Managers do, watch this space.

The post Learning from explanations of Product Manager first appeared on Allan Kelly.