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!

Summer is over, time to get back to the office?

When I started work I had my own desk. Even when I was a lowly systems administrator at Nixdorf UK I had a large desk with my own phone. A Z80 powered terminal and a laptop I’d “borrowed” from the repair stores.

A couple of years later I was on the team building the Sharp PC-3000, the third or fourth handheld PC (with the DIP team which designed the Atari Portfolio). On my first day I had to build my own desk: there was my space, there was the flat pack desk, I needed to put it together, it was almost a company tradition.

After graduation I was a programmer in an analysis team at Southern Electricity. My desk was always fairly clear and organised. Not as clear and tidy as Kerry’s – she could have won awards. But neither was it the big pile of papers that covered Murray’s desk. Occasionally a manager would question if his desk should be tidied but we knew it was his filing system. Other team members had family photos or certificates on their desk or mementos of visits to power station.

Above our desks were manuals both for the tools – a complex set of VAX VMS manuals, DEC Fortran, Borland Turbo Pascal and Turbo C++, later Visual Basic. Hidden away behind one desk was an illicit kettle with a jar of instant coffee and tea bags. Although I kept a small cafetière in my draws among my files. This saved us from paying 12p to the drinks machine which dispensed weak coffee and tea.

(And then there was the staff canteen, social club and even golf course!)

I mention all this to remember how offices and employers used to be. In those days teams sat together and your desk was your second home. A place you belonged. Today…

Desks are a lot smaller. Few people have their own desks, most hot-desk.

Hot-desking means teams don’t sit together. You sit with some random people you may never see again.

If you do have any personal belongings you either carry them in each day or lock them in a soulless locker at the end.

You carry in a laptop every day and carry it home at the end of the day – even if you never switch it on at home. (Maybe this is why everyone on the London Tube has a massive backpack these days?)

Desks don’t have telephones any more, nor do they have family photos, mementos and certificates, let alone files and manuals!

Each desk is the same and soulless. Employee space is a cost and employers have done everything to minimise it.

There might be a fancy coffee machine, and it might even be free, but its not yours. It is anonymous and likely serviced by minimum wage cleaning staff. Still, no need to arrange who’s turn it is to bring in milk.

Is it any wonder people don’t want to go to the office any more?

At the start of my career the office was a second home, your team a second family. Over the years companies have been “reducing the office footprint” and modern offices are clinical. If people want to stay in their own home, with their own family, is it any surprise?

Personally, I’ve had a office at home for a long time but I’m sick of it. I sometimes dream that someone will offer me a job working in an office 5-days a week with my own desk. Do such things still exist?

So, is it any surprise companies struggle to get people to come into the office? Companies have stripped their offices of the things that made them home and they only have themselves to blame if employees don’t want to be there.

While this blog may not have the big reader numbers of some blogs many of my readers are very loyal – my mail open figures are off the chart! Thank you.

I ignore many of the blogging rules I’ve heard advocated: short posts, tight topic focus, limit topics, keep focus both in the posts and across post. I’ve tried following such rules but it doesn’t last. Its not me.

In my mind you, my dear readers, follow me and my (sometimes) whacky ideas. I like to think we have a “special relationship”. Having said that, I’ll also admit: I write about what interests me, you reads seem to like that!

So I want to share something personal with you. I share it because I’m sure some of you will have had similar experiences. It is important to recognise we are not to blame. Sad to say that no amount of success seems to insulate one from this sort of thing.

About two years ago I got involved with a toxic client. I won’t go into details but in retrospect the client’s manager was a bully. I’d not been working with the client very long when I saw there were problems. I decided to tackle the problems face on and sat down with the manager concerned in an effort to resolve them.

Rather than resolve them I brought them to a head. The manager turned on me. In classic bully fashion it was all about them, how hard they worked, how many problems I created for them, the problems they faced. So I suppose I did resolve them but just not the way I wanted to! There then followed a few weeks where they wanted me to sign an NDA and I refused. That itself is a story but ultimately I called their bluff.

If anyone offers you an NDA to keep quiet remember: they want you to keep quiet for a reason, you have power over them. If they are clever they will realise that offering you a sum of money and then taking it away is probably more likely to make you share your story and it makes them look worse.

Anyway, this was all really bad for my mental health.

I had some counselling at the time and thought I had managed it but actually I hadn’t. It had completely undercut my confidence. I was failing to function properly. It dragged on, weeks and months.

I was slow to realise this but then two things happened. One of you, yes you readers, came to me with an idea. Something which I’d never thought of, it got me back in harness. Thank you.

Once I started working again I quickly realised how I wasn’t over the bullying incident. I was still carrying a lot of baggage. It wasn’t just the recent bullying, I was bullied at school. So I went back into counselling for several months.

In counselling I also came to realise that much of my internal logic stemmed childhood: both the bullying, the way schools treated me and the (now obvious) fact that my neurodiverse dyslexic brain doesn’t see things the way it is “supposed to” – I don’t share the canonical view of, what, some many other.

Take Project Myopia and #NoProjects for example. I’d seen Projects as crazy for years, it was only when Mary Poppendieck said the same thing over dinner in 2011 that I realised I was not alone. Slowly I started to say publicly what I’d only thought privately and ultimately write the book.

At the time my views on projects were career limiting. Not only could I never be a Project Manager but nobody who was doing a “project” (which was everyone back then) who checked out my social media would hire me.

But, I am not the only one who thinks like this – many of you readers do too! It is because I think differently, because I will say these things that I am immensely valuable and I suspect, why you read this blog.

So my dyslexic brain if both a curse and a blessing,

Back to where I am now.

I’m actually in a pretty good place now. My professional life is very different to where it was two years ago and I don’t think its every going to go back. I’m not sure what happens next, I have a couple of ideas but I’m in no rush to change.

Anyway, I wanted to share this with you for two reasons.

In the last year I’ve told several people about my mental health problems and I’m often told in return that they too have had problems. It seems a very common problem for people who have worked as agile coaches to suffer mental health issues as a result of the work. (I might talk about way that could be another time.)

Second, anyone can have mental health problems, and they are nothing to be ashamed off. In truth I’ve had mental health problems on and off my entire life. It is not because I am weak, it is because of things that happened during my childhood I had no control over – like being dyslexic.

Second my professional pivot leaves me wondering what happens next with this blog. I’m not giving up, I’ll keep blogging. I wanted to say thank you to my loyal readers, knowing some people value what I write has meant a lot to me during this time. I’ll keep up non-canonical ideas coming.

I might be known for speaking my mind, being honest and wearing my heart on my sleeve but there are some things I try to avoid talking about. There are time when I consciously bite my tongue.

Perhaps because I brought down the wrath of project managers with #NoProjects all those years ago I try my best to keep my mouth shut when people ask me about Change Managers and Change Management*.

A few years ago a contact asked “What is your chagne philosophy?”

Inside I thought “I don’t have one! Change is not a thing” but rather than say this I waffled. Since then, from time to time, I have glimpsed my change philosophy out of the corner of my eye. Let me try and break it down…

Fundamental my change philosophy rests on the belief that

People don’t resist change, they resist being changed.

Take those two parts separately.

People actually like a lot of changes: when you get a new mobile phone or other gadget, when you get a pay rise, when you change your location for a holiday and so on.

That is not to say people like every change but the changes people don’t like – and thus resist – are largely the changes they have no control over. Thus, if you start from a position that change must be done to people then resistance becomes a self-fulfilling proposition.

Therefore….

Enrol people in change, don’t impose change on people, respect them and make changes which they welcome.

(I almost wrote “put them in driving seat” there, while that conveys what I mean its not entirely true as in most cases there are multiple people on he receiving end and they can’t all be drivers. The moment one person becomes a driver everyone else becomes a passenger and that is exactly what I don’t want.)

Remember …

Change is a leaning process, some people learn faster than others and it is difficult to know what you will see until you have learned. So don’t plan too far ahead. Indeed, one person’s far sightedness can be another’s learning inhibitor.

Because …

Change is not the objective, focus on the outcome.

Talking about change in the abstract – a change programme, a change manager – is a diversion from the goal you are trying to achieve. Change is a means to an end but when we talk about change itself as a thing in is own right it becomes a distraction.

When people are part of a change which benefits them, i.e. makes their life better or supports something they believe in, then success breads success: focus on the outcome, take small wins and use them to motivate further action.

It flows from this that Change Managers, Change Programmes and even Change Initiatives create the most of the very problems they set out to address.

Instead, focus on the outcome you want to achieve and ask people to help.

Another loose end to pick up…

When OKR setting I’m very keen that everyone involved thinks “What is needed?” – more specifically, “What do our stakeholders/customers/users need?” or just “What will add value?”

The aim is to park the “can we do this?” and “how long will it take?” because to answer those questions you need to know what you are doing. And when you answer those questions you start to ask about details, and this all becomes a long conversation, especially when people doubt the information available (i.e. they don’t trust it or don’t want it to be right).

Getting such information also introduces a forward tail where with upfront pre-work. That creates scheduling problems and complicated everything.

Instead you want put customers and outcome first, assume that in the twenty-first century with technology coming out of our ears it is possible to do something which will move towards the objective. What that something is, is itself open to questions but something can be done. Even if it doesn’t solve the problem entirely.

Rather than set an objective by reference to what you can do, set the objective by reference to what is needed.

Remember: to any problem there is always more than one solution. The solution you choose will depend on other parameters like resources and funding. There are always options.

The OKR 2-step

Step 1: set the objective, decide the outcome you need to advance on

Step 2: think/plan/design how you will go about meeting the objective (or at least moving towards it)

Step 1 might be in the morning and step 2 in the afternoon. Or maybe step 1 happens this week, there is a week of feedback and refinement, then step 2. Just separate the discussions, allow your brain to think differently in each.

Of course it is entirely possible that when you come to do step 2 you decide that step 1 and the resulting OKR needs revisiting but that is a worst case scenario.

In truth it is always going to be difficult to completely separate the “what shall we build?” from the “can we build it?” and “what does the solution look like?” questions. If you don’t try you certainly won’t.

I apply this 2-step approach whether setting OKRs which are ambitious (moonshot, 10x thinking) or predictable (guaranteed delivery). When aiming for predictability its gong to be even more difficult to separate the what from the how but again try.

I mean, what could possibly be wrong with putting the customer first?

In recent posts about OKRs I promised to say something about eggs-within-eggs, I also promised to talk about the OKR 2-step. So, at the risk of creating a OKR mini-series here…

Objective egg

The objective – or outcome with my OACs renaming – is a goal, a target, something to aim for, and outcome you wish to bring about. But, as much as I’d like that outcome to be the end state in itself, more likely, it is part of a broader, longer, larger goal.

The thing about goals is they are almost always wrapped in other goals. Look at sports, like football: you score goals, scoring goals is the aim. But actually, those goals are are themselves part of a bigger goal: winning the match.

But winning the match is not the final goal either. Winning the match may help the team win the league this season. So the real aim is to win the season – or some other contest.

But even winning the season isn’t the ultimate goal. The team wants to continue winning, and to continue winning they need to make money. Even winning the season is a goal nested inside bigger eggs.

Now goals aren’t always so well aligned. The owners of the team may aim to make money, so although they want the team to win their make money goal can some times conflict with the winning games.

On the whole the individual players will have aligned incentives: win the match, be crowned the best player, bag a bonus. Possibly a player has other incentives, one recovering from an injury may have other concerns. Just possibly, a player has been offered a lot of money to throw a game, so they may be pursuing a personal goal which conflicts with the team.

Goals work best when there is alignment, small mis-alignments may not be an issue but big misalignments can be.

Misalignment probably isn’t nefarious

The same is true in our work. Taking a Machiavellian view you see lots of conspiracies for team and individuals to pursue alternative goals. However, I tend to the see goals diverging for more mundane reasons.

Goals aren’t communicated clearly: leaders say one thing but workers hear another.

Works see divergence between what stated goals and their actions.

Conflicts between different goals aren’t spotted, or nobody listens conflicts are spoken, e.g. cost effectiveness is a goal but so too is innovation.

Or simply, goals aren’t prioritised sufficiently: everything is priority #1, team A spend their time on goal Y while team B on goal Z and team C try and do a little of everything an get sidetracked somewhere else.

Try this at home

Try drawing your goals as one of my egg diagrams – like above. Start with your immediate goals, then the goal they exist within, carry on going for as many layers as you can identify.

Then check your company website: what are you stated goals? or missions? What about your values? Do they all align?

Now show this to others and see if they agree with your analysis or see things differently.

This is why I advocate a challenge-respond-discuss protocol, it is feedback. Leaders set out the bigger goals and and challenge, ask, teams to contribute. Teams respond (with OKRs) and then the two sides discuss and give feedback, they iterate towards goals which everyone agrees.

And this is where the outer eggs become more relevant: by understanding the different eggs and how they need to align all can work to build smaller goals they support bigger goals.

By not giving orders leaders test their own communication. If teams come back with goals that don’t align, or don’t seem to build towards the leaders goals the question is why?

Is there something the leader didn’t know?
Did the leader’s communication lack clarity?
Or maybe a team member had a insight the leader should know about?

If the team members misunderstood who’s problem is that? And more importantly, what can we do about it?

By letting team members decide for themselves not only do you enhance motivation and bring their knowledge into play but you get to debug your own thinking.

The thing is, you don’t get alignment by telling people. Simply adding OKRs to your way of working does not deliver alignment either.

Rather, you get alignment because this approach shows you where alignment is missing or where conflict exists. Because each goal is articulated and can be compared with others. Because these are seen by different people.

In short, you get alignment by working at it.