Why You Can’t Pivot as Quickly as You’d Like

Theamerican-sniper_612x380_1re’s a great scene, towards the end of the film American Sniper, where Bradley Cooper’s character has to take a shot from over a mile away from his target. Don’t watch this video, if you don’t want to see what happens (though you can probably guess!).

But the point is, there’s a long time between the point he takes his shot, and when he finds out if he has hit or not. It’s not like shooting a pistol from 20 yards – you have to wait to see the results of your efforts.

One of the authors who has been influential at the place I work is Jim Collins – in his book Great by Choice, written with Morten Hansen, he describes how you should “Shoot bullets before cannonballs”. What he means by this, is that in a world of uncertainty, full of assumptions, you need to test your ideas [with the market] with small bullets first (i.e. small investments of resource). Wait to see what hits, then go in with your cannonballs when you know what will work (rather than wasting cannonballs early on).

This is a great idea of course – why start a team of 100 people on a project when you don’t know if it’s a good idea or not?

And this is great, when you’re running a startup using a SaaS model and the Lean Startup principles – promote an offering on your site on Monday, check the feedback metrics Tuesday to Wednesday and pivot to a new proposition by Friday, if it’s not working out.

But the issue is that, in my experience in the world of B2B, that feedback mechanism takes more than a week to work. Hopefully you have a great Agile team, producing a minimum viable product as soon as possible, getting early ideas out to customers quickly. And you’re doing everything you can to get qualitative and quantitative insight from those customers. But is this enough information to make a pivot? Do you really know if your bullet has hit home or not just yet? There are a few issues that make this process slower than we’d all like:

  1. As mentioned, the speed to get a first version out. The principles of Lean Startup are that you shouldn’t wait to have a fully working version before trying with customers. But I just don’t think you can get accurate, actionable feedback for an idea based on sketches on the back of a napkin. Particularly if you take in to account the points below.
  2. Numbers – we’re not making changes to Facebook here. Each new idea isn’t getting seen by 5 billion users. If you have billions or even millions of users, then it only takes a tiny percentage to react to your new offering to get statistically significant data on what you should do next. But what if you only have thousands of customers? Or hundreds? Most of these people have day jobs and won’t have time to tell you whether your new idea for an “Automated Dog Grooming Service” (I heard this a few weeks back) is a good one or not.
  3. Money – the true test. Someone looking at your sketch and saying “Yeah, looks pretty good” does not a sound, profitable business make :) If you want to test if people really like your idea (i.e. they’re willing to give you dollars for it), then you need to start selling it. And that involves sales cycles, proof-of-concepts, purchasing processes and so on. Particularly of course if you’re selling for more than $10 per month. If you want to test whether your $100,000 proposition is a winner or not, you’re not going to find that out in a week.

So these things mean you have to wait for more than a few days to see if your bullets are hitting their targets, before you load up the big guns.

But this is a problem – the issue is: when do I know if my bullets have missed? I started the project months ago (fired the first volley – not sure how long this analogy will last…), and I still don’t know if I’m shooting in the right direction or not? What do I do? Change target now? Wait and see? What if it takes 6 months, a year even before I know if the idea is good? Do I just carry on regardless?

This is a real problem – kill a project too early, and you could be clutching defeat from the jaws of victory. Keep it going unnecessarily and you’re just burning money (and teams, that could be used elsewhere for more profitable gains). But how do you decide, when the evidence isn’t in yet?

I think there’s a few things you can do in fact:

  1. Good ol’ fashioned product management. Is there a market for this product? People paying money for similar services? Who’s the competition? I love this tweet: https://twitter.com/justinkan/status/614904706624720896 – there’s basic work to be done showing that there’s a market for your service, people are willing to pay for that service, that the incumbent isn’t unmoveable and so on. If you have confidence you’re addressing an existing market, with a better product, in a environment where you have reach and brand recognition, you should have confidence of success that can take you through the low points.
  2. Being honest about the feedback you are getting. With a new idea I, personally, think that unless people are chewing your arm off to get something (“This is magic!”, “How did I survive without this!?”, “Please can I give you some money for this?”) then you need to be pretty cautious and honest with the feedback you are getting. Often we know a set of close customers really well, and this is great, but those close relationships can make it hard for said customers to tell you the truth about your new idea. You present something to them, you can’t help but convey your sparkly-eyed enthusiasm for this new miracle of software that you’ve created, and few people have the heart to tell you what a piece of crap it is. So despite the issues outlined before, you do need to be taking your idea to as many people as possible as early as possible. But more than that, you need to listen to them, encourage “constructive” criticism, and when 19 out of 20 people respond with “Meh”, hear that, and think about drowning your puppy.
  3. Hedge, intelligently. Have a fallback, be thinking about alternatives, alternate uses for the technology and so on. If you do get to, say, 6 months in to your project, and are beginning to have serious doubts, this shouldn’t be the first time you’ve thought about a bad outcome. Really you should have been considering the bad outcomes from day 1. I like to think of this as “Schrödinger’s Cat Thinking” – you don’t know, on day 1, whether the cat is alive or not, but you should be thinking about what you do in either circumstance. Perhaps there’s a way of developing the product so that it can be easily switched to another market? Or sold off to someone if it doesn’t fit with your business? If you’re a sniper, waiting for your shot to hit home, you should have a plan of what do do next, regardless of the outcome [by the way, I know literally nothing about such military affairs, so I have no idea if this is the case or not – but it seems reasonable]. In essence, if you decide to pull the plug, you should be ready to go with “What next?”, not sitting there shrugging.

But the reality is that, even if you take these things in to account, you’re likely to have a long period in limbo, not sure whether you’re on to a winner or not, not sure whether to kill the project or not.

And this is where leadership comes in. What effect would it have to go to a team and say “Well, things are looking okay – I’m not sure, but there’s a chance we might kill your project at some undefined point in the future. Still, off you go – make progress!”? All you’re doing here is undermining that team, leaving them in a state of uncertainty, likely to seriously damage productivity.

Instead that team needs your support and backing. And they need to hear it from you. Yes, you may be only be 60-70% sure that what you’re doing is going to pan out, but internalising that uncertainty is part of your role – it doesn’t help to transmit your worries to everyone around you. So if you have a 6 month period where the project is in the balance, better to assume that project will succeed – and push it hard – than to dither and create a self-fulfilling prophecy of failure..

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>