Splitting, Refraction and Facets


Chatting with Steve and Tobbe – we were discussing refraction – light going into a prism and then splitting into a lovely rainbow. It is useful to slightly separate things and it can help us to clarify terminology.

A good example is the term Product Management – I was asked for a definition – so my first place of reference was ‘Escaping the Build Trap’ by Melissa Perri – with an excellent description of the role of a good product manager. This helped a lot – and when I looked into the situation a bit more, I realised that there was more to it. In conversations, not only did we start mixing together the terms Product Manager and Product Owner, but there was something else that was more than the role.

The landing point was to split it out into a few different facets; Profession, Role, Skills and Process – there could be other facets – these were the helpful ones for the recent conversations.

The Profession of Product Management grew from marketing and brand management and has evolved as organisations place more focus on Customer experience and the technology supporting that experience. In some places your career could take you through a range of product management roles all the way up to CPO – Chief Product Officer.

The Role of a Product Manager is to be able to articulate the ‘why’ of a product or feature so that the various teams can build the ‘what’. There is a lot more to it than this – but this is also where it is useful to split out the role from the skills and process facets.

The skills of Product Management need to be performed by many roles. There is the skill of stakeholder engagement to understand needs, goals and drivers. Being good at this skill means that the skill of prioritisation gets a bit easier. Then there are other skills such as data-driven decision making – all of us could use some of these skills in our work activities and we certainly should develop enough of these to be able to understand the outcomes we are aiming for (not just getting the bit of work done).

Product Management in Processes was a bit of a surprise when I noticed it. If we think about large organisations that allocate a certain percentage of time to innovation, this is an example of it. The organisation has prioritised innovation – allocated effort (which is time and therefore budget) with the outcome being to identify and develop new opportunities. The decision about the amount of time to dedicate and the level of priority is a product management decision that has been adopted as part of the regular planning and scheduling process. I’m certain that there are other aspects of product management that we could embed into processes and I will be looking for them.

I have previously blogged about the gradients of misinterpretation – those are still there, in this example there are gradients between one ‘end’ of the definition of Product Management and the other ‘end’. The point of this post is that is can be useful to put a definition through a ‘prism’ and split out some of its aspects or facets into discreet chunks.

“Need to Know Framework” derived from the PRISM

Trying to work out what you need to know and which information is most relevant at a particular time is like trying to hit a moving target. Not impossible but many factors play a role in the result. We all know that things change, yet we can fortify ourselves by becoming aware of which factors can impact us either directly or indirectly. Even factors out of our control can be planned for and risks mitigated.

The idea of a “Need to Know Framework” is actually an acknowledgement of how things used to be. The traditionally small groups of people working and existing together, organically gave rise to a sharing of information and knowledge, each person knew what the other person was doing and a network of awareness of the whole developed naturally. In the modern workplace the scale actually prevents the easy flow of information between indirectly but still connected groups. The recent ideas of tribes, regularly scheduled meeting and intranets etc. all are modern devices to try and replace the paradox of increasing isolation in larger groups.

So the only way forward is to begin at the level of the individual and instil a sense of “the Whole”. It is only when we appreciate the perspectives and requirements of others in the group that the greater good of “the Whole” moves forward. Some of the greatest advances in human history have only occurred when a discipline is examined from another perspective.

The need to understand the interconnections and dependancies that impact our tasks, is crucial to the understanding of the environment or “ecosystem” that our body of work will exist in over time.

It is essential for us to examine and determine which information and facts we will require. The resulting maturity that will develop, if we attain this perspective will be essential in helping us to reach our goals. The byproduct of striving to this end will be an increase in “Transparency” and a Need to Know Framework where each piece of information, can easily be prioritised into impact and according to our specific needs.

So how do can we get to this point?

Well it is only when we realise that just focusing on the immediate and specific task at hand, although seemingly efficient is actually detrimental to the ultimate whole. When any one thing is focused upon solely the result is always that the whole suffers. This does not mean that concentration on a particular task is bad but that any task no matter how small must and should be considered as part of a larger system. It doesn’t matter if your API is perfection, well coded, efficient and a masterpiece if it can not interact with its larger ecosystem.

So how do you generate a Need to Know Framework” ?

The inspiration for this comes from newtonian physics, in particular Refraction of light through a Prism.

Using the PRISM we can utilise the colours as indicators of the Importance, Directness and Impact of Information.

Centrally at Level 1 (RED) would be the direct and immediate information required for you to do the task, and the task only with little or no appreciation of where your task fits into the larger landscape. This is the equivalent of just in time management.

Next at Level 2 (ORANGE) is the knowledge required to perform your task and deliver it.

Level 3 (YELLOW) is information which helps you locate and position the task at hand, within a slightly broader framework. Such as knowing how it will impact and interact with its immediate neighbours or dependences.

Level 4 (GREEN) is information which is not usually considered required but when obtained frames and allows the project or task to comfortably sit within the broader landscape. This type of information aids in allowing you to grasp the interconnection between your task or project and those not directly involved, the first cousins to your work.

Level 5 (BLUE)  this level of information frames you task or project in the broader environment, with awareness of interconnection and nuance between the up stream and down stream relationships.

Level 6 (INDIGO) this level like the colour is between BLUE and VIOLET, the interconnection and interdependencies of all the tasks and projects, yours included and the information required to distill the over arching “5 Year Plan” or Vision..

Level 7 (VIOLET) this is the highest level of separation from your work, and as such is not often seen as essential or even required. Yet, it is the guidance under which all your tasks and projects have been organised to function within. This is the “5 Year Plan” or Vision developed from the Level 6 (INDIGO) information when evaluated and seen in the light of the company in the Global Economic and Social Ecosystems.

Agile Governance

Or…How it is Difficult to Understand a Thing if you don’t Already Know the Key Thing

Governance is a word that throws me off – wondering what it really means.

It’s supposed to mean having clarified roles, accountability and responsibilities.
It means understanding how decisions get made and who makes them.
It means making sure that policies are in place and that processes are monitored to ensure that they are working as intended.

It’s tricky to explain governance in agile when people don’t already have a good grasp of governance in traditional organisational constructs.

It’s similar to when I was a new video editor and our organisation bought a fancy piece of equipment called an ADO – Ampex Digital Optics (It flew a small picture around the screen and cost over $100k AUD in the 1980’s/90’s…now you can do the same thing with free software).
We did not purchase the training reference materials and only had the operating manual – which kept stating to do this, that, or the other with a thing called a ‘keyframe’.
I had no idea what this keyframe thing was – and the glossary was not helpful – so I stressed and tried a few things – and eventually called another video editor who was more experienced and asked him.
He explained that in any movement from point A to point B, the key frames would be the start and end point (so you basically put the small picture into the spot you wanted it to start at and press the ‘keyframe’ button and then move it to point B and hit ‘keyframe’ again – then the small picture would move from point A to point B whenever the effect was run).

Once I understood what a keyframe actually was, the whole machine was unlocked and I could use all of the features – but until I understood it, I could not even start to use this very expensive machine.

Back to governance and agile – when we understand how decisions get made – it’s quite easy to translate roles such as Product Owner into an organisation – the same decisions are being made – we are packaging them in a different way in agile teams.

When governance is not well understood, we end up circling around definitions for Product Owner etc – we are already causing confusion by introducing a completely different way of working. And on top of that, we need to break apart the decisions, accountabilities and responsibilities and place them into the daily planning, checking and doing aspects of agile delivery.

A way forward is to spend some time ensuring that the governance principles are better understood for the pre-agile ways of working and only after that, attempt to translate into the agile context. It feels like taking a step backwards – and it is much better than going around in circles and talking at cross-purposes.

If governance was never really there in the first place – this is one reason for the impression that governance is absent in agile.

Personal Philosophy 101: No Solutions, just Tools

Personal Philosophy 101: No Solutions, just Tools.

In a world driven by a culture with a need to compete, complete, deliver and rapidly produce. I put forward, the simple personal perspective that there are no solutions, only tools and choices.
The need we all feel to deliver a “solution” for our customers and ourselves is admirable but it also has a much darker side and consequences. The unspoken idea that we can give people and organisations a solution, can be very harmful and blind us to the true solutions. The cold hard truth is that we can not give anyone a solution to anything, we can only provide them with tools, which they can use to help find their own solutions.
The underlying premise is that only “self” can find the “true solution” because only self can know the factors needed to solve anything often with many conflicting needs and consequences. To complicate the process even further, often these factors specific to attaining your true-solution are partly or mostly unknown. Therefore, if the self doesn’t know the required factors to attain the true-solution required how can a third party give them a solution?
It is this philosophical viewpoint, which leads me to the personal view that regardless of saying we deliver solutions, we actually can only ever provide tools so the client (“self”) can determine their own solutions.
We can provide options, opinions, advice and other tools but we can not actually quantify completely their requirements and the level of “hardship or discomfort” the client would find acceptable. In actual fact, they themselves, often are unaware of some or most of these factors, when they engage you to solve their “issue”.
The “solutions” we provide often become band-aids because of this very fact. If we do not know the complete environment, how can we provide a solution? If the customer is not aware or educated about the options, constraints, and issues how can any “solution” they ask for be anything but a band-aid? Just like a band-aid, these solutions sit on the surface and never actually become part of the “self” or culturally absorbed. The true-solutions are derived from “self” only when awareness of the goal and the issue matrix surrounding the goal are realised.
This may seem an unbeneficial viewpoint, yet if you and your staff understand this, then this acceptance will liberate and empower them to focus on the why and what-ifs.
Consider the developer asked to provide a solution for a customer, the first step is to usually focus on the constraints of the solution, not the issue matrix for the customer. In this step we immediately become solution focused not customer focused. Then we focus upon the constraints of the individual technologies we force upon ourselves to be used, not the evaluation of the best technologies or processes for the particular case. Again solution focused and constrained.
If we see our job as to provide tools we more easily embrace the path of discovery through discussion, communication, advice, options, and opinions and avoid the pitfalls of assuming the responsibility of a flawed band-aid solution.
The old saying “The customer is always right” always annoyed me, even when I worked retail. The simple fact is that if the customer knew what they needed, they would not need you. Your role is to help them make a good well-informed decision, your job is to give them the tools to do so! It is then up to them to decide their appropriate course. Some customers only focus on cost and then complain, others focus on brands and then become frustrated (you can’t complain when you spent that much). A few customers realise they need help and trust you will do the right thing by them. They are the customers you want and need to try and develop through education and together we may move a little further towards a better outcome, a true relationship.

The thing that holds the thing that the Stakeholders were holding

So we all know about stakeholders…those people that care about what we are doing and should have a say in what happens.

Are there also people that care about the thing that the stakeholders care about that we would not call stakeholders?

What does the ‘stake’ mean when we refer to the stakeholder? According to Wikipedia, the term originally referred to the person who temporarily held the stakes from a wager until the outcome was determined. Business has since co-opted the term to mean people interested or impacted by the outcome of a project.

Tobbe and I were having burgers for lunch today…they were so tall that they had skewers in them to keep them together. So the chef held the skewer (stake) and we held the skewer when we ate the lunch, but the person serving us never touched the skewer…just the plate that supported the burger with the skewer in it.

That got us thinking about what supports the interests of the stakeholders, and yet, is not a stakeholder of a project or outcome?

It may be what we call governance. The scaffolding in an organisation that ensures that business interests are looked after…ensuring that our burgers arrive safely and without toppling over onto the floor.

Assumption Pillows – Lightning Blog

Expanding the thoughts behind a recent tweet of mine.

‘Pondering….less obvious reasons…generate ‘pillows’ of assumptions…and are ineffective cushions against the sharp rocks of risk below’

Assumptions are like pillows – they are very comfortable and we are not aware of them for much of the time. The trouble is that our assumptions and the assumptions of other people that we are working with are likely to be different. When we don’t inspect our assumptions, we can overlook risks – so that is why our assumptions are like pillows.

It can feel like a waste of effort to inspect our assumptions – there are ways of working them into a workshop facilitation plan – that’s the easiest one to address.

Another way is to be aware of the feeling that something is not quite right in a conversation. Once I was negotiating a contract and almost starting to argue with the other party about a particular point – both of us thought that the other one was being a bit unreasonable. After a short break, we took a moment to clarify what we were discussing and it turned out that we both agreed the point, but had been discussing quite different things before the short break.

The main risk that assumptions cause in projects is delay. If we find ways to highlight assumptions earlier we can save wasted effort in circular discussions, rework or duplication.

It’s better to see the sharp rocks of risk than to cover them with assumption pillows.


Welcome to the first in my lightning blog series. This series is for the ideas and observations we all make during our daily lives and rarely share or have time to explore them.


The rule of threes is an observation I made while trying to save energy and money by examining and swapping light bulbs and the mode of generating the emitted light.
Sounds great and very intellectual but as usually happens you do something and then upon reflection realise there appeared to be a pattern. I actually was just trying to swap over to the newer 6 Watt LED bulbs, I had recently found in my local supermarket, to save money because my energy bills are creeping up there and starting to hurt (mother of invention).

I had swapped all the lights in my house with these 6 Watt LEDs, except for the two main lights in my kitchen and the dinning area. The reason these two lights hadn’t been swapped over, was that they were 18 Watt Fluorescent tubes. Well, finally the day came and I had decided it was time to do the swap. When I began to remove the fixtures, I noticed that they were not the original fixtures but had themselves been replacements for the type of light that was there previously. The original light fixtures were actually lamp holders, just like the type of fixture I was installing, great less touch up work.

Then it struct me, when the house was built the dominant form of lighting was incandescent bulbs. Incandescent bulbs ranged usually from 100 Watts to 60 Watts in your typical single light fixture for a room. Yes they made smaller bulbs 40 Watts and even as low as 20 Watts, but these were usually the bulbs used for bedside lamps or in chandeliers. The most likely scenario was that the original lamp holder would have held a 60 Watt bulb due to the small room size.

So what we had was a situation where if they had put a smaller bulb than 60 Watts the room would be poorly lite, however at the time, the more cost effective technology of fluorescent lighting would have meant a 20 Watt florescent tube would have given more light than the 60 Watt incandescent for a third of the cost. In fact the florescent tube would have probably given out the equivalent light from a 75 Watt bulb or more.

Now the fluorescent tube I was replacing was in fact, a newer more efficient 18 Watt florescent tube. Yet it struck me that I was now installing a 6 Watt bulb that was one third the wattage of the one I was removing. I also realised that the fluorescent must have been replacing a bulb at least three time the wattage as itself.

The rule of threes or thirds was born.
So did this mean that only when something became three times better or more efficient or used a third of the energy or effort, that we actually muster enough motivation or pressure to change?

Can the rule of threes be seen in other areas or even help us to decide when retooling or changing the way we work is most beneficial?

Like I said observations and ideas only in the Lightning Blogs. Food for thought and I hope the rule of threes or thirds may help in some way to guide you in your decision making.
Yes I know wattages do not equal Lumens but for simplicity, I didn’t go into that.
From Wikipedia : The luminous efficacy of a typical incandescent bulb is 16 lumens per watt, compared with 60 lm/W for a compact fluorescent bulb or 150 lm/W for some white LED lamps.

PS. Careful how you pronounce, The Rule of Thirds, it could be misunderstood as something else.

Complex in Hindsight

When we reflect on a complex event, it often looks predictable in hindsight and this makes it harder to deal with complexity in the future. This post is about complexity in the Cynefin sense – where it is not possible to see linkages between events beforehand – but it is possible to see those linkages afterwards.

The two Cynefin domains that have high certainty are called Complicated and Obvious. The complex events that happened in the past – look like they belong in these domains – when facilitating sessions with people and asking if the past events were predictable, they will often say that they were. It is a good idea to double-check that this is the case – ‘are you saying they were predictable with your benefit of hindsight? Or if we went back in time, is it really an unpredictable set of linkages?’

It is useful to take examples of past events and create a Cynefin Framework from them in order to create a shared understanding among a group of people. The Cognitive Edge Method to do this is called 4-points or 4-tables contextualisation. Once the Cynefin Framework has been created, the labels on the groupings of events become very useful in the future. The group can then say that an upcoming event is like one in the framework, and if it is in the Complex Domain, use an exploratory approach rather than a project management method more suited to the Complicated Domain.

The main ‘gotcha’ with using historical events is this one – that the complex ones do not appear complex in hindsight – so be careful when facilitating that this is not a factor – otherwise, the Cynefin Framework created will have more examples of high-certainty events than actually exist in the environment.

Polar binary paralysis, the current social condition.

So what the hell does that mean?

Well in our modern society and culture we tend to see things in Black and White. There has to be a winner and a looser. We tend to see things in absolutes, all or nothing, off or on always binary. Now if you acknowledge this basic fact about our society then you are closer to seeing the issue.

While a binary view of the world is helpful in decision making and rapid responses, which makes us feel more efficient and therefore superior, it also is a very unnatural state. The world is not binary, yes you can define parts of it that way but when looking at the entire system it is more complex and interlaced. There is rarely a binary condition, physic has understood this and made a branch called Quantum mechanic.

So what is the problem with our binary view?

When we lived isolated and disconnected lives a binary view was easy and extremely helpful but as society becomes homogenised, the binary differences become grey and complex. We enter a Quantum state where there can be complex states, off and on at the same time.

I have always explained that most of us when faced with a decision, consider there are only two option positive or negative (Yes or No) but in reality there is always a third option. The third option is actually what I call a Zero state, so instead of positive or negative we also have a Zero. This zero state can range for “wait and see” to do nothing, yet its very passive nature makes us consider this not an option.

We have been trained to polarise in one direction or another. What this means is that in our modern society there has to be a winner and a looser.

We have all seen it recently with Brexit and the US presidential election. There must be a result therefore one side wins with only a fraction of a percent more than the opposition. The winner seems also to state that they have won with a mandate from the electorate. So our desire to have a winner means we end up splitting hairs to find a winner, Polar Binary Paralysis.

There is no middle ground or balanced view only polar opposites which are often shadows and reflections of the other.

Discovery and Re-discovery

We’ve been discussing the concepts of ideation and the workshop activities that we do to generate ideas. These activities use the intent behind ‘brainstorming’ – not that I am recommending the common form, let me explain why.

The method that springs to mind when we mention ‘brainstorming’ is for a facilitator to capture ideas onto a whiteboard while people call them out. There are many issues with using the method in this way related to good old human nature such as our tendencies to focus on the first theme mentioned or our tendency to defer to people in positions of perceived higher status.

No BrainstormingThere are many better ways to generate ideas from design thinking and other facilitation approaches such as

  • Silent brainstorming
  • Rapid sketching
  • Surfacing assumptions and generating hypotheses

What if we are working on a big, important goal? There are many questions that we overlook because it’s easy to make the assumption that once was enough and doing a process of discovery again might generate more work than we desire.

  • Should we facilitate only one of these idea-generation sessions with one group of people?
  • How can we know if we have looked at the goal from enough angles?
  • If we should do it more than once, then how many times and how much time between the sessions?

Perhaps this is the original intent behind governance processes. We know that humans are very creative and are likely to learn much at the beginning of a piece of work that leads to more interesting ideas as we proceed. In an idealistic world, the process of governance is a way of checking in with a bunch of smart people to help us identify key decisions and make those decisions in a timely manner.

Those same smart people can also assist with identification of the needs to re-discover – perhaps they have learned something useful from elsewhere that could help us to reach our goal sooner or obtain better outcomes. This new information might be a reason to facilitate another ideation session – but how many of us would want to set that up? It seems much easier to take the new information and simply work it into our current set of tasks.

How can you tell and why should you revisit old ground?

Things change, information is not static and the believed facts can also change with time as a better understanding is developed.

So if we acknowledge this reality then the attitude that we should only plan, then act, denies the fact of change. Imagine a set and forget toy on a table, the inevitable outcome is that it will eventually fall off. This is the very reason why biology, engineering, mechanics and programming are full of feed back loops and reiterations, so monitoring and corrections can be made. It is naive to think our projects are somehow exempt from change.

The size, complexity, number of inter-dependencies all increase the requirements for re-discovery, so we should always be asking ourselves if it makes sense to continue, or to pause and do some form of re-discovery at regular intervals.