So whilst I believe it’s impossible to properly understand a novel problem at the start of the project, most established design methods (which I refer to as project maps) work on the assumption that it can be: Encouraging or prescribing an initial problem finding stage followed by the solving stages.

The Agile Method is perhaps the most exciting recent development in this space, coming from software development and now making its way strongly into the language (at least) of project management and design. The Agile approach is an iterative circular method which encourages regular checking in and small scale testing with the client. The idea being that the client is “at the heart” of the project, with the team consisting of cross-functional members to avoid silo thinking and a blind passing-the-ball to the next person down the chain.

So whilst I’m not a fan of circular methods, it’s definitely a positive step forward and I’d like to see how well it works in a hardware environment. But even so I believe it could be improved further with the addition of a project compass to keep an eye on the big picture and check everyone’s perception of reality.

Your project compass should show you what turns you took, what places you saw and also reveal the things you could have done. So that no matter which set of instructions you’re following or how closely you follow them, you’ll always be able to see if you’re on the right path or not.

The goal is balance, but how to balance is a personal choice based on how much risk you want.

Your How activities, that progress the design and build of the project, whether it’s a new product or a new business, should balance with the Why activities that give you clarity of purpose and validate the need.

Deeper and deeper understanding of the need you’re trying to satisfy allows you to commit more and more resources to achieving it.

Without sufficient understanding, going any further forward is a risk.

So lets see how it comes together…

So let’s chart the spend profile of this project, how much did it cost them and when? Initially things were cheap, just some engineer time to brainstorm possible solutions. But costs climb rapidly in the second half as development work ramps up and they get excited with their progress. Not sure if what they have made is good enough and seeing the potential to improve it they spilt up their efforts and actually build a range of products. Each with different primary attributes for different tasks.

Below the line, the team understanding stays the same, all being based on the boss’ insight at the start.

Without telling you if this project was a success or not, looking at it plotted like this, do you think their chances of success were high or low?

This team were not fools. They are very talented engineers, but what chance do we think the boss’ hunch was right? I’d say slim.

Then we have 6 months of inactivity where they had to start again almost from scratch, based on memories of the issue. Again, chances are slim that this had a beneficial impact on the project.

Finally they spent a large portion of their money making changes they didn’t know were needed. So whilst they have cast their net very wide, it’s almost a certainty that much of this work was wasted on variations the market didn’t want or need.

FAQs

This process seems vague, how do I use it?

You’re right, it’s not a detailed prescriptive process, it doesn’t tell you what to do. We use prescriptive methods to tell us what to do, they are a set of instructions. But if I am exploring a novel problem I don’t know what to do or which instructions to follow. So I don’t want a prescribed route, instead I want to have freedom to do whatever I need to do to tackle the problem, whilst all the time keeping an eye on how much I’m spending and how far away I am from solving it.

The Jump & Dive approach helps you keep track of your efforts to solve novel problems by revealing imbalances in your activities. Why is that useful? So that you can change your focus if needed and predict the likely chance of future success.

If you were in a management position and needed to make a decision on whether this project should continue or be stopped, perhaps you can only continue with 3 out of 4 projects… Comparing the Cost / Confidence for each of them would help you know which were more likely to succeed. See project diaries and reflective tools for more information on how to do this.

Does it matter if you Jump or Dive first?

It makes no difference at all. I tend to have lots of ideas quickly so will generally do a jump first, but this first jump stage might only take an hour, a day, a week maybe before I start trying to test these ideas through user research. It all depends on the scale of the project.

Whichever way you wish do it, be careful that the first ideas you have don’t send you down a narrow solution path too soon or that your initial research doesn’t close too many interesting doors before you’ve given them a creative push.

You need to always keep an open mind whichever way you do it.

What can be done to limit the level of false confidence in a project that has progressed by quite a bit?

False confidence is an infectious disease. I believe the only way to tackle it is with frequent WHY activities and independent projects reviews. Once you’ve drawn the project compass it’ll be obvious to see whether the team’s confidence is based on some truth or falsehood.

Just like COVID… take a step away from the infected project, and look at it objectively, test the real confidence level: is the problem you are solving the right one to achieve your objective.

I’ve read how the fear of failure in creative processes can cause a reduction in innovation. During the design process, how would you go about finding the balance between the risk of failure while making sure that people still feel emboldened to make innovative decisions?

I believe failure for every novel project is inevitable, the problem is too complex to ever be right first time. So if the first version is always a failure, there is no reason to fear it, don’t worry about it! Get through it as quickly as possible so that you start uncovering real customer insights to make version 2 a success.

There’s a few issues I see where development teams get this wrong:

1. They treat novel problems as routine and spend far too long trying to get it right first time (which as we’ve said is a waste of time and money).

2. After a novel project inevitably fails, they don’t learn from their mistakes and just repeat the same routine process again hoping to be luckier the second time.

3. Because of point 1 & 2, management are reluctant to continue funding the project (or start a new similar) because a repetition of the process gives no guarantees that anything will change a second time round. Management want data, not luck.

If the failures are small, fast and the outcome is learning, you can be emboldened to make more. Think of them not as failures but as experiments. Real failure is spending more than you can afford on something that doesn’t return what you need whilst learning nothing from it.

How do you manage time in general between each jump and dive without running the risk of not doing sufficient idea generation or research?

There’s no definitive answer because it can depend on a range of factors affecting you or the project being worked on. Idea generation is relatively very quick. The problem is that without focus, idea generation doesn’t yield much. So move quickly to a testing phase as quickly as you can because that’s where the progress is made. A couple general approaches I’d suggest would be:

• For fixed time projects with a known deadline - Since the first idea is almost certain to be a failure, we need to plan for several creative jumps. The Explorers “Fuzzy to Finished” Model would be a useful guide for this.

• For open ended projects with no fixed deadline - I’d do it with a series of “Cost Gates”. For example, it could be don’t go beyond £1,000 of spend before we reach a certain level of confidence, then maybe £5,000, then £15,000 and so on.

Do you think this visual representation is accurate for large companies? Wouldn’t some activities (design, testing and refinement) occur in parallel?

Small teams will tend to do things one after the other, but big teams or big projects, can absolutely run things in parallel. It all depends what level of ‘zoom’ you want to apply to the project. Are you zoomed out and looking at the big picture stages or zoomed into the details and activities of each individual person?

In this example, the development team splits to focus on two different elements at the same time, one doing a research dive and then a subsequent development effort whilst the other meanders through a different technical challenge. The outcome from the first was not used for any user testing but some of the technology developed was incorporated into the output of the second to form a new version for customer tests.

Design, technical testing and refinement are all HOW activities that can definitely all run in parallel. But meaningful user testing (WHY) can only happen when you have something tangible to show them. Yes development activities can and will continue in the background to those user tests, but they are at risk if the results are not what you expected.

Individual elements within a project will all happen sequentially but likely in parallel with each other… An engine will go through the same process but perhaps in parallel to the progress of the chassis, styling or interior for example. Look at the project diary template, this is where the real details are kept. The jump and dive model is meant to be just a quick visual guide.

I have done some research into structured problem solving techniques ( Lean Six sigma DMAIC for example) and have not found much on the application of problem solving techniques like this in product design and development. I appreciate that it is important to not over-constrain the design process, but I’m also a believer that well defined processes are key to success. What is your opinion on this topic?

I think there is absolutely a place for something like DMAIC in design. It is the same as many other processes, circular in nature with logical steps that basically follow a process of: establish what the problem is, measure it and improve it. In my mind its the same as any other traditional method... establish a spec, design and build.

It or something similar is exactly what I would use for what I call a "routine" problem. Routine problems require only problem solving. There's no (or a highly constrained) problem 'finding' element. Fixing something that has gone wrong, improving efficiency, all the usual manufacturing challenges are all strictly problem solving.

But designing a consumer product, something with human interaction or something new and different can't be done effectively with routine methods. Unless you try to split it in two, a problem finding phase followed by a problem solving one. But this is impossible because you only discover the real problem that needs solving as you try and solve the first one. If during this second phase you only have your solving hat on (like DMAIC suggests) you won't notice the problem has changed until you complete the whole cycle, which may take years for complex or highly inventive projects.

Personally I don't like process. I think it's a very slippery slope into bureaucracy, box ticking and the death by design of creativity. 

Which is why I've come up with the balanced jump & dive approach. This approach doesn't matter what you do, as long as you think about why you're doing it. It's very strong on reflective practise, do something, analyse if that helped, continue or change course, and at the end of the project, if you’ve kept a project diary you can see where you went wrong and improve next time.

I believe you only need a strict process if you're new to something (the more experienced the less constrained by process people tend to become) or if you have to report to someone (so they can easily understand, compare and judge).

As teachers we want to see your process so that we can judge if you were logical or just lucky. There are plenty of lucky people around, but you wouldn't ask for financial advice from a lottery winner. It's the same with engineering and design.