Design Sprint For Hackathon?
Entering a 3 day hackathon with only a problem, no solution
At SEEK, like many tech companies, we participate in hackathons a couple of times a year. Hackathons are our opportunity to work on any problem, with any technology, and any colleagues we want, for three days.
Over the years, the product delivery teams have learnt the value of including different parts of the business in their hackathon teams. Understanding the exact pains our customers experience; knowing if they’re likely to buy your idea; understanding how to pitch it; and having some solid thinking behind your solution is the difference between a cool, almost there idea, and a Hackathon winning, ready for production, solution to a problem.
This is how it’s panned out for me previously — I had an idea, I popped it on our intranet and started recruiting developers and designers (vital for a working hack). Once we had enough peeps on board I’d reach out to sales, service, marketing, strategy — whoever hadn’t joined a team — and pitch them my idea. “This is the problem, and this is how I’d like to solve it”. If they liked it, they’d join and start tailoring their expertise to fit the solution we were building.
The problem was this. I had diverse teams, with many skill sets, and so much customer and business knowledge, but I only used these skills to execute MY solution. As a PM, I should know better than anyone that the value in the diversity of thought is in using the diversity to help come up with a solution.
So when Craig, our Delivery & Operations director highlighted a problem that he felt quite passionate about, but didn’t know how to fix, and suggested a design sprint type hack, I jumped at the chance.
The problem we were tackling resonated. And so did the style of hack. For those who have never participated in a design sprint, Vedran Arnautovic has previously written about how SEEK has used the “GOOGLE Sprint” method for ideation in this blog post: Using Design Sprint to accelerate innovation (part II of II)
That’s where Craig left us to our own devices and I had to work out how the hell to fit a 5/7 day design sprint, that usually takes weeks/ months worth of pre-work in understanding the problem, gathering data, user research etc etc, into 2.5 days.
Here’s what we did:
Stage One: Unpack, Immerse and Build Empathy
Pre hack — 1 hour meeting.
Our marketing and strategy teams had each conducted user research earlier in the year around the higher level theme of our problem. They presented the research to the hack team, and shared the pack with us all.
We also found independent research on the same theme and used this time to share everything we could that talked to the problem.
The team read, asked questions and got their head around the research available and how it related to SEEK and our customers.
Pre-hack 1/2 hour catch up.
We each used this time to talk to why we wanted to work on this hack, what experience we had with the problem, and what change we would like to see. Each member had joined the team because the problem resonated. We wanted to ensure we captured the why, and fed this into our thinking.
Stage Two: Ideate & Converge
Day 1: 9am- 12pm —Ideation
We spent the morning coming up with as many ideas as we could, using the crazy eights method, talking through them, and then voting on what parts we liked and why.
We then iterated with a second and third round, until we landed on two very different ideas that solved different parts of the problem.
After group discussions we were able to recognise that the ideas actually complimented each other and were two sides of a marketplace. So we made the crazy decision to build one part of the solution and design the other, so that we could talk to both sides in our pitch to the judges.
We were half way through day one and we now had our idea. Something that the other teams had before the hack started.
Stage Three: Prototype or Build
Day 1: 12pm-5pm Design, Build, Gather, Create
This is where we split up and did what each of us did best . The developers coded. The designers designed. Groups of us sourced content; put together our sales pitch; created dummy data; found users to test on; mapped our progress; and gathered our thoughts. And by the end of day 1 we felt on track, under control, and most importantly ALIGNED.
Day 2: Still building and pulling it all together
We started to complete pieces of work that we could stitch together. This is where Steph, our designer, decided to map out our user flow from start to finish (even though we only built a chunk of it, to ensure we had all the pieces we needed to talk to our solution in the pitch). Some last minute additions were added, but by the end of day two it just needed minor tweaks to be complete.
Stage Four: Test
Day Three: Finishing touches, practice pitching, presenting and tackling the marketplace.
This is where I truly saw the benefits of the design sprint. It’s the first hack where every single person on the team had input on the pitch, gave feedback and worked together to ensure that we nailed the story. I’m sure at the end of the day, other teams had more exciting and compelling pitches than us. However, I’m also sure that the judges could have asked any single member of our team why we were tackling the problem; what impact it was having on SEEK and our customers; and how our solution would help; and they would have been able to answer without a thought. We were all aligned. We were all invested. We all owned the idea. And we all believed in the solution.
So how did our “testing” go? Did the judges like our hack?
I like to think that it was the collaborative, yet diverse thinking, and the deep understanding of our problem that led to us taking home two awards for our hack.
We won the Mobile First award for building our workable hack as an extension on our Android app. It was amazing work by our developers to get this accomplished in such a short period of time.
We also won the Disrupter award. This is awarded to the hack that has the potential to make the biggest business impact by being closely aligned with our purpose and greatly affecting our customers, marketplace and industry.
I hope I’ve sold the value of taking a bit of time away from delivering on your solution and then spending it with the team, so they come up with a solution that they're invested in. We know its how great products are made. So why should our hack ideas (that often make it into our products)be any different?
Thank you to our killer team: Michelle Tan, Neha Ravi, Taryn D’Souza, Pip Saalfield, Jo Miller, Den Ramos, Stephanie Moss, Ed Bulog, Craig Penfold, Lauren Taylor, Seble Kebede, Richard Tan & Molly Blue.
