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
Early Majority
Late Majority
Early Adopters
Lagards
Innovators
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
Early Majority
Early Adopters
Innovators
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.
•
•
•
•
•
•
•
•
•
•
•
*Reasonable for the small scale release.
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)
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
INNOVATORS
Need
•
•
•
•
•
•
Novel capability
Low level control
Flexibility
Feedback mechanism
Close contact with team/company
High touch support
* As long as expectations and
SLAs are managed appropriately
Don’t Need *
•
•
•
•
•
•
High Availability
High performance
Scalability
Delightful Experience
Polished and complete User Experience
Low per-user costs
INCREMENT TO EARLY ADOPTERS
Need
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 nontechnical staff
• No blocking defects
• Responsive support
• Reasonable availability*
• Reasonable performance*
•
•
•
•
*Reasonable for the small scale release.
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
INCREMENT TO THE EARLY MAJORITY
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
Don’t Need
•
•
•
•
Turnkey solution
No learning curve
No configuration
Dead simple experience
CONTINUE TO INVEST TO CAPTURE THE
LATE MAJORITY
Need
•
•
•
•
Everything the early majority needs, plus:
Turnkey solutions
0 learning curve
Dead simple experience (choose
intelligent defaults)
Don’t Need
• 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 nonfunctional 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 nonevent.
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
Vertical Slices
• Agile Atlas: User Stories
• Steve Blank.com
•
•
•
•
•