What does Product Management have to do with Time Travel? Well, the jury is out on real time travel, although I quite like the first line of Looper: (“Time travel has not yet been invented. But thirty years from now, it will have been.”) However, temporal distortions are alive and well and have formed a big part of most of the product launches that I’ve been a part of. What’s struck me in over two decades of digital product launches is the clockwork regularity with which some common time distortions appear.
There are three main time distortions that roughly correspond to three project phases. Bear with me as Product Management is a science these days, and delivery language can be technical and confusing: I breakdown product delivery time frame mapping into a tripartite structure of sequential phases I call ‘The Beginning’, ‘The Middle’ and ‘The End’.
The beginning: Kick-off in Dreamland
This is the phase when the Product team is newly formed and is enjoying the fun of a new project and is excited by the possibility of doing great work. The weird temporal distortion that happens here is a complete denial about the project’s timeframe. Everything is possible! The software developers are going to use a new, cutting edge approach based on some tools they used building a ninja fighting game at the weekend when they were very, very stoned. The designers are going to use fonts of such beauty and obscurity that the users are going to weep when they see them for the first time. The UX team are creating a navigational concept that eschews buttons, and works via direct brain-to-brain human connection. The QA team have decided that this time they really are going to test every line of code separately, totally eliminating the possibility of any errors. And as Product Manager, you’ve decided this is the big one.
You will no longer simply bow down before the stakeholders.
You will build something amazing.
The temporal distortion is there is no way that all of this stuff can happen in the time frame. The Product Team is behaving as though ’Next January’ was a decade away.
Unfortunately the Product Manager’s role here is to take away the punch-bowl, pour it down the sink, and force the Product team to turn this mush into actionable tasks. The best strategy is a big, clear visual on the wall. Run a quick workshop, and get the whole thing up there in all its glory. Eventually everyone sees the truth and all the air goes out of the balloon. I like to leave it there to taunt myself for the rest of the project.
Then you need to seed a very clear final deadline, and start socialising ‘The big January launch date.’ It’s extraordinary how often I’ve been on a Product launch deadline and someone six months in has said, ‘But I thought you meant January in two year’s time! You mean *January* January? Oh No!’
Don’t underestimate the power of a nice clear deadline that everyone has said out loud at least once: that clarity can move mountains, and it’s your job to provide it. Once the mountain is in sight, and everyone is thoroughly scared, the Beginning is over, and the difficult work of the Middle gets underway.
Part two: The muddle in the middle
Let’s not kid ourselves. The Middle is hard. For playwrights, Act Two problems are a running gag: ‘Sags a bit in the middle’ is true of most plays, most product managers, and most product plans. The only thing that keeps the whole thing in, like Spanx, is a good dose of Product Management. The temporal distortion in the Middle is a feeling that time stretches on endlessly: January, like Christmas in frozen Narnia, will never come.
The Product Team loses heart. The software developers discover that the platform is still a bit rubbish and everything takes too long. The designers realise that maybe this project isn’t going to get them a job at Apple after all. The UX team does the testing and it shows that – fancy that! – these particular users seem to *like* buttons and stuff that works, you know, the way most stuff works. The QA team finally accepts that they can’t check every line of code and fumes at the injustice of world in which complicated stuff breaks in complex ways. And nobody believes the thing will ever launch. The vibe is one of despair, sometimes quiet, sometimes loud and noisy, especially in the pub.
The solution to the Middle is to turn it into a series of small Ends: it’s a combination of milestones and quick wins. As Product Manager you need to get everyone excited about passing the next lamppost, and you need to put energy into the fact that it’s cool that, say, the directory structure is in place! It’s *brilliant* that the first set of designs have been approved by a key stakeholders, it’s *fantastic* that the first stories have passed QA with flying colours. At this point you are Appreciator-in-Chief, as nobody else is appreciating much of anything, so get used to turning molehills into milestones. As Product Manager on a big launch you may spend up to eighty percent of your time in The Middle, so get comfy. This is where you live, so you need to find ways to make it work for you.
It isn’t called the Muddle in the Middle for nothing, and you may find the team oscillating into another temporal distortion: sudden panic about feature creep. Everyone thinks: we are never going to launch this thing. Let’s cut all the scary stuff and just get it out the door. What do you *mean* we have to rethink the directory structure? What do you *mean* the code runs like a dog and we have to rewrite everything to improve performance on Android? Let’s just replace the interface with a friendly icon of a dinosaur and get this thing out the door. The vibe? Desperation.
The solution is to go back to the beginning and get a sharper take on the minimum viable product. You can give the Product a legitimate haircut now you have better timelines, of course you can’t cut the important stuff, but you may have forgotten what the important stuff is, and it’s probably changed. As Product Manager you’re making all these trade-offs feel strong, reasonable, secure. You’re creating a shared timeline: we’re going to do this, in this way, for these reasons, because we have to, and then we’ll all get to there – and it will be great!
Be prepared to see different members of the team move between hopelessness and desperation at different times, and realise that it’s your job to succumb to neither emotion and to keep everyone on the same timeline and heading towards the same goal.
The end: The bitter, bitter end
It feels like The Middle will never stop, but eventually it does. You will be the only person who realises that you’re getting close to the point when you have something that can be launched, and an urgent need to launch it. At this point everyone else is so focused on the Product Detail, and so close to the trees that they’re totally missing the big picture. This bit always reminds me of an interview I saw with the commander of one of those huge US aircraft carriers, which have massive teams working to manage what is effectively a floating city with an airport attached. The journalist asked the ship’s captain what his job was, and he pointed out that he had specialists thinking about refuelling, and logistics experts managing their ammunition systems, and catering teams ensuring that everyone was fed. His job?
“My job is to make sure we don’t crash the ship into Africa.”
At this point your team is so focused on their bit of the elephant that they’ve forgotten that the point isn’t improving code quality or iterating the design – it’s launching the damn thing. And very often a weird fear of disaster comes over the Product Team. They’ve been staring at it for so long that the Product starts melting like a wedding cake in the rain: nobody thinks it will ever be ready. Even the cocky software developer who lets *anything* go is saying, ‘This could do with another two week’s QA…’
The vibe has now become fear – fear of disaster, fear of launching something so bad that it will define people’s career. Everyone is exhausted, everyone’s catastrophising, and it’s your job to overcome the denial and get the thing launched.
This is the hardest part of the job. There are always more reasons to not do something than to do something. There is always *some* risk, even for your state of the art trouser-press blog. Most of all, nobody wants to be the one to pull the trigger. The Editorial team used to tell you that if you didn’t launch on time they’d lose their jobs. Now they’re saying that if you launch on time with this product they’ll definitely lose their jobs. The commercial team are picking up on the anxiety, and are starting to question if the thing is any good. Even the CEO is sniffing around, saying, ‘How’s it going?’ with a cracked smile and a vague air of menace.
This is the bit where you go and take soundings, and you find the smartest people on the project and you get them to admit, under fierce questioning if necessary, that actually it’s not perfect, but it’s ready to launch. This is where you earn your money and make the call, and it’s hard, but you make it easier for everyone else if you make sure that everyone knows it’s your call so they can stop worrying and finish. When Eisenhower ordered the D-Day landings, he wrote a letter taking full responsibility for its total and complete failure, and walked around with it in his jacket pocket all day waiting to find out if he needed to use it. It was on him. Thankfully your new me-too mobile payments app doesn’t bear quite the same weight of history, but it’s the same leadership principle. You’re the one who says it’s time to launch. The temporal distortion is over: it’s time to go.
Then you launch it, and its fine, or it’s not fine. And then you improve it for as long as you can, until you have to launch something else. And then you do it again, and it will feel just like it did the first time around. And that really is time travel.
Michael Parsons is a Digital Product Consultant and has worked on product launches in the UK and US for companies that include CBS Networks, Conde Nast, and Immediate Media and with brands that include CNET, Wired, Vogue, and Gardener’s World.