As product managers, one of our core responsibilities is product strategy. To this end, we often read about strategies adopted by other great companies to see what we can learn from them. In this guest post, product manager Arfan Ismail explains why what has worked in one company—even if it worked spectacularly well—may not necessarily work in another one, and employs an example from World War II to help illustrate his point.
Here’s a simple historic example of a cargo cult:
During World War II when US soldiers were stationed on in the South Pacific Islands, the indigenous population witnessed the soldiers flagging overhead cargo planes which as a result dropped supplies onto the ground for their soldiers. The soldiers then shared some of these supplies with the islanders. After the war ended and the soldiers left, the islanders still hoped to be able to get supplies from cargo planes. They repeated what they saw the soldiers doing, i.e. waving flags for the cargo planes. When that didn’t work, they built their own bamboo cargo planes thinking the existence of a plane, any plane was the cause of the rations being dropped. After their attempts were unsuccessful, they realized there was no direct cause and effect.
I’d call this the idiosyncratic principle. As I learned early on in my doctoral studies, context is king. The most challenging this on earth is trying to find general principles that will work across multiple contexts. Understanding cause and effect is not easy. Understanding correlations is easy and can be measured but there’s a difference between correlation and causation. Pinning down the latter is far more complex and is one of the quintessential distinctions between the physical and social sciences, where replication is often straightforward in the physical sciences using, for example, mathematical models but in the social sciences, this is far more challenging. I’d argue this is due to the intensely complex nature of human cognition or as David Chalmers calls it the hard problem of consciousness.
What’s this got to do with product management?
Business strategy as it is studied in business schools around the world is about trying to understand what worked at great companies, successful companies, profitable companies and apply it to your own company. The way this is done is no different to any other social science discipline. It involves a lot of observation, data crunching and then the extraction of general principles. From this, for example, we’re taught that the best companies practice certain forms of management, such as management via outcomes, and don’t practice others such as micro-management (yep, we’ve all had those managers in our time, they make life difficult). So product management is part and parcel of this process. Great companies make great products. Shortly after, successful academics and professors move in to study what made them great and their practice gains currency across multiple contexts. With the proliferation of media such as this one and other blogs etc. often the professors and academics get cut out and so the usual academic rigour is missing from analysis which makes the findings that much more problematic.
As a result of the above process, we have a range of different frameworks, ways of working, methodologies, and processes that we’re told will lead to leaner, quicker and more iterative product delivery. All we need to do is read the right books and blogs and watch the right YouTube videos (like this one and this one from Spotify) and you’re ready to go.
The problem is, and it is indeed a problem, that humans generally don’t behave the same as other humans. What works in one context often doesn’t work in other contexts. Why is this important? Because it means that rather than simply learning a bunch of frameworks, it’s more important to understand the principles that underlie those frameworks, methodologies or processes. The reason this is important is that it provides for a deeper understanding and hence an ability to try to work out causation in your specific context.
There are a number of implications of the idiosyncratic principle. First and foremost is the necessary humility that goes with adopting any of these. Many organisations stress humility as a defining feature of their corporate culture, and this is a good idea. There’s nothing worse than working with a bunch of folks who have read a few books and blogs and then suggest that what they’ve learnt is the single best way to get anything done.
From a corporate perspective, I think there’s also an important implication that relates to the manner of any digital transformation or ways of working change- programme. The leaders of any such programme could do with understanding the theoretical underpinnings of the ideas they themselves are advocating. The benefit of those is that rather than adopting or trying to adopt a specific approach wholesale they can apply it in a manner that is more suitable for their idiosyncratic context. This makes a significant and important difference as the context itself will determine the success of the intervention. It’s not the ways of working themselves that will generate greater innovation and profitability but the embedding of these new ways of working in a manner that suits your specific context. It’s not formulaic in the same way f = ma is, it requires far more nuance and trial and error. It’s one of the takeaways of the Spotify videos I linked to earlier, that ways of working evolve and it is important to recognise that, there will be a process of trial and error to find what works in a given context.
As an individual, the implication I take from this is that it is important to understand not only the idea but the theory and philosophy underpinning the idea. This requires a desire and probably enjoyment of reading but the upside is considerable in that you gain a more rounded perspective on the frameworks or methodologies you encounter. As companies consider where to spend their professional development budgets then, an eye on at least some people going deeper is probably a good idea.
The distinction between complicated and complex work
Finally, it’s worth touching on the ideas of Dave Snowden and the concept of complexity. This is important because many of the underlying business principles extant today derive from engineering disciplines and more specifically from e.g. car manufacturers such as Toyota. The challenge here is that many of the business strategies that resulted such as total quality management were derived from processes that were complicated in nature but not overly complex.
The table below (reproduced below from here) shows the distinction between complicated and complex work. Without getting into the details of this, the key difference is that complex work involves higher levels of creativity and is therefore more subjective and more difficult to articulate as defined processes that are likely to work in multiple scenarios across different contexts. Complicated processes such as putting together a house, ship, car or designing a hotel are more amenable to this. Developing software is definitely complex work and as such not amenable to processes and models reserved for complicated work.
My view on this is this is that some generalisations are possible in product but should always be understood in light of the fact that the problems we as product managers are solving are complex and this requires maximum agility. I’d argue that in order to be agile to the maximum you’d need access to as many tools as possible and that means understanding the underlying theory behind the models, frameworks and/or processes you choose to follow. In the final summation, the cliche is there’s no right answer here but there is a right approach and it involves humility in knowing what we don’t know and the limits of what we do know.
Access more great content on Mind the Product
- Giving direction in product with Janna Bastow, Chiedza Muguti, and Nacho Bassino
- Evidence-based product decisions – Itamar Gilad on The Product Experience
- Beyond Amazon.com: Amazon-as-a-Service