Estiaan le Roux has been part of SnapScan since its inception, and is currently the Head of Product. On Friday, 2 June, the ZATech Slack community hosted an AMA with Estiaan where he answered questions about startups, mobile payments and compliance, and some of their future plans for SnapScan.
Before SnapScan, Estiaan studied Electronic Engineering, dabbled in augmented-reality and co-founded a mobile games studio. He has a keen interest in UX, web technologies and the disruption of stagnant industries.
You can follow him on Twitter @estiaan.
Here are some of the highlights of the AMA.
SnapScan had a chicken-and-egg problem - merchants not interested unless a lot of consumers use the app, and consumers won’t adopt if no merchants accept it. How did you go about solving this?
We had that problem indeed, and we continue to have it for most new features we look at. What worked for us is to make small, iterative jumps of focus as we work between merchants and users. For example: Start with a merchant → hack the user number up as quickly as possible identifying the levers → see if we can duplicate. With trial and (lots of) error we’ve gotten pretty good at making the jumps at the right time.
How big is your product team and what tools and processes do you use?
The specific size of the team is a little fluid due to to the way we are set up with our parent company (Standard Bank), but at any given time it’s around 7 developers. We use AngularJS, PhoneGap, Ruby on Rails, Postgres in the cloud, and we host with Amazon. We follow Agile principles, or at least a version of it that works for us. (It might make purists frown, though.) The entire company works with unified 2-weekly sprints so that we are all working on the same goals at any given time. We always push for the leanest possible PoC and take it from there.
As you grew your team, what was the most surprising problem you faced and how did you address it?
I found growing teams to be really, really hard. I still think it’s one of the biggest challenges a company of our size faces. Everything that made it hard was surprising to me initially, mostly because I was so incredibly naive about it. Some of the biggest challenges:
- Culture: for a long time we were a company that wasn’t settled and comfy, but also not a startup;
- Accurately identifying what positions to fill most urgently;
- Changing the team structure to be able to accommodate all the new people.
Can you comment on native mobile codebase vs one (HTML/JS?) codebase for all devices. What did SnapScan go for and why?
We’re on one codebase. I think the “best” tech option for a new product is always dependent on your team and capabilities. We were a really small team so maintaining one base was the only viable option. Also, since we are doing payments you really don’t want to have to make changes to pay flows and tests twice.
Do you see Zapper as a rival, or do you see SnapScan as targeting different a market? How does (what seems to be) a direct competitor affect team morale, and have you found effective ways to combat that?
I’d say they’re direct competitors, and they’re doing really well and growing fast. We’re also still growing fast. Merchants are mostly happy to support both of us. We’ve found (figured this out the hard way) that the best way to optimise our own growth is to focus on ourselves and not the competition. We’ve found that when you truly focus on your own growth and success, your competitor’s success doesn’t impact morale. Easy to say this now, took us a while to get here :-)
What is up with pos.snapscan.io and what is the history behind pos? Is it a joke? Why have you never migrated away from it?
:-D I’m not completely sure to be honest! I can only tell you that the name had to do with the metaphor that our server is replacing the point of sale machine. As for migrating away: we’re in the process now. It has just never been high priority since it is only ever used in QR codes and most users don’t even notice it.
How has the way you manage the product changed since the Standard Bank acquisition?
Not too much. The acquisition was a (really) long process and we’ve been working with Standard Bank (SBSA) for a very long time. We’re a SBSA product and align with their vision, and are compliant according to SBSA standards, but they give as room to run the product as we see fit.
Are there any mobile-payment specific compliance regulations (other than PCI) in South Africa that SnapScan has to adhere to?
We comply to all the general, expected standards like PCI but the powers that be are still finalising the approach to mobile vs online vs mobile-at-brick-and-mortar payments. So there is no “extra” compliance specifically governing mobile yet. But we should see our use case being addressed in the normal PCI compliance process very soon, I know they are working on some drafts.
Do you have an internal security team for penetration testing and security auditing? Are they responsible for penetration testing or only for ensuring good and secure coding practices?
Some background first: We are quite strict about good (read: secure) coding practices across all our dev teams. Compliance means we also have stringent processes for any code changes that have to do with payments. Our security and compliance team is a separate team consisting of members of the dev, operations, and finance teams. This team ensures that pen tests and auditing happen on a regular basis, but we get external parties in to do pen testing.
Can you give examples of best customer experiences and worst customer experiences for users of SnapScan?
This question is harder to answer. No single instance comes to mind for either, but it’s always really crappy when we try to help someone complete an e-commerce payment but can’t due to either their card not supporting payments or the card not being enabled. It’s not a big cool story but it hurts me a little every time it happens. On the flipside, I always think it’s cool when someone tries to do some random payment that fails (think big amounts to consultants or service providers) and immediately gets a call from our ops team to help them through it.
With 770k downloads you obviously have many types of users. How does the product team stay in touch with what users want?
We have an awesome operations team that constantly and proactively chat to both merchants and users on a daily basis. At this stage delivering all the things our users want is harder than figuring out what they want.
What wrong assumptions did you have about early users? How did this influence the product?
People older than 40 made up a significant portion of our early user base. We assumed they wouldn’t touch the app because, at the time, older South Africans generally didn’t even do online shopping. That meant we could look at interesting cases targeting that group for growing the user base - medical bills, for example.
Can you share some of SnapScan’s future plans? How do you think about online payments and person-to-person payments?
We’re always testing new ideas in the background but will only roll it out once it’s properly validated. You should see quite a few new features over the next month or two. I don’t want to spoil things too much, but bill and utility payments are pretty exciting to us and you might see some of the things you mentioned pop up soon ;-)
Do you plan to move into foreign countries? Zapper, for example, works in some places in the UK?
Possibly, but not in the near future. We don’t have a playbook to successfully launch this product in an arbitrary country. Growth seems to be very culture dependent. We’ll need a core team on the ground and that is a very big step for us.
Do you intend to ever support location based payments? For example, I’d like to be able to pay when I’m in a store without having to go to the front to get the code.
Indeed - you should see devices for this at some shops. The device maintenance is a problem, though. Merchants don’t really care if the batteries go flat because it doesn’t seem to impact sales at all (as long as they have a code in store).
I’ve found myself wanting the ability to click on a past payment, and pay the same merchant again, without having to scan. In general, the ability to pull up an “invoice” of a past purchase would be super useful for billing purposes. Is any of this going to be an option anytime soon?
We’re looking to build solutions to both your problems in the very near future - probably as soon as we get the new app skin live: a) A repay option given by tapping the receipt of a previous payment; b) Some way of delivering a proof of purchase. We’re still finalising the details on it, though.
A growing number of smartphones have tap-to-pay capabilities. Is there some concern that “snapping” a QR code will no longer be a relevant means?
Cool question :-) SnapScan has always been associated with scanning a QR code, but honestly that step is quite arbitrary. It was just at the time the only viable method of growing the product at the pace and scale we needed to. We’re happy to move with whatever method the market prefers to initiate the payment. To more directly answer your question, we’re definitely looking at, and working on, tap to pay. Looking at Europe, it does seem to be the technology that is most likely to gain mainstream support here. We’d have to differentiate SnapScan from just tapping your card for it to be viable, of course - like offering some “smart phone wallet” services.
What would you rather: fight 100 duck-sized horses, or one horse-sized duck
I’d go for glory and pick the horse-sized duck. It will probably be pretty dangerous, but I figure I’d manage if I can get to that flimsy neck. I’d take the risk because roasting a horse sized duck over an open fire sounds like a once-in-a-lifetime kind of party.
For more on SnapScan’s product team, check out OfferZen’s interview with Estiaan.