1. THIN SLICING THE TECHNOLOGY ADOPTION LIFE CYCLE

2. 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.

3. AGENDA & GOALS Problem Statement Technology Adoption Life Cycle Thin Slicing Build, Measure, Learn Bringing it all together

4. 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..

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

6. 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.

7. 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.

8. TECHNOLOGY ADOPTION LIFECYCLE

9. Innovators Early Adopters Early Majority Late Majority Lagards

10. 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

11. 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.

12. 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

13. LATE MAJORITY Conservatives Skeptical of the value Somewhat fearful of technology Looking for fully integrated, simple solutions

14. THE CHASMS Innovators Early Adopters Early MajorityLate Majority Lagards

15. THE NON-FUNCTIONAL CHASM Early AdoptersEarly 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.

16. THIN SLICING

17. 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.

18. 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

19. WHY DO WE NEED TO RELEASE THINS SLICES? There are no facts inside the building - Steve Blank

20. BUILD, MEASURE, LEARN

21. 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

22. 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]

23. BRING IT ALL TOGETHER

24. 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

25. START DELIVERING SLICES TO INNOVATORS NeedDon’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

26. INCREMENT TO EARLY ADOPTERS NeedDon’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.

27. INCREMENT TO THE EARLY MAJORITY NeedDon’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

28. CONTINUE TO INVEST TO CAPTURE THE LATE MAJORITY NeedDon’t Need Everything the early majority needs, plus: Turnkey solutions 0 learning curve Dead simple experience (choose intelligent defaults) Configuration Flexibility Choice

29. 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

30. 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.

31. 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.

32. 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.

33. REFERENCES, ATTRIBUTIONS AND FURTHER READING Crossing the Chasm The Lean Startup The Innovators Solution Lean UX Adobe Blogs: Splitting Stories into Small Vertical Slices Adobe Blogs: Splitting Stories into Small Vertical Slices Agile Atlas: User Stories Steve Blank.com