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

• 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

Original https://submissions.agilealliance.org/attachments/2615

My copy fortune-teller_to_scientist_-_with_notes.pdf

Lean experimentation

1. Define the problem (not solution)
2. Determine kpi
3. Guerrilla research
4. Create shared map
5. Write hypothesis
6. Test your hypotheses
7. 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” <address a business problem> so that <a measurable desired outcomes happen>

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 <we had this capability> then <we would see this measurable outcome>

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.