7 Steps to Building Something Successful and Awesome in a Day

Most companies these days have some form of hack day, at SuperAwesome we do these quarterly. As a product manager, my role mainly focuses on strategy, communication and planning so I relish the opportunity a hack day presents, getting my hands dirty again like my web designer days.

What I love about hack days is that it’s literally what agile is supposed to be all about; getting the basic thing working that solves a Job to be Done (JTBD). I have distilled this process into seven steps.

Step 1. The Idea

Unless you want to waste most of your day brainstorming I strongly suggest having a rough idea before the day. What works for me is simply having an Apple Notes file called “Hack Day” where I dump ideas I’ve thought about in the shower.

It’s important to start with an opportunity or problem and not the solution. If you focus just on the solution you won't be able to pivot if your solution is too big for a day’s work.

The opportunity I was exploring was around a piece of content that has a network effect and can go viral. It should pass a simple test “If only one person found the feature, could it go viral?” Social networks have hundreds of these things happening all the time so there are plenty of solutions out there already that I could adapt for a kids social experience like PopJam.

Adults love sharing stuff that tells a story about who they are or what they have done, which is why personality quizzes and ‘Year in Review’ content is so popular. The deeper JTBD here is about getting attention and social validation. The assumption I had was that PopJam’s audience of kids aged 7–12 were developed enough to have a similar need.

Step 2. Plan the Day

I now had a rough idea about what I want to create i.e. a mechanism that allowed kids to share something about their PopJam achievements.

In hack days there’s no time for roadmaps, tickets or stakeholder sign off or alignment so making a plan is important. My approach is as follows:

1. Make sure the right people are in the team. There should be no dependencies outside of the working group.
2. Set some basic milestones. I always aim to have a working prototype by lunchtime so we have the afternoon to add polish and touches of delight. It also allows time to prepare to present to the other teams.

Step 3. Rough Sketch of the Idea

You won't have long so sketching the idea should be restricted to 30 minutes maximum, else you risk getting too detailed.

You are going to have to iterate your idea constantly as you run into roadblocks so fancy wireframes and visual prototypes are a waste. The purpose of this session is to figure out what the solution will look like so you can decide what to start on first.

This took less than 30 minutes to sketch out with my full stack developer

Step 4. Prioritise Your Riskiest Assumptions

In Lean UX, we talk a great deal about finding your riskiest assumption but it’s pretty difficult to do in a large project. A small hack day project, however, helps you train yourself to quickly spot the gremlins that can derail your idea.

For my team’s project, it was fairly easy to figure out what assumption was the riskiest. We already had the sharing ability in the PopJam app, and a way to display HTML content but what was going to make this whole idea fail was if we couldn't extract user data and get it to display.

Project priority #1 was to get a rough prototype working that could display a number of statistics from a kid’s PopJam profile. We also needed to prioritise the stats in order of importance in case certain data sets weren’t accessible, as that would change the project’s scope.

The sketches and prioritisation of assumptions should take no longer than an hour.

Step 5. Design and Build

We had around four hours to make progress before our first milestone so we split the work and got started. We needed to be very flexible and cut scope quickly during this phase so we’d have something working before lunch.

These milestones are important for staying focused on the goal or else time will creep up on you!

Being a website designer earlier in my career meant I had the skills to handle the design and front-end build, freeing up the full stack engineer to focus on the gathering and displaying of the data i.e. our riskiest assumption. We also setup a Github project so I wasn't sending him code over Google Drive!

I used Figma to design the screen for the Year in Review

Step 6. Polish and Delight

Post-lunch you are full of pizza and excitement because you should have something working, albeit not totally ready for production.

You have around three hours left to add the finishing touches so you should aim to do the following:

1. Make sure it’s working end-to-end
2. Add something fun and delightful. We added a joke and animated gif to the loading screen as we anticipated kids would be on this page for a while so we wanted to entertain them to prevent drop-off
3. Get it on production and test it again. Make sure its ok to be public e.g. that there are no copyrighted images, fonts or SDKs etc.

Step 7. Presentation

Every hack day has an end of day presentation and people always underestimate how important preparing for this actually is (mainly because they are rushing to get their projects finished 😉 ).

Done the right way, you can make anything more interesting with a great presentation. I normally tell my team to pretend we are presenting at an Apple product launch event so we build suspense, make people laugh and tell a story about how the idea delights users.

But was it successful?

After the project is live and in the wild, it’s time to look back at our success criteria.

“If only one person found the feature, could it go viral?”

If our assumption was correct that kids have a need for social validation and to show what they have done then it should only take one kid to use the feature in order for it to go viral.

We hid the feature in a secret official channel in the app called popjamstats and didn’t tell anyone about it. A kid found the channel via search and was curious enough to try it. The feature’s share functionality posts directly to their profile and is immediately visible to everyone who follows them. Kids can get their Year in Review stats directly from the shared post so friction to entering was very low.

Here are the results:

Since its launch, over 100k PopJam Year in Reviews have been created. Not bad for a day's work!