Navigating Uncertainty when Launching New Ideas


Published on

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:

Published in: Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • * 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
    * 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
    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
  • Navigating Uncertainty when Launching New Ideas

    1. 1. Navigating Uncertainty when Launching New Ideas @khopper
    2. 2. Uncertainty doesn’t stop success
    3. 3. #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
    4. 4. #1: Know your purpose SIX SECRETS TO NAVIGATING UNCERTAINTY
    5. 5. “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
    6. 6. Knowing your purpose permits different solution approaches without losing your way. SIX SECRETS TO NAVIGATING UNCERTAINTY
    8. 8. Desirability (human) Feasibility (technical) Viability (business) Risks hide inside bad assumptions
    9. 9. “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
    10. 10. RISK UNCERTAINTY Prioritize your assumptions
    11. 11. Test your assumptions
    12. 12. Knowing your risks lets you unravel them early. SIX SECRETS TO NAVIGATING UNCERTAINTY
    13. 13. #3: Know your mindset SIX SECRETS TO NAVIGATING UNCERTAINTY
    14. 14. target customer market needs solution shape communication scale reliability infrastructure predictability safety maintenance cost insights evidence hypotheses unknowns what-ifs assumptions surprises EXPLORER MINDSET BUILDER MINDSET VS.
    15. 15. Knowing your mindset helps suggest the appropriate actions to take. SIX SECRETS TO NAVIGATING UNCERTAINTY *
    16. 16. #4: Know how to plan SIX SECRETS TO NAVIGATING UNCERTAINTY
    17. 17. Take your position regularly and course-correct
    18. 18. VALUE TIME Re-plan to eliminate diminishing value
    19. 19. Knowing how to plan allows for course-corrections and helps ensure you hit your destination. SIX SECRETS TO NAVIGATING UNCERTAINTY
    21. 21. Small teams ensure shared values
    22. 22. Use a learning framework. Be deliberate. REFLECT IDENTIFY IMPROVEMENT ENACT CHANGE ASSESS RESULTS
    23. 23. When the team knows itself anything is possible. SIX SECRETS TO NAVIGATING UNCERTAINTY *
    24. 24. #6: Know how to fail SIX SECRETS TO NAVIGATING UNCERTAINTY
    25. 25. All startups know disappointment
    26. 26. Anything is possible
    27. 27. “Success is going from failure to failure without a loss of enthusiasm”
    28. 28. Knowing how to fail ensures you get back up. SIX SECRETS TO NAVIGATING UNCERTAINTY
    29. 29. #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
    30. 30. 'Installation (Banana Peel)', Adriana Lara, 2008