What Matt Damon taught me about product development
We’ve got a lot to get done and we’ve got to hit the date. We’ve really got to nail down the scope as a lot of people are expecting their stuff to get delivered first. What are you doing about that?
If the answer to that is more requirements analysis, more workshops, more planning, then look forward to the same conversation with the same people in a month. Then again a month later. Etc.
There is nothing wrong with planning. In fact, there is a lot right with planning. Everyone should do it. Everyone should do it more. Do it daily. Review it constantly.
However, if you’re trying to do something awesome that’s going to take a while to get done, then don’t try to produce a detailed plan of how you’re going to do it.
I worked with a fantastic team for a while trying to do something awesome. We’d been given something of a moonshot to take on, which was awesome in the fullest sense – really cool and also very scary. Our team were super excited about the challenge and wanted to get stuck in.
However, to reach awesome we needed a whole load of stuff to happen. So what did we do? We started listing out all the work that was needed, and someone started putting things into something that looked a bit like a project planning tool. (OK, I admit it, someone was me, and that something was Microsoft Project).
But we quickly spotted a problem with what we were doing. It was going to take months to get to a plan that everyone would have confidence in, particularly as we had an understanding of compound probability.
So we had a rethink. Instead of focusing on the work that needed to be done, we started talking about all the things we didn’t know, and all the things we thought might go wrong. This doesn’t take long with a group of motivated people and some post its.
We then talked about priority and schedule, and started mapping out the work required on a timeline. Woah, hold it, this is starting to sound like a gantt chart again.
And this is where Matt Damon came in. Or rather Mark Watney, the botanist, engineer and astronaut from Andy Weir’s book, The Martian, who Matt Damon played in the film adaptation of the same name.
One of the team drew a parallel between our moonshot and the challenge that Mark Watney faced (let’s not get too hung up on the specifics of the challenge, suffice to say no lives were at stake).
The parallel was in the approach to take. If you haven’t read the book or seen the film (both recommended), then [SPOILER ALERT]. Bookmark this article, go watch/read and come back.
Having found himself stranded on Mars, Mark Watney’s first step is not to try to launch himself back to Earth, not was it to plan in detail all the things required in order for him to do so.
Rather, his approach was to “work the problem” and solve each challenge in turn. For example, he recognises that he’s going to run out of food and can calculate how long that will be, so sets to work on solving that challenge. And so on.
Mark Watney did have a plan that would end up with him launching back to Earth, but didn’t waste time planning in great detail all the things that would be required to achieve that before he did anything.
And that philosophy carried our team a long way. Did we achieve our moonshot? No. No we didn’t. But we solved some really tough problems and delivered a lot of value, including demonstrating that our moonshot mission wasn’t actually worth the time and money.
As we reflected on our efforts, there were lots of things to learn. A couple stood out, and I now always look for these whenever I’m starting out on something.
The first was that the team all bought into the vision. It was a true big, hairy and audacious goal, and we wanted it. There’s lot involved in setting and communicating a compelling vision, a whole topic in itself. For today, the takeaway is that you need one that the team buys.
The second is the philosophy of “working the problem.” You can and should put a plan together to achieve your vision, but don’t bother with much detail beyond the short term. Instead, start working the most important problem. Solve it, then move onto the next one.
Will this guarantee success? Absolutely not. But it’s an awful lot better than a 1000 line gantt chart.
