Aligning on “Why” for product development work is always important in work but it’s especially important for distributed teams. When the “Why” is consistently missing, projects end up feeling like a list of context free tasks from ‘up above’ and teams can become demotivated and resentful – no one likes being told what to do all the time.
In synchronous, in person cultures, understanding and reenforcing the “Why” happens more organically in corridor conversations, social time (lunch/after work) that colleagues to have conversations about the reasons behind their work more naturally and transfer energy and enthusiasm to each other (also an important lever for leaders). As a leader, it’s easier to notice misalignment or lower motivation because you can ‘feel it’ and course correction can happen faster by grabbing a room talking through something and emerging with a decision.
In distributed, asynchronous cultures it’s very important that the people doing the actual work have a strong understanding and believe in the “Why” and are rowing in the same direction because detecting misalignment can be slower. This is amplified in importance if you are changing product direction and focus or are working on a new product (with lots of potential directions).
As a leader of these teams, you need to put systems in place to understand if people have a shared understanding of the business or user problem they are solving. Include your teams on the journey towards the decision (to improve shared understanding and acceptance) vs. just communicating the decision in isolation. I would try over-indexing on time spent on the user and business goals with more space reserved for discussion upfront for new projects. The contributing teams need to be able to express concern, propose alternatives and build motivation for the problem space. This can admittedly feel slow, but over the long term it’s better for both the people and the product.
I’d suggest experimenting with more rich media (audio, video, pictures) to allow people to understand your thinking as a complement, not a replacement to longform text which is still the most important as it’s easy to scan, indexable and searchable. I’ve been experimenting with quick Loom Videos to give product feedback or sharing a short video colleagues (in addition to a bullet point summary) to transfer more context of sentiment and detail across, whereas previously I would have defaulted only to text. I think this helps communicate with more personality and context but also preserves some of the benefits of async communication and culture.
As a leader, try not to be be a taskmaster. When you’re trying to align teams, try to have them write the “Why” documents and determine and justify own problem spaces (with your guidance). You can guide and get alignment by asking questions to shape the problem spaces and making decisions about priorities. Being a taskmaster creates single person failure risk (you) and ultimately leads teams being demotivated over the long term. Having to do something ‘because someone senior said so’ is deeply unmotivating over many cycles. There are periods of ‘War Time‘ where being a taskmaster is appropriate, but should is not the case for business as usual work.
We all have to execute things that we don’t fully believe in – it’s just part of the nature of work. In these situations state your position clearly but ‘disagree and commit’ if the decision has been made. When you communicate the problem space and the “Why” to your teams, emphasize on the components you actually agree/believe (versus the areas you don’t), as your team will be able to sense authenticity and energy.
In summary, as a leader of distributed teams, it’ll pay long term dividends to focus more on “The Why” upfront especially for new projects or when you’re changing directions even though it may feel slower at times. Plan for more time and space to get all folks involved to understand the rationale (user and business) and build motivation for their work whenever possible.
I’ve been leading product development teams for over 10 years in different industries (ads, gaming, fintech, tools) and customer segments (consumer, enterprise, SMBs). There are a few things have been consistently true across these industries particularly at scale.
I typically broken up my role into three different buckets:
Product: What are our goals? What we are building to achieve these goals? Why are these features impactful from a user or business perspective? What priority order should we build these features? How do we measure our success (metrics) against these goals? How do we align with other stakeholders (e.g. other product leads, marketing, finance) across the company? What are the right health metrics for the product and are we monitoring them effectively?
People: Do we have the right people in the right places? Are we aligning the right mix of complementary teams with the right problem spaces? Am I helping the people on my team achieve their personal goals, as well as driving business outcomes? Am I managing performance (both outstanding and underwhelming) effectively?
Process: What is the ‘product development system’ that ultimately allows us to build great products? What are our rituals that are consistent across teams, and what can be flexible within teams? How do we ensure continuous iteration and experimentation on our system?
When running a suite of products with multiple product, the very practical things I like to spend my time on include:
Identifying problem spaces that roll up into a coherent strategy to drive user and business outcomes [this is often the hardest].
Aligning each team to a problem space and a clear ‘why’ for their work.
Working with product development teams to craft their solution spaces and roadmaps.
Giving feedback on product specs for high investment features.
Giving feedback on products that are shipping (quality control).
Acting as the pattern matcher/glue for related work across teams.
These practices need iteration and refinement based on the type of company (and culture), the type of product (e.g. enterprise is more customer led), and the mix of the people on your teams but being intentional about priorities and practices is always helpful (I published a version of this internally).
In 2017, I made a virtual reality (VR), live action series with a friend (who I worked with at Pocket Gems) who was the creative visionary and conceived the idea. I was new to both VR and filmmaking and this was a cool opportunity to learn a lot in a time boxed project (8 months) with a concrete deliverable.
Our thesis had a number of components, and we were trying to figure out if we could drastically improve the quality to cost ratio for VR film production by introducing constraints. Ultimately we were looking to create a platform and process for profitable VR content creation (‘Netflix for VR’).
First Person: The series is shot primarily from the perspective of the protagonist, which allows the viewer to experience the story from their perspective. We thought that stereo (both eyes have a different video) was important for realism as it mimics our own eyes.
Narrative Stories: Focus on storytelling and include some light interaction and choice to give the user agency and improve immersion. Black mirror tried this approach with their Bandersnatch Series (which was produced after this).
Freemium: Start with episodic content with the first episode free, together with an upgrade path to unlock the rest of the experience (learned from our time working on Episode)
Technology: Build software to create proprietary production techniques that increase the quality and reduce the cost for even low end Android devices (increase the size of the audience).
This was our short pitch for the production, called Playback:
“Playback is a revolutionary VR miniseries that pushes the boundaries of narrative storytelling and viewer interaction. It’s a cautionary tale about life-changing technological advancement and the personal and societal implications of its adoption.
You experience life through Alex’s POV as his company is about to launch their new, groundbreaking product: a device that records moments and allows people to re-live those moments in all five senses
As the story progresses, the boundary between Alex’s technology and his own reality begins to fall away, pressing the viewer to question what their own reality will mean as our world becomes increasingly virtual.”
The entire process took around eight months and was broken up as follows:
Month 1: Pitch and Funding
High Level Pitch: We wrote up a high level pitch and deck for the Oculus team who then approved a $50k budget for Playback (over another Zombie concept).
Budget: Prepare high level budget to make sure that we could actually produce the experience with the $50k.
Month 2-3: Writing and Production Process
We split up the creative part (writing and character development) with the production part (technology, team, production process) and worked on each in parallel:
Overall Workflow: How would our overall process work from the point of filming to getting it in a users hands. We went through this entire flow, including creating an app and deploying it to the app store.
Vertical Slice: We picked a single scene and tried to make it look ‘production ready’ with a very short test clip. This set the quality bar for the production:
Story arc and characters: The pitch needed to be broken down into a story, and the characters needed to be developed.
Detailed Script: After the story, a detailed script with dialogue was prepared for 4 episodes, including choice/branching narrative.
Core Team and Contractors: We needed to assemble a small team (which was mostly unpaid) and the core team included our Directors of Photography (Sensorium) an NYU film student, and a visual designer who worked with us at nights and weekends.
Technology experiments: We ran lots of experiments with both hardware (e.g. cameras, rigs, lighting etc) and software (e.g. Depthkit) to figure out some of the tools that we could use during production.
Month 4: Pre-Production
Casting: We decided to hire SAG Actors (under New Media) which meant we had access to better actors, but had to follow certain guidelines. We looked at 100+ audition tapes and 3 finalists for each major role.
Prepare for shooting: This required a lot of work – we needed to pick venues, rehearse with actors, design the sets, and create very detailed shot lists to make sure we got all the footage we needed.
Shoot week: We planned to shoot the whole series in one week. This was a very structured and organized period starting early in the morning and ending late at night. Our “team” included over 30 people working at different points during the week and this was the most “expensive” part of the production process.
Month 5-8: Post Production
Post production took almost half the total time, and we underestimated how long this part of the process would actually take by a fair bit.
Shot selection: We reviewed all the raw footage and picked the shots that we wanted to use for the series.
Stitching: For stereoscopic VR, we needed to ‘stitch’ the video and image files together and make sure that each eye had an image that did not make it look like the user was seeing double (very off putting) which was difficult and time consuming.
Engineering: We added components like a ‘cyber world’, user AR interaction, branching narrative, and a number of performance improvements which required focused engineering and design time.
Film festivals: We chose a few festivals and created pitch decks and submission entries for them.
Launch and review metrics: Once launched we needed to analyze the metrics and user behaviour and compare to our original hypotheses.
We had a strict budget, and part of our thesis was to see how high we could push the quality bar with a fixed, restricted budget (comparing ourselves to experiences with 20x+ bigger budgets). We raised $50k from Oculus (as a grant), and we ended up very close to our original budget.
We prepared a detailed budget with 10% flex built in, and tracked the costs vs estimates meticulously in a spreadsheet. Most creative projects go over budget, and having this kind of discipline allowed us to keep costs under control and scrutinize all expenses carefully.
Given that our thesis was to try to create high quality content for a fraction of the price that was typical in the industry, it was important for us to control for costs carefully.
We tested out a number of different technologies in the production:
Stereo 4k footage: Each eye has a different video (mimicking our normal eyes) at 4k resolution which makes it feel more real to the user. This is hard to achieve on low end devices.
Proprietary image + video cut out system: In order to get the quality of video that we wanted, we built a system to constrain the ‘action’ to a small part of the scene and overlaid video on top of a still image. This required a very precise shooting and post production process that we created ourselves.
Photogrammetry: We mapped the inside of one of our scenes (3d + textures) to allow transition between live action scenes and a computer generated world seamlessly.
Volumetric video: We used Depthkit to capture volumetric video (3d), for a scene with a ‘ghost’ in the virtual world.
AR Interaction: At the start of the first episode we created a HUD which the viewer could interact with – read emails, the news etc which added to the sci fi and first person interaction.
Branching Narrative: We created choice where users could send different texts (via their AR HUD) which changed the outcome of the story depending on the choices they made.
We created something that was both innovative in the way it approached story telling, as well as the technologies that we implemented for VR. We decided to apply to a few film festivals (Sundance, Tribeca) in their VR experiences segments. We got fairly far with Sundance but were ultimately not selected.
I went to Sundance in 2018 anyway, and had a great time skiing and watching movies. Our Directors of Photography (Sensorium) had another VR experience which was featured, so it was fun to see them experience some of their other work.
Here is a short video showcasing the first episode (although it’s much better experienced in VR).
We released the final product in the Oculus App Store. We were featured and had reasonable download and view rates (over 15k people). Users got the first episode for free, and had to pay to unlock the next three episodes. There were some bugs in the upgrade process that negatively impacted our ratings but for people who were able to upgrade, many seemed delighted.
We were still a step function off in terms of both addressable audience as well as conversion to payer rates to justify our original hypothesis and invest further. Neither of us are still working in VR.
Scope creep: This was a classic mistake that we should have realized earlier (as we’ve done this many times in games) but we got too excited about some of the tools and technologies and probably added too much (e.g. volumetric video capture, branching narrative) that was not necessary to test our original hypothesis.
Stereoscopic vs. Monoscopic: I think we should have killed the stereoscopic requirement early in post production. Stitching of video so that it does not look warped or incorrect for both eyes is a real pain, and this would have saved us a few months as well as allowed us to ship a more polished experience overall.
Developer experience: We built most of the application in Unity and used tools like Blendr, Adobe Premiere Pro as well. The workflow was pretty cumbersome and it was fairly manual to create scenes and test out in VR. We could have built a lot of automation ourselves but it was not worth it if we were just doing it for one series.
VRUser Experience: At the time, we were optimizing for users using Oculus Go devices (Android phones strapped to your face) and this entire UX was terrible (buggy, battery hog, performance and storage issues etc). Standalone devices have improved the experience substantially, but we’re still not at the stage where this will be mainstream.
Running out of energy: Towards the end, it became a real grind to get it out the door. Everyone was tired, and the project took 30% longer than any of us expected.
Overall it was a great learning experience but it made me realize I don’t want to work in the ‘content creation’ business especially in entertainment. I much prefer working on tools for entrepreneurs and business, and hope to spend more of my career building technology for this audience.
In this post, I summarize a process that I recommend for hiring product managers at a midsize or growth company, adapted for a distributed hiring environment (most applicable to a company that will hire multiple product managers).
I’ve hired and trained over 40 product managers over the course of my career, and this draws on my experience as a product hiring manager and team lead.
Internal buy in and scope of role
When hiring product managers (PMs) at a mid size company the most important thing is to have internal support from the executives and the design and engineering partners. There should be a strong desire to hire PMs to help build better products in a better way and to bring in more structure and systems to the product development process.
Once there is buy-in from these stakeholders, organize the teams into sensible working groups (e.g. by user journey such as onboarding/growth or by key metrics such as conversion/retention or by product line).
I prefer a matrix structure (although has tradeoffs) where PMs ‘own’ each of these areas in partnership with a design and engineering lead (with around 5-10 engineers per PM, depending on the project). I also suggest that engineers and designers report into their own functional leads and PMs direct the scope and priorities of the projects.
It’s essential to have a clear hiring process and system both for the sake of your internal team and for the candidates. Most companies are incredibly disorganized about hiring, but a little bit of work can save a lot of time in the future, especially when hiring many folks for the same role.
Recruiter:There should be a consistent point of contact for the candidate during their application process – ideally a recruiter. The recruiter communicates with the candidate, lays out the hiring process clearly, and moves them through the process. They act as a liaison between the hiring manager(s) and the candidate. They often do the initial resume screens and have an essential input into hiring because they get to know the candidate so well.
Hiring Manager: The hiring manager is the person that is hiring for the role. They are the person who ultimately makes the decision to recommend the candidate as a ‘hire’ or ’no-hire’. This is typically a senior product leader.
Interviewers: Each interviewer should have a clear set of criteria that they use to evaluate the candidate. The interviewers should be excellent at the functional areas that they are evaluating candidates and hold the quality standard for the organization. The best people should be involved in late-stage interviews and this should be a core part of their job description.
Resume screen: Internal and external candidates should submit a Resume / LinkedIn profile which should be screened upfront (recruiter + hiring manager). Candidates who pass this phase should move to a conversation with the recruiter, followed by the hiring manager.
Interviews: Interviews should consist of a standard set of, very well calibrated questions that can be asked by a variety of interviewers representing the different development functions (e.g. design, engineering, product, marketing). A structured hiring guide improves consistency and calibration, and can reduce bias from the hiring process.
Central Tool/ATS: Interview feedback should be stored in a central place/tool (e.g. Greenhouse or Lever) and each interviewer’s feedback captured clearly (with a hiring recommendation). This allows us to both evaluate interviewers and the candidates – e.g. some interviewers bias towards higher or lower scores.
Written Exercise: If you are hiring in a distributed environment, try to find candidates with strong communication skills (particularly written skills) and clarity of thought. All candidates should complete a written exercise as part of their recruitment process which could include:
Break down a product you love – what you like, what you don’t like, how you would make it better (1 page)?
What is your favorite technological shift and why?
Write a ‘product spec’ to address a specific problem that the company has (better if it is a real problem).
Trial: If possible, ask the candidate if they would be open to a two-way trial (which is compensated) where they try and solve a real problem and collaborate with an internal team. This is time consuming (20-40hrs for the candidate, 5-10 hours internally) so very few candidates should go through this process if you decide to incorporate trials. You may filter out some good candidates because of the time commitment, but candidates who join are more likely to be successful.
References: I think that final candidates should be referenced checked by the hiring manager, especially if there are open questions. Backchannel references are the best (but avoid people at their current company) otherwise, ask the candidate for references. Here are some questions that I like:
How do you know the person? (gauge depth of relationship)
What are their strengths?
What are their areas for development?
What percentile would you put them in relative to similar folks in their position?
Would you hire them again?
Decision: For borderline candidates, the panel of interviewers should have a sync or async discussion – e.g. a private recruiting slack channel for hiring. The hiring manager is ultimately the decision maker. From start to finish, try and keep this process fast (e.g. under one month, and track the throughput).
Candidates should have a great experience, understand how they are being evaluated and have consistent clear communication through the process.
Hiring Criteria: Candidates should understand the criteria by which they are being evaluated and the steps in your hiring process – this should be a templated email or a public blog post that you can send to product candidates.
Point of Contact: Candidates should have a clear point of contact (ideally the recruiter), to ask any questions about timelines and next steps.
Acceleration: If a candidate performs very well in early interviews or comes in through a trusted referral, they should be bumped up to the top of the queue or potentially skip steps so you don’t lose great people because of slow process.
How to Assess
When hiring, it’s important to be explicit about the skills you are looking for, and get a sense for where candidates are truly exceptional.
Here are the dimensions that I think you should use to assess candidates in the interview process:
Analytical Ability: AB Testing, Interpreting metrics, Data-informed decision making.
Product Judgment: System design, UX design to solve user / business problems.
Execution: Prioritization, Getting things done when you say you will.
Technical Ability: Earn trust and respect from engineers as partners. Some roles will have a higher technical bar than others.
Each person on the interview team (3-5 people) should be responsible for evaluating the candidate along a subset of the interview criteria to create a balanced view. Ideally interviewers would ask the same questions to each candidate to calibrate their answers. I suggest that each interviewer test at least 2 dimensions of the list.
I suggest looking for candidates with an exceptional ‘A’ level strength, particularly in harder to learn skills like analytical ability and product judgement. I much prefer ABC candidates over BBB candidates because it’s possible to design complementary teams with AAA skills in aggregate.
Candidates should also demonstrate strong domain knowledge, and passion for the product, company and the customer. If they have prepared, it goes a long way (and it’s surprising how many candidates are ill prepared). If a candidate teaches me something new, or helps me challenge my own assumptions, that is wonderful.
Appendix: Other resources
Product Design: User experience, Design driven problem solving.
Analytical ability: Fluency with numbers, Using data to drive product decisions, dashboard design.
Technical ability: Understand technology and fundamental computer science principles.
When you’re running a small startup, you may ask yourself when to hire your first product manager and what you should look for in the candidate. This is a question I get from founders fairly often.
Startup founders in technology companies usually are great at least one of the following things; making stuff and selling stuff. Few individual founders are great at both, but most successful founding teams are excellent at both.
In the early stages of your startup, when you are trying to find product-market fit, you do not need a product manager. As founders (at least one of) you should be the product people at the company – obsess about the product, spend time with customers, drive the product roadmap, etc.
When you have found product/market fit and you are starting to scale, is when you should hire your first product manager. This person can run the day to day product development and allow you (as the founder) to step back and focus on fundraising, product strategy, hiring, and important partnerships. This person should bring you significant leverage.
Many founders think they need a ‘Head of Product’ first – I don’t think that is right. I would not hire a super experienced product person who expects high compensation, owning the entire product vision and strategy or brings in ‘this is how we do things’ from their background.
Instead, I would look for an early/mid stage in their career, who is a strong executor and is high potential and can grow with the company. This person should be passionate about your product, users and you should be excited about mentoring and working closely with them (as founder/CEO).
If this person ends up doing a great job at the execution, they can take on more product strategy from you as you build mutual trust and respect. If they are not able to scale in this role, you can bring in more experienced folks to lead the organization. Replacing a product manager is much easier and less expensive than a head of product.
Over the last few months, I’ve been thinking about how to design a lightweight framework for product development that fits in with different ‘product cultures’ and scales from a few teams of a few people to up to 50 people.
My current ‘best guess’ of this is a modified version of the Now/Next/Later framework that Noah Weiss nicely laid out here. For each product line I’d recommend a separate roadmap of this otherwise it gets pretty unwieldy. You can always roll up specific projects into a higher level company level view, if needed.
Here are some principles that I suggest for your roadmap:
The product roadmap needs to be publicly visible and easily accessible to folks in the whole organization.
It needs to be easy for folks outside the immediate executing team toadd ideas or requests to the ‘New’ section for triaging.
Ideas should be tracked from ideation to completion without duplication of work to update projects by lots of unconnected tools.
The tool you choose is not important, as long as everyone uses it. I’ve enjoyed using Asana in the past (although they don’t integrate super well with other services).
New (Inbox) : This is where all new items start to be prioritized. Items could be anything from large feature ideas, bugs or feature modifications. There should be a clear owner for prioritizing these items, usually the product lead, or on call engineer depending on the type of issue. Large projects should be broken up into milestones and prioritized. Try and keep this section at ‘Inbox Zero’.
Now (In Development) : This is what the team is actively working on right now, in order of priority. These tasks should be assigned to individuals on the team and usually correspond the the current sprint. Tasks in ‘Now’ are granular and well defined and have a clearly scoped deliverable and timeline. If you want more granular ordering or filtering in this list, I suggest tagging tasks by priority (e.g. P1, P2, P3).
Next (On Deck): These are the tasks/features that the team will work on in the next 1-2 development sprints. Tasks in this section should be in rough order of priority and have some definition around them, but may be broken up into more specific tasks when they move into the ‘Now’ bucket.
Later (Icebox): These are items that are unprioritized, but you know you want to get to them at some point. They could be bugs, loosely defined features, or feature modifications which should be tagged for clarity. The order or specificity around these is less important (especially for features) as you will prioritize and add more definition when the time comes.
Not Doing (Pit of Despair) : This bucket of tasks is usually hidden but is a list of ideas that you have explicitly decided that you are not doing. I suggest adding in a comment into the task to articulate the reason why you are not doing it, before moving it to this ‘Not Doing’ bucket.
In addition to the execution priority, it’s also useful to include some way to show the relative importance of tasks, so you can clearly see what tasks in the sprint can not drop. I suggest a Priority (Impact) and Project Size (Effort) tag like I’ve shown below.
This is an example of what a product roadmap could look in Asana:
In an ideal world, the tool is easily used and accessible by everyone in the organization and tightly integrates with other product development tools you use – e.g. Figma, Github, Google docs. Asana does not do a great job here and it’s hard to get information out of Asana if they whole company does not use it (which probably improves their retention, but makes it a worse tool overall).
These principles don’t just apply to user facing product development teams but would be also useful for ‘central teams’ like data/analytics or platform teams who are working cross functionally with folks across the organization. These teams often have ‘requestors’ of their time and expertise. It allows for better visibility into work and timelines, and also provides a structured system to ask for help or request reprioritization of work which hopefully leads to better visibility and trust between ‘central’ teams and ‘product’ teams.
Every company is different and each team may have different norms, but having a set of common principles, common tools and a shared language can improve visibility and reduce the switching costs for managers who oversee lots of projects and individual contributors moving between teams.
I spent 5 years working at Pocket Gems, a free to play mobile gaming company in product management where I helped design, develop, and manage most of our products.
Nail the ‘Core Loop’ first
I often get asked by friends about how they can incorporate gamification techniques into their products. Most of the time, folks are asking about these tactics prematurely before they have a ‘core loop‘ established and before they’ve reached product market fit.
The core loop is the set of actions that a user completes over and over again and this must be inherently satisfying and / or useful before applying gamification tactics.
Some examples of core loops:
Instagram: Take Picture, Post/Share/Tag picture, Review / Respond to likes and comments
Uber: Request ride, Take ride, Rate driver
Candy Crush: Play level (consume life), Complete level, Progress to next level, Request/Buy life
Once you’ve defined your core loop and this is already inherently satisfying (or provides utility) to your users, then tactics from free to play gaming can be very helpful in improving core metrics such as retention and monetization which ultimately drive improved LTV.
Understand user goals and motivation
When designing products always start with the user goals (short, medium and long term goals) and design the meta-experience around these goals. Once you understand user goals (and ideally map them to business goals) you can then design a set of tactics to help incentivize behaviors that help users achieve these goals.
Here are a few principles of player motivations in games that can also be applied to lots of other products:
Purpose: All great games have a meta-objective (e.g. Save Princess Peach in every Mario game) that players can easily understand. This gives players purpose, and these principles also apply to utility products where purpose is already clear and does not need to be manufactured.
Progression -> Completion: People enjoy the feeling of progression. The simple act of completing a level, or filling up a progression bar is very satisfying to many players and is a very tangible feeling of making progress towards a meta objective.
Mastery: People like improving at the core action in any skill based game. It’s important to communicate to players explicitly when they reach different mastery tiers as these are typically moments of great satisfaction.
Status / Peacocking: People like to show off their status to their community – I’m a VIP or important in some way and there are lots of examples of this both online and offline. Some examples include – Yelp Elite, Instagram Verified, League of Legends Platinum and Rank/Awards on military uniforms.
Expression / Creativity: People like to create and to express themselves with easy to understand constraints. Lego or Minecraft are both great examples of having some constraints but also allowing users to be incredibly creative within those constraints.
Collection: People like to collect things and we’ve been doing it for a very long time – coins, stamps, etc. They like to be able to see what they have collected and admire it, as well as identify what is missing and know how to find it. Loot drop mechanics combined with collection can be very powerful. A game like Hearthstone does this very well.
Not all of these principles or motivations apply to every player, and many of the best games pick a few and execute them very well vs. trying to be all things to all players.
Apply Gamification Tactics
There are a number of effective tactics in gaming that appeal to some of the player motivations described above.
Levels: Even a simple leveling up system allow us to hit a lot of player motivations – Progression, Mastery, and Status. It’s a relatively cheap way to reward behaviors in your product and incentivize continued engagement in the core loop.
Ranks / Tiers: Ranks are quite useful to differentiate between players and allow them to also communicate to others that they have a higher status (either earned or purchased) in their community. In League of Legends, players rank up by playing competitive matches and it’s used to both signal skill as well as find other players with similar skill levels. This can be applied to users outside of gaming with ‘VIP’ Tiers or ‘Elite’ Tiers for customers who are either highly engaged or high spenders.
Rarity: Collectors, Expressionists and Status seekers all enjoy finding items that are exclusive and rare. When combined with randomness this can be a very powerful mechanic. Some of the most successful free to play games like Hearthstone allow rare items to be both earned through skill, purchased (usually through loot drops), or crafted (usually very expensive).
Randomness (loot drops): Packs or Boxes which have an unknown set of rewards are very appealing to players. Sometimes just the act of opening these packs as just as satisfying as the rewards. You can integrate mystery / loot drops into your products by running a mystery sale for example where players need to open a box to reveal their custom offer.
Quests: Quests are one of the most useful tools in free to play games to incentivize user behavior. They allow us to guide the user in a specific direction for a clear reward. Quests are quite easily applied to lots of products outside of games – e.g. 3 blog posts in 3 weeks for WordPress.com for $10 of credit towards your next purchase or 10 rides in your first month for Peloton for a badge displayed on your profile.
Badges: Badges are a very quick and easy way to reward ‘good behavior’ from players. In the example below from Peloton, you get badges for beating a record, cycling with a friend, or working out 10 days in a row. I like to look at user behaviors that result in improved retention (or another metric) and then create rewards for those behaviors – badges are one way to do that.
Gating: Gating prevents users from accessing parts of your product until they have completed certain tasks. Level gating or item gating are a simple way to do this in games. For example, in Links Awakening, you can’t access any of the water areas of the map until you’ve found the flippers which allow you to swim. You could apply this tactics to many complex products where users need to have complexity exposed to them gradually.
I hope that folks find this useful – it’s not meant to be a playbook but talk about some of the principles and tactics that we use in games. Remember none of this is a substitute for having a product which is inherently satisfying or useful at its core but act as a multiplier instead.
As a manager or manager of managers of product development teams, it can be hard to focus on the right things and to make sure that you’re making progress on your ever growing list.
To help others overcome the same challenges, I am sharing a few of my personal frameworks that have helped me focus better and be more productive over my career:
1. Understand Product and Team Health
I wrote a separate post about this here but one of the most important things you can do when managing lots of products/teams is to understand the health of both the products and the corresponding teams. I do this by asking the following three questions and tracking this over time.
What do the metrics say? Metrics are impartial measures of how the product is performing on an absolute basis and trending. Having valid, high quality data sources is essential.
What does the team say? Most of your insight will be from the team lead, but make sure and also talk to team members from time to time so you can further validate (or invalidate) the insight from the lead.
What do our customers say? Talk to customers, talk to customer support, get structured data on customer pain points.
Combining the insight from these three sources has helped me improve judgement around what we should build and also help with designing better teams.
2. Segment your work
I segment all of my work into three buckets:
(10-20%) Set of things that only I can do (or want to do) myself
(60-70%) Set of things I can structure and review
(10-20%) Set of things that need zero oversight or someone else can do better
This allows me to spend time on the areas that I can have the most impact while making sure that I don’t drop the ball on all the jobs that need to be done by the organization.
Over time, if your objective is to make yourself redundant you should aim to move more and more tasks from category 2 to category 3. This is also a good sign of a team that both well assembled and performing well.
3. Track your time
Each quarter I write up my personal goals (Primary focus, Secondary focus, Observing) and share them with folks I work with very closely.
As part of this exercise, I reflect back on the previous quarter and break down my allocation of time and highlight anything in my list of goals that did not get done.
I then take all the tasks that I don’t think should be on my plate going forward (not the right priority, or someone can do better) and plan to transfer them to someone else for the next quarter as part of my personal planning process.
This has helped me be more deliberate and focus on the things that matter.
4. Get buy in for projects
People are the most important asset in any product development organization and high performers do not like to be told what to work on. One of the most important things that managers of product development teams have to do is get buy in from their teams on the projects they work on.
In the ideal situation a specific job to be done matches both the interest of a team/person and their capabilities. In other situations you’ll need to get buy in from teams to take on projects, and the best outcomes are always situations the team is motivated to work on the project (ideally it’s even their idea).
Depending on the person or team and their preferences, it’s important to phrase the project in the right terms:
Do it for the Company: This project the most impactful thing you can do for the company’s growth – logic and long term thinking.
Do it for your Team: This is the most impactful thing you can do for your peers or your team – community and selflessness.
Do it for Yourself – This is the most impactful thing you can do for your development/career – drive and growth.
Do it for Me: This is something I need you to do for me – strength of the personal relationship. This line should be used sparingly, because it can be relationship damaging and/or selfish.
These are a small subset of tools that I’ve found personally helpful as I’ve worked with product development teams over the last decade and hope you do as well!
I get asked frequently for advice from folks who are looking to get into product management and often send them slightly customized versions of the same thing. I decided to write something a little more comprehensive and share it broadly.
There are a few phases of work for folks looking to get into product management:
Start by learning about product management and what product managers do
Figure out where you want to work and make a list of companies that are exciting to you
Prepare for your PM interviews, and learn how you’ll be evaluated
1. Learn about product management
Product management is different from company to company. It’s worth learning about the different perspectives of product people at different companies, and here is a short selection:
An important part of the process is generating a list of companies you may want to work at by evaluating company size, quality of mentors, your connection to the product etc. Product management varies significantly by product, vertical (ecommerce vs. autonomous car PMs do different things) and individual company so it’s useful to spend time upfront here.
I recommend going somewhere where you think you’ll get good mentorship from people who are both experienced and very strong product managers. I also recommend joining a company which is growing, as a lot of opportunities can arise from growth.
Companies like Google and Facebook have very well respected product management practices, but it can be difficult to get an interview or get through their process without prior product management experience (unless you are earlier in your career where they have great rotational Associate Product Manager programs).
If you want to learn how to run a product development process I suggest reading agile product management which can be a bit dogmatic and dry, but it’s useful to know these foundational elements
Practice questions on the PM interview – it autogenerates a bunch of questions and you can go through them
Analyze products: Spend time breaking down products you like/don’t like – most ‘product people’ naturally do this, and enjoy this type of exercise. I like to break down my analysis into 1) Why does this product exist, what user need is it solving? 2) What do I like about the product? 3) What would I change and how would I change it?
Learn how you’ll be evaluated: Companies hire somewhat differently so make sure that you ask your recruiter or hiring manager about how you’ll be evaluated as part of the interview process. Here are a few dimensions from my experience that I’ve used, and seen used in the past.
My Interview Criteria: There are a few key skills that, I believe, PMs need to be successful and I use them to assess product management candidates. It’s important to have at least one area where you feel like you are excellent and can get that across during the interview process.
Analytical Ability: Run AB Tests, interpret metrics, data informed decisions
Product Sense: System design, uX design
Leadership: Inspire, influence, build loyalty, have empathy
Project management: Prioritize, get things done, make tradeoffs, unblock
Technical ability: Ask the right questions, build trust/respect
Google Interview Criteria:
Product Design: User experience and design
Analytical ability: Fluency with numbers, product metrics
Technical ability: System design, algorithms – earn respect from engineers
Strategy: Business turnaround, go to market
Culture: Googliness, kindness, leadership
Facebook Interview Criteria:
Leadership and Drive: Influence, Self starter, influence teams
Execution: Goals, metrics, prioritization, process
Product Sense: Design, understanding users
Engineering fit interview: Not a technical one like Google, more of a fit interview
Being a product manager is fun, challenging and a great fit for people who like to make things, and like making things in a better way.
Best of luck in your journey and thanks for reading!
I love using tools to make myself more productive and let fewer things fall through the cracks. There are so many great (free) tools available and here are a few of the ones that have helped me the most:
Calendly:Scheduling is one of the biggest time sinks for me. Calendly allows me to share my availability (in time slots that I define) and allow people to schedule time with me without the back and forth usually required. It usually saves me 3-5 emails per scheduled call and I like it better than using virtual assistants like Clara or Byron ($200 per month each). I use the free version which I imagine would fit most people’s needs.
Streak: If you manage any kind of pipeline (sales, investments, recruiting) and use gmail, then I highly recommend Streak. I’ve used it to track potential investments, investors and for recruiting. Streak allows you to have a CRM in your inbox and also scales well to multiple users. It allows me to stay organized, have a record of interactions, and make sure that I don’t let to-dos drop. I use the free version as well, but it costs $50 per month if you’re using it with multiple people or need API access.
Gmail canned responses: I realized that I was very frequently writing the same set of emails over and over again: 1) Scheduling time 2) Making a connection 3) Product information 4) Passing on an investment. I use the Gmail canned response feature to add in the re-used content in addition to the personalized note that I send.