Less noise, more data. Get the biggest data report on software developer careers in South Africa.

Dev Report mobile

Behind The Scenes of SnapScan's Product Team

5 May 2017 , by offerzen

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.

alt

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?”

alt

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.

alt

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.”

alt

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.”

alt

Recent posts

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.