Case Study: Testing the Market More Wisely

Let’s call the company XYZ. It wants to sell a software product to fill a specific gap in a specific market. The design has been done. Now it’s time to hire a vendor to develop the software. The best-looking bid will take nearly half a year before the product is ready to sell. Its cost will take half the cash XYZ has on hand.

What if they do all that and not enough customers buy it? Even though it fills a need, people don’t buy what they need. They buy what they want, and maybe they won’t want it.

Deciding to Prototype

Faced with that scary possibility, XYZ decided to test the market. They have IT background themselves, although they aren’t big enough to develop the whole product themselves. So they decided to reassign their business development and sales lead to build a prototype with only the first portion of the specified functionality and see whether that will sell.

Red-Flagging the Prototype Decision

Havenshire raised a red flag. Let’s step through why their prototype plan isn’t the right solution, and what we thrashed out as a better approach.

Here is our ‘red flag’ email to them, anonymized and generalized:

Whilst we understand wanting to verify that you can sell this once it is built, having Charlie [not his real name, obviously] build a prototype before doing anything else alarms us.

The goal is to find out whether

  • enough people out there will want the product and
  • want it enough to buy it and
  • be willing to pay a price that makes it worthwhile and
  • be reachable by XYZ.

The prototype approach would

  • be a throwaway, as prototypes are, so everything about it would need to be rebuilt if you go ahead and
  • delay the start of work on the actual product (perhaps long enough for the bids to expire) and
  • thereby delay the point when you can begin to earn revenue and
  • produce something so far short of the intended product that it is an entirely different product with stronger existing competition and
  • therefore not test the target market for the target product.

This is why we dislike the prototype idea. There has to be something else XYZ can do that will get closer to achieving your goals and have less adverse impact.

Are Other Approaches Possible?

It would not be fair to simply say that and not come up with any alternatives. Here are our thoughts so far along those lines.

There are two classic general approaches to making a product like what you want to launch, and then there are modern hybrids.

  • One is to build it and create a market for it. That’s the only viable option when a new product is so groundbreaking that the market doesn’t even imagine it yet. That’s the Apple Macintosh in the 1980s when all other computers used a command line user interface. It’s a car when everyone drives a horse and buggy. Admittedly, this product wouldn’t be that revolutionary.
  • The other is to dangle the carrot in front of the market and see whether enough buyers have an appetite for it at enough of a price.
  • In the age of the internet, it is sometimes possible to combine elements of both, and in some cases even gather money or pre-release orders before anything is built.

Our bias is to combine elements of both classic approaches if we can, and going for the third option would be even better.

What Are Some Alternative Ideas?

Some options that come to mind, separately or in combination, presented in no particular order:

  • Charlie can only put full time into a prototype if he drops everything else. That seems foolish when he is just getting back into the swing of networking and marketing [after pandemic lockdown], yet anything less would impose so much delay that development bids on the table would expire. If you want a prototype, you could use the lowest, least capable bid to get a prototype built on the cheap. They are prepared to put full time effort into that. In about two months (just ahead of holiday season shutdown) you would get a prototype that covers the full feature set… albeit without the polish and sturdiness the preferred vendor can deliver. This is trickier than it sounds. The two vendors would each need to work in the website, and each would be unhappy about the other’s deal with you.
  • An alternative to using the low bidder’s version as a prototype would be to decline their proposal for this, but engage them to build something entirely different (less extensive) that you could sell quickly to bring in early revenue and start establishing a presence in the market. Off the cuff, we don’t know what that would be, but it would alleviate the problem of friction with the preferred vendor.
  • The preferred vendor may be willing to tweak its development plans so that you can begin selling access to the product when its feature set is not yet complete but is far enough along to provide value to buyers. Early adopters would buy at a deeply discounted price, somewhat like people who buy real estate off-plan before it is constructed. This would bring forward the date when you could begin to see revenue.
  • You could turn to compatible crowdfunding websites. A couple of them look like they could be suitable. You would not be looking for people to donate in return for nothing, and you would not be looking for investors who want equity. Investors who want to lend would be okay, and people who pledge funding in return for a reward (e.g. launch-priced access to the eventual product) would be ideal, an actual test of the market. You would not need to build your own list first to test the market this way. The crowdfunding website would bring an audience looking for productive ways to spend money. Any list building you do could send people to the project on the crowdfunding website.
  • Speaking of list building, at some point you need to establish a genuine relationship with your segment of the market. You can’t go into relevant social media groups and flagrantly try to sell there, but XYZ could solicit participation in a series of surveys for research. The first survey might ask, for example, to rank which aspects of the market they are finding most challenging: [for which we suggested a list]. The second survey might zero in on what is so challenging about one or more of these… and so on. You can release our findings in two tiers. A public summary will go on XYZ’s website and be announced in the groups where you solicit input. Anyone who wants more detailed findings can give their name (at least first name) and email address to get the white paper. If you do this well, it can simultaneously tweak in-progress software development, build up authority in the market, whet appetites for what you are building, and start the list of warm prospects to whom you can market whatever you want to offer.
  • You can approach venture partners to help market the final product. [We discussed this at some length and one of XYZ’s directors took responsibility for learning more about how to do it.]

These aren’t mutually exclusive. Some of them can dovetail. We think the prototype plan as it stands is not the right move, and we believe we can come up with something better.

Where It Stands Now

XYZ has now held a couple of meetings to put together a new action plan combining some of the ideas suggested. The company recognises that its initial prototype plan wasn’t going to be as satisfying and effective as its new approach.

It isn’t rocket science. But it’s what happens when we apply NASA’s way of thinking to an ordinary business situation.