Validation, Practically Speaking

gravatar
 · 
3rd June 2024
 · 
6 min read

So what does validation look like on a practical level?

Photo by Daria Nepriakhina

Last week, inspired by Noah Kagan's book Million Dollar Weekend, I went into some depth on how the concept of early validation of an idea can test the merit of a business. Without even needing to build anything.

Of course, in product design, and especially medtech, it's never as simple as asking someone if they'll pay for what might build. Yet it is still possible to work with users and decision makers very early in the development cycle. This ensures that what you're building both meets their needs, and is sustainable as a business.

However, after reading a Dovetail article called "The four deadly sins of continuous discovery" (an amazing ex-colleague of mine works there), I was somewhat abashed that I hadn't gone into more detail in my own article on exactly what that validation should look like.

Side note: Dovetail puts out many high-quality articles, including the one I linked, I'd encourage you to have a look through their Outlier blog.

It's a classic case of assuming that everyone knows what I know. Which, I suppose in time and with enough articles, I'll get the hang of breaking down in detail the things I take for granted.

So what does validation, especially early, informal, and formative validation, look like on a practical level?

That, detective, is the right question.

Without a deliberate approach to validation, you won't have the specific data you need to make informed decisions that progress the design and development. Without clear objectives for your validation, you're just collecting data for data's sake and you'll get nowhere.

Taking another cue from Dovetail, I'm going to break it down into four 'questions' that you should really be asking yourself and your users to ensure you're getting the right information you need at the right time. This isn't an exhaustive list, but are some of the most fundamental questions that you should be seeking answers to early on.

They are:

  1. Who has the power to make or break your product;
  2. What feature will make your product and what failure will break it;
  3. What exactly are you trying to discover; and
  4. Are you documenting the journey.

Let's get into it.

Who Has The Power to Make or Break Your Product?

To get the right answers, you need to start with the right question (more on that later). But asking the right question to the wrong person is equally unhelpful as asking the wrong question.

First, find the right person/s.

This is the core of any discovery phase; talking to the people who will use and/or buy your product.

Just because you have identified a need doesn't mean you are correct. And even if you are correct, doesn't mean you see the whole picture. Any decision you make without evidence is an assumption. And as the saying goes, to assume is to make an ass out of u and me. Remember:

You are not the customer.

Have a think about who will use your product.

Just as importantly, have a think about who will buy your product.

Often in healthcare systems, they are not the same person. If you have a product that users want, yet procurement won't buy, you don't have a business. You will need to rethink your product, your customer, or at the very least you need to rethink your business model.

Kagan in his book talks about his one-minute business model. Which is simply identifying the size of the market for your product, if it's growing or shrinking, and how much that market will pay for your product.

You need to go on fact-finding missions to identify who your market is. Talk to the users as a start, and follow the network chain up and down to identify the people that have the power to make or break your product.

Keep in mind that this may not be the person that has the most experience, skill, or authority. It could be the people with the least skill or experience, and subsequently present the most risk. Risk they or others may be looking to mitigate.

What feature will make your product and what failure will break it?

Once you've found the right person/s to ask, it's time to start asking the right questions.

As with any product, there are things that your product absolutely must do well to be viable in the market. And there are other things that it absolutely cannot fail at.

I wrote some time ago about maintaining purity of purpose in product design. In every product, there is a single function that it must perform to serve its purpose. Chairs seat human bodies. Rulers measure distance. Spotify plays music. This is where you find out what that is. Talk to the people you've identified, and ask targeted questions.

Don't let them just tell you their solutions either. Make your questions pointed about why they have the problem they have. What is the cause, and what causes that cause. Be observant and challenge what you hear.

In medical devices, this is almost always summed up in your statement of intended use.

As Caitlin Sullivan puts it in the Dovetail article: Their problem should be excruciating, and your solution make them ecstatic.

Conversely, also find out what it is that your product must not fail at. Something that if it did, would entirely undermine its purpose. Failing at its purpose could be included here, but that is not always the case. In medical devices there are always things that your device shall not as often as it shall. This will become a long list once you wade into risk management, but for now keep it top level and succinct.

What Exactly Are You Trying to Discover?

When trying to validate an idea, and later the product, it pays to be specific about the questions you ask and the answers you're looking for.

Have clear objectives before you talk to your customers:

  • What is the biggest unknown you have?
  • What is the key decision you're trying to make?
  • What choice are you trying to confirm?
  • What test do you need to run?
  • What pieces of information do you need to progress?

Every bit of data you collect should be progressing you to the next decision point. These should be granular and very specific. They should, of course, also be asked to the right person to get the right answer. Don't ask the nurse how much they would pay for the device, and don't ask procurement how often they would use it.

Are You Documenting the Journey?

Remember that assumptions can turn turn u (and me) into an ass? This is important in all product development, but especially in medical devices:

Document your journey.

Collect your evidence that backs up your decisions.

You'll need to maintain traceability through user needs, risks, and requirements anyway, so you may as well start now. When you ultimately need to show where those requirements come from, you can trace them right back to the root.

Make it a journal. Before your meetings write down the things you want to discover, and during your meetings write the things you do discover. Preparing beforehand ensures you get the specific answers you need. Conversations can often meander, side-track, and railroad. Stay clear on your objectives.

I work a lot with super-early product development, and I find it simplest to use a rolling text file (I use Markdown) where I note discussions had and decisions made under the date on which they happened. Every new entry gets appended to the bottom of the document. It doesn't have to be neat or detailed, it just needs to include the information.

Continual Validation

As I discussed last week, validation should happen continually throughout development.

Don't wait for "validation" to do validation.

While I've focused here mostly on the validation of the idea (again), the same holds true for all validation during development. Albeit, as the development matures, the detail and formality of the validation increases.

Make sure you're continually asking the right people the right questions.

Don't assume.

ⓒ Lincoln Black 2024

Get some free design thinking, fresh every week. Straight to your inbox.

I respect your privacy and will only send you the fresh design thinking you've asked for.

Virmachi-Logo-White-Transparent

Virtimachi Pty Ltd

ABN 31 651 760 762

PO Box 7156 Kariong

NSW 2250 Australia