Customers don’t want the shadow of what may come, they look for the complete package. Reduce your story to fit the package you can deliver.
Bringing a B2B software product to market is a resource game. It’s high stakes, but still just a resource game. And no founder has the resources to bring a fully finished full product to market. Not only is this extraordinarily expensive, but it also is extremely risky.
In pursuit of the proper product the founder just might cement in decisions that cannot be reversed but that permanently wall out the proper product. Customers don’t want the shadow of what may come, they look for the complete package. Reduce the story to fit the package, or the product, that can be delivered.
To dream the impossible dream
No longer young… bony, hollow-faced… eyes
That burn with the fire of inner vision. […]
And all he reads oppresses him…
Fills him with indignation at man’s murderous
Ways toward man. And he conceives the strangest
Project ever imagined… to become a night errant
And sally forth into the world to right all wrongs
Mitch Leigh, Man of La Mancha (I, Don Quixote)
The opening lines of Dale Wasserman’s masterpiece, Man of La Mancha, lay a scene that is well known to most veterans of the B2B software game. The endeavor hard; the dream – impossible. And yet, founders persist. What drives this?
The dream drives this. The dream of validation. The dream of fulfilment. The dream of showing up all those who doubted and the sweet embrace of the fulfilled hopes of supporters. This propels the founder.
But in this moment of propulsion, the founder is presented with a challenging task: curtailing the product to hit an early, but complete version of a product. The urge to go wide and excuse imperfections on the core workflow is real. It is palpable and it must be confronted. It is the impossible dream. It is the siren call of glory the founder must resist.
The right product to build is the smallest valid subset of the proper product. This subset must accomplish the following key standards:
- Smallest possible product
- Complete workflow
- True value
- Cooperative
- Extensible
Smallest possible product
This standard is linked to the design principle “Small as possible.” The goal here is to carve out of the set of valuable customer experiences a small, discrete subset of value. The proper subset of the proper set will be the subset with the most definable parameters.
Often a product is made up of a mixture of valuable customer experiences that flow effortlessly and ceaselessly between each other. This mixture becomes difficult to separate. And it is the founder’s job to investigate it and see what can be extracted and isolated.
Take launching a restaurant for example. Let’s say a founder is from a demographic that she expects will value authentic Oaxacan cuisine along with high end tequila’s and mezcals. She has a unique perspective on this value proposition and a unique access to source and deliver the experience. Building the entire experience and outfitting it properly (the proper product) would cost $2 million. However, there is still a question of whether her intuition on this problem is correct.
Hence, she needs to bring the smallest possible product to the market. Very rarely do restaurateurs (or funders of restaurants) accept a partly done concept. For instance, if she only had $250 thousand to demonstrate this need, most would agree that a 10% complete concept would not adequately test the hypothesis. Instead, she needs to create a subset that is discrete, and risk adjusted to prove out the hypothesis.
For instance, she could work with another restaurant to bring a temporary menu item with drink pairings to test out the reception. Or, if the budget was larger, she could offer a private chef experience for private parties. Or, if the budget was larger still, she could launch the concept in a causal variety with a food truck. All these routes are possible subsets.
In software, we see the 10% buildout happen all the time. It is unfortunate and creates chaos. The corpse of the failed concept hides profitable niches from discovery. This is partly due to the abstract nature of software. Unless you are the customer, it is very difficult to know whether the product is a subset or a portion of the set.
Complete workflow
The subset must be complete. The customers must be using it for the value it can deliver today. Selling expectations of future product deliveries is like putting multiple liens on a deprecating asset and then consuming the cash from the lien unproductively. It locks the company into delivering loosely defined emotion driven ‘feelings’ on a timeline. This is a liability, and it is undefined in size, scope, and term.
Completeness means the product must provide value. And, that value must be compelling enough to prove out the broader thesis. Customers must see the product as it is in its smaller form and see value.
True value
The value customers receive from the product must be true. This may seem derivative of the prior standards, but in fact it is distinct. Novelty can compel adoption which hides the nature of the true value. Novelty wears off, true value builds.
The subset must provide true value. Founders can discern true value if the product is driving achieving a business objective that results in dollars of ROI. The challenge here is pushing past the surface level and into actual value.
Cooperative
The subset must cooperate with the customer’s other processes and systems. This cooperation might include data interoperability, workflow interaction, UX similarities, and so on. Subsets that are not cooperative sow the seeds of their destruction before customers have a chance to get hooked.
Extensible
The subset must be built with the broader set, the proper product, in mind. The subset is the foundation and growing from it to the proper product needs to be a consistent story and a fluid process. Extensibility includes the workflow steps in addition to the technological stack.
Conclusion
The proper product cannot be built in one push. It takes interactions with customers to fit it into the culture and into a stream of value that an enterprise can build itself upon. These interactions take time which takes money. Founders must discern the appropriate subset of the proper product to build that will be a proper test of the hypothesis that they see so clearly.
This article is an extract from a case study we published recently published titled “A Founder’s Journey Through Building a B2B SaaS Company“, written by Dougal Cameron that shares some of our experiences building startups and journeying towards meaningful exits.
