Practical Experience with Christensen's Innovation Methodology JOBS(R) Jobs-to-be-done when creating the Avaya Flare User Experience, Avaya Digital Video Device and Cloud Offer. Learning: Add focus on emotions.

Clayton Christensen's Jobs-to-be-done approach describe a series of steps to create innovation systematically. This article describes the application of the methodology to the creation of the Avaya Flare User Experience, the Avaya Digital Video Device and the related enterprise cloud offer. We found key for success is to add focus on emotions. And the result to be a condensed job description as more work is required to detail the solutions that it becomes testable against objectives and barriers. This blog is complemented by a slide deck in slideshare covering this topic. Disclaimer: The blog represents my opinions and not the views of my employer Avaya.

Practical Experience with Christensen's Innovation Methodology JOBS(R) Jobs-to-be-done when creating the Avaya Flare User Experience, Avaya Digital Video Device and Cloud Offer. Learning: Add focus on emotions.

View more presentations from vonreventlow

1.  Overview of the JOBS Methodology.

JOBS(R) ( atrademark of Innosight) consists out of 4 steps: Jobs-to-be-done, Objectives, Barriers, and Solutions.

1. Jobs-to-be-done is the description of the problem a customer tries to solve. Christensen suggests to create complete job descriptions in the form: (Customer) wants to (solve a problem) in (this context).
2. Objectives. These are the criteria the customer is using to select a solutions. Note this includes functional criteria "like should not cost more than" as well as emotional as well as social objectives.
3. Barriers. List those which prevent customers to potentially use solutions. Christensen points out the barriers are typically functional as "battery life time beyond 2 days".
4. Solutions. Create a candidate list of different ways the job could be done. And look for outages of existing solutions.

2. The Context of our experience with the JOBS methodology: What we wanted to achieve with the Avaya Flare User Experience, The Avaya Digital Video Device and the related cloud offer

Goal of the project was to move Avaya beyond voice: Add Video Conferencing and Web Conferencing to the portfolio.

3. Step One: Identify the Jobs-to-be-done.

We visted customers and observed users during virtual conferences (voice, video, web conferences). As part of the process we learned its important to start observing users substantially before the actual activity as well as after the activity. It allows to uncover further "Job-to-be-done" that can fuel novel innovation.

We captured our observations in the form above. Examples are: "Team lead" wants to "exchange information as effectively as possible" in the "distributed team" context. Or "Sales person: wants to "have the latest up to date information on the calling party as fast as possible" in the "inbound call" context..

We learned that "saving time" and "getting related information" are key elements.  These findings are crucial for the next step: Objectives.

Thus in addition to Christensen's method we suggest: create a list of objectives when writing the Jobs-to-be-done.

4. A new step added to Christensen's method: Use Show and Tell so that team members and customers understand the characteristics of great products: Emotions make great products.

Enterprise products are typically around solving pain points. However we not only wanted to solve pain points - we wanted to create a great product. To learn what makes a great product we asked project participants to bring products, tools or services they really loved. What we learned was: A great product is

1. Multifunctional AND simple to use. You would say no surprise.
2. Makes people's eyes shine when they use and when they talk about it. Note - this is pure emotions.
3. Feels good when you touch it. Note this is pure emotions.
4. One can learn how the complete product works in less than 5 seconds. This translates into: the user gets instant gratification. Again this is about emotions.

We learned that great products are around emotions and not only about solving pain points.

5. Step Two: Objectives.

We found the functional objectives to be straightforward. Here some examples:

• 100% of users wanting to save time
• 100% of users looking to get background information on the task at hand quickly. I.e. save time.
• 50% of users were looking for a solution that makes collaboration of graphically dispersed teams effective.

Based on the learnings from Show and Tell the soft objectives are THE key to create a great product. Here some examples for emotional objectives:

• 16% of users - the innovators and early adopters - want to show they are thought leaders
• The early majority (34% of users) want to make it safe to use the product. Note that specifically for senior executives face loosing is a substantial issue. (note we excluded the late majority (34%) and the laggards (16%) from the target audience.
• Users stated: "I don't want to waste time - i have to get work done"
• Users stated: "Needs to be fun to use - like in a game". This is about instant gratification - leading to shiny eyes.

And a number of examples for social objectives:

• For leaders -  50% say "I need to be in control"
• Be connected with the rest of my leadership team
• Effectively broaden my network inside the organization. Make me more visible. That makes me more effective and powerful (note this is emotional).

6. Step Three: Barriers. We added emotional and social barriers to Christensen's methodology.

We found the functional barriers of the current solutions. Examples are

• 35% of uses stated the quality/performance of current solutions is not good enough
• 20% complained current solutions are diffult to implement or
• 20% did see security issues as the barrier.

We found that there are a significant number of soft barriers. Examples for emotional barriers are

• 39% of uswers were concerend its more difficult to multitask in videoconferencing setting. Reason being one might face boredom.
• 35% raised increased nervousness presenting.
• 25% of users were concerned being controlled in a video setting.

And we identified social barriers as well. Examples:

• Group adoption might be required to make the solutions productive.
• The leaders might need to use the solution first.

7. Step 4. Solutions. We found the above is not enough to create solutions. We did derive a condensed job description instead.

We found that more work is required to create the solutions. The reason being that the solutions need to be sufficiently detailed to be testable against the objectives and the barriers. This instead we created a condensed job description that served as the focal point for next steps.

This is how it read.

We want to build

• A universal tool to collaborate, that saves me time. Universal like the human hand - the most versatile tool ever invented.
• The tool delivers the background information I need for the job at hand.
• It feels good, makes my eyes shine when i use and other folks can learn it in less than 5 seconds. So its safe to suggest to others to use it.
• We want to make measurable if we are on track: Goal is a net promoter score of 75% during development.

We used that to guide the next phase - searching for the solution. That's a different story for another blog at a different time.

8. Results

We succeeded. Avaya Flare made it to the top of the stack of no jittters cool enterprise products 2010. It consistently rated 8.5+ out of 10 in wow factor and 9+ out of 10 in ease of use. And people get in 2 seconds how it works.

User Experience of Cloud based Mobile Systems

Many readers of my blog asked in email: could i please compile the relevant research with references? Here you go: Today we want to focus on page load speed and latency. 

 

Faster cloud based web for mobile devices latency and how to accelerate by christian von reventlow v1

View more presentations from vonreventlow.

(Note the views represent my personal opinions and are not the views of my employer Avaya, detailed references are in the embeeded powerpoint presentation)

1. What are the page load limits for an acceptable user experience?

Google, Yahoo and others have researched this. The findings are:

• The time users are willing to wait before they navigate away from a page has decreased from 8 seconds in the year 2000 to 3 seconds in 2009. 2 seconds load time of a landing page decreases both the conversion rate and the total number of pages viewed by 10% - when compared to a 1 second load time.
• In addition users never get in a flow if the load time is too long. When a page loads in 200ms users click within 500ms. They experience that as a smooth flow. However time to the next click increases by 4 seconds when a page loads in 2 seconds.

Thus my view is: 2 seconds is the 2011 page load limit for an acceptable user experience. And i expect it to become less in the years to come.

2. How are various mobile web pages compare to the 2 seconds page loading speed limit? And are the cloud service providers giving you response times that allow to hit this limit/

There is a very limited number of mobile web pages with a load times below 2 seconds. In a recent review by blaze.io only 20% of the web pages were below this limit. Specifically a Google and a Microsoft Bing site were below this limit. This shows that both companies have taken their published research seriously.

I measured the actual latency of applications run on various clouds during 6 hours on a Monday morning on the east coast - resulting in 2.9 seconds to 4 seconds on wired network. Content delivery networks measured over 7 days showed between 6 and 12 seconds with an average around 8 seconds. Variability was quite large and reached 120% in an instance.

3. What is the right architecture to deliver your mobile web?

Typically LAMP (Linux, Apache, MySQL, PHP) or similar setups are used.

When designing the systems avoid sessions. Use cookies to store userID and login status. Scaling the webapps, image conversion, audio and video is easy - they scale horizontally. Use Hardware loadbalancers followed by SW loadbalancers as Wackamole, Poud, perbal or Apache with mod_proxy. And just add more servers.

Queuing helps for peak periods. However at some point you want to turn off the page as people learned from Macy's and JCPenny's web site performance at a recent Black Friday. People return later when the page is not available. But they are frustrated if the page is extremly slow and are reluctant to return.

Scaling the database is more tricky. As Carl Henderson puts it: Avoid it and go for a bigger box if possible. If you can't avoid it go for database replications. In most applications the read/write ratio is 80/20 or 90/10. That allows Master-Slave replication. Add memcaching to make scaling cheaper. A sideline cache as Danga will help.

When you need High Availability go for Master-Master replication, or to increase bandwidth Dual Tree architecture. Even more scale can get created with ringlike MySQL databaser clusters. Or by dividing tables into disjoint sets, federating by users or partitioning the database horizontally (Shards). Have a look on the Flickr architecture in the slide deck as an example of these methods.

4. What are the challenges on the device side and how to resolve them?

There are so many devices out there with so many different screen sizes. And so many different browsers with different capabilities. ..unfortunately on a global scale - IOS, Android, and Blackberry devices are a minority...

Coping with this variety gets done best by starting the design of a web page with a mobile only web page assuming a browser with minimum capabilities. Use a default stylesheet. And then enhance the view progressively using Javascript and @mediaquery. And adapt the content of the screen for the devices you want to support. WURFL is a database that contains hundreds of devices with their specific capabilities. Use CSS instead of Javascript for performance. And compress data. Plus - very relevant -send only data that will rendered on the screen.

Note that many PC oriented web pages have lots of data that never gets rendered. Find an example in the presentation where around 80% of the data transmitted to the mobile device never gets rendered.

Some tools help in the process. As an example: the open source phone gap tool allows to build Javascript based application that run on Apple's Ios, Android and Blackberry. And it supports WURFL easing supporting various screen sizes and resolutions.

Take Yahoo!'s 14 or now 34 performance rules and suggestions by people as Yibuu, Jason Grigsby, and Steve Souders to heart:

• Make fewer HTTP Requests. Don't forget that HTTP connections pipeline requests - slowing things down. And that according to the standard many browsers only support 2 connections per domain. Thus you want to use multiple domains to parallelize things. (and how many a browser supports varies from browser to browser...)
• Limit cookies as they get loaded with each request. Better only one. Or zero on some connections.
• Encourage caching with expire headers far out. And test if it works on your target browser.
• GZIP compression. Can take out up to 75% of transmission volume
• Javascript and CSS need to go external. And use only 1 each. Go for CSS and not for table layouts. And use CSS sprites - at least some browser support it.
• And minimize DNS lookups - as the are blocking till the DNS is resolved.

Testing your results is key. Tools like Yslow or Safar Web Inspector allow to understand the size of the individual elements of a page being downloaded, display a waterfall chart showing how time gets consumed and come up with suggestions on what needs to be done to improve the page.

Find some more suggestions in the powerpoint. And if you want to take things to the next level read Steve sounders article: Faster Webpages from the velocity-20090622.ppt. Just Google it.

5. And is the cloud making things better and simpler?

Unfortunately it does not look like it. Recent research shows that on average 8 hosts are involved in each transactions: Hosts delivering session information, search or CMS content - all inside of the firewall. And other hosts like Web Analystics, CDN content, Videos from a media server, ads from an adserver or information from a shopping card server.

And measurement shows, that more is required to be below the 2 seconds page load limit for a great user experience. At least for the majority of web pages out there. And even more so for mobile devices.

6. Conclusion

The quest for page load speed and low latency will continue. And many organization will need to continue to invest in optimizing their mobile web experience.

As a consequence all types of mobile applications - fat mobile apps, hybrid apps downloading data from the cloud and web based applications will be around.

It will be fun to see how HTML 5 with resident data will impact the game..


Let me know what you think. Questions? Suggestions?