====== Kylie Castellaw - Fortune-teller To Scientist ====== Telling the future is hard but telling the past is easy. As they say, hindsight is 20/20. We all have stories of products that we should have known would fail. It usually goes this way: Your company invests a lot of money to get the A-team together to create a critical piece of software. The team has impressive iterations and delivers high quality software with smooth, on-time releases. But then it doesn’t perform well in the marketplace, the investors retract, and eventually there’s no alternative but to kill the product and disband the team. Looking back, there must have been a better way. In this workshop, we’ll use lean experimentation to predict a product’s future (spoiler alert: it’s all about science). We’ll work on defining problem statements, agreeing on metrics and measurements, creating hypotheses and designing tests. In the end, you’ll be ready to experiment your way to success. So follow Linda Rising’s advice: Be brave! Try an experiment. Get ready to let your inner scientist out! Learning Outcomes: How to agree on a problem statement and associated business metrics How to formulate a testable product value hypothesis How to design tests for a product value hypothesis How to keep learning until you find the right value ====== Summary ====== * Content rating (0-no new ideas, 5 - a new ideas/approach, 9-new ideas): 1 * Style rating (0-average presentation, 5 - my level, 9-I learned something about presenting): 1 ====== Action / Learning ====== * ====== Presentation ====== Original https://submissions.agilealliance.org/attachments/2615 My copy {{fortune-teller_to_scientist_-_with_notes.pdf|}} ====== Notes ====== Lean experimentation - Define the problem (not solution) - Determine kpi - Guerrilla research - Create shared map - Write hypothesis - Test your hypotheses - Analyze and design And repeat Write the problem statement Connect to many tech solution - generate not prescriptive This is alignment we are all behind Better problem statement Five whys - "I want an app" implies solution already Answer the question "How might we"
so that Need to address the business concern not your own view of that. Determine KPIs Biz - Tech tension Actual biz vs * Too businessy - average monthly revenue (too many could effects, and want faster feedback) . And it's a lagging indicator * Too technical - questions asked to waiter. What is business impact * Just right - waiter labor hours saved Guerrilla research External research - what third parties have done Interviews - one on one (needs good with People) with actual people and experience Observation - say one thing / do something else Shared experience map Steps the user takes Overlay the pain points or opportunities for improvement Prioritize the points Write a hypothesis If then If customers had access to meal allergen information the waiters would have to ask the chef fewer questions Test hypothesis Simplest thing to do "How low can you go to test" Save time and money - fast validation Don't need to do it now. {{tag>Forecast Conference Agile2016 Planning Probability Lean}}