What is your target demographic?

Not sure how many of you out there have put together a business plan and tried pitching to VCs. One of the key questions (other than who the team are), is “who is your target demographic?”. This is such an easy question to use to weed out who are serious and who are fake. The “fresh out of college with an idea” answer is, “everyone”. If you think your target demographic is everyone, you have failed, it is impossible to build to satisfy everyone, the time and resources you would be spending on design & advertising alone will bankrupt you, irrespective of the fact that the answer is just absurd.

Now, if you say, 18–24 year old’s who like online gaming, then we have something we can work with. Why is this so important? Because understanding who you are building for, allows you to test what you are building against them. If you want to know if they would like the feature, its as simple as going onto /r/gaming and throwing up a questionnaire.

Understanding who you are building for, makes you better understand what you are building and allows you faster feedback loops.

Now, you will notice in the title, I wrote “What is your target demographic?”, not “Who”. The reason for this is simple, yearn, and by extension all our newly acquired sister companies, are building for smart contracts, not humans.

Now to understand this nuance, you need to understand a bit about how smart contracts react (or rather don’t react). Lets say smart contract A reads data from smart contract B. If data in B updates, A is completely oblivious of this fact, you need to instruct contract A that a change in B occurred, for A to react. Now, this is by design, as it provides us strongly immutable guarantees. But this distinction is important none the less.

As a practical example, in Cream v1 there was a function repayOnBehalf this function allows third parties to repay the target parties debt, on their behalf. But what if I have a smart contract that believes it has 100 ETH debt, and now some external entity repaid its 100 ETH debt, without knowing this, or being made aware of this, the contract would continue functioning under the assumption that it had 100 ETH debt. So when building for smart contracts, we removed the call.

Another practical example is Cover v1, tokens have expiry. So at some point, v1 cover expires, and a new expiry set is launched. This is fine for human interaction, but problematic for contracts, they aren’t aware of the expiry, they aren’t aware of the new contracts, so how can they interact with this? Instead, with the v2 design we included perpetual positions based on a lending market model instead of an AMM model.

Within the new collaboration/conglomerate/whatever you want to call it, we are building for each other, not as users, but as protocols and smart contracts. Yearn needs simple, manageable, low gas overhead coverage, Cover is building pay as you go money market based perpetual cover. Yearn & Sushi need leveraged positions, Cream is allowing borrowing on a protocol to protocol level without external interference. Cream needs risk isolation from distinct pairs, which it can gain from supplying protocol level borrowing to bento box. All of these protocols need token agnostic cover, which is made available via Cover protocol agnostic staking. There are many more examples, but these should illustrate the value of understand what you are building and what will use it.

Knowing who (or in this case what) you build for, drastically changes your scope, vision, and future direction. So its is important to always be mindful, and ask yourself, what are you building for?

We know we are building for smart contracts and protocols.