You hear the same buzzwords all the time in the startup world: "customer-centric;” "user-friendly product;" "the customer comes first." Each and every company advocates those words and claims that its product team is listening to end-users on a daily basis.
And perhaps it’s true in many cases. But it can be a little funny to read so many articles, interviews, and LinkedIn posts about how close a particular company is to its customers. Certainly this is a key principle of building a great business, but too often it’s just lip service.
The truth is, at Spendesk we really do try to put our customers first. And not just in marketing materials. Our teams consistently advocate for specific customers to have new products built, better onboarding and ramp-up materials, and a smoother experience overall.
We focus on the value we bring them, we want to better understand their issues and their needs, and we work hard to build the best solutions for them.
And most importantly, we talk to customers and learn about their biggest challenges. Every team - from tech to legal - tries to make our services as useful and customer-friendly as possible.
Which is great, and we’re proud of it. But once we uncover these challenges along the way, how do we actually help customers overcome them? The smaller or more unique cases can be handled by our excellent support teams.
But in mid-2020, we found ourselves with a healthy list of promising product and process upgrades that could use more attention.
With several items on that list, and limited time and resources to tackle them, Spendesk software engineer Clément Garbay took the initiative to plan something different within the company. He created a specific event to try to tackle them, or at least to unearth a few concrete steps towards doing so...
A company hackathon aimed at three key issues
As I mentioned, we had no shortage of specific ideas we could attack. But in talking to clients and amongst ourselves, we always came back to three key themes:
1. Create easier and faster access to Spendesk
We like to think we’re building something new and different - an all-in-one spend management solution. And while people visit our site and ask about us for a whole range of reasons, we’re not always an easy product to understand. Spendesk relies on custom accountability rules, and on the company creating its own set of internal regulations.
And then there’s the fact that we’re talking about company cash - a touchy issue in general.
So naturally, people want to see and touch Spendesk to better understand it. And that hasn’t always been possible. There’s a legal aspect to the process, and they inevitably have to talk to our team - not everyone is a phone person.
A few hackathon teams were specifically tasked with finding ways to open up our solution earlier in this cycle - before sales teams are involved.
2. Prove the value of software solutions for expense & spend management problems
Expense and spend management are fast-growing, exciting industries. Just like fintech overall. But despite the growing enthusiasm in the market, we still talk to plenty of people who have no idea what they need, or how much their old fashioned finance processes hurt them.
We need to help our sales and marketing teams explain the solution to companies in the simplest way, and also provide them with valuable information. This might include a searchable database of customer quotes they can use when speaking to a similar company.
Several more hackathon teams explored this concept in detail.
3. Show existing customers how specific features can solve their particular needs
Another side effect of building a solution with a wide range of features and use cases, is that our users discover and adopt them all differently. Speaking to customers, we found countless cases of problems we could already solve, but the user didn’t know how yet.
Which is obviously our problem, not theirs.
Further hackathon squads were tasked with helping current users explore the product fully, especially those features they’re not currently paying for and familiar with. How could we let them test and try things in a guided, smart way that didn’t feel pushy or exploitative?
What is a company hackathon?
Just quickly, it’s probably best to spell out exactly what we mean by “hackathon.” A hackathon is essentially a group of people working together to solve a particular problem in a set period of time.
The word is a portmanteau of “hack” and “marathon,” and most readers will probably picture a group of developers chained to their desks, barely eating or sleeping until the job is done:
Which is often true, of course. But you’ll also find environmental hackathons, policy hackathons, and plenty of other instances where coding isn’t the only outcome.
In our case, we gave our teams one of those goals above, and they were able to solve them however they saw fit. That's "hacking" in the newer sense of the word - to find a quick and original solution to a problem.
How to run a company hackathon
Once the goals were in place, we needed to decide how the hackathon itself would play out. Like any good competition, we needed rules and regulations.
Here’s what our hackathon plan involved:
- Eight squads composed of Spendeskers from our product, tech, product marketing, and design teams.
- Each team would have two days to create and present a functional prototype - or at least, a very clear plan for how they’d build one.
- After two days, the entire company (not just the squads themselves) would vote for their favorite prototypes.
- The two winning squads would then have one further week to actually build an MVP.
This is all fairly straightforward stuff. But when you’re running your own company hackathon, there are a few more factors to consider.
Building the teams
The instructions were to choose the people they wanted to work with, mixing profiles and backgrounds to encourage creativity. That of course meant mixing up the squads too. Each person would bring their own skills to each stage of the project's design.
And squads were limited to 5 or 6 people maximum to keep the team lean and efficient.
The event schedule
A kick-off took place on the first day to launch the event. Each topic was presented by a “customer representative” - someone who could speak first hand about the challenges. These people acted as a point of contact during the hackathon if the teams wanted more details about the problem or pain points, to submit ideas, or to seek advice.
After the presentation, each team chose one topic to address.
They then had two days to find a solution and work on a concrete result. They had to brainstorm, find data, analyze, prototype, design, code, iterate, and do what can normally take months.
This fast pace is pretty much central to any hackathon.
Of course, the most exciting moment of the whole event was the presentation at the end. Each team had 7 minutes max to showcase their creation, and try to convince that their solution was best.
All Spendeskers were invited to this presentation, and everyone was able to vote following two criteria: they would choose their favorite project (the most complete outcome, the one they prefer, the most creative and relevant), but also the one that gave the best answer to the initial problem. Naturally, some solutions showed promise but hadn’t quite reached their conclusion.
As a result, the two squads with the most votes were selected as hackathon winners.
Of course, this is all largely pointless if nothing comes from it. But we also don’t have the time or resources to build eight entirely new proposals.
Instead, the two winning squads received one week full-time to make their prototypes a reality. The goal of this week was to have the most accomplished and convincing solution, and a deliverable result in production.
It’s crucial to think of this next phase right from the outset. Like any innovation project, you can get too fixated on the ideation phase, and completely forget about implementation.
Our squads were charged with presenting their implementation plans in that first demo, and any unrealistic options simply wouldn’t receive the votes.
Why run a Hackathon?
As I previously explained, our teams are focused on finding new ways of solving our customers' problems. However, the idea here was to get away from the usual working methods, to involve all kinds of people working on product development, and to rethink the working framework.
While our teams work closely together and interact on a daily basis, our marketers don’t often build new features. Likewise, one of our goals was to improve acquisition - something our product and tech teams don’t regularly focus on.
A hackathon gives them more freedom, new team combinations, mixes disciplines, and increases autonomy in the way solutions to problems are re-imagined. Plus, they get to enjoy this teamwork time and tackle problems outside their usual day-to-day tasks.
As one of our teams explained at demo time:
"It was a challenge for us to rethink the way we present the product. It’s a complex software that solves so many problems regarding spend management: from virtual to physical cards, to invoice management, to control workflows... We imagined a whole new way of interacting with the features customers aren’t using (yet!)."
People join companies like Spendesk to innovate and build new things. A hackathon offers a work environment of freedom and empowerment for the Spendeskers, where their ideas can be shipped immediately and have a direct impact on users.
Time to create your own company hackathon
Overall, this two-day hackathon project was a huge success. We saw eight worthwhile, creative solutions to significant challenges our customers regularly confront. And while we’re only choosing two for now, I’m sure there’s a time and a place for all of them.
If you’re keen to give this a shot in your own company, it’s a fairly simple process to follow. Be sure to start with a clear desired outcome (or three, in our case) - otherwise you risk losing some teams to their own imagination.
Give your employees creative freedom - within some careful defined parameters - and just watch the incredible work they produce.