How to Prototype your App

Finding Product-Market-Channel-Model fit

Demonstrating demand for a given product prior to building it is necessary but not sufficient for commercial success.

I've come to realise that there are several other pieces to the commercialisation puzzle. When prototyping your app, if you only validate your own capability to build your product and your user's willingness to use it, you risk being falsely reassured on the size of your opportunity in front of you. Especially in healthcare.

To correctly validate your opportunity, you need to attack each of the following assumptions:

1. Product
That you can build the product you're promising


2. Market
That there is a cohort of users who want your product and are willing to pay for it


3. Channel
That you have a way to access these users repeatedly


4. Model
That you can price your product in such a way to economically satisfy your Channel and your Market

I'd like to give credit to Brian Balfour for the foundational theory crafting around this topic, whose 2017 blog post really distilled this idea for me.

When I built the mobile app Rapid Access to Forms, I knew at the outset that I could easily build the product, and that there was a cohort of people that wanted to use it. As a junior doctor who hates rifling around for forms each day, this was low hanging fruit in terms of problems that need solving. In that sense, my product and market were partially validated out of the box.

(It turns out that ultimately there were problems in these domains too - perhaps I'll share more on that in the future).

What I failed to adequately consider before investing many weeks into Rapid AF were both the Channel and the Model.

I do have a limited "word of mouth" or "personal network" channel at the hospitals where I have worked or studied. But how could I grow the use of the tool beyond this? Setting up Rapid AF at a new site is unfortunately reasonably involved, and so to do that from the outside of a given hospital's ecosystem would require a lot of effort from a sales or customer success point of view.

People who work in a hospital environment will attest to how hard it can be to make change.

And if I need to provide many dozens of hours of installation, support and maintenance for every customer who adopts Rapid AF, then I need to charge an amount of money to justify this - likely in the region of many hundreds to a few thousand per month.

And so suddenly, my tool that probably generates a few hundred dollars per month in value (depending on the size of your hospital) needs to cost $1000 per month at an absolute minimum to justify the support systems necessary for its existence.

As you can see, the Channel/Model fit has really broken down. In other words I couldn't acquire customers for a price that justified the revenue they would bring me. This puts a low ceiling on the potential growth of a project. If the only channel your product can be distributed through is your personal network, it's going to be an uphill battle to grow.

Exceptions to the rule

There are exceptions of course. Many of Atlassian's products are just so outwardly the best in their industry that they have a very frictionless distribution channel. They employ very little salespeople or customer support staff relative to the size of their company. The word of mouth and goodwill their products generate are enough to sell themselves.

It also helps that they're selling technical products to software engineers who have the capabilities to independently configure their products right off the shelf.

Unfortunately for us mere mortals, it's unreasonable and in fact dangerous to assume that a product you build will be so good and the uptake so frictionless that it will spread organically via word of mouth. Especially in a hospital ecosystem where the burden of change management is so immense that virtually no meaningful system-wide innovations happen spontaneously on a month-to-month basis. "Build it and they will come" might have been true at one point in history, but it's certainly not true today.

Validating your app efficiently

So, we know that we should attack our underlying assumptions with respect to Product, Market, Model and Channel to increase our chance of success with a prospective product. As you may have gathered, that's really complicated, and can take lots of money, effort and time.

For an emerging entrepeneur it's essential to be able to prototype each of these domains quickly and affordably, because we've got finite resources.

So how do you validate each of the above efficiently? Here are my thoughts.

1. Keep things as lean as possible to begin with

For every assumption you're addressing, do the minimum amount of work required to address it. For example, to validate your ability to build your product, build the most simple version that solves your user's need. It realistically won't have every feature you had dreamed of, but if you build too much too early, you risk wasting time and money. On the other hand, to validate your distribution channel, you might film a few short YouTube videos or run a series of low-budget Google Ads to demonstrate that you can acquire users in this way. In that sense, you're prototyping your user acquisition strategy. After all, to build a successful business, you need a repeatable way to access new users after the launch peak dies down.

2. Attack each of the 4 domains in a uniform way

It's no good proving that you can build a highly advanced version of your product before you've demonstrated that even one person is interested in it and willing to pay. You should invest your time and effort evenly among Product, Market, Model and Channel because solving one of them entirely at the expense of the others is likely to lead to wasted energy. You should have confidence in all 4 of these domains before you invest to heavily in any individual area.

3. Go after the most important or unlikely assumptions first

By going after the dubious assumptions about your business first, you provide yourself with a chance to save time and money. Let's say you're selling handmade kids toys for $12 each. Your Channel assumption might be that you can profitably sell these toys using Facebook Ads. This is quite unlikely given the low price of the product. If you try to verify this assumption first and it fails, then you won't waste time designing or manufacturing a product you'll never be able to sell.

An example in action

As luck would have it, I'm prototyping a software product as we speak.

My friend Phoebe Bardsley and I have a hypothesis that the peer-reviewed research system is broken, both with respect to the price and the accessiblity of research to every day people.

We're prototyping Journable, an online research journal that is powered by digestible audio summaries of peer-reviewed papers.

Here's a bit of a roadmap about how we're approaching the assumptions in these domains:

1. Product
We've built a very simple Wix site to host our first few episodes - it took around 2 hours to make!


2. Market
We've recorded a few research summaries and are drip feeding them out in the hopes that we can capture emails of interested users.


3. Channel
Our plan to repeatedly acquire users is to share these episodes via YouTube, Twitter, blogs, and communities that might be interested in the subject matter.


4. Model
It's our hope that one day, users would pay a subscription to a given stream of research summaries in order to stay up to date with a given field.

The first assumption we're verifying is that people will find value in short engaging audio chunks that summarise topical research. You can check our first episode out here. Wish us luck!