THIN SLICING THE TECHNOLOGY ADOPTION LIFE CYCLE

AGENDA & GOALS

• Background (definitions, scope, etc.)• Problem• Release Early & Often• Release What, To Who• Build, Measure, Learn

DEFINITIONSRelease – delivered to and usable by a customer/user

Story - a small bit of value that should follows the INVEST neumonic

Feature - one or more stories that make up a cohesive, releasable unit of functionality

SCOPEI’m not going to focus on splitting Stories

I’m not talking specifically about design sprints, story mapping and other Lean UX practices but these are very complimentary pre-cursors to this presentation.

I will focus on choosing how to slice and release features to real users.

http://www.buzzle.com/articles/what-does-the-phrase-beauty-is-in-the-eye-of-the-beholder-mean.html

Quality and Value are defined by the User

PROBLEMBy building first releases that deliver on the requirements of the mainstream/mass market we:

• Risk overbuilding and/or building overly complex features

• Reduce our ability to learn (functionally and non-functionally)

• Increase risk of quality problems (performance, availability, usability, value, adoption, etc.)

• RISK OVERBUILDING AND/OR BUILDING OVERLY COMPLEX FEATURES

REDUCING OUR ABILITY TO LEARN

There are no facts inside the building- Steve Blank

The unit of inventory is the invalidated decision

- Alistair Cockburn

Validation

GA SHOULD BE A NON-EVENT

VS

Valu

eFu

nctio

nalit

yNo

n-Fu

nctio

nal

All FunctionalityAll Non-FunctionalAll Value*All at once

SO RELEASE EARLY & RELEASE OFTEN

But that’s easier said than done.

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

RELEASE WHAT AND TO WHO?

Purposefully choose your customerPurposefully choose your value hypothesisPurposefully choose your scopeBuild, Measure, LearnRepeat

PURPOSEFULLY CHOOSE YOUR CUSTOMER

Your typical customer is not what you want.Choose your early release customer(s) purposefully.

Fire your customer!

PURPOSEFULLY CHOOSE YOUR CUSTOMER - TECHNOLOGY ADOPTION LIFE CYCLE

Innovators

Early Adopters

Early Majority Late Majority

Lagards

INNOVATORSNeed Don’t Need *• Novel capability• Low level control• Flexibility• Feedback mechanism• Close contact with team/company• High touch support

• High Availability• High performance• Elastic Scalability• Delightful Experience• Complete Functionality• Low per-user costs

* As long as expectations and SLAs are managed appropriately

CAVEAT – BEGIN WITH THE END IN MIND

While I say the innovator does not need these non-functional requirements, you absolutely need to be thinking about them from the start and make continuous improvement toward GA release requirements

EARLY ADOPTERSNeed May not need *

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

• A solution they can understand and speak about

• A solution they can take to market

• 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)

• Delightful Experience• Low per user costs

*Reasonable for the small scale release.

EARLY MAJORITY (GA)Need May not 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

LATE MAJORITYNeed Avoid complexity of any kind

• Everything the early majority needs, plus:

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

intelligent defaults)

• Configuration• Flexibility• Choice

RELEASE WHAT AND TO WHO?

Purposefully choose your customerPurposefully choose your value hypothesisPurposefully choose your scopeBuild, Measure, LearnRepeat

PURPOSEFULLY CHOOSE YOUR VALUE HYPOTHESIS• Which piece of functionality provides the most value

to the user?

• Consider (stolen from Gian’s presentation)• Frequency• Pain• Existing solution/work-around

… AND DECIDE HOW YOU WILL VALIDATE YOUR HYPOTHESISWe 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]

RELEASE WHAT AND TO WHO?

Purposefully choose your customerPurposefully choose your value hypothesisPurposefully choose your scopeBuild, Measure, LearnRepeat

CHOOSE YOUR SCOPE

• What is the minimal functionality to provide value and validate your hypothesis.

• What is the minimal set of non-functional requirements to enable the user to take advantage of that value?

MVP

RELEASE WHAT AND TO WHO?

Purposefully choose your customerPurposefully choose your value hypothesisPurposefully choose your scopeBuild, Measure, LearnRepeat

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

RELEASE WHAT AND TO WHO?

Purposefully choose your customerPurposefully choose your value hypothesisPurposefully choose your scopeBuild, Measure, LearnRepeat

IF YOU GET IT WRONG (WAIT FOR MASS MARKET)• 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 eventRelease 1

IF YOU GET IT WRONG (EARLY RELEASE TO WRONG CUSTOMER)• Won’t be used significantly• Little to no data on usage• Reduced ability to learn (both functionally and

non-functionally)• Poor perception of quality• You will be spending time managing • Reacting to feedback about less important

items

ThisFunctionality

ThisCustomer

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.

IN SUMMARY

Leverage the technology adoption curve to purposefully choose your customers.

Continuously release MVPs that validate your hypotheses

Progress functionally and non-functionally along the adoption curve to ensure low risk and highly successful GA.

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