Squirrelled product

Good morning Squirrelled team. Great to see you again. So we have been reviewing our notes doing a little bit of early stage research because we just can't help ourselves um and discussing internally to figure out what would be the best discovery structure for you. Now, what I'm gonna run through is based on your current goals and where you are in your start up journey. But it's important to note that we run flexible discoveries and what this means is that as we gather more data, we may adjust it to ensure that we answer as many of your questions as possible. Um And we validate as many assumptions as possible as we go. So to start, we'll recap quickly on the goals that you mentioned in the last workshop, which can be broken down into three main points, I think. So the first one is understanding what people want. The second is what order people want it in. And the third is about getting the data to prove it. So we use the same structure to outline our discovery plan just to make sure it is as relevant as possible to you guys.

Pippa: So starting from the top with understanding what people want. When starting a start up, we naturally make a whole bunch of assumptions as to what customers want, how the product should work and look and how it will be successful. Now, before starting to build absolutely anything before we write even a single line of code, we want to ensure that everything we're building is based on data about what our customers actually want, not our gut. While some of our assumptions might be correct and they are are quite likely to be correct, if an important one is wrong, such as the type of customer who would want our solution, what we think would solve their problem the best, or if the solution is big or painful enough to even require a solution. If we get any of those wrong, we risk our product failing. We therefore want to test our riskiest assumptions as early as possible. And we do this through something called an assumption map. And this basically entails as dumping brain dumping any and every assumption we're making about the product onto a board before ranking them against number one, How much evidence we have for them. And number two, how important is it that we get this assumption correct. So this will be the first thing we work on in the discovery and the outputs of this will essentially inform the rest of the structure for the time that we have. As depending on the assumptions that we're looking to test, we'll create experiments, mini research pieces and tech spikes, which is basically our fancy word for investigations on kind of the coded side to try and prove or disprove them. Now, these experiments can be anything from us of interviews, competitor analysis, blue ocean analysis, um trialing ad campaigns, creating test landing pages, low and high fidelity designs, proof of concepts of like specifically or particularly tricky parts, um integration proof of concepts A B testing messaging anything really. The most important thing is that we test our assumptions.

Pippa: Now, I recognize it might sound a little vague, not giving you a line by line breakdown of what the discovery will look like. But we do this specifically so that we can pivot as our learning develops. If we understand that actually, this isn't the right customer base. We want to know that as early as possible so that we can spend the rest of the discovery, finding the correct customer base or pivoting the product so that it fits the needs of that user better to give you an idea of what it could look like. Let's run through a couple of the assumptions that we pulled out of the workshop um and how we might look to validate one or two. So a couple of the assumptions that we pulled out were we believe that users will find value in different ways to make the app useful and an integral part of their life such as shopping list and school P A. We believe that users would first want the rewards mechanism, the cash back based on the value to the user. We believe in Gamification and referrals and that they'll be important. We believe that we can handle complicated family structures for the distribution of rewards, et cetera. So these are all the assumptions that we would pull to light during the assumption mapping and then plot on that assumption map. So to give you an idea how we'd go through, through the disco, let's take one of these assumptions and assume that it is one that we end up testing. So let's let's go with the first one, which is we believe that users will be willing and able to use open banking to earn their awards. So to explore this, we would first start by understanding the three assumed user personas. So the parents, the extended family probably focusing on grand and godparents and the students themselves. Now, when building an MVP, it's much better to completely solve one problem for a small audience than to try and solve everything and end up not completely solving the problem for anyone. We would therefore start by kind of narrowing down all of our user personas and ensuring there aren't others that we've been missing such as access officers at schools, for example, so that we land on those who feel the problem most acutely. And to do this, we conduct user interviews and probably a survey in which we'd explore the biggest pains of each user when it comes to saving for education. This will allow us to get both quantitative and qualitative data which we'll come to a bit later. The second stage would most likely be exploring how comfortable they would be with using open banking as a solution, which could also be done by interviews in the survey. It could also be done by research groups exploring online communities, et cetera. And we will pick and choose which is best depending on the data we already have. Sometimes we can tackle two or three hypotheses with one research piece. So for you guys, we'd probably also ask about their views on acceptable time frames for receiving their rewards as well as the products they already use so that we can run some competitor analysis after. And then after we've done that after we've tested the assumptions and created a user flow, which I'll also come to in a second, we'll prototype out the core user journey to test it with the users and to get feedback.

Pippa: Your second goal is to understand what order people want it in. So by this point, we should have a really good understanding of what each user wants and where we will focus for the MVP to use in the pilot phase, we'll start by focusing on the core user persona and this is probably going to be the parents, but we are gonna test this and we'll start by building the smallest possible thing we could to satisfy their most pressing need. This allows us to test our solution and pivot if necessary and if they love it and we can demonstrate traction and product market fit, then we will continue to build on this. So to do this, we'll create a step by step user journey map for your core user persona and obviously yourselves who will be part of the flow. And then we'll then do a Moscow analysis and this means that, it's pretty simple, it's must have, should have, could have would like to have. But what it does, is really challenges you to think about what is the most important things that we'll put into this app for MVP. And then this allows us to create a prioritised plan.

Pippa: And then the third goal, which is getting data to prove it. So if we've done the first two parts of the discovery, well, this should be the easy part here. We want to bring together all of the data we gathered and weave that into a narrative that would bring colour and credibility to an investor pitch. The easiest way to do this is to use the quantitative and qualitative customer data that we've already gathered to prove that you have a deep understanding of a problem that actually exists. And what I mean is that you're solving a problem and that a sufficient number of people experience and that they experience it deeply enough that they'd be willing to download and engage with an app for a solution and potentially pay. So depending on what we've done in the discovery, this could be percentage of users that would be happy to use open banking, average number of transactions a month, average number of additional family members they want to invite. Some basic stats on, on the usability and the viability of the product. Um And then during the discovery phase, we'd also consider the analytics that we'd look to collect during the MVP and pilot phase. So if we assume that we build open banking and card linking, we'd look to collect data such as number of sign ups, number of purchases, average cash back per purchase. Number of sign ups with no open banking linking. Which parts of the app or platform people are clicking on the most, the drop off rates at different stages of the user journey, the cost of acquisition, huge number of things or it could be feature specific stats such as the number of pots per person, the average team size, the average size of the shopping list, um the average pot goal size and the average time to reach a goal. We'd also during this time look to set up tracking for metrics that will help you to raise investment with investors later on. So these would be things such as daily, weekly and active, daily, weekly and monthly, active users revenue and your MP S score and that's it. Thank you very much.