Monday, 26 August 2013

On innovation and management

In the past month I've been reading a lot and two particular articles caught my eye. The first article I found interesting was a case study by Suleimanagich  (2013) of how even successful implementations of new technology, e.g at the project level, doesn't guarantee success if the company strategy isn't correct.This is the story of how Kodak had invented a digital sensor before any digital cameras were available on the market. This seems to be a common assessment of Kodak's fortunes - they slipped up by not pursuing the innovation - for example "Kodak's Missed Opportunities" by Bergstein (2012) or The Economist's (2012) "The last Kodak moment?".

So at this point in my journey I was thinking, why did Kodak fail? Which brings me onto the second article I found interesting this month. Avlesson and Spicer (2012) puts forward a stupidity-based theory of organisations, could this offer an explanation on why Kodak failed? Did Kodak suffer from what they describe as a "functional stupidity"? They describe this as:

"functional stupidity is inability and/or unwillingness to use cognitive and reflective capacities in anything other than narrow and circumspect ways. It involves a lack of reflexivity, a disinclination to require or provide justification, and avoidance of substantive reasoning. It is related to the intertwined elements of cognition, motivation, and emotion. In many cases functional stupidity can produce positive outcomes in the form of significant benefits to organizations and employees. The narrow and circumspect use of reason, high levels of means-ends oriented intelligence, and the partly positive outcomes, differentiate functional stupidity from ‘pure’ stupidity."
(Avlesson and Spicer, 2012, pg. 1201) 

Going by the CEO's interview in 1995 they certainly seem to have had the his backing, although there is evidence of some lack of reasoning through this quote from a former engineer:

“He told my boss to tell me to stop writing computer proposals, because Kodak would never be a computer peripheral company…not on his watch, at least.”

by why would a senior executive be so against opening up a new market? one clue is earlier on the article where an 800% mark-up on the production costs of a roll of film is mentioned. In that environment you need what the Agile community calls safety - a sense that some risks and the potential to fail are not allowed by how you learn on your way to becoming successful.This blog post by Elssamadisy (2013) describes safety and how productive and high quality agile teams need it.

An alternative theory based on work by Teece (1986) is that for an organisation to make maximum advantage of innovation it needs control of complimentary assets, for example knowledge or products. In this case the sensor and digital image recording is only one component of a camera, Kodak did partner with a Nikon and Canon to produce early high end cameras but they were bulkier re-badged versions of the original cameras. Both companies soon developed in-house digital ranges as the technology matured, Kodak didn't have control of the product so it was easy for the market to slip away from them.
Reading around the subject a bit more I have found a Fortune article from 1995 (Nully and Rajiv 1995) where apparently the main issues were known by the CEO at the time and he did want to build on the digital products. The Economist (2012) is rather damming in its assessment of Fisher's leadership in this period and the outcome for Kodak. Perhaps that's the key, the management at the project level worked, in getting the first still digital camera system, but the leadership throughout Kodak was not suited to what they had. More on innovation and leadership later ...

References

Alvesson, M. and Spicer, A. (2012) "A Stupidity-Based Theory of Organizations". Journal of Management Studies, 49: 1194–1220. http://onlinelibrary.wiley.com/doi/10.1111/j.1467-6486.2012.01072.x/abstract 

Bergstein, B. (2012) "Kodak's Missed Opportunities" 19 January 2012, MIT Technology Review Available at http://www.technologyreview.com/view/426647/kodaks-missed-opportunities/


Elssamadisy, A. (2013) "Why Are Most Agile Adoptions Failing?", 20 June 2013, Industrial Logic, Available at http://www.industriallogic.com/blog/why-are-most-agile-adoptions-failing/

Nully, P., Rajiv, R. (1995)  "Digital Imaging Had Better Boom Before Kodak Film Busts". Fortune, Vol. 131 Issue 8, p80-83.

Suleimanagich, K. (2013) "Kodak’s Problem Child: How the Blue-chip Company Was Bankrupted by One of Its Own Innovations", petapixel.com, http://petapixel.com/2013/06/10/kodaks-problem-child-how-the-blue-chip-company-was-bankrupted-by-one-of-its-own-innovations/

Teece, D. J. (1986) "Profiting from technological innovation: implications for
integration, collaboration, licensing and public policy", Research Policy, vol.
15, no. 6, pp. 285–305.


The Economist (2012) "The last Kodak moment?" 14 January 2012, The Economist, available at http://www.economist.com/node/21542796

Tuesday, 20 August 2013

On user experiences and needs

The Amadeus blog recently posted an interesting take on the fad "less is more" in a post entitled Why the ‘less is more’ concept in software design often falls short of its intentions. At first I agreed wholeheartedly as the title and intro had lead me into some nice confirmation bias ("grrr! gosh darn those gurus selling us different flavours of snake oil every year!"). Then I thought about it a bit more and the new feature being discussed was meeting a need; people wanted it and were pleased it was now present. That made me think that there was possibly some effective product management going on .. lo and behold the post was written by a product manager! This sentence was the most telling :

"how we define the worth of adding more features. For me, it is worth it if you are doing something for the human being who will be using the feature."
So a focus on user need is important, as if by magic later that day I read the brilliant post  How to Work with Designers that suggests the way to get the most out of working with designers is to focus on user need, for example:
"... the language here matters. Make it easier for users to sign up vs. Optimize the conversion rate on the sign-up flow. One approach speaks to the value for the end user. The other approach focuses on what the company needs to do to be successful. Designers generally think and operate in the mindset of the user."
I think this is actually useful advice for all the project team, let what the user will see and/or experience be the lens through which you see that fancy new feature.

Looking at the other side of the fence from a developer's point of view Sometimes less is more in language design probably explains some of the original intentions above. Simplicity should be the base and complexity layered on top as needed, you shouldn't start off complex otherwise things will get unwieldy.

An example from my real life, recently I've moved office building and the new kitchen has a "fancy" microwave. Most microwave ovens I've used have two dials - time and power - and at most two buttons - start, stop/open door. These covers pretty much anything I'd want to set on a basic oven. Unfortunately the makers of this microwave had decided it would be useful to let the user alter the time and power in combination according to the weight and type of food being heated up. This means it has various buttons and an LCD display. It took multiple attempts (including resetting the clock!) before the floor's receptionist rescued me and told me I had to press start for each 30 seconds I wanted to heat it up and then wait, after a short pause of no buttons being pressed it would heating. Here more is most definitely less, it doesn't meet any unmet need I had and is much harder to use the basic functionality.

Another more practical example of when less really is more in the world of IT products came in the Tnooz article Why we ditched mobile and hitched to tablet gives a good example of how when you know the market and have data on how it works you can make decisions to concentrate on features that are useful and meet a need. Although going mobile seems a no brainer and a good feature to have, that's if your product is in advanced booking it might not be the best option. Here is Anshuman Bapna describing how took the decision and viewed the experience they wanted to create:
"we always thought that travel planning should be a lean-back, sit-with-your-partner-on-the-sofa, browse-a-magazine kind of an experience. That screamed tablets, not mobile phones.

So to begin with, we decided to ignore mobile."

So, "less is more" seems to be a poor phrase to use as a guiding principle in product development; and can lead to frustration and miscommunication between different stakeholders. If you're going to use a single phrase I would prefer "build the right thing", the right thing can be a bit vague but I'd try and use these two principles to find out what's right for now:
  • focus on the user needs
  • use your experience in the market place to the maximum

Further reading

Prioritizing Joy By Drew Colthorp at Atomic Object (Posted August 20, 2013) a slightly different look at building the "right product, instead of merely the most feature-complete product." including brand and emotional response.

Sources

Why the ‘less is more’ concept in software design often falls short of its intentions Amadeus blog by Jean-Noel Lau Keng Lun Head of Product Management Corporate, Services and Security, Amadeus IT Group (posted August 1, 2013)


Why we ditched mobile and hitched to tablet Tnooz "Special Nodes" blog post by Anshuman Bapna, CEO and co-founder of mygola, a trip planning portal. (posted August 15, 2013 )

Sometimes less is more in language design "Haskell for all" blog post by Gabriel Gonzalez (posted August 2, 2013)

How to Work with Designers Medium post by Julie Zhou (posted August 15, 2013)

Confirmation bias entry on Wikipedia

Starting text mining with R

Like a lot of Product Managers I use Excel with tools like Google Analytics a lot. Probably like many people I find Excel very frustratin...