Market (as a reminder) & size (who and how big)
TAM – College affiliates in the US
SAM – 57% of US universities are willing to spend on Slack [Source]
SOM – Stanford affiliates which is about ~22K people [Source]
Pricing – Subscription model like Slack
- $5 price per head billed annually
- $100K annually if we sign on Stanford
The interviews revealed that the process for scheduling private events is smooth and rather enjoyable. Scheduling a meeting with people within the same company also seemed straightforward as the same Calendar software is used and employees have access to the meeting attendees calendars. This way free time blocks can be identified across multiple people within the organization.
But the most painful scheduling experiences by far were related to semi-professional, academic settings where lengthy back-and-forths via email or scheduling tools such as when2meet add to the frustrations encountered during the scheduling process.
To estimate the pricing model for our product, we looked at how Slack charges organizations for its product suite. Slack operates with a subscription model and charges per head at an annual rate of $100. Since our product is less powerful but still provides value to the user, we estimate that an annual rate of $5 per head is realistic. Multiplying this price with the number of users we can capture gives us the TAM/SAM/SOM estimates below.
We defined our Total Addressable Market (TAM) as all college affiliates in the US, calculated by finding the sum of all college students and all employees in the US. Based on our pricing model, this market would yield $110 million per year in revenue.
We calculated our Serviceable Addressable Market (SAM) by looking at the adoption rate of an analogous product in our TAM. A rough analog for our concept is the productivity and communication tool Slack. We found that about 57% of US colleges have adopted Slack and assume that our solution would see a similar trend. Based on our pricing model, this market would yield $62.7 million per year in revenue.
Finally, we defined our Serviceable Obtainable Market (SOM) as the population of Stanford’s campus. With a population of approximately 22,000, our pricing model projects a market that would yield $100,000 per year in revenue.
Tech stack and why
For our tech stack, we have opted for the MERN framework. This is because it is widely used in industry which makes it a good choice for tech support and should make it easier to hire people who can help us scale the platform. We also have coding experience on our team with this framework which will reduce our prototyping time. This should help us move faster and get to a better result by the end of the quarter.
We were also thinking about using Flutter as our tech stack. Although none of us have worked with Flutter before, we have all expressed interest in trying out the stack due to its seamless cross-platform integration. We currently believe that our product will be used mostly as a mobile website and need to prioritize this in our design. If we ended up becoming an app as well, Flutter would give us an edge instead of needing to re-implement lots of code from scratch.
BMC first pass (from in-class activity in 3A and your iterations)
This is our first pass at our BMC. I think we have a good idea of who are users and customers would be. They are not the same. Our users would be university affiliates but those who would pay the subscription fee would be university IT departments. We filled in several of the cells thinking about both groups since we need to show value and cater to both. We have also honed down on a specific group of university affiliates who are equal in standing and in search of recurring meeting times. This will likely be students rather than professors or university admins. We will update the model accordingly and fill out the remaining cells now that we have a clearer idea of the concept we would like to test and implement.
Early ethical challenges to consider
The main ethical challenge we see revolves around privacy. In its current form, we expect our users to share their calendars with our platform so that we can search for free times where meetings might fit in. Our first assumption which we will need to test is that users are okay integrating their calendars with our application. If that is not the case then we will need to think about a different user flow. In our interviews, we have also received several comments about calendar visibility. We need to suggest meeting times without revealing a user’s entire calendar to other parties. This is another assumption we need to test.
