Christchurch Tech Stories: Smudge Apps
Christchurch’s tech sector is proud to be world class, connected and creative. The Talent Hive has been working on a blog series with a number of Tech employers in the region and we’re delighted to share those with you over the next few weeks.
Smudge Apps have been building mobile solutions for regional and international brands for nigh on a decade. Bona fide mobile veterans, they carved out a spot in the nascent app space and dug their heels in just as the smartphone was going mainstream. This self-described ‘experienced and nimble’ company is one of New Zealand’s star performers in software development – which is why The Talent Hive was delighted when Toby Vincent, Co-Founder at Smudge, agreed to sit down for a chat with us.
Tell us a little bit about Smudge. How did you get here?
Toby: Smudge has been on a little bit of a journey. We’ve changed a lot since we started nine years ago, sitting in [Smudge co-founder] Reuben’s bedroom during the holidays making very, very simple apps, potentially trying to make some money. We were just looking strategically at what was performing well on the App Store, building something similar, and putting it up. We’d built a lot of things and only really invested time in something if it actually started getting some traction.
One of the first things we built was a Halloween soundboard. That was where we started. We made 50 apps in three months. We wouldn’t build anything that would take more than two days. A big project for us was a week!
Then we started doing some corporate work in New Zealand. We focused on what we really wanted on our iPhones. It’s not like now – the iPhone was still viewed in corporate New Zealand as a marketing opportunity at best, or a novelty at worst.
Through persistence and a couple of years’ work, we managed to build quite a few consumer-facing apps that we wanted to see, like the Vodafone My Account app. You could pay for your phone bill and see how many minutes you’ve got left, which was a big deal for us, because we were seeking every cent out of our $20 a month plans!
We built some of Sky TV’s stuff. That one took a while. I think we first discussed streaming Sky TV on iPhones three or four years before we eventually ended up doing Sky Go.
You’re in the pit with the big IT vendors in New Zealand.
T: Absolutely. It’s gotten more and more that way. Now we’re predominantly focused on enterprise apps and taking some of those learnings we’ve got from building apps for large audiences. If you’re building an app for 100,000 people you have to be able to build something that people can just pick up and use with no training. It’s very different from the corporate world, where they roll out a tool and they go ‘ok, what’s our roll-out strategy and how are we going to train everybody on it?’
We wanted to bring some of those ideas of simplicity and consumer-level experience. We started doing a lot of work in the enterprise space, which is what we do now. We work in two key industries right now. FMCG – Fast-Moving Consumer Goods, with Coca-Cola’s regional bottler Coca-Cola Amatil, across New Zealand, Australia and Indonesia. For them we built a bunch of mobility tools to help power their business; sales tools to help the sales representatives go out and take orders; the iPhone tool used by delivery drivers to drop stock off; coaching tools for sales teams. The list goes on.
That’s a lot of infrastructural support to come from a small company.
T: There are fifteen of us in the office, yet we’re building the software that in some cases – Coke, for instance – is accounting for billions of dollars of sales going ordered through the products we build every year and it’s critical to their business.
The journey from a good concept to an effective, marketable piece of software is long and in most cases will remain incomplete. With so many developers out there, how do you ensure your software completes that journey?
T: I think the key word that you said there was incomplete, and I think that’s exactly right. Good software is about iteration. It’s about refining things. Part of that is to do with the ways software development methodology has changed. Once upon a time, most people approached software like building a house, where you’d spec it all out, design everything exactly how you want it, choose every material, decide where you want every wall and every beam, and you go and pour the concrete. Once it’s done, you test it and make sure it works. Software was built like that: spec it out, build it, test it.
It works. But, if you’re building a big project there can be a year in between. Where you go I specced that out a year ago and then it took a year to build. By then, is the house that I thought I wanted a year ago still the house I want now?
Software’s changed a little bit now. Now it’s essentially building a house one room at a time, getting feedback on each room and seeing what people think of it.
I think that iteration a big part of building great software. The other part is obviously a focus on the users and understanding what their actual needs are, and then building software for them that actually meets those needs.
Often when people are building software they have one of those two things. They might have an understanding of what the user needs and what the pain points are, but it’s harder to build stuff that solves some of those problems. Often it takes longer and is more complicated, harder. Yeah, it’s really that care and understanding, that empathy for the users that we care about.
In the Smudge book you talk about generating ‘concrete insights into the audience we are targeting’ and how to convert those insights into ‘refined, sharable ideas and user experiences’ – could you illustrate this process with an example you’ve worked on?
T: The book you’re referring to is actually going to be one of three. We think good software’s all about balance between that user-centric experience, good technology and commercial viability. It’s a balance between those three things. In that one book we talk a lot about the audience and the usability, but we don’t think that’s the only important bit in making good software obviously, you can have the best user experience in the world but if the technology doesn’t support it in scale and every time you open it it crashes, hey, it doesn’t matter. It’s about balance.
In terms of those concrete insights, probably the predominant way we do that is through developing that empathy for the user. Firstly by observation. So, with New Zealand Police, we built a tool for their frontline force, that provides intelligence in the field and enables things like issue speeding tickets and issue traffic-crash reports and so on. To build that we really needed to understand what cops do – the pain points and the variability of their job.
So we spent a lot of time in the back of police cars and working with a lot of people internally at police who were from the frontline in workshops, trying to understand not just what the workflow should look like on paper, and what the person would say is best practices, but what actually eventuates in the field when you’ve got competing jobs and priorities. Sometimes those things don’t perfectly match up.
After observation is immersion. If we can, we love to go and actually do the job ourselves. Obviously, with police, they’re not going to say ‘hey, here’s a badge, off you go’! But if we’re building an app for cinema ticketing, we can be the consumer and we can go and actually buy cinema tickets in the queue on a busy Saturday night, and we can try and buy one online, and try those different experiences and figure out what’s wrong with each of them ourselves.
Immersion, observation, and the last one is engagement. If we can’t do either of those two things, which are our preference, we just talk to people who are able – in a situation like, with the police, where obviously they won’t let us be involved in, like an armed offender squad call out or something, we’re never going to do and engage an observation with those guys because it’s too dangerous. So, we talk to people about their experiences.
What are the most common ‘pain points’ you encounter when dealing with businesses? How do these challenges differ between small start ups and huge multinationals (like Coca Cola)?
T: That’s a good question. Probably the most common pain point we see for the people actually on the ground using the stuff we build is frustration with the tools they currently have. We see this quite often where something has been digitised, potentially, it’s not paper anymore, but it hasn’t been done with that care and understanding, that empathy. And so in some cases, it’s made the process worse than paper. Instead of being able to pick up this form, I now have to log into two different systems, remember my passwords, do all that and then find the right place.
Often when we look at the emotions people are feeling and the tools they use at work. Often., that emotion is frustration. When we started working with Coca-Cola, the tools that sales reps were using there was one of the key reasons people were leaving Coca-Cola.
Another common problem is having the data but not the insights. Again, with Coca-Cola, the sales reps would get sent endless spreadsheets, pages and pages of numbers, and the business would say ‘here’s what’s going on in your market, figure out what to do about it’. And it requires quite a lot of analysis to actually look at that, and if you’re a sales rep and you’ve got to also go and see 30 customers in a day physically and you’ve got about seven minutes per store visit, which is the schedule they operate on to try and get everything done, you’re probably not sitting down analyzing spreadsheets very often. You know, you don’t have time to sit there and actually think about it. So we try to look at how we can give people the insight rather than the raw data.
With smaller companies and startups, the pain point is technical delivery – sticking on track and building something. Building the software delivery team that’s able to perform at a high level and be able to build stuff that’s good. That’s quite hard.
It’s been said that New Zealand generally under-invests in tech R & D. What’s your view? Is the situation beginning to change?
T: This is not an area of particular expertise for me, so I just have my opinion. This is maybe not Smudge’s opinion! Perhaps New Zealand does under-invest in technology R&D, but on the other hand we do have some of the best technology infrastructure in the world. New Zealand’s UFB infrastructure is world-class. Most countries do not have fibre to the door, and sets up New Zealand very well for future tech innovation.
Secondly, we’ve got an amazing cell network. Vodafone’s network is one of the best in the world. In terms of infrastructure, we’re bang on. Government and large private companies have put the money in the right places and done things that matter in terms of infrastructure.
In terms of R&D, yeah, maybe we are a little bit – if you look at the technology success stories and, based on the infrastructure we have, we don’t have that many global success stories.
At the same time we’re uniquely positioned to be focusing, especially down in Christchurch, we’re traditionally an agricultural economy, and somewhere like Christchurch with its rich hardware technology background could be a great hub for investment and innovation and agri-tech businesses and the Internet of Things, hardware engineering things based around that agriculture sector.
So, it would be nice to see Christchurch – I guess, you know, maybe Wellington’s got that image of ‘we’re the software capital’. It would be nice if Christchurch could get viewed as ‘we’re the hardware capital’ and we’re building things in that Internet of Things agri-tech space. That’s just a personal view though.
This interview is condensed and edited for clarity.
At The Talent Hive we specialise in connecting IT & Engineering professionals with the right career opportunities. We encourage collaboration, socialising your success and sharing industry insight and expertise. Start the journey, connect with The Talent Hive today.
Categorised as: IT, Tech Stories