On 13 October I wrote our Business Model Canvas, worked out TAM, SAM and SOM, and wrote our UVP, USP and problem statement for the IVP pitch. Writing these forced me to answer questions I had only half-answered. Here is what each one is, and how I approached it as a first-time founder who had never done this before.
Business Model Canvas
The BMC is a one-page map of how your venture makes money. Nine boxes: who you serve, what you give them, how you reach them, how you keep them, what it costs you, what you earn, and what you need to run. The point is that all nine boxes have to fit together. If one box contradicts another, your model does not work, and the contradiction is on the page where you can see it.
I had thought about most of these boxes loosely. I knew who our customers were, roughly. I knew what we would give them, roughly. I knew what it would cost to acquire them and what we would charge. But loosely is not the same as decided, and loosely is not the same as defensible. The BMC forced me to write them down in a specific order and connect them. I started with the customer segments and the value propositions, because if those two do not line up, nothing else matters. Then I worked outward.
The box that gave me the most trouble was the revenue streams. I had an idea of what we would charge, but I had not thought through the different ways a customer might pay, or the different customer types that might pay differently. Once I sat down with that box, I found three revenue models I had not considered. I did not end up using all of them. But I would not have found the one I did use without writing the others down.
TAM, SAM, SOM
TAM is the total market. If everyone in the world who could ever need what you build bought it, that is your TAM. SAM is the segment you can actually serve. The part of TAM that is reachable given your geography, your capability, and your constraints. SOM is the part you can win in the short term. The realistic, first-years number.
I found TAM easy to estimate and SAM hard. TAM is just a number you can argue with. You can find reports and analyst estimates and government statistics, and you can build a number from those. SAM requires you to be honest about what you can actually reach, and I was not used to being that honest. It asks you to subtract everything you cannot serve, and the things you cannot serve are the things you wish you could serve. That is uncomfortable.
SOM is harder still, because it asks you to predict what you will actually capture, and nobody knows that. I found myself building SOM from the bottom up, starting with how many customers I could realistically reach in the first year, and that felt more useful than starting from the top and dividing down. The bottom-up approach at least grounds the number in something I can defend.
UVP and USP
UVP is your unique value proposition. USP is your unique selling proposition. They are similar and they are not the same thing. The UVP is what makes you different in the customer’s mind. The USP is what makes you the obvious choice over the competitor standing next to you.
I wrote a UVP that was really a list of features. Faster, cheaper, more integrated, better reporting. I read it and it sounded like every other startup pitch I had ever heard. I had to rewrite it. The UVP is not what you do. It is what the customer gets that they cannot get elsewhere. That took me a few drafts, and the first few were still wrong. The one that finally worked was a single sentence about what the customer’s day looks like before and after using the product. That was useful, and it was also true, which is the part that matters.
Problem Statement
The problem statement is the shortest and the hardest piece of the pack. One or two sentences. What problem are you solving, for whom, and why is it a problem right now? Everything else in the pitch pack flows from this.
I wrote one that was too long. I had identified a real pain point, but I had also included three related pain points that were adjacent to it but not the same thing. I had to cut them. That was difficult, because each one was true. But the problem statement is not a list of true things. It is the one thing that, if you solve it, the others become less urgent. I kept the one that was most urgent and most specific, and I cut the rest.
If the problem is not urgent, nobody will care about your solution, no matter how elegant it is. If it is not specific, nobody will believe you understand it.