Cutting Through the Noise
Across three days this summer, a number of teams at Omio set aside their routines to compete in our Summer 2022 Hackathon. When the smoke cleared, one team had bested everyone by not only building a feature that is launching on Omio’s platform, but one that marks something unprecedented in the industry. We brought three of them together to talk about what they built, and how they did it.
Alright, let’s get down to brass tacks real quick. Talk about what this project is, and what it does.
Aurelia: The project is organised around providing pricing insights to our users to empower them to make informed decisions when purchasing tickets on our platform. There are three features built into it. First, we have a price range that indicates whether the current price for the selected travel mode is lower or higher than usual. The second feature is a price calendar which allows the user to know, at first glance, which dates are cheaper for the route of interest. The last feature is a chart that displays the ticket price with respect to the days to departure (tip — ticket prices do get pricier if you book closer to the date of departure). Key to all of this is that all three features can be used for the three travel modes available for booking on our website — train, bus and flights. I’m really looking forward to its launch, because I’ve never seen websites doing such elaborate price-comparison for ground transportation in Europe.
That it’s unprecedented in the ways that it is suggests there are significant technical challenges to it; challenges the space has been unable or at least unwilling to tackle up to now. From your vantage, what were those? And why did you feel you were positioned to solve them?
Guillaume: Omio has a unique inventory of train, bus, flight and even ferry companies. That took years to build; the partnerships that make that possible didn’t happen overnight. Consequently, Omio can provide a much more comprehensive picture of available travel options; comparing not just flights, but all available modes at once. That’s the first piece of the challenge any other travel company would face. Then you need scale, actual users searching and booking millions of routes, to be able to track prices for every single route across multiple dates. That’s the second major challenge. And last but not least, you need a company culture that empowers teams to think outside the box, bringing a diverse set of skills together to build something meaningful.
The biggest challenge we encountered was managing the considerable data we have from all these travel companies, tracking prices and getting an understanding of price fluctuation. Having Aurelia and Emilie, two very talented data analysts, was crucial in building these features.
You all did something rather extraordinary, here. You took an idea, built a team around it, broke down its various angles, and ultimately executed something that is going to be implemented this year. And you did this in three days, right? That seems… non-standard.
Guillaume: Hackathons are very hectic, in a good way! It’s fascinating to see what you can pull off in just three days. Looking back, our success was down to three key components: Having a diverse and motivated team with a variety of skill sets, resolving our users’ number one pain point, and demonstrating the value this project could have for the business. The funny part is we’d never really worked together, and still had a lot of fun. Those are relationships that will continue beyond the event.
Jack: Agreed, all-around. I think the varied skill sets and functions we all brought to the table were a key reason we were able to successfully build a few key features which cater to our users’ primary area of concern when booking travel. It was refreshing to remove the structure and hierarchy existing in our (or really any) company and sit with a like-minded group of people, focused entirely on building something useful! We went from idea to execution in a couple of hours and got to forget about the OKR process for a few days. That focus on moving fast was fun and I think we all found it quite energising.
Aurelia: I think that Guilaume and Jack have said it all. I’d just add: Parkinson’s Law was definitely in our favour throughout all of this.
Wait. Talk about that a little more. Because, first of all, it’s not necessarily a concept immediately familiar to everyone. But additionally, that probably wrenched the gears a bit, and forced you all to bring different skills to bear on the process, to rein it in and keep things on track.
Aurelia: Parkinson’s Law states that work expands to fill the time available for its completion. This was especially relevant during the hackathon, as we only had about two full days to to work from ideation to a working prototype. It felt nearly impossible at the outset, but we pulled it off in the end!
Jack: Totally agree with this. It’s daunting to have to deliver something workable so quickly, but it’s also refreshing to be able to strip away some of the bureaucracy of working “properly”. The cross-functional alignment, OKR processes, and focus on things like documentation are integral to our day-to-day jobs. But they’re removed as a concern during a hackathon, allowing you to ignore everything except building something for a user.
Guillaume: Aurelia and Jack nailed it. The excitement from every member of the team to fully focus on bringing an idea to life — that was palpable. And it was strictly about building something we thought was valuable for our users. The hackathon allowed us to take these shortcuts that we wouldn’t have been able to take in our day-to-day work. I think our early decision to tackle a major pain point for our users really helped us lay out the story for everyone and showcase how well it aligns with our business strategy.
And so that more creative, exploratory aspect unfurled into the vacuum left by what we might call more bureaucratic obligations. Two days is not a lot of time to adapt to that set of conditions — while creating something. And you’re all coming at it from multiple vantages. Did the distribution of roles drive the end result in significant ways? How did you all find an optimal rhythm?
Jack: Well I mostly just sat around. The real success of it in my view was how Helio Medeiros pulled us together as a group and made us go through a proper brainstorming process. We had assumptions and ideas of what we wanted it to be. Especially me, as I had been thinking about this for a while and pitched it. That collective ideation session at the beginning of the two days took around three hours and helped ensure we were all on the same page by the end of it. It gave us clarity and focus and then that naturally gave way to clear roles and responsibilities for design, data science, and especially engineering. The end result was driven by buy-in at the outset, and then a demarcation of areas of responsibility — with a high level of trust from that point on.
Aurelia: Sorry, I’m still laughing at Jack’s opener! Yeah now that he mentions it, that three hour session Helio led did feel a little long and unnecessary at the start (sorry Helio!). Inside my head, I was thinking, “It’s just a price feature for a hackathon, must we really conduct a full-blown workshop like we usually do when launching a product feature? Damn, other groups are already working on their code and here we are still writing post-it notes and sticking them on the whiteboard”.
But the next day, everyone in the team knew what they had to do and by when — we were all aware of the feature priorities, overall timeline and output dependencies. We were working extremely efficiently as a team, with great communication and a steady supply of adrenaline. That was when I realised the importance of the workshop. It helped bring together the multiple vantages into a single, common vision. It helped the entire team become hyper focused on bringing our ideas to life!
And if I were offering guidance to hackathon teams, it would be that. Have a kickoff discussion and ensure that everyone in the team is aligned in terms of product feature vision, purpose, use cases, and how it would benefit the users. If you have multiple product features in mind, make sure to prioritise them in terms of user impact. We had three features in mind but only had time to get two of them to work. And that’s totally fine because those two features had the highest impact on user benefits. When delegating tasks, create a project timeline and make sure that you stick to it, start to finish.
Guillaume: Helio did an amazing job bringing the different team members into alignment, and that was crucial for executing things in the short time we had. As a team, we brought up close to a dozen different feature ideas we could’ve built, but creating that focus from the beginning really helped us be in “execution” mode. We were so lucky to have formed a very cross-functional and capable team. We had the necessary ingredients to bring that idea to life, no need to chase people down spread throughout the building.
I also think our success was due in large part to the fact that we were populating our feature with real data, thanks to our two very talented data-analysts Aurelia and Emilie. Jack might have just sat around as he says, but what he’s not mentioning is that he was sitting around behind our backs connecting all the dots. The way he delivered the presentation on the last day was crucial to our success and he was able to tell our story beautifully. Like I said, It was in some ways the dream team, everyone bringing their forces together for a good cause.
You’ve all talked about how the perspectives brought to this by differing roles was a significant contribution. Which, on the surface anyway, would suggest some tension — even just challenging your own intuition about things, within your respective expertise. I’m curious how that meshed with that intense focus. Was there a particular perspective within the team that really pushed back on or transformed how you tackled your personal area of focus?
Aurelia: I don’t recall any sort of tension within the team because everyone was an amazing and understanding team player.
Guillaume: It was my third Omio hackathon and, given that experience, I know how things can go very wrong when teams don’t run in the same direction. This time around, though… The team dynamics and expertise everyone brought to bear on things intersected with a deep respect. I don’t really recall any conflict or even small tensions within the group, even on the last day when we were putting final touches on our presentation. Quite literally, right up to a few minutes before presenting, the energy was so positive and exciting. When it came to refining our idea, we did of course toss thoughts in all directions, but everyone was very attentive to each other’s ideas and we were able to incorporate everyone’s insights. The funny thing is, the tension mainly came from members of other hackathon teams when we were discussing ideas. They highlighted some very key, relevant risks and things we hadn’t considered. And in the end, that really brought us back together as a team, at the drawing table, to polish our idea.
It’s part of your job, at the end of the day, to develop new features that ultimately get implemented for Omio users. But this seems to have a different texture just in terms of its novelty and the frenetic process through which you all executed it. How’s it feel now that it’s rolling out?
Jack: It is definitely part of our day to day job. I think what makes this different is that we were strictly developing a feature we thought would have customer impact, setting everything else aside. We all have priorities, OKRs, and a long list of things that need to be done every day. This process allowed us to remove all that noise and focus exclusively on what we can do within a fixed time period to cater to the users’ aspirations.
Guillaume: It’s a very good question. At Omio, we have lots of teams working on bringing lots of new improvements to our product, and we are all experts in each area. Whether that ‘s improving the way you pay for your ticket, or knowing what info you need while boarding your train. Hackathons give you the opportunity to jump into a totally new area and generate fresh ideas. That’s why they’re so exciting for teams — it’s a way to get out of your comfort zone and the inertia of day-to-day projects.
It feels great to know that –in addition to having a great time working together– we were ultimately able to push our idea into the product. We’re all very excited to see how users will interact with the feature and how it will improve the way they search for their next trip.
Want to learn more? Come join us! We’re hiring for a number of roles, and would love to talk to you.
