.png){kind=small}
.jpg)
Games are fun, work is (usually) not. Games are designed to be rewarding, work has a mixed track record. At work, we usually oscillate between sleep-inducing boredom and nail-biting anxiety. At rare moments, we find ourselves in flow: where our skills and challenges are well-matched.
By applying game design principles, I believe we can increase the joy of day-to-day work. Three notable principles:
- Clear bar for success - many people don’t know what this looks like!
- Early momentum - early wins are power-ups for new players
- Easy to learn, hard to master - this makes for a fulfilling journey
As an example, I’ve deconstructed the product role into a curriculum with these principles in mind.
If you’re new / aspiring to product, this curriculum shows you the ropes. If you’re a product veteran, this should guide you in onboarding others. If you’re an otherwise curious reader, you can replicate my approach in other domains.
Play with the existing product
Being new to product is hard. You face a lot of decisions, and not enough context or experience to make them. Rather than fly off the cliff with a makeshift cape, start small. Familiarize yourself with all the existing features of your product before doing a deep-dive in your area of responsibility.
Develop an understanding of how your Lego block fits into the larger universe. Learn how your product grows. What are the steps and funnels that ladder up to a thriving business?
Context is king, and will take you from good to great.
When you’re playing with the product, try to put yourself in the shoes of a user. If it’s a shopping site, buy something. If it’s an enterprise subscription, evaluate if the offering is clear and compelling enough that you would subscribe. Take notes on anything that seems confusing, unexpected, delightful. There’s no better time to assess with fresh eyes than at the very beginning.
Shadow user interviews
Once you’ve developed your own point of view, dip your toes into some interviews to recalibrate your instincts. Shadowing sales and support calls helps you understand how the product is perceived by new and disgruntled users. Shadowing interviews on the product team is another great way to learn by osmosis.
The main things you want to get out of this phase are:
- What are the jobs your users have hired your product to do?
- Why did they hire you, and not Joe Shmoe?
- Had they not hired you, who would they turn to?
- What are the other problems your users struggle with frequently and painfully? As a rule of thumb, painkillers > vitamins.
Build a dashboard
Once you can put a face and persona to your users, it’s a good time to zoom out and look at the bigger picture. Build a dashboard for a feature within your domain (ideally for something you plan on improving). Numbers are the best way to prove or disprove anecdotal learnings.
The contents of a feature dashboard varies based on the feature, but at the very least, it should answer the following:
- # of users engaging with the feature over time
- # new vs. returning users over time (to uncover stickiness)
- % of total visitors engaging over time (to understand share of mind)
Most importantly, you should verify the feature is a net positive for the product. Features should make the overall experience of the product better. This is typically determined through an AB test goaled on a global metric.
Pure adoption, on the other hand, can be hacked by promoting your feature everywhere. I might sound like Captain Obvious, but it’s easy to forget the boring fundamentals in the excitement of building something new.
If you don’t know SQL, now’s a good time to pick it up. You probably won’t be writing queries forever, but knowing the basics will empower you to do quick analyses that accelerate your understanding of the product. If you’re very uncomfortable with SQL, sketch out the charts you want, and work with an analyst to get it done.
There may already be a dashboard. Resist the urge to take it at face value. A dashboard is merely one person’s perspective on what’s important. Building products requires developing your own. Any duplication of work at this early stage is worthwhile tuition.
Brainstorm improvements
Before you dive in, understand the problem that remains to be solved with your feature.
Will this problem enable you to build a painkiller or a vitamin? While both can be successful, effective painkillers attract demand on its own, while vitamins need to inspire demand. Sometimes vitamins evolve into painkillers by tapping into an unknown need (think the first iPhone), but most of the time, starting with painkillers is a better bet.
Write down the exact problem you want to solve. It’s easy to get swept up in brainstorming and forget about why you started.
When you dream up improvements, keep in mind that “better” is in service of the overall product. Prioritize ideas based on your estimate of what will be most impactful for the effort required. This is a great opportunity to collaborate or at least get buy-in from your teammates.
Test ideas with users
Put your ideas to the test in user interviews. Create an interview guide with the goals of your interview and prepared questions to guide the conversation. Try to read over notes from previous interviews, so you focus on questions that generate incremental learning.
Source your users carefully. If you’re looking to grow adoption, you need to find users who have not adopted. If you’re looking to deepen engagement, you need to find users who have adopted your feature (with a mix of non-power and power users).
Start with open-ended questions. People are easily primed, so if you start off with your ideas right off the bat, you can bias responses and limit the creativity of others.
When evaluating the value of an idea, ask them to compare it to anything else they would like to see. What you’re asking may feel like the most important thing in the world to you, but in the context of their world, it might just be a nice-to-have.
You want to do enough interviews where you can see patterns converging. This will vary based on the diversity of your user base, but patterns typically start emerging around 5-10.
Refine your list
Use your learnings to refine and reprioritize your list of improvements. Regroup with your teammates. Deciding what to work on may not be democratic, but everyone on the team should be given the opportunity to advocate for a different view, and understand how the final decision is made.
As a new member of the product team, you should lean towards improvements that are quicker wins — the results of which will materialize in a matter of weeks, not months. This builds your confidence and credibility, giving your early trajectory a power-up.
Scope out your idea
Take your top-priority idea, and scope it out in detail. There are 4 main pieces to a scoping doc:
- Define the problem
- Define the business value and user value created by solving this problem
- Describe in detail how you plan to solve the problem, and how the user experience changes as a result
- Plan how to measure success
A great scoping doc captures your thoughts, so anyone can understand what you’re looking to do. A stellar scoping doc helps you de-risk ideas by exposing the gaps in your own thinking, giving you the superpower to see around corners.
Execute with extreme paranoia
The devil is always in the details. Even great ideas fail upon poor execution. As you work on designs, make sure the solution solves the original problem and meets the business goal. It’s surprisingly easy to get caught up in the pixels and forget the larger picture.
At the implementation state, you will benefit from extreme paranoia. Ask yourself: what could go wrong? Unintended consequences often hide in plain sight. Many are left undiscovered until the launch results come back negative. Study previously failed launches to make sure you are not repeating the same mistakes.
Watching experiment results can feel like getting publicly graded in slow-motion. There will be exhilaration, dread, remorse. When you’re at a gut-wrenching turn, take solace in the fact that the toughest launches will end up teaching you the most.
Success in the early days of a product role mostly hinges on these last few phases: scoping out a problem and solution thoroughly, then executing the hell out of it to put points on the board. By spelling out these early phases, I hope the path to learning product becomes more clear. ☺️
What next?
So far, we’ve covered level 1 of an infinite game. Product is devilishly hard to master because the world keeps changing and customers are divinely discontent. But I’m convinced building products is also the best feedback loop of all time, and is worth the psychological roller coaster.
I plan on covering more levels in the future, including de-risking big ideas, building a roadmap, iterating vs. innovating, unlocking performance vs. people. Let me know if there are specific topics you’re interested in.
