2022 is coming up (yikes!) and your team’s goal is to make a list of features you’d like to see added to the product’s pipeline. Compiling such a list is not an easy task, and usually involves a handful of long meetings spanning around the same or very similar ideas.
I was looking for a different solution for my clients. A one-day effort will generate diverse ideas that are also actionable, resilient and fit into the product’s DNA. Inspired by design thinking and design sprint methodology, I combined it with a game design framework, and tried it with my first client about a year ago.
As of today, more than a dozen game companies utilize this method with great success. I am now ready to share the hackathon’s formula with you. Although my clients are usually gaming companies, I believe this formula can work for every product company who seeks to come up with new features in a fast and reliable way.
What to prepare
- Time. your team needs a full day, 9:00–17:00. Get them ready in advance.
- A bunch of colorful sticky notes and sharpies
- Big A0 papers that will serve as maps for the teams
The day’s breakdown
1. Split to teams | 5 Mins | No maps
Three to four people make a perfect team. Make sure people from various departments are on the same team. It will result in a better blend of ideas.
2. Set goals and KPIs | 10 Minutes | Map: Goals
Make a list of KPIs that need to be improved before the hackathon begins and let the teams choose the KPI they will be working on.
Each team can only work on one KPI, but multiple teams can work on the same KPI. Teams should write their KPIs and expected results big and clear on their goal boards. This serves as a guiding star for the team.
KPI-based goals should be formatted like this:
- Retention: How to improve 1D, 3D and 7D retention in our game
- Conversion: How to improve subscription conversion rates
- Session extension: How to improve players time in game
3. Ideas per player type | 60 minutes | Four player matrix
Now that the teams and goals have been set, it’s time to get creative. During the next hour, team members will:
- Get familiar with the different types of players
- Come up with a feature idea for each type of player (Each team member writes her own).
- Gather ideas on a board and get all team members on the same page.
3.1 The four player matrix
I’m referring to the Bartle study types of RPG players, which I altered a bit for the hackathon’s purposes. Working with the framework allows the participants to come up with different ideas based on the types of players.
Make sure all team members are familiar with the four types.
Type #1: Competitive
Winning is the primary motivation of the competitive type. They like to show off their skills, participate in tournaments, earn badges, etc. Following is a list of components and activities that go well with this type:
Leaderboards, Missions, Boss Fights, Bragging, Badges, Skill tree, Bonus points, Tournaments, Personal Record/score, Brackets, Chaining.
Type #2: Creative
The players of this type are passionate about expressing themselves, and they want the tools to do so. From Minecraft to Instagram, a variety of products act on this motivation. Following is a list of components and activities that go well with this type:
Customizing, Arranging, Animated gifs, Reviewing, Building, Painting, Using stickers, Avatar, Dressing up, Designing, Crafting.
Type #3: Social
Social relatedness refers to the interests and desires associated with social behaviors. Such people enjoy working together to achieve a common goal, seeking feedback from friends, and playing with others.
Components and activities that go well with this type include:
Chatting, Gifting, Teams & Guilds, Trading, Community, Helping, Working together, Friending, Voting, Sharing, Commenting.
Type #4: Explorer
This type of player digs deep. They will explore every part of your system, sometimes attempting to exploit it. There is a strong desire for more information. Curiosity is their main motivation.
Components and activities that go well with this type include:
Story, Easter eggs, Evolving content, Surprise, Collection, Side quests, Narrative branching, Choices, New Worlds.
Project the four-player matrix, along with its list of components and activities, on a screen while participants work. This will help them come up with ideas if they are stuck.
(If you are interested in reading more about the four players types, Amir Dori has written an excellent article about it.)
3.2 Working alone, in the group
After learning about the types of players, the participants can now think of features for each type.
To increase 1D retention rates, for example, we can think of features that appeal to every player type, such as:
- Competitors could be introduced to an in-game tournament as soon as they launch the game for the first time.
- Socializers will appreciate the ability to play with friends. It’s a great motivator to come back to a product when you know that someone is waiting for your response.
- Some stories or mysteries will leave explorers eager to find out what happens next.
- Tools for creation may be enticing for creative types, who will gain full access gradually.
Naturally, all ideas should be connected to the core game loop already present in the app or game. Each team member should work alone for 20 minutes. Ensure they come up with at least three different ideas per type of player.
3.3 The gathering
Once the 20 minutes are up, all sticky notes should be pasted on the players’ board. It is now time for the team to familiarize itself with all ideas, removing duplicates and irrelevant ones.
4. Voting | 5–10 minutes
It’s voting time.
Give each team member three round stickers and ask them to vote on their ideas.
The participants vote by pasting the stickers onto the sticky notes and can vote however they wish. All three stickers can be used on the same note, and they can vote on their ideas as well.
Take the three or four most popular ideas after voting. These ideas will be worked on from now on.
5. Journey | 60 minutes | Journey map
Now that each team has a minimum of three to four feature ideas, it is time to drill down. Each team should be split into two, so that each couple can work on two ideas. Teams are responsible for creating a high-level user journey that begins just before the feature is revealed to the player (by way of UI buttons, promos, etc.) and ends after the user interacts with it. The journey should not have more than six steps.
As soon as the steps are in place, ask the team members to write beneath them what the player feels and does at each step.
The result should look like this…
After completing this step, allow teams to read out loud their stickies and eliminate redundant or multiple notes.
6. Spot weaknesses | Spot weakness
Having gone over their boards, it’s time to test the new features. Look for weak spots in the flow. What can go wrong with this feature? Is it worth interacting with to begin with? What is the evolution of this feature over time?
On sticky notes, team members should write all possible weaknesses and paste them under the relevant step in the journey.
Some features may not make the cut when looking for weaknesses. You can remove them, eventually each team should only present two features.
7. Fix weaknesses | 40 minutes
If you didn’t kill the feature in the previous round, now is the time to enhance it. Examine the listed weaknesses and use a few design tools from your toolkit to overcome the biggest challenges. As a way of helping participants come up with ideas, I show them the list of behavior drivers and ask them to think about how these drivers can help resolve any weaknesses.
For example, perhaps a team has created a card collecting feature whose primary objective is to increase the game’s stickiness. The concern with that feature is that players may not be interested in collecting cards at all.
To resolve this particular weakness, we can go through our list of drivers and see if something can enhance our feature.
- Competence: Cards could enhance players’ ability to achieve the main goals of the core game
- Autonomy: Players will be able to choose one card out of three when they win cards (giving them more choices)
- Relatedness: Cards can be traded, gifted, or gathered as a team
- Scarcity: Create limited edition cards that will be more desirable
- Unpredictability: Each time the player wins, he or she receives a different card
- Endowment: Players will receive a few cards as a gift when the feature launches, so that the collecting process starts automatically and they can familiarize themselves with the mechanics
- Curiosity: Completing sets of cards opens up new gameplay possibilities
It’s likely that some ideas won’t make the cut (The “curiosity” driver solution is obviously too big for a complementing feature), whereas others may enable you to see the feature in a new light so you can come up with innovative solutions for its possible shortcomings.
8. Wireframing — Get ready for presentation |60 Minutes
It’s time to prepare the feature ideas for presentation. Teams should present two features in total, which means they need to decide which one to present internally if there are more than two.
I enjoy presenting ideas by showing high level wireframes that tell the entire user story from beginning to end. However all methods, as long as they are visual, are acceptable.
9. Present | 30- 50 Minutes, (Depends on the number of teams)
The teams present their feature ideas to the group. Allow three minutes for the presentation and two more for questions.
10. Vote | 20 Minutes
Now it’s time to score. I like to use the impact/effort matrix (Itamar Gilad version) to gain a clearer picture of what the group has accomplished during a hackathon.
There should be a consideration of low effort features that have some impact, as well as high effort high impact ideas, whereas high effort ideas with dubious outcomes take the majority. There are also features that may have negative effects. People who do not like an idea despite the fact that it is effective (Imagine a low cost low impact idea that doesn’t fit with the product DNA can give it a negative score.
How do we decide where to place the idea on the board?
A debate that could last a few hours, which we don’t have.
Here are a few suggestions:
- Give each group a laser pointer. As they vote simultaneously, you place the idea (in the form of a sticky note, of course) on the board.
- Use your own pointer to scan the board and ask team members to clap when the laser hits the area where they think the idea belongs. Put the idea on the noisiest place.
- Go digital. Have the team vote on Google slides, Miro, Mural or any other whiteboard of choice, then take the average and paste it on the real board.
- Use a different method of voting on ideas
By the end of the process, we will have all 8 ideas on our effort/impact board.
Finishing off
Wow, what a day! It’s 5:00 PM and the group is exhausted, but they should be pleased with what they accomplished. Two ideas for features per team, this should provide a good jumpstart for any development team looking to add new features to their product.
To learn more about the workshops I conduct at companies such as Playtika, Google, Ironsource, or to read a few more game-related articles, visit www.doriadar.com.
And if you’ve tried this hackathon formula in your company, I’d love to hear about it!
