We have all read about this happening, so lets go through an exercise of making it happen! In this story I work with my trusted business partner Liz. She is hyper organized and good at business. I am neither of those, but can make software; so we make a good pair.
Liz phoned me up the other day...
"I met someone that works as a cashier, and they have to carry around this cash register all the time. The shop they work in want to expand, but these registers are expensive. Thing is, all it does is add some numbers and print out a receipt. I thought, a software app could do that; and it would be easier for them to use their phone instead of the big register. Also, if it works and is cheap to buy, they would use that instead of the register."
Then I thought: don't all stores have this problem? If we make a 'mobile register', then we could disrupt this entire cash register space!
Understanding the problem is the start of solving it
Ok, so from that we have some things forming up about the product definition; but it's clear we need to know more about this opportunity before we start making anything. What's the value to the user, and the buyer? Is this a big market or small, and who would pay for this? If they would, how much would they pay?Using lean canvas or the venture process, we can go deeper on the understanding of the possible opportunity.
Our Hypothesis: People buy stuff, so the need to cash them out seems pretty real and constant. If the register is expensive and we can build a cheaper one; then small companies would buy them to save money. presumably any company would for the same reasons.
My response to Liz: "Ok, this seems feasible at a glance, but need to know more. Let's find some prospects and see if this could work."
Liz went back to her original retail friend Chris, and asked if he would like a cash register on his phone, instead of carrying the old clunky one around. 'Sounds great!' Chris said.
- This issue with this 'ask' is that Liz was immediately selling Chris on the solution, and that sounds good. What is Chris going to say? "no thanks, I love ol' clunky!".
Perhaps a better approach would be investigate why Chris would trade his old machine for the phone or why not. Asking why would get to the problem at hand, and a good way of finding that out is investigating what they do now to solve their cash-out problem.
What do they do now?
If the problem is key, and the solution is valuable, the prospect is doing that job in some way. What we are hoping is that their methods have pain that they want to get rid of, and see our solution as a way to get there.
So, what does Chris do now?
1. Carry around clunky, its heavy.
2. Clunky adds numbers, but I need to look up the currency conversion in the daily currency table and the tax rate of the buyer. Mary wants the totals in CDN dollars.Ok, who is Mary?
"Mary is the manager of the store. I need to send her the totals when I'm done with a shift so she knows the totals."It turns out Mary the Manager is a persona we need to care about; since it's Chris' job to report totals to Mary. Lets talk to Mary about her role and these 'Totals'.
Mary responds with:
'Ya, I need to settle up every day and send sales totals to my owner, and I also need the totals to get my inventory status'
This info is gold! Mary need 2 outputs from the register experience. The sales totals of the shift, and the amounts sold so she knows what inventory is left, so she can order more or not, and see what is selling.
Now we have 2 Personas; a User (Chris) and a Manager (Mary), and there was also mention of the Owner. We have to care about Mary since correct reporting from Chris its a measure of doing his job correctly. If we make Chris a success in Mary's eyes; he will use our tool. If Mary is able to provide great reporting to the Owner, then she is a success, and she will use our tool. So, in reality, we need to make the tool for the Owner of the store, and then Mary, and finally Chris. This may seem counter-intuitive since Chris is the one using the tool most often, but its the value that the tool is able to generate that pays for it, and the Owner is the persona that needs the convincing.
Personas and Problems
- Chris the Cashier - adding numbers, calculating/adding taxes, converting currency, reporting sales to Manager. time to cash-out customer
- Mary the Manager - calculating sales, reporting on sales and inventory used, reporting to Owner
- Sue the Owner - needs accurate reporting of inventory and sales to determine health of the store.
Ok, this seems to be making more sense; but one big question still needs to be answered. Who is going to buy the product?
Would Chris pay out of his pocket? Would Mary expense it for Chris? Does the Owner need to OK that purchase, or does the Owner make all the decision making on the purchase? At this point it could seem like a good idea to pitch the Owner to buy the product, and convince them that the managers and clerks in their stores need mobileCashier (we just decided to call it that).
This is probably too early to directly sell to the Owner; as the first contact from the Owner's point of view is getting sold on something they haven't heard of.
User Personas influence Buyer Personas
What would be more influential is to have Mary tell the owner that they are trying a new product that will save time and money. If you were the owner, what would you listen to? If Mary sees value in it, then she will pitch for it, and if Chris is making more sales because of the efficiency gains from the app, then he will tell Mary about it.
Persona Key Problems
So, this is only going to work if Mary proves to the Owner that mobileRegister saves time and money, and thus increases sales throughput. From this, we can ascertain that a Key Problem for the Manager Persona is reporting on sales and inventory. If we don't build that, Mary won't see the value. But wait, you are still making Chris carry around the old register? Sure, but the sales and inventory report is what is really needed in the end. We can address this key problem by making sure when Chris uses the app; the data generated ends up in the reports to Mary. It might even be enough for the MVP to forget about the manual currency and tax calculation and concentrate on the report for Manager Mary.Domain Problems
Regardless of the users involved, there are rules about the domain of cash registers that we need to satisfy, and these will become requirements of our solution.- Numbers arithmetic of adding, getting percentages and totals.
- Currency - this changes, so how do we get the latest exchange rates? How accurate does that have to be? Daily, Hourly?
- Taxes - this changes, but only annually. How do we get updates on the tax rules for any country that the user is in? How often will we sync our rates with the reference. What is that reference?
Checkpoint for Market-Product fit
We don't have anything resembling a product at the moment because we are still figuring out the key problems for the Domain and the Users in the Market. What we are trying to identify is what key problems that the user will need, and need so much that they, or the persona identified.Go for a v1?
How far does this research go before starting to build? This is a tough nugget. You need to know you have a Market that has users and money to pay for a possible solution. We could spend more time analyzing this, but it might be more effective to build a simple version so we can go back to our prospects with something that is showing that we can solve their problem. Otherwise we could tire them out with our research questions.You might find users that are totally passionate about what they do; but most people are there to get their job done.
This set of problems, personas and jobs to be done is a key deliverable for understanding the market and how our solution is effective at solving key problems. This understanding will evolve over time as we learn more, so it's never done, but there seems to be enough there for our current needs. We really believe there is a need. There is, but perhaps the point of sale space is a bit crowded (it is), but we think we are going to build a better mousetrap.
From this point, both Liz and I have our current mission.
I need to
- start on a possible architecture that will allow the user to do the cash register thing over the web on a phone
- do reporting, this sounds like a desktop spreadsheet thing
- find out about the data needed for currency and taxes, can I easily import this, and can it be automated
Liz need to understand the basics of the business
- Cost of getting a customer and more customers
- Understanding the jobs to be done, and how big is the possible market of people that do this?
- A basic forecast to understand what can be sold, for how much, and how many customers are needed to pay the two of us
Time to make something
We think we are onto something here, so we are going to build what we consider to be a MVP to test out this hypothesis and see the results. How do we do this? We have a good idea of what is required, but its still in a very informal format. We need to understand how the user is going to use our solution, and what problems from the domain need to be solved to show that the product has value.
Understanding these Problems will form our Strategy for building this solution, and the company that surrounds it. It's a key deliverable, for sure.
Lets go for it
We are going to take the next step. We do this by formalizing the behavior of the User in Stories, and conversely, understanding the Requirements of the solution to make it all happen.- User experience is a combination of user stories. we validate the story with Acceptance Criteria.
- Domain Rules need to be formalized so they can be implemented.
No comments:
Post a Comment