Developing innovative products involves confronting a dizzying amount of uncertainty. Here's a talk from Thomson Reuter's Knowledge Worker Series from 1/21/15 on how to best navigate that uncertainty. Lessons gleaned from prod dev at NPR and through dozens of Techstars startups. More here: http://keithhopper.com/uncertainty
4. #1: Know your purpose
#2: Know your risks
#3: Know your mindset
#4: Know how to plan
#5: Know yourself
#6: Know how to fail
SIX SECRETS TO NAVIGATING UNCERTAINTY
5. #1: Know your purpose
SIX SECRETS TO NAVIGATING UNCERTAINTY
6. “We need to stop users from abandoning our
shopping cart”
“We want more customers to go paperless”
“Our online advertising rates are plummeting
and we need revenue to support content
production.”
Articulate a clear problem statement
7.
8. Knowing your purpose permits
different solution approaches
without losing your way.
SIX SECRETS TO NAVIGATING UNCERTAINTY
9. #2: Know your risks
SIX SECRETS TO NAVIGATING UNCERTAINTY
11. “Very few startups fail for lack of
technology. They almost always fail
for lack of customers”
- Steve Blank
“There’s one thing that kills startups:
not making something users want”
- Paul Graham
29. “Success is going from
failure to failure without
a loss of enthusiasm”
30. Knowing how to fail ensures you
get back up.
SIX SECRETS TO NAVIGATING UNCERTAINTY
31. #1: Knowing your purpose permits different solution
approaches without losing your way.
#2: Knowing your risks lets you unravel them early.
#3: Knowing your mindset helps suggest the appropriate
actions to take.
#4: Knowing how to plan allows for course-corrections
and helps ensure you hit your destination.
#5: When the team knows itself anything is possible.
#6: Knowing how to fail ensures you get back up.
SIX SECRETS TO NAVIGATING UNCERTAINTY
* Story of 2 products at NPR
* 1 Complex platform for launching custom news sites - several years to build
* 2 Standalone, stripped down mobile site - a few months
* Success: 200 newsrooms; thousands edits, millions users
* Dismal Failure: no newsrooms; killed product line
* Too difficult to port content; mobile apps
* 1st was well understood, mobile (at the time) was new= uncertainty
- around users, needs, technology, messaging. All this was new to us.
-> Two big takeaways
1. Products go astray when they have too many uncertainties – too many unknowns
2. You can’t just treat all product development the same way. If you’re working on something w/ lots of unknowns, you need to take a different approach
Since working on these two products, I’ve got to work with dozens of new product teams,
Some at NPR
Dozens of startups at techstars, where I’ve been a mentor for going on 5 classes of startups
At at Olin college, where I teach engineers how to launch new products
and I’ve learned some secrets to manage all these unknowns, these uncertainties
The secret lies in turning uncertainty into certainty
Knowing your unknowns
Each one will unlock a little uncertainty
And I’ll show you how
* Silly to ask “why are we launching this?” – should be obvious, right
* Ask team; ask those at top = different answers
- generate revenue? make customers happy? Solve specific user problem? Explore biz opportunity?
* Dangerous to maintain ambiguity
W/ so much uncertainty, one place need to lock down
* Ideal purpose = well-articulated problem statement
* Clear problem statements hard to get right
* For example, we may inadvertently limit solution possibilities; like w/ 3rd example here
- “fix our advertising” = band aid w/ new ad format rather than exploring new revenue streams
* Ideal when team hits snag
- stop, assess right approach; address underlying problem?
* Startups call this pivot
* Example EdTrips
* Saw inefficiencies w/ school field trips
* Teachers didn’t have a burning need here. Too infrequent. No direct incentive for them to fix it.
* Venues felt differently - pivot solution for venues
* If problem statement was around helping teachers, give up deep knowledge, tech infrastructure and partners in the field trip space
1st = some risks are going to be obvious and easy to avoid. You should avoid them.
- IOW: wear your seatbelt
- Corporate example: brand
Turns out to be kind of hard to spot your assumptions, so you need to go hunting for them
There’s three places they hide
- D: Assuming that customers have a meaningful enough problem & are you’re addressing it effectively
- F: Assuming the solution is technically possible based on your capabilities and resources
- V: Assuming that bringing to market helps your business thrive
When hunting for the biggest risks, you should look to desirability
Understand assumptions get you in trouble and prioritize them
You want to address these uncertainties
* You’ve found the risks you can avoid. You’ve identified the rest. You’ve prioritized them, now you test them
* Fortunately, this is what the lean startup movement is all about
* I recommend you read this book, so I won’t be going into it here
WITH ONE EXCEPTION
* Assumptions testing is hard
- Hard: craft a good experiment; be conclusive; identify true causation
* Sometimes is best to just get in front of customers with something and see what you learn
Either by getting rid of them, mitigating them, or revealing ones you weren’t aware of
At their core of these uncertain projects are a search for something that works
Search for target market, biz problem, set features, biz model, form factor, distribution channel
in short, things to make your idea succeed
And this takes a particular mindset
But this isn’t always the default way that orgs tend to think
So let’s look at two different mindsets on a project
Builders concern themselves with…
* Explorers have goals, needs, approach of someone on the hunt for evidence and insight
* If you see yourself a builder of things, this will feel weird and unfamiliar
* Not jettisoning needs of builders, just knowing when to introduce them and how they should be prioritized
Purpose helps figure out WHAT to accomplish
Your mindset helps you figure out HOW to do it
i.e. should we take the actions of an explorer or of a builder?
Boston -> London
Setting a compass heading and hoping in 1-2 weeks you’ll land in london harbor is a bad strategy
Instead, sailors use dead reckoning
Get a fix (absolute position) & monitor speed and direction over time to develop a relative position
But the secret is to regularly take new absolution positions
You then can course correct for wind, current and small inaccuracies that build up over time
This is exactly what you need to do in highly uncertain project environments
Pause regularly and take a fix: where are we? What have we learned?
Then course-correct as necessary towards achieving the team’s ultimate purpose –
Manifests as changes in specific product development activities
Equivalent BTW of setting a single compass heading up front is creating the master project plan
With schedules, dependencies, action items, specifications and so on
Often, these are built to create a sense of safety, but ultimately they can postpone setting sail or worse,
Create anchor that the team won’t question, even when new information emerges to challenge
Not PLAN or NOT PLAN, there benefits figuring out up front – you wouldn’t set sail without crew, food and lifeboats
After an initial plan, value diminishes slowly over time
(intuitively) : starts w/ core features becomes bells, whistles, polishing = not know where line is
The way to solve this is by regularly re-planning. Agile Scrum methodology provides one way to do this
* Scrum forces pausing regularly, assess progress and re-plan= ensure highest value items get worked on
* By incorporating what learning = get significantly more value over time (reveal)
* Interestingly: Diminishing value problem doesn’t go away, but it’s continuously pinched off
One of most powerful shared values on a team is a willingness to learn or to know yourself
- not just yourself as an individual, but for the team to understand how they work together
* Big teams = develop political factions; difficult make decisions; require exponentially larger number of interactions to manage communications
* Small teams by contrast quickly develop shared values
* Amazon = two-pizza teams
Best way to learn is to use a learning framework
REFLECT: WWW / EBI
IDENTIFY IMPROVEMENT: Team chooses one improvement to make
ENACT CHANGE: As part of enacting change, the team articulates not just what to do but the desired results
* Reflect back after pre-determined amount of time
- did team perform improvement?
- did it have desired results?
* Seems obvious. Do we need a framework? Shouldn’t we improve naturally? = NO
Secret = be deliberate & do steps. (reason for “pick only one”)
Oddly difficult to be deliberate here => Like watching yourself on video. We wouldn’t choose to do it.
* When team consistently identifies, tackles & acknowledges ability to solve problems = shifts perspective
* Creates collective self-efficacy = a belief in themselves and ability to solve problems.
- self-efficacy starts small but can be applied big
* Participated in my fair share of projects that some point felt discouraging.
* I suspect we all know what this feels like
* I assumed = team dysfunction or bad exec decisions
* Teaching students helped me form different opinion
* Almost every team at some point - if risky enough - gets discouraged
* I’m not only one who sees
* Paul graham YCombinator describes it this way
- timeline w/ emotional state on vertical axis
Reason this is funny is because it’s true
When things don’t go well it sucks. It’s discouraging to be wrong.
* The weird part is that we don’t really talk about it
The first approach I propose is that we simply acknowledge the fact that it’s part of most risky projects
Discouragement manifests differently for different people
Most common are denial, blame & apathy - What to do?
1. Acknowledge something gone wrong and feels crappy
2. Try and get at underlying problem by asking why?
- likely problem is not the normal reactions of blame and dysfunction, but some underlying problem
- perhaps evidence has started to appear that team was wrong in some of their assumptions & product success is at risk
3. If so, now would be a good time to revisit the team purpose
- are you on the right track? Is there something important going on here?
* Another method for addressing failure = cultivating resilience, Significantly Harder
* One way is to celebrate failure
* Org cultures where this exists = engineers w/o borders = annual failure report = rare
* Start small team or individual level first
* Celebrating failure isn’t just cheering => recognizing important lessons w/ what happened
- lead to future success
- prevented team from going forward false assumptions for months (maybe lesson learned in weeks) = that’s worth celebrating
* Trick here is to invert “made mistake learned something” into “we learned something critical to our success and all it cost us was two weeks”
The simple answer to how to navigate uncertainty is when you can, remove it. And when you cant, respond to it effectively.
---
Wrap up with a story about my most recent class teaching engineering students to launch new products.
This will take us through all six insights.
good bets - inspired by the ALS ice bucket challenge
friends challenge each other for money - loser pays to charity instead of the friend
Purpose - helping charities? process more efficient? more fun?
Risk – great ways to play test w/ paper and pencil
Mindset – this balance between builder and explorer – they tried to code an app
Plan – reflect on what they had learned from playtesting to have the challenger pay rather than the person who was challenged
The team did regular reflections and saw they weren’t going to get their app built
So they had the guts to throw away some of their work and focus on a stripped down app based on what they had learned
