SnapScan doesn’t really need an introduction. Users marry their credit cards with the app and can then shop anywhere with a SnapScan QR-code. But who are the people behind this payment magic? OfferZen talked to the Head of Product, Estiaan Le Roux, who decides where the product goes and how the team will get there.
Early Days
In the early days, the SnapScan crew consisted of five keen heads: the two founders and a team of three developers.
Estiaan was a studied electrical and electronic engineer and had an MA in Augmented Reality -this is where his keen interest in user interfaces and usability stems from. He and two other devs created the successful Mxit-game “BattleTrivia” after university. âEssentially, we were one of the few success stories on Mxit at that stage, we had over 100 000 users on our little gameâ, Estiaan recalls. Thatâs what drew Kobus and Gerritâs attention in the first place because they wanted to bring finance onto mobile platforms and figure out how to do this on Mxit.
Despite this initial idea quickly passing, the newly formed crew stuck together and luckily so because the next project happened to be SnapScan and the rest is history.
The Legwork
Although a success, as you know, often takes its time. In this particular case, it took a lot of legwork to make history happen: The teamâs first attempts were at the farmers’ markets in Stellenbosch where the team basically spent their Saturdays trying to convince people to use SnapScan.
âI honestly didnât think it was a good idea! I didnât think that we could get South Africans to pay with this leading edge technology. I thought: âTheyâre already sceptical, they donât even want to load their cards onto the internet, they donât want to do online payments.â Luckily, they proved me wrong.â
âI honestly didnât think it was a good idea! I didnât think that we could get South Africans to pay with this leading edge technology. I thought: âTheyâre already sceptical, they donât even want to load their cards onto the internet, they donât want to do online payments.â Luckily, they proved me wrong.â
A number of people were keen to use the technology so the first barrier was taken down. Now the team had to identify a place where they could find similar potential early adopters: âWe had all these beautiful nice little artisanal coffee shops popping up and young 20-somethings sitting there with their iPhones the whole day.â Realising that this was the perfect target group for their early product, the devs then moved from the farmers’ markets to the coffee shops and personally signed up people who then got the word out organically: âThey ran around and told everyone they need to get SnapScan because why donât they have SnapScan yet?â
This, of course, took its toll in other areas. âI spent at least 60, 70% of my time running around in coffee shops, speaking to merchants and not a lot of time developingâ, Estiaan recalls. But the field work was a necessary âevilâ, as the product was in its infant shoes. âIf you want to understand a product, you canât be sitting around getting second-hand knowledge from your sales team, especially at the start. I think it becomes easier when the company grows but you need to get out and really understand the market youâre targeting and in our case, also the merchantsâ, he says.
âIf you want to understand a product, you canât be sitting around getting second-hand knowledge from your sales team, especially at the start.“
For quite a while, the team stayed the same size until the snowball-effect of their word of mouth marketing got traction. First, it was mainly the sales and business teams that had to grow fast. The development team consisted only of Estiaan and three others who were doing the back-end coding while he was working on the application, UX and front-end.
Wearing off the Startup Koolaid
âWe really liked the idea of having this guerilla-eske, very lean development team where everyone has authority and can move quicklyâ, Estiaan says. But after SnapScan boomed at the end of 2014, things slowly started breaking. Half a year after the official launch of the app in May, the development team finally needed to add on.
âWhen you start out and you’re small, you tend to drink the startup-koolaid. You think youâre in this cool, hip startup and itâs all about the rushâ, Estiaan explains the mindset of the early days. Thatâs why initially the developer-team hired like-minded people in the same age-group.
Then however, they quickly learned that growing the team past five people wasnât really working. âThereâs this strange, difficult phase between 18 and 30 people when you think youâre still a startup but itâs quite difficult to do things in the normal startup wayâ, Estiaan says.
âThereâs this strange, difficult phase between 18 and 30 people when you think youâre still a startup but itâs quite difficult to do things in the normal startup way.â
Thatâs when the flat hierarchy had to give way to a new system - in itself a learning process. âThereâs definitely a bit of denial around it when people love the startup culture as much as we doâ, Estiaan laughs. âIn our instance we basically had to get our core members to realise that their role now is not just to develop but also to help everyone in the company to be better, help the product to become better and help the new guys coming in to get up to speed.â These subtle shifts were important, because by then SnapScan had a business team, a sales team, an operations team and a dev-team that all needed to be work together.
Splitting Forces
On the developer side, Estiaanâs team realised that, in order to function effectively, it had to split: âWe strongly believe that we donât want to run a dev-shop here, we still feel that small teams move faster and you donât get that much return on investment by growing these massive development teamsâ, he explains.
Thatâs why SnapScan now has one team that worries about the security in the core payment structure and another team that is product focused. âThe idea is that the product team moves really quickly and never needs to feel that anxiety of working with the payment code. Theyâre allowed to hack things and do proofs of concepts and basically move fast and leanâ, Estiaan says.
The Core Team
Estiaanâs aim is to get the core team to be self-sustaining and make autonomous decisions. They focus solely on keeping the systems trustworthy and the payment side of things up to scratch. âWe also let them handle proof of concept products completely and also the back-office systems we need, including interfacingâ, Estiaan explains. So the back-end team can come to the business and operations side and talk about what features the back office people need.
âIf we feel that this isnât working, we sometimes swap out members. We mostly find that someone getting frustrated is just a case of getting tired of working in a specific environment and then they get to switch sides for a project or two.â
However, thanks to being a startup, nothing is entirely set in stone. The team has come up with the system of a âmental refreshâ: âIf we feel that this isnât working, we sometimes swap out members. We mostly find that someone getting frustrated is just a case of getting tired of working in that environment and then they get to switch sides for a project or two.â That seems to work.
The Product Mindset
One of things the product team needs to reiterate again and again is that they are a product team, and not a development team. Estiaan has a good reason for that: âIf we speak of ourselves as a development team, the team focuses on the code; on rebuilding for the sake of it, just because itâs two years old and the code isnât nice -itâs still working, thereâs nothing wrong- but now we go and redo the code.â This mindset takes away too much time from building the product.
To reinforce these team-identities, the core team and the product team are not just split mentally but also physically - which, incidentally also helps the bigger teamâs integration. âNow if the product guys want to randomly take a break and talk to people, they go to the business team or the operations people instead of having just developers talk to each other the whole time. That makes a massive difference.â
Building Product
The actual building of SnapScan’s product is based on a process of fortnightly sprints, and includes stakeholders from all units: product, operations and business. Everybody meets in the product planning room and makes a case for whatâs most important for them at the time. These points are compared to the road map so that the different teams can make a decision together. âWe isolate these tasks for the following two weeks. At the end of the sprint, we start again with a whiteboard and ask the same questions.â
At any given time, they have three proofs of concepts (POCs) running in the background with small targeted groups of real users testing it out.
These cycles between product development and customer development are intentionally held short. âSo we will build a quick POC and pass it over to new business and work with them while theyâre doing customer development on the product weâve developedâ, Estiaan explains. âAs soon as they get feedback, it loops back in and we take another sprinter and we build it out further.â
This makes for a very quick turn-around time. POCs can go live and return with feedback within two weeks. In addition, any given task within this cycle is only allowed to take up one day. If it takes longer, the problem will be re-assessed or supported with extra manpower because, in Estiaanâs words, âWeâre doing something wrongâ.
The Challenges of Fin-tech
Innovating in the fin-tech space is notoriously hard. One particularly challenging event Estiaan remembers well is the implementation of 3-D Secure. The team initially tried to build an internal solution, but once they started testing it, they realised that it had an even higher failure rate than the normal 3-D Secure system and they couldnât isolate the reason.
The developer team then rather went about optimising the normal 3-D Secure system. âSo we had boards full of little sticky notes that we started moving around and trying to figure out all the failures and then working with the banks to try and get it fixed on their sideâ, Estiaan says.
"Essentially, no matter how far down the payment pipeline your payment is failing, youâre using SnapScan. So youâre always going to think SnapScan is failing. That makes every issue a SnapSnan issue.”
âIt was really important for us to figure it out fast. Essentially, no matter how far down the payment pipeline your payment is failing, youâre using SnapScan. So youâre always going to think SnapScan is failing.â To retain their customers’ trust, the team monitored all transaction failures and immediately called customers, helping them through the process and going directly to their bank to fix the problem.
Future Plans
With 39 000 merchants, 777 000 total device downloads and a partnership with Standard Bank, SnapScan has captured a solid base market and is now looking to move in with the larger retailers as well. âItâs all new learning for usâ, Estiaan says. âWhenever you work with big companies, they work on different time scales so we need to figure out how to do that quickly and how to not spend all our time on these massive integrations.â
