Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Navigating Uncertainty when Launching New Ideas
Ähnlich wie Navigating Uncertainty when Launching New Ideas (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Navigating Uncertainty when Launching New Ideas
- 1. Navigating Uncertainty when Launching New Ideas keithhopper.com/uncertainty @khopper
- 3. Uncertainty doesn’t stop success
- 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
- 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
- 10. Desirability (human) Feasibility (technical) Viability (business) Risks hide inside bad assumptions
- 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
- 14. Knowing your risks lets you unravel them early. SIX SECRETS TO NAVIGATING UNCERTAINTY
- 15. #3: Know your mindset SIX SECRETS TO NAVIGATING UNCERTAINTY
- 16. 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.
- 17. Knowing your mindset helps suggest the appropriate actions to take. SIX SECRETS TO NAVIGATING UNCERTAINTY *
- 18. #4: Know how to plan SIX SECRETS TO NAVIGATING UNCERTAINTY
- 19. Take your position regularly and course-correct
- 20. VALUE TIME Re-plan to eliminate diminishing value
- 21. Knowing how to plan allows for course-corrections and helps ensure you hit your destination. SIX SECRETS TO NAVIGATING UNCERTAINTY
- 22. #5: Know yourself SIX SECRETS TO NAVIGATING UNCERTAINTY
- 23. Small teams ensure shared values
- 24. Use a learning framework. Be deliberate. REFLECT IDENTIFY IMPROVEMENT ENACT CHANGE ASSESS RESULTS
- 25. When the team knows itself anything is possible. SIX SECRETS TO NAVIGATING UNCERTAINTY *
- 26. #6: Know how to fail SIX SECRETS TO NAVIGATING UNCERTAINTY
- 27. All startups know disappointment
- 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
- 32. keithhopper.com/uncertainty 'Installation (Banana Peel)', Adriana Lara, 2008
Hinweis der Redaktion
- * 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