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, Outcomes and Acceptance Criteria. 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.

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.

Even before I published my Product Management model (and before that Learning from explanations of Product Manager) 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.

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.)

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 Outcomes and Acceptance Criteria (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.

Last year I took an unexpected pivot and have spent most of the time since working as a Product Manager. While I’ve had a couple of minor side gigs in that time I think my consulting life is gone, I see myself continuing on as a Product Manager. While I enjoyed my years consulting its also great to be consistently working on one thing, delivering product to real customers.

Now feels like a good time to reflect on just what I’ve been doing as a Product Manager and how I make sense of this world now.

A little background

Now I’ve been a Product Manager before, I dabbled in managing a product manager when I was still coding and then trod the common path from engineer to Product Manager via an MBA. I even did training with Pragmatic Marketing in the USA.

As a result my flavour of agile has always been heavy on the product side and I frequently found myself asked to coach product manager, owners, BAs and founders. I often describe this as “the demand side” or “what question.”

A lot of my writing a lot of it clearly falls into the product space: Business Patterns for Software Developers (how I wish I had called this book Strategy Patterns for Software Products), Continuous Digital, Project Myopia (which didn’t talk about products and simply said “projects are wrong”) and of course The Art of Agile Product Ownership.

Product Owner or Product Manager?

Somewhere along the line I kind of fell out with the product manager community part of this is because I refuse the distinction between Product Owner and Product Manager. I’ve observed Product Managers who look down on Product Owners and see them as some kind of charlatans. Now granted, Product Owner as defined by Scrum is a pale imitation of a Product Manager role but both roles have, or at least should have, the Product at heart. Both roles are concerned with the demand side and should be value oriented.

Now the two roles are really badly named but the a bigger problem is the way companies interpreted by corporations is completely messed up but unfortunately I can’t fix that. Often there are two roles but I would call them Tactical Product Manager and Strategic Product Manager (more on that in The Art of Agile Product Ownership).

While most of my year has been spent as a Strategic Product Manager one can never get too far away from the day-to-day. Without a Tactical to partner with I’ve taken a lot of that on but I haven’t written a single user story or prioritised a backlog. I’ve been driving work through OKRs which means I’ve been much more strategic.

Strategy

Now as a Strategic Product Manager it is not just a case of writing a strategy, giving in to everyone and putting my feet up. Delivering a strategy means living the strategy, it means repeating it, and repeating it, it means letting it into every decision, it means calling out decisions which you (and others) make which don’t fit the strategy, and it means coping with problems which arise so they don’t disrupt the strategy.

For example, one of my early strategy decisions was to develop a small product and expand it. Having made that decision I had to fight for it and explain to people that building small didn’t prevent us “going large” later. That mean finding the language and metaphor to explain that decision. It meant socialising it, getting key people to understand my logic and agreeing. That meant repeating it, it meant reassuring people we weren’t walking away from the large product and it mean prioritising decision to deliver the small.

One of the other teams in the organisation kept implying that my product was going to be much bigger than it needed to be. I had to keep correcting them, saying “In the first instance we are building a small product, we may do that large stuff later but right now we are going small.”

In fact, I’ve made lots of decisions along the line to not doing something. To put a problem in a box and label it later.

Yes I listened, yes I took on other concerns, but once I’d made a decision the team and I had to live that decision. When we’ve had problems, fires, and need to react those decisions have to align with the strategy. Rather than saying “This is an emergency we need to go bin the strategy for a week” it means saying “Our strategy tells us to deal with the emergency by doing this.” A crisis is an opportunity if you handle it right.

Business value

Most of the business value for the product had been identified before I arrived. But I still worked over where the product added value, I needed to make it my own. And on many occasions in reasoning, and thinking strategy, I’ve taken myself back to first principles: “What is the value this product is delivering? And to who?”

That has been especially true of the second product I’ve been involved with. That product has been troubled. It is a “business enabler”, it doesn’t so much deliver the value itself as support teams who are delivering value. With this product I regularly find myself going back to “how does this deliver benefit?” Unfortunately I find the business side too forgiving here, I wish they would join me in looking at business benefit and querying work was being suggested. Too many people hear that the work is both strategic and technical and switch off, they then trust the techies.

The client organization is paranoid about delivering the right thing. Knowing the value in both cases, having a strategy, and giving a consistent message in all cases both furthered the case and saved time. I didn’t need to go back to basics everytime.

Guilt, or just imposter syndrome?

In fact, if you ask me “Describe in one sentence what you have been doing as a product manager” I’d probably reply “Forming and promoting the strategic vision.” That sounds pompous, so let me try again: “Agreeing the outcome and keeping the focus.”

I do feel like a charlatan product manager: normally when I read Marty Cagan’s posts. Don’t get me wrong, I’m a big fan of Marty Cagan’s work and his posts. I agree with almost everything Marty says but measured to his standard of product management I’m a fraud.

I don’t spend my every possible hour meeting customers. Actually the product I’ve been managing is largely internal so very few users are “customers.” I pretty much know all the customers. And those facts add to my charlatan feel.

I don’t agonise about Product Design – its not irrelevant but in our environment its not a high priority. So again, is this really product management?

I do encourage agile style working, I do work with an outsourced team. The client likes the idea of a product operating model but they can’t give up their project habits so it is full of compromises and dysfunctions.

In short I just don’t feel I live in the same product world as Marty. Maybe I should be considered a project or programme manager but the client considers me a product manager.

(Actually, every time Marty complains about agile coaches who try to coach product people I feel guilty too.)

OKRs

One of the attractions of working with this client was OKRs. When I joined they were starting OKR adoption. As such I had one of the first to teams using OKRs. While my OKR execution may not have been perfect, and while the organisation has been a long way from perfect I have had success.

My backlog free approach has worked great: OKRs are set quarterly, we review them in most planning sessions, work is direct work towards the OKRs and the team write their own tickets for things to do. There are no user stories and the only backlog we have is work we simply haven’t got to yet. (Although even just a tew dozen items in the backlog, in progress or blocked we get duplicates!)

Problem solving team

Part of my success with the OKRs has been respecting my main delivery team as Problem Solvers. The OKRs describe the problems and parameters of the solution and the team can work out how to solve it.

The second product team I was working with things didn’t go so well here. This was a different supplier and it seems the culture here was less problem solving and more doing what was asked. Which mean a) the asks had to be more detailed and specific, b) it was more time consuming and c) they were more easily distracted and blown off course.

Conclusion and next

So there you go, there are some thoughts on life and challenges as a product manager. This is the way I find the Product Manager role. Personally, I don’t think this is much like it is in the books (and conferences) – with the possible exceptions of The Art of Product Ownership. But does this make me less of a Product Manager? Does it mean I should have a different title?

And now… the main project is coming to an end. I expect to stay with the same client so if you want like to tempt me to be your Product Manager get in touch fast!