Feasibility - Derisking and Proving Your Product can be Built

You've got a specification, a technical direction, some timelines to target and a clear idea of what you want to build. You know the what and you know the why. The next question you should be asking yourself is "can this product be built?". Can it be built within the laws of physics, within the reality we live in, and most importantly - can it be built within your budget?

The feasibility stage allows you to answer these questions and progresses you from TRL 2 to TRL 3.

Why the Feasibility Phase Matters

De-risking and uncovering technical unknowns is key to the success of your product.

A few years ago a customer came to us to reduce the power consumption of their product as it was only lasting a few hours, they thought some firmware tweaks would fix it. Upon reviewing the code and the electronic design we determined that the device was already incredibly low power - the original designers had done a great job within the constraints that were set. So what then? The battery capacity had to be increased 4x. This had a huge knock on effect both for the end users, timelines, and the project budget.

If they had found out this fatal design assumption at the begning of the development lifecycle then they would have saved £1000s by not having to revisit the industrial design and source the battery again.

Some feasibility activities can be done on paper - for example calculating power budgets and determining battery sizes. Some things are best tested in reality, and this will uncover other unknowns that you hadn't considered.

These "reality check" demonstrators serve as a great way to de-risk your project, or at least to uncover the risks that are there so that you can accept them, mitigate them, and move on.

The feasbility phase gives you confidence that the development direction and technical implementations that you have made are the right ones - this means that you can push ahead with development in the most efficient way possible.

The Core Goal of Feasibility: De-Risking the Unknowns

You product will have some killer features that make it stand out from the competition - focus on testing the feasibility of these features and not things like making sure you can blink LEDs or charge the battery (unless of course these are your killer features!).

As yourself these questions:

• Can this actually work?

• Can we design-in and produce this for the target price?

• Does this work in the wider landscape?

When you can answer yes to all of these questions then you have validated that core concept. Let's dig a bit deeper into those questions:

Can this actually work?

Think about that killer feature. Does it involve something that nobody else has done before? At Embedism our quality management system demands we dig into the feature with these questions:

1. Is the technical implementation well known or established (do we know how to do it)? If no:

2. Will different solutions potentially result in significantly different development burdens (is only one solution commercially viable)? If no:

3. Is at least one potential solution highly likely to meet the technical specification (is there anything likely to succeed)?

Each question digs deeper and the feasibility test gets more challenging as a result. If the answer to any question is "no" then you need to move the needle towards "yes".

Can we design-in and produce this for the target price?

It's all well and good having a feature that works in principle (and maybe on the bench), but if your project budget won't stretch to designing it in then you might need think about alternatives (or grow the budget).

In addition, if the feature will push the unit cost up and your target sale price goes up as a result, will the market accept that?

Test your assumptions, as your target customers, get development quotes or talk to your engineering team, map out the development risks.

Does this work in the wider landscape?

Geopolitics, component availability, supplier willingness. These are the things that you need to establish when asking this question.

It's no good building your product around a component that is going EOL, or can only be produced in tiny quantities. Or using a material that is so specialist that even the supplier doesn't know how they would produce it in high-volumes.

How to Run an Effective Feasibility Phase

Make it Real: the "Ugly" Prototype

Search for one of the electronic features of your product followed by "dev kit", or "Arduino", and you will likely find a little PCB with the sensor/input/ouput you want readily available online. Buy it! Test it! These kits can help you make a decision on if the part is the right one for you.

Take the cereal box out of the recycling bin and cut it up, build a cardboard model of your product, and then interrogate it. "Can the electronics fit inside this enclosure?", "if this was made of plastic, would it survive in the target environment?". Duct tape and glue are your friends, test all of your assumptions on some free cardboard before wasting hours in CAD.

Test Your Assumptions: the Spreadsheet Reality Check

Spreadsheets are your friend in the feasibility stage. You can model out power consumption and calculate battery life (and size!), you can map out component leadtimes, you can reach out to suppliers and get quotes for key components or high value parts.

Derisk: the Critical Experiment

If there is just one thing that goes wrong, and your product development is derailed, or the product fails (and hence gets returned) you should identify it and test it in the real world.

For example, if your device needs to work in a 200 degree oven, then test the sensors you are using in a 200 degree oven - rather than just assuming they will be fine.

What Good Feasibility Produces

At the end of your feasibility stage you should have several things: some demos of your core tech, something written down to show that you have demonstrated feasibility for t he high risk areas, a risk register (and the mitigations), and a decision - GO or NO GO!

Many factors will influence what these feasibility deliverables look like, for some a risk register is a spreadsheet and for others it is a note on your phone that reminds you to constantly think about where the risk is in your project. Do what's right for you, but don't skip it.

When Feasibility Is "Done Enough"

It's important to know when to stop. When you:

• have data,

• have core components/materials/tech selected,

• and you're ready to start integrating,

That's when it's "done enough".

What Comes Next: Concept Development

Now that we know our product is possible to build, it's time to work out how we integrate across ID, mech, elec, and firmware and build something that meets the critera and is manufacturable.

In Stage Three we will build our concept unit by integrating subsystems and progressing towards TRL 4.