The challenge
Background
iZettle acquired a start-up iOs point of sale (POS) company, focussing on the food and drink industry (cafes, restaurants and bars). The teams were in the process of creating a new refactored version that could scale across markets. The POS product was accompanied by a light-weight reporting application on both iOS and Android. The team's original decision was to kill the reporting application and focus only on the iOS POS. I helped the product team get the iOS reporting application back on the roadmap after highlighting customer usage data. I found that 1 in 3 customers used the application at least 4 times per week. The team felt the risk of churning existing customers who migrated over to the new POS was too high if we killed the reports application. We believed it would likely support acquisition of the new food and drink POS.
Business goals
We aimed to get 20% of new customers active weekly on the iOS reporting application. We hoped to reduce support tickets by at least 50%. The main support theme showed customers sales data often didn’t show.
Customer needs
After some initial research, we prioritised two core customer needs for hospitality business owners and managers. These were;
I need to quickly get an overview of my sales so I can check my business is on target when I’m away from the cafe. For example, If I’m below my sales target, I might have to send staff home as their wage would eat into the profit
I need to see the sales of my top-performing products. If we’re selling lots, I might need to re-stock or get the team to prepare more food. For example, it takes time to make more sandwiches. I’m not near a laptop and need to quickly check sales away from the Point of sale
Results
✅ Researched, tested and launched the new iOs reports application within 3 months
✅ 34%+ of new customers used the new iOs reports app frequently
✅ +25% more engagement. On average the app went to being used 6 times per week from 4 times per week.
✅ I saved the team weeks of time finding and recruiting customers for testing
Churning customers was our biggest worry and we believe we prevented that.
Key learnings
Check customer usage data early - Check feature or product usage data early to get an idea of how important we feel a feature/product is. It was eye-opening to see how many customers were frequently using the applications we were about to kill
Recruit customers quicker - Introducing a screener in the back office of the product saved us weeks of time. This should be part of the process when possible for future research
More effective planning - Spend more time structuring project kick-offs so most risks, assumptions and measures of success are noted. Because we were moving quickly, we rushed a little at the start. For example, we could have listed what tasks were needed in the discovery and testing stage. We would have spotted earlier that support with customer recruiting would have saved us time.
Project breakdown
Organising and facilitating a kick-off with the team
I organised and facilitated a kick-off session with tech, product, support and design (me) to ensure we had clarity on problems before diving in to solutions. We aligned on the business goal, noted assumptions, risks, known problems, the next most important thing to learn and what success looks like. I found using a ‘pre-mortem’ helped surface critical risks which would derail the project if not addressed. For example, we needed to run a Beta test with our core customer segments (cafes, restaurants and bars) to test the stability of the new codebase before officially launching the reports application on the App store. Stability and app failures had been a large majority of the existing support drivers on the existing app. Below are examples of the risks and success criteria we noted.
Examples of risks
The app might crash with large volumes of transactions
There’s not much engineering time to solve big problems so try and keep functionality basic
We could churn larger customers who have multiple sites. Multi-site login would need a big technical spike and we don’t have the time to investigate such a big unknown
It takes weeks to find and speak with customers. This is critical for Beta testing
What success looks like
App store reviews go from a 2.2 to 4+ within 6 months of launch
We reduce iOs reports app support tickets by at least 70%
Users who download the app use it at least 3 times in a week
80% of Beta test customers tell us it’s between at least a 4 out of 5 (5 being Excellent) in a feedback survey
Key decisions - Next, we wanted to make sure we would only focus on must have functionality as opposed to nice to have functionality. We were very limited with developer time and needed to avoid scope creep. I organised a Moscow Matrix workshop where we decided on must-have functionality.
Creating solutions good enough to test and learn from
After we decided on the basic functionality and journeys, the developer and myself set-about designing solutions that were feasible in the time frame. We purposely focussed on keeping functionality functional and simple. We didn’t need all the bells and whistles for the first Beta test. We knew we might have to change things after Beta testing based on what we’d learn. We’d add the polish after the Beta test.
Key decisions - Whilst the developer was building out the app, I started to build out the process to find and convert customers ready for Beta testing. Our goal was to get an MVP ready for the iOs test flight software. This allowed us to test with customers in a closed Beta as opposed to advertising the application in the app store.
Finding and converting customers for Beta testing
Previously, it had been tricky to find customers to test with. We usually resorted to asking sales and support for lists. This could take weeks. We were challenged with not knowing which customers had the existing iOS reporting application. We only knew there was high usage. I put together a Google form screener in the Point of sale back office to see if we could find the right customer segments and make sure they were already using the iOs reporting application. I aimed to create an inbound flow of customers who were willing to collaborate with us.
We managed to convert 12 customers for Beta testing in a few days. We had 3x cafes, 3x bars and 3x restaurants. We had over 100+ total respondents to the screener. I created a Google feedback form linked within the Beta app so we could learn about customers' experience. This helped inform one of our measures of success for building confidence in the test.
Key decisions - During Beta testing we found a major bug which prevented some sales data showing. Myself and the tech lead collaborated with the customer who discovered this to solve the issue. As most customers stated they were happy or very happy with the basic version, we were confident we could refine the design and roll this out to the app store.
Ensuring the application aligned with the design system
The company was in the process of developing the existing design system and had a design system team focussing on this. We wanted to make sure we aligned with the new design direction where possible. I organised design critiques with the wider design team to help guide the direction.
Key decisions - We compromised on a few interactions to ensure we got the new product ready to join the go-to-market strategy of the Point of sale. The date picker was more manual than we hoped. The main thing was it functioned and people could change dates without feeling lost. There was a large technical unknown in pushing the date picker further. We didn’t have the time to investigate before the first release and were happy to revisit these at a later date.