The idea was simple. We knew that CV’s fail to deliver on their promise in the recruitment process. They are an idea formed in the late 1950’s and have barely changed since then. They are increasingly commoditised, and describe what you’ve done, not who you are. In short, they lead to poor recruitment decisions – as witnessed by the 60+% of people who look to change jobs within 18 months of appointment to position.

So the project idea was to provide an alternative to the CV – a document that described the personality and profile of an individual, and give candidates a better way of explaining their strengths. It would enable recruiters to consider whether a candidate would fit the role as one of the first questions they consider when selecting candidates for interview and do so in a way that reduces traditional bias.

This didn’t sound so difficult, and we thought that the initial MVP would be available in a matter of months. Having delivered a range of innovative projects, we knew that this was unlikely to be the case and extended the initial estimate to 12 months. 18 months later, Higher.Work was finally launched.

Discovery of Clarkson's law

During this project, we had an ‘epiphany’. We learned that the duration of a project was inversely proportional to the depth of understanding of the problem. In simple terms, when your thinking can be captured in a paragraph, you’re a long way from launch. We named this ‘Clarkson’s law’ – in homage to Jeremy Clarkson’s infamous battle cry of ‘how hard can it be’, which is inevitably met by failed solutions.

You don’t know what you don’t know

The root cause of Clarkson's law is that at the start of the project, you haven’t, by definition, thought through every aspect of the project. Your assessment of what needs to happen is distorted by the simplicity and enthusiasm for an idea. As the project develops, your understanding of the requirements develops. Anyone who’s been involved in IT projects will have been met by the challenges of ‘scope creep’ – the idea that what’s required is more than was originally specified. However, in reality it's not that your solution needs to deliver on additional outcomes, it's that your solution is required to do more to effectively deliver the initially defined outcomes. In fact, we fully support the Jeff Patton idea that ‘Scope doesn’t’ creep, understanding grows’.

You can’t tell if you’re right until you see it

Learning exactly what's do be done requires seeing the solution in action. A description (however well articulated) won't be enough. There’s an idea in psychology called ‘Cognitive dissonance’ which in simple terms is the uncomfortable feeling that we have when what we think and what we do are inconsistent (think about how you feel when you have that chocolate after dinner and break your diet). In new / innovative projects, there is a sort of cognitive dissonance that works in your favour. Your brain is great at taking in visual clues and descriptions of something and then seeing if all the inputs are aligned. Only when you see what doesn’t work are you able to define what does.

For a small example from the above example of Higher, we thought it would be powerful to dynamically generate a coat of arms that captured your personality. It would resonate historically and give a shortcut to understanding people you meet. However, after several design iterations, we realised that it was just too simplistic and distracting.

Design is not a child of the idea, it’s a sibling

Traditionally, there’s a mindset that says, ‘get the ideas straight and then find a design that executes on them well’. The idea is treated as ‘the parent’ – the design is ‘the child’. However, good design is as much about problem solving as visual creativity and we regularly find that the process of design helps us grow our understanding of an opportunity and has generated new ideas that improved on the initial thinking.

It’s not unusual for designers to be seen as ‘second class citizens’ relative to the ‘business leads’. It’s a mistake and leads to missed opportunities.

Another example from the Higher project came as we were exploring personality assessments. Recognising that a user has a certain personality type, and looking to enable them to explain their profile without jargon, we realised we needed to build a personal portfolio – where individuals could build a bank of evidence, a set of stories that would allow them to explain themselves better in career conversations. This line of development resulted from the design of the personality feedback.

Higher.Work example: Once users understood their profile better, how could they prove it?

Iterations lead to learning

In our experience, you need to do more iterations that you initially plan for. Each iteration deepens your understanding about how you are going to solve the problem for the user. The initial version of something is typically equivalent to a view from (say) 5k feet. Each iteration takes you closer to the ground. And as the ground comes into view, you learn more about how the solution needs to land.

Prior to the launch of Higher, we iterated through 7 different sets of home pages. The home page, in essence, describes the core idea. In a linear model, this should require marginal changes over time. Indeed on each iteration, we were sure we had the right answer – only to have to change it again as we developed and tested the solution.

Solution

We now have 4 steps that we follow to understand and develop the solution:

Step 1: Recognise that the idea strength will develop over time

There’s an urban myth (which maybe true) that one of the famous West Coast American VC partners has a criteria that they’ll only invest in a business if the founder has been working on the problem for 5 years. In essence, an innovative idea and solution needs time to mature.

Few innovations have a 5 year incubation period, so we expect that there will be considerable learning that takes place during the implementation.

Step 2: Practice the ‘shimmy’

We refer to the practice of taking an idea, sketching it out, seeing it work and iterating on it as ‘the shimmy’. For agile software architects or innovation experts, this is effectively an iteration, but the emphasis is on understanding how the tangible solution improves the basic idea, and takes the project forward. Recognising that you’re going to do a ‘shimmy’ several times allows you to not get too focused on details before you’re ready.

Step 3: Capture the core idea simply

Business plans, briefs and requirements documents have a poor track record of being read, and a worse record of being updated and kept up to date. To overcome this, we combine our unique ‘Business Tweet-deck’ approach with use of videos. With the 'Business tweet-deck', the core ideas are captured in a series of 140 character descriptions. Confidential to the project, easy to read, update and see the evolution of the ideas, they reduce wasted effort.

Step 4: 5 How's

If you’ve any experience in lean thinking or structured problem solving, you’ll probably have come across the 5 Why’s technique: when trying to understand a problem, ask why; then ask why to your answer; then again etc.

When it comes to exploring a new project, the same approach is applied but this time focusing on how (not why). In a separate article, we’ll cover off the importance of the ‘how’ question, but suffice to say, going through this exercise allows you to quickly get a gauge of project complexity and identify which areas of the solution will require more focus.

Conclusion

Innovative projects are, by definition, focused on doing something new. Most businesses are configured to be really good at following existing ways of working, and tend to have less experience on doing things differently. They over-estimate how well they can describe their idea at the start of the project, and then create downstream challenges when it comes to setting milestones and delivering to budget. Our 4 steps to developing idea strength can help make your innovation process more efficient and effective.

Take aways

Here are a set of questions to help trigger your thinking about understanding 'how hard can it be':

• Have you captured the core ideas simply?
• What level of detail have you considered for the solution?
• How soon and how often are you getting to see the solution?
• Does design have an 'equal seat' at the table?
• Have you planned enough iterations to get to your MVP?
• Have you completed a 5 how's exercise?