Post on 13-Jan-2017
transcript
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