He’s mainly awesome, in my opinion, because of things like this:

The old, ‘punch you through a car window and steal your gun’ trick.

See? The man is built like a tank, has the reflexes of a super-ninja, and the charm and wit of Jeff Goldblum in Jurassic Park. As a character, he seems to be almost entirely without flaw – proof that god can indeed give with both hands.

And then (and I’m purely making this comparison because he’s another character that Tom Cruise seems to think he actually is, in real life) there’s Ethan Hunt. Does everyone remember Ethan Hunt? Silly question really – how could anyone forget the impossible mission leader working for the Impossible Mission Force? Let me refresh your memory. He does things like this:

exploding. goddamn. sunglasses.

He’s pretty badass too. But I think there’s an interesting contrast between these two characters which we can relate directly to the day to day fun and games of working in the tech industry; problem solving.

Ethan Hunt would be pretty pants at this in real life, for all his badassery. No doubt, he comes up with some fabulous solutions to some equally fabulous problems – but, in contrast, Jack Reacher approaches problems like a product team will approach user stories: we assess their size and break them down. In contrast, Ethan Hunt would take a problem the size of a businesses entire 5 year plan and attempt to headbutt it until it isn’t there any more. And then set it on fire. Yes, true, they always seem to make the impossible mission possible, in Mission Impossible (boy was that fun to write), but this is the movies; in real life this approach can get a team pretty unstuck pretty quickly. More on that later.

Let’s make a comparison to illustrate my point (thanks IMDB!). Here’s the synopsis for MI2:

Ethan Hunt leads his IMF team on a mission to capture a deadly German virus before it is released by terrorists. His mission is made impossible due to the fact that he is not the only person after samples of the disease. He must also contest with a gang of international terrorists headed by a turned bad former IMF agent who has already managed to steal the cure.

And here’s the synopsis for Jack Reacher: Never Go Back:

Investigator Jack Reacher springs into action after the arrest of Susan Turner, an Army major accused of treason. Suspecting foul play, Jack embarks on a mission to prove that the head of his old unit is innocent.

There’s a pretty stark difference here between the two problems being tackled – and one important detail is neglected in the second synopsis, namely being that Jack Reacher wants to clear Susan Turner’s name because he wants to go on a date with her. Because she has a nice voice. That’s a nice, sizeable problem to tackle. Getting a date. Ethan Hunt however is attempting to save the world from utter devastation. And zombies. German virus zombies.

Deep. Breathy. Intimate.

Now, I have to apportion some of the blame here on the Impossible Mission Force; I mean, the company actively discourages breaking down an impossible mission into several, smaller, possible missions, and I can see some obvious reasons why that makes sense, not least from a PR and recruitment angle. Who wouldn’t want to work for the Impossible Mission Force? That job title would make for a most excellent business card. In contrast, Jack Reacher is a lone agent, a self-confessed maverick who plays by his own rules; he has no Impossible Mission Force insisting that his missions remain impossible. It’s a nice life for some, trying to get a date and in the process solving a big conspiracy theory.

Anyway, I digress. The comparison being made here does, I promise, have some direct application to the world of product development. Our approach to a problem is as crucial as identifying the solution to the problem, and it underpins almost everything that comes afterwards: the metrics we’ll measure, how long we’ll spend trying to solve the problem, what the proposition looks like, and, fundamentally, whether we can even be successful or not. How we approach a problem and how we break it down is the bread and butter of our roadmap, and getting this step wrong can have huge repercussions.

This doesn’t have to mean that we need to put limitations on our creative process and the possibilities for solving a problem, by any means; I’m sure everyone is familiar with the concept of 10X thinking, a term coined by Google, and yes there’s definitely a place for this in the sphere of product development; the point here though is that 10X thinking should be related to the solution we arrive at, not the size of the problem in the first place. 10X thinking can only exist once a realistic problem has been identified in the first place. We can’t apply magical thinking to a problem that is too big to solve, and there’s no point in trying to solve a problem as a whole if there’s any realistic proposition of breaking it down into smaller tasks. Breaking down a problem efficiently offers two key benefits; problems become easier to solve, and team morale improves as problems are, indeed, solved.

I’ve got nothing. I Googled ’10X thinking’ and this is what I found.

Let’s take a typical product team setup within a general business structure. We have;

• A business objective (long term; years)
• Which forms the basis for a product statement (long term; years)
• Which allows us to articulate goals for a period of time (with KPIs) (short term; months)
• Which underpins our problem roadmap (with KPIs) (short term; days/weeks/months)
• Which drives the development stories (short term; Hours/days)

The business objective is in itself a problem to be solved. This ties into the product statement, the raison d’etre for our product within the context of the business. This product statement is again a problem, tied back to the business objective. The product statement is then broken down into a series of goals or objectives to be achieved over a period of time, with measurable KPIs tied to them. These in turn are broken into even smaller problems which can be plotted into a problem roadmap, problems which the team can endeavor to solve and measure by the implementation of user stories, again aligned back to the product goal, which aligns to the product statement, which aligns to the business objective.

This structure offers every member of the team traceability for each piece of work they do, back to the very high level business objective that is driving the development. And this structure is incredibly important; being able to articulate a business objective into practical problems to solve is key to ensuring that the things we build are aligned to the reasons that the product exists to begin with. Getting this wrong can leave teams trying to achieve the (mission) impossible, which can cause team morale to dip and belief in the product team to falter, as KPIs routinely fall short.

Let’s take a stab at this: company X sells shoes online. They have no physical stores, but they prop up their direct web sales with retail profiles on Amazon and eBay. The business objective is to Increase sales by 20% for the financial year. Within this business model we have several products; a website, and shops on eBay and Amazon. Each of these ‘products’ should have it’s own product statement, so let’s take the example of the eBay shop. Their product statement might be To offer the most competitive alternative to buying second-hand shoes via an online marketplace. This aligns to our business objective because, we know, that offering the most competitive alternative should, by rights, increase sales. But how do we achieve this? Here’s our problem, and this is where our product goals come in. As a product, the eBay shop team may decide to set three goals for the first six months of the year for their product, each aligning back to the product statement; increase seller reviews from 4.0 to 4.5 stars, reduce turnaround from order placement to delivery by a day, and reduce bounce rates by 40%.

Each of these goals can be tied back to a hypothesis, which in turn can be tied back to the product statement; we want to increase ratings, for example, because we believe that the more trustworthy our buyers perceive us to be, the more likely they are to consider us a viable alternative to buying a second hand pair of shoes, and therefore the more likely they are to complete a purchase. Now we have our product goals, and from here we can begin to deconstruct these into smaller, more manageable problems to solve – our problem roadmap. For example, we might decide that a problem to solve might be that a high proportion of buyers don’t leave any feedback at all, so finding a solution to that issue may become the first problem on our team’s problem roadmap.

From there, the team can take this problem and work out some proposed solutions; maybe they decide that the first possible solution might be to send an automated email asking for feedback after a product has been delivered. This can be implemented, and then measured, in relation to the KPIs defined for the problem roadmap, which in turn can be measured against the short-term goals, which can in turn be measured against the product statement, and onwards until we hit the top of the problem chain. When this model works, everything being built should be traceable back to the top-level objective, and every member of the team should be able to articulate why they’re doing what they’re doing.

On the flipside of this, if the team is simply given the task of increasing sales by 20%, the fact that this problem hasn’t been broken down to a manageable level can leave the team trying to climb mount Everest; the likelihood of implementing a single feature that solves this problem instantaneously is slim to nil.

Giant problem-bear totally ate your solution.

This can also cause issues in terms of the actual implementation; if a developer is given a remit that isn’t transparent in terms of its objectives, it is nigh on impossible to articulate where to draw the line in terms of engineering effort; without context of where your task fits within the wider picture, there’s no basis by which to prioritise the appropriateness of your solution – or indeed to ensure that what you build is a suitable platform on which to build whatever is coming next.

Being able to review the problem you’re trying to solve in the context of the business within which you are working is crucial, and there are some practical methods for checking in on the goals your team has been set to ensure they’re the right size and shape for your team to try and solve ( I know: IMF would hate this). One method is to apply the INVEST principles, commonly applied to stories, to your problem:

• I – Independent; is the problem sufficiently independent in that a solution can be worked on without the need to depend on other areas of the business?
• N – Negotiable; is the problem sufficiently broad so that a series of potential solutions could be arrived at?
• V – Valuable; does a solution to the problem offer a value that can be articulated concisely, which aligns to the wider business objectives?
• E – Estimable: can any potential solution to the problem be estimated (with some degree of certainty) in terms of the effort required to achieve it?
• S – Small; is the problem small enough that the team can arrive at a solution they have a reasonable degree of certainty might solve it?
• T – Testable: Once we’ve applied a solution, can we test the effectiveness of that solution in a practical fashion?

Being able to revisit the problems you are being asked to solve, and being able to gauge that they’re suitable to tackle is massively important, and something like INVEST can offer some tangible methods by which to do that.

I have it on good authority that Jack Reacher uses INVEST to work out if he should tackle a problem or not in the first place. Ethan Hunt? Well, he’s got wicked-sick sunglasses, for sure; but he’s biting off more than any reasonable product team should chew.

Sorry not sorry.