One size fits none

Media_httptomfishburn_sfhup

 

Great post from Tom Fishburne about marketing’s tendency to aggregate and average out customer feedback.  He suggests a focus on ‘jobs-to-be-done’ a la Clay Christensen but I think it applies in so many ways.

I think the key is to understand the context in which the item will be used which can then help you to identify the different audiences or user groups your product might apply. Let’s consider a simple enterprise software example such as a CRM system.  You might have some people like an inside sales team that almost exclusively interacts with the system via their desktop.  Conversely, your face-to-face sales team is on the road all the time and craves mobile support. 

In both of the examples, the jobs-to-be-done are the same (updating CRM system) but the context in which that job is to be done is strikingly different.  When both of these groups discuss what is important, they rarely will agree since their context are so different.  As a result, there is fragmentation in priority and other things that are common to both audiences (but often less valuable to each) get prioritized.  As Tom put it the application owner will ultimately “average out all of the feedback from consumers, ending up with one-size-fits-none products.”

The Cloud is like a teenage driver

Nobody is shocked when they hear the teenager just learning to drive got into an accident. After all, even with the safest car on the block, the kid just lacks the depth of experience.

Maybe that’s the same growing pain we’re seeing from some of the recent outages at many major tech providers over the last few weeks. Maybe we simply lack the depth of experience? We think we know what to do but aren’t really prepared for situations that occur just 1% of the time.

Developing processes, buying hardware, staffing up, increasing complexity…. Making those significant investments just for something that just happens 1% of the time. Tough to get 20x return on that stuff. Tough to justify when the “accidents” just hurt you.

Now imagine that teenager is driving a bus full of people. Those 1% situations switch from potentially doing harm to just a few to endangering many. After all, they are providing a transportation platform for anyone willing to pay.

Isn’t this the same for our cloud providers that supply many others with platform-as-a-service? Now when Amazon or Google hits a rough patch, the thousands of others riding on their platforms get tossed around too.

I’m confident that our teenage drivers will get better. They will gain more experience, plan better, get help, and most importantly realize their actions (or lack of action) can and does impact others.

Let’s hope the leadership of the new guard for cloud computing are brave enough to fight for funding to take today’s platform offerings from ‘good enough’ to ‘great’ since we are all now getting on the bus.

A baby named innovation

Skeleton for blog post. Having a child is a serious commitment. Newborn can’t do much, completely dependent, lots of personal care and nurturing.
Toddler learning about the world, how to think, communicate, etc.
Elementary school to learn and master more basic skills, social skills, etc.
Tweens are awkward and insecure.
High school gain confidence, master specific skills, preparing for adulthood.
College almost on their own, entering society as individual.

During each of these stages, parents need to apply differing levels of discipline, support, understanding, and guidance. Well innovation goes through these same phases of maturing. But many innovators dont have the skills and/or

Capability vs. Context

Might not get it all out but the essence of this post is about whether we need to be building technology based on context rather than capability. More and more there are great capabilities available but they fail to reach the desired adoption by the target user base. Why? I think it’s because they lack context for how/when/where/why the user needs the capabilities.

Agile user stories are effective because they provide some level of context… As a (audience), I want to (capability) so I can (goal). Both audience and goal gives us more context to understand how/when/where/why the capability will be leveraged.

A trend I’ve noticed about my successful work over the last few years is that the designs were directly influenced by understandinqg the context of the audience. Not just the job my product was hired to do, but the context in which that job is to be done.

Apps store success – many capabilities already optimized for a specific context (small screen, limited bandwidth, etc)

Blah blah blah

Adoption – fun versus efficient

I love how this diagram highlights that the adoption of ‘fun’ things is much more viral than the adoption of ‘efficient’ things. Of particular interest with this diagram is that it considers older innovations and how they took off. This is part of the allure of gamification…. making things fun.

Unknownname

This diagram is from the article “Household appliances and the use of time: the United States and Britain since the 1920s” by Sue Bowden and Avner Offer.  It was published in The Economic History Review, Volume 47, Issue 4, pages 725–748, November 1994.  

Do I contradict myself? Very well, then I contradict myself, I am large, I contain multitudes.