THIN SLICING THE TECHNOLOGY ADOPTION LIFE CYCLE

WHO AM I

Current: Kent Richmond, Engineering Director, D2L

Past: • Managed development teams and

organizations at numerous companies, applying many technologies across a number of different industries.

AGENDA & GOALS

• Problem Statement• Technology Adoption Life Cycle• Thin Slicing• Build, Measure, Learn• Bringing it all together

QUALITY

"Quality is a customer determination, not an engineer's determination, not a marketing determination, nor a general management determination. It is based on the customer's actual experience with the product or service, measured against his or her requirements -- stated or unstated, conscious or merely sensed, technically operational or entirely subjective -- and always representing a moving target in a competitive market". – Feigenbaum, Total Quality Control.

.

SCOPE

Delivering Disruptive or Discontinuous change in startups, SMB or Large enterprises.

PROBLEM

By building first releases that deliver on the requirements of the mass market we are:

• Delaying the delivery of value• Reducing our ability to learn• Decreasing quality of the product.

SOLUTION

By applying a methodology that releases thin slices of value along the Technology Adoption Curve we can better align to what needs to be delivered, to who, at what time to optimize the value, quality and timeline of our products.

TECHNOLOGY ADOPTION LIFECYCLE

TECHNOLOGY ADOPTION LIFE CYCLE

Innovators

Early Adopters

Early Majority

Late Majority

Lagards

INNOVATORS

• Technologists that like to tinker• Interested in creating solutions that don’t exist

elsewhere.• Want to be heard and have input into the solution• Value flexibility and low level access• Highly tolerant of technical hurdles• Don’t want to pay for a solution

EARLY ADOPTERS

• Visionaries• Can see the value/opportunity in new technology• Not necessarily technologists (but may have some on

staff)• Interested in demonstrating the value to be ahead of the

competition.• Tolerant of technical deficiencies if value can be

demonstrated..• Will often pay to be on the leading edge• Will often be keen to promote the innovation.

EARLY MAJORITY

• Pragmatists• Adapt to new technology once proven• Expect a polished solution• High expectations of non-functional requirements• Must be easy to learn and integrate smoothly

into their environment and processes• Little to no tolerance for defects or problems

LATE MAJORITY

• Conservatives• Skeptical of the value• Somewhat fearful of technology• Looking for fully integrated, simple solutions

THE CHASMS

Innovators

Early Adopters

Early Majority Late Majority

Lagards

THE NON-FUNCTIONAL CHASM

Early Adopters Early Majority (Mass Market)

• Functional UX, usable by non-technical staff

• Some tolerance for technical hurdles• Expect some gaps in functionality• Reasonable availability*• Reasonable performance*• Accept that integration could be required• May tolerate a discontinuous experience

(give up legacy support or data migration)

• Lower scale may allow higher touch training, configuration, deployment, etc.

• Delightful Experience• Polished and complete user experience• Proven value proposition• Bug free• 5 - 9’s Availability• 0 down-time upgrades• High performance• Scalability for the mass market• 100% Self-serve experience• Support of legacy functionality and data• Fully automated customer adoption (no

touch)

*Reasonable for the small scale release.

THIN SLICING

WHAT’S A THIN SLICE

A small bit of user value that is created by building vertically through the architectural layers of the system.

Key to the concept is to build only the minimal functionality within any particular horizontal component to satisfy the value being delivered.

WHY BUILD IN THIN SLICES

• Easier to understand and estimate• De-risk delivery• Stakeholder feedback• Improved flow and parallelism of work (Dev, QA,

Design, PO)• Requirements clarifications• Avoids over-building

WHY DO WE NEED TO RELEASE THINS SLICES?

There are no facts inside the building

- Steve Blank

BUILD, MEASURE, LEARN

BUILD, MEASURE, LEARN

• Validate (or update) our hypothesis

• Learning the necessary functional requirements

• Make data drive decisions• Learn non-functional

requirements• Maximize delivery of

value• Know when to stop

HYPOTHESIS DRIVEN DELIVERY

We believe that[building this feature][for these people]will achieve [this outcome]

We will know we are successful when we see[this signal/data from the market]

BRING IT ALL TOGETHER

BRINGING IT TOGETHER

The real challenge in writing software isn’t the time spent writing the code itself. Instead it’s the time spent deciding what software we should build, and perhaps just as importantly what we shouldn’t build. - Mark Levison, Agile Atlas

START DELIVERING SLICES TO INNOVATORSNeed Don’t Need *

• Novel capability• Low level control• Flexibility• Feedback mechanism• Close contact with team/company• High touch support

• High Availability• High performance• Scalability• Delightful Experience• Polished and complete User Experience• Low per-user costs

* As long as expectations and SLAs are managed appropriately

INCREMENT TO EARLY ADOPTERSNeed Don’t Need *

• A strong value proposition that will give them a competitive advantage

• A solution they can understand and speak about

• Functional user experience by non-technical staff

• No blocking defects• Responsive support• Reasonable availability*• Reasonable performance*

• 5 - 9’s Availability• 0 down-time upgrades• Scalability for the mass market• 100% Self-serve (some hand holding is

acceptable and can be a learning experience for both)

• Polished and complete user experience• Delightful Experience• Low per user costs

*Reasonable for the small scale release.

INCREMENT TO THE EARLY MAJORITYNeed Don’t Need

• Proven value proposition• Proven capability• 5 - 9’s Availability• 0 down-time upgrades• Scalability for the mass market• 100% Self-serve experience• Polished and complete user experience• Delightful Experience• Cost effective at Scale

• Turnkey solution• No learning curve• No configuration• Dead simple experience

CONTINUE TO INVEST TO CAPTURE THE LATE MAJORITYNeed Don’t Need

• Everything the early majority needs, plus:

• Turnkey solutions• 0 learning curve• Dead simple experience (choose

intelligent defaults)

• Configuration• Flexibility• Choice

IF YOU GET IT WRONG

• Long project schedules• Little or no interim user value• Black hole development (what are they working

on and why is it taking so long?)• High risk of not building the right solution (due

to lack of feedback)• High risk of over-building (building features or

non-functional requirements that are not needed)

• Release to the mass market is a high risk event

GETTING IT RIGHT

• Deliver early and continuous value• Validated learning from real

customers• Data driven rather than opinion

driven decisions• All stakeholders on the same page

(because it is live)• Solution evolves to a mass market

success.• Release to the mass market is a non-

event.

HOW TO FIND THE RIGHT CUSTOMERS• Enable to specific customers only• Identify innovators through operational

intelligence (customers using advanced features with a need for your solution)

• Advertise an alpha/early access program. To some it is a badge of honor.

• Early Adopters will usually have innovators to evaluate technology.

• Even conservative companies will often have innovators hidden inside their IT department.

SUMMARY

Releasing thin slices is intuitively easy, yet hard in practice, especially with an established, conservative customer base.

By understanding and applying principles from the technology adoption life cycle, stakeholders can better understand what needs to be delivered, to who, at what time to enable successful and efficient mass market adoption.

REFERENCES, ATTRIBUTIONS AND FURTHER READING

• Crossing the Chasm• The Lean Startup• The Innovators Solution• Lean UX• Adobe Blogs: Splitting Stories into Small Vert

ical Slices• Agile Atlas: User Stories• Steve Blank.com