Thin Slicing the Technology Adoption Life Cycle
•Download as PPTX, PDF•
2 likes•543 views
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Thin Slicing the Technology Adoption Life Cycle
Similar to Thin Slicing the Technology Adoption Life Cycle (20)
Thin Slicing the Technology Adoption Life Cycle
- 1. THIN SLICING THE TECHNOLOGY ADOPTION LIFE CYCLE
- 2. AGENDA & GOALS • Background (definitions, scope, etc.) • Problem • Release Early & Often • Release What, To Who • Build, Measure, Learn
- 3. DEFINITIONS Release – 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
- 4. SCOPE I’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.
- 5. 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
- 6. PROBLEM By 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.)
- 7. • RISK OVERBUILDING AND/OR BUILDING OVERLY COMPLEX FEATURES
- 8. REDUCING OUR ABILITY TO LEARN There are no facts inside the building - Steve Blank The unit of inventory is the invalidated decision - Alistair Cockburn
- 10. GA SHOULD BE A NON-EVENT VS Value Functionality Non-Functional All Functionality All Non-Functional All Value* All at once
- 11. SO RELEASE EARLY & RELEASE OFTEN But that’s easier said than done.
- 12. 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
- 13. RELEASE WHAT AND TO WHO? Purposefully choose your customer Purposefully choose your value hypothesis Purposefully choose your scope Build, Measure, Learn Repeat
- 14. PURPOSEFULLY CHOOSE YOUR CUSTOMER Your typical customer is not what you want. Choose your early release customer(s) purposefully. Fire your customer!
- 15. PURPOSEFULLY CHOOSE YOUR CUSTOMER - TECHNOLOGY ADOPTION LIFE CYCLE Innovators Early Adopters Early Majority Late Majority Lagards
- 16. INNOVATORS Need 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
- 17. 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
- 18. EARLY ADOPTERS Need 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.
- 19. 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
- 20. LATE MAJORITY Need 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
- 21. RELEASE WHAT AND TO WHO? Purposefully choose your customer Purposefully choose your value hypothesis Purposefully choose your scope Build, Measure, Learn Repeat
- 22. 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
- 23. … AND DECIDE HOW YOU WILL VALIDATE YOUR HYPOTHESIS 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]
- 24. RELEASE WHAT AND TO WHO? Purposefully choose your customer Purposefully choose your value hypothesis Purposefully choose your scope Build, Measure, Learn Repeat
- 25. 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
- 26. RELEASE WHAT AND TO WHO? Purposefully choose your customer Purposefully choose your value hypothesis Purposefully choose your scope Build, Measure, Learn Repeat
- 27. 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
- 28. RELEASE WHAT AND TO WHO? Purposefully choose your customer Purposefully choose your value hypothesis Purposefully choose your scope Build, Measure, Learn Repeat
- 29. 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 event
- 30. 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 This Functionality This Customer
- 31. 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.
- 32. IN SUMMARY Leverage the technology adoption curve to purposefully choose yourcustomers. Continuously release MVPs that validate your hypotheses Progress functionally and non-functionally along the adoption curve to ensure low risk and highly successful GA.
- 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 • Agile Atlas: User Stories • Steve Blank.com
Editor's Notes
- In this talk I’m going to try to bring together ideas from a few different books, mostly from The Lean Startup and Crossing the Chasm. While you are quite likely familiar with the concept, hopefully it will give you a practical way to think about and align your team and stakeholders on how to approach your project.
- When people talk about thin slicing, they are often talking about how to split stories into smaller slices. There is a lot of great material on Story Splitting, to better thin slice your stories: Elephant Carpacio Workshop Google Thin Slicing or Story Splitting etc. I’m going to focus on choosing Features and how to deliver thin slices to the market.
- The value of a product depends on the user. It depends on what they need and what they value. One user may be able to get tremendous value from a csv data dump where it would seem like a terrible solution to another customer, even though they have the same general problem. 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.
- There was a study conducted a while ago that found almost 2/3 of features were rarely or never used. I’m sure you could be pick the study and some of those rarely used features might be critical in certain cases but a very loose interpretation of these results suggest about ½ of what is built is not valuable. The other thing to consider here is that more features is more complexity and permutations to test, more code to understand and support.
- A couple famous quotes on learning. Decisions made without users are real usage are only hypotheses based on assumptions. As we are building software without release, we are just stock piling assumptions and risk.
- So we risk over building, we reduce our ability to learn and we’re increasing our quality risk So how to you become confident that your product will be successful? By validating it daily (or at least frequently)
- Operational Learning How will it be used Integrate with customer data Prove and improve monitoring Prove scaling We want to slide on the feature into the market, learning and adjusting as we go. Then there is no BIG release event
- … release what and to who?
- So let’s talk about some ideas to help you decide what to build and what not to build
- What we want to do is continually narrow what we deliver. Of all our customers, narrow down to a very small subset. Narrow down the value as small as you can. Narrow the scope of the solution to the smallest bit to prove that value.
- Innovators: Technologists that like to tinker Interested in creating solutions that don’t exist elsewhere. Value flexibility and low level access Highly tolerant of technical hurdles Early Adopters: Visionaries Can see the value/opportunity in new technology Not necessarily technologists (but may have some on staff) 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 Fearful of the learning curve and disruption to current business or behavior Somewhat fearful of technology Looking for fully integrated, simple solutions Geoffrey Moore identified that the technology curve is not continuous. Between each of the segments is a gap in the expectations of the product. What a technologist requires is different than what a visionary needs Moore identified that the biggest chasm is between the Early Adopters and the Early Majority. While the Early Adopter is a risk taker who wants to be the first in their market to adopt a new technology, the Early Majority want a hardened product with references from similar pragmatists. While “Crossing the Chasm” primarily addressed the marketing of a product, I want to suggest that there is also a chasm with respect to non-functional requirements that need to be addressed before taking your product or feature to the mass market.
- Release thin slices that add incremental value, meeting the needs of the Innovator. Apply Build, Measure, Learn for each slice. Only when confidence is gained in the value, begin to prepare for release to the Early Adopter. Example: Could be API only Batch processing via scripts Data Delays Etc.
- Being on the leading edge, there is some tolerance for working through issues as long as work-arounds exists and value can continue to be extracted. Release thin slices that add incremental value, meeting the needs of the Early Adopter. Apply Build, Measure, Learn each slice. Only when confidence is gained in the value, begin to prepare for release to the Early Majority. Example: Simple UX, generating .csv into Excel Excel plugin to call API and DB backend Google Doc report templates
- This is hard! Even more so when developed in isolation, without a safe learning environment. Release thin slices that add incremental value, meeting the needs of the Early Adopter. Apply Build, Measure, Learn each slice. Only when confidence is gained in the value, begin to prepare for release to the Early Majority. Example: Full and delightful integrated user experience Integrations and new reports could evolve incrementally
- Example: Home page integration Notifications of important reports (push the data they need to them) Integrate report data right into their current experience. Auto configuration based on their profile, usage data, etc.
- Okay, so we talked about choosing a customer type that aligns to the stage of your product Now we want to choose what value to deliver
- What is the most time consuming, expensive or error prone aspect of that process? and remember that this is all a hypothesis. Make your best guess and then validate it as quickly and cheaply as possible
- Jeff Gothelf, author of Lean UX suggested this template for defining an iteration throught the Build, Measure, Learn cycle.
- Okay, so we talked about choosing a customer type that aligns to the stage of your product Now we want to choose what value to deliver
- … and remember that this is all a hypothesis. Make your best guess and then validate it as quickly and cheaply as possible.
- Okay, so we talked about choosing a customer type that aligns to the stage of your product Now we want to choose what value to deliver
- Eric Ries coined the build, measure, learn process in book The Lean Startup to achieve Validated Learning He used the term MVP to describe the small bit of functionality you could release to validate your hypothesis. Starting with a hypothesis, you build the MVP, release it to users, measure data, learn from the result and then form a new hypothesis. The faster that you can iterate through the loop, the faster you will get to a successful product. I will further suggest that you will also learn about your non-functional requirements. How users are using your system, what the load profile is, how to monitor it, how it scales, how easy it is to use, etc.
- In some cases you can simply Build, Measure, Learn again but I’m suggesting that you are also considering moving to a different customer segment, which will have different scope requirements.
- So there are a couple ways to get this wrong… If you try to meet the mass market requirements in your first release, Its hard! Especially when you are not building net new