Jenny Wanger

Category: Articles

  • Why you Should Treat Your Resume as Your Professional Product

    Why you Should Treat Your Resume as Your Professional Product

    This article was originally posted on Mind the Product on February 20, 2020.

    To help hiring managers and recruiters, like myself, decide whether or not to interview you, it can be a great exercise to treat your resume like a professional product. Here I’ll share some useful pointers on how to do just that.

    Having reviewed hundreds of product managers’ resumes in the last year I’m sure I’ll have overlooked some fantastic candidates, simply because their CVs didn’t shine. Building on some of the other excellent career-as-a-product posts and talks out there, let’s do a deep-dive into your resume.

    Consider this article a requirements document: it’s structured into several user stories from the perspective of a hiring manager, for a product manager role. I’ve pulled in examples from real product managers’ resumes to help you think about how you might improve your own.

    Use this article as a guide to polish your resume and improve your job-hunting prospects. Ultimately, your resume should itself signal that you have the skills required to be a successful product manager on any team.

    This advice is designed to apply equally well to those looking to break into product management as well as those who are already experienced in it. If you’re

    • an experienced product manager, I’d expect to see strong examples of your work in your resume
    • looking to break into product, I’d expect to see your non-product management work explained in product-driven language

    And in both cases, no matter what, keep in mind that your resume is just one part of your job application. You will, of course, often need to take multiple steps to land that interview.

    Storytelling

    As a hiring manager, I want to hire great storytellers, so the team can work towards a unified vision.  

    Product managers need to be expert storytellers, and a resume is simply your story in bullet-point format. It needs to explain your journey into and through product management, as well as the evolution of your products.

    If you’re looking to move into product, your resume needs to explain how your past experience is relevant for work as a product manager. Think of your previous roles as prototypes for a product management role – you might not have had all the features of a full product management role, but you had some of them. Highlight the relevant features of your previous roles.

    The following is how one product manager describes their current role on their resume:

    Leading a team of 20 people (analysts, developers, QA) developing one internal tool and integrating another external tool used by 800 agents on a daily basis.

    Note for this example that the applicant just tells us what they did in a very literal sense. I could use this same sentence for a product, scrum master, or engineering manager role. In addition, “leading” in product management can be very vague. They could improve their resume quite a bit by being more specific:

    Running ceremonies, identifying feature gaps, and defining requirements for a 20-person cross-functional scrum team building an internal tool to improve call center operations.

    I can now understand a lot more about the product and role, without taking up more space on the page. Take a minute to look at each position on your resume and check that there is one bullet point that describes the role you had and the product you were working on.

    Data-Driven

    As a hiring manager, I want to hire people focused on gathering good data, so we can craft good hypotheses about what to build next.

    Every product manager needs to be data-driven. This includes qualitative and quantitative data. Use your resume to show how you’ve made decisions using data. This could include different tests you’ve run, quantitative analyses that have helped you make a better choice, or user research that has changed the course of your roadmap.

    One product manager described their decision-making as follows:

    Engaged client executives to assess strategic business needs and challenges, and translate business strategy into human capital opportunities with business impact.

    This excerpt tells us at a basic level what the story was, but it could also use a dose of specificity. And any time you talk about strategy or roadmaps is a great chance to highlight your data skills:

    Ran an ROI analysis and presented results to client executives, leading to a redefined strategy for our employee hiring and training programs.

    See how adding a layer of data (and detail) enhances the story? If every bullet on your resume looks like this, it can highlight a wide range of relevant experiences, frameworks you’ve used, and the tools you’ve encountered. With this I can find reasons to interview you because I have more confidence that you have the right experience for what’s next.

    Impact-Oriented

    As a hiring manager, I want to hire people who measure their impact, so we can make sure we’re building the right things for our customers. 

    Great product managers never stop measuring and communicating the impact of their decisions. Use your resume to highlight your successes and failures (aka learnings) through the performance of your product.

    One thing to note: it’s far more useful here to talk in relative rather than absolute terms. Without context, increasing revenue by $1 million per year can either be revolutionary or quotidian. On the other hand, increasing revenue by 10% clearly shows the scale of your contributions.

    Use detail and clear KPIs like this product manager to demonstrate these skills:

    Introduced KPIs and evaluated success; depreciated underperforming features which improved engagement by 34%.

    Note how good use of metrics reinforces the other two user stories – this bullet point is a mini-story where data led to a decision. The one thing that could improve this even further would be to add why removing the features led to increased engagement.

    If you’re at a company that doesn’t measure the impact of your products or if you can’t share your KPIs for some other reason, talk about what you did to push your org’s culture in a data-driven direction. Did you install analytics or build dashboards? Tell us about it.

    Iterate and Refine

    Combine these three pieces together to make your whole resume shine. In combination, you have data-led stories which demonstrate the impact you’ve had on the teams you work with. This provides the hiring manager with a strong understanding of what they might be able to expect from you if they were to bring you on board.

    Like any product, your resume should be a living document. Seek lots of feedback from as many sources as possible to make it better and better. While these concepts sound straightforward and simple, you’d be amazed at how many applicants have generic resumes which don’t tell me enough about them to move forward.

    Thank you so much to the product managers and aspiring product managers who gave me permission to use their content for this article. Best of luck on your next job hunt, wherever it may take you!

  • Silence the Squeaky Wheel through Feature Prioritization

    Silence the Squeaky Wheel through Feature Prioritization

    UPDATE: I revisited this topic in 2025 and have done a 180. Read all about it: Stop scoring everything: how to prioritize with strategy

    This article was originally posted on Mind the Product on February 7, 2019. It is based on a talk I gave at INDUSTRY in 2018.

    Prioritization is challenging and stressful. Sometimes it’s because of micro-prioritization such as bug triage and moving one small fix in front of another. Other times it comes from the macro level: deciding to target new user growth versus lifetime value; spending time on user research or analytics; handling your manager’s feature request versus the tech debt the engineers beg for.

    And then there’s the squeaky wheel. This can be a person or a topic, but it’s always something where I feel like an all-caps message came through: “THIS IS A BIG DEAL!! FIX IT!” Given that I want to be good at my job, please stakeholders, and solve problems, I’m always tempted to rush to make things right. I tell myself that if I just knock this one out they’ll go away and I can return to my regularly scheduled programming.

    This happened to me recently. We’ve been reworking our home page and in the process found the search bar had a bug – a strange loading effect where it flashes gray for a millisecond. The product team decided to ship with this bug and we put it in our backlog to be fixed once we took care of a few other stories. An engineer on another team saw the bug and was concerned about it, starting a conversation on Slack that escalated to the point where I had multiple people messaging me about when we were going to get this fixed.

    Nobody likes shipping imperfect products, but at the same time we all know that we can’t hold off to wait for perfection. I had a prioritization challenge in front of me – do I change our backlog and move this story up or stick with the original plan?

    Squeaky wheels get more complicated with status. I have been in situations where a C-level executive said, “we need to build something like THIS!” and laid out feature requirements. However we had a list of features that had already been validated by user research. Do we move this idea up and begin to research it, or go with what we know?

    The best way to solve for squeaky wheel syndrome is to have a prioritization process in place ahead of time. A system removes the personal from these conversations and turns it into a conversation about the values you’ve established as a team. Because it’s systematized, there are more consistent inputs and outputs which mean that the emotions anyone is feeling that day are removed from the equation.

    So that bug on our home screen? I was able to lay out that our system defines issues in terms of severity. This bug has a certain severity score and should get pulled in next sprint, but we don’t interrupt work in progress for that level. Given that we already had those standards established, I was able to quiet everyone down and get back to work. They were able to trust the system and were glad that I had heard them and had a plan in place.

    What about the CEO, however? Can a prioritization process help you through larger feature development and tactics? Yes, if you have a system in place. But the only way your system will work is if your leadership believes in it as much as you do.

    Pick a Method, any Method

    When it comes to building out a prioritization system, it doesn’t matter which you choose. RICE, Kano, MoSCoW (who came up with that capitalization?), or any of the other ones out there – pick one you like and run with it.

    The only thing that really matters is gaining support for your prioritization system. If everyone has agreed on what prioritization model your team is using, they became part of the decision to de-prioritize their idea. And if they still don’t like the outcome and want to be a squeaky wheel?  It shifts the conversation from “Product refuses build my thing” to “The system says that my idea isn’t the most important thing to work on right now”. Any debates become about whether the process is working or not instead of a personal conflict between product and the requestor.

    Step 1: Define Prioritization Goals

    We began by talking at a high level about our goals as an organization. All product teams did this at the same time, and we all made sure our executive stakeholders and leadership were in the room. Once we felt like everyone had the same sense of our guiding principles, I asked our stakeholders to list out all the goals for my product team. I said yes to every goal they mentioned. The list was a little long.

    So I asked: “What do we do if we have an idea that we think might improve customer satisfaction and retention, but will decrease our margins? Should that win out over an idea that might increase total revenue but could cause more calls to customer support?” Our extended leadership team hadn’t gone into deep discussions about our product KPIs before, so this was a good opportunity to help them learn more about the product process. Once we had a short list of goals in hand, we wrapped up for the day.

    Step 2: Customize a Framework

    When the team reconvened, it was time to talk about frameworks. We chose a RICE model because it leads to numeric scores for each item on the list and matched well with the objectives we had chosen for the product. We didn’t spend too much time choosing the framework.

    We spent a tremendous amount of time customizing the framework. If you use something off the shelf, it’s too easy to say “well, that worked for so-and-so, but it isn’t going to work for us”. You create room for excuses. When you customize the framework to fit your needs, everyone has shared ownership.

    We thought about customization in several ways – the first was categories. Instead of Reach, we talked about the number of customers who would see this per month. Impact became two things – reduction in customer support calls and increase in average order value. Our definitions allowed the model to use the language we use when talking about our business.

    The second way we customized was with the definitions. Within our framework we defined that a big impact might be so many thousand extra customers taking an action, while a small impact might be defined in a different way. Each category had clearly outlined definitions of small, medium, and large to make sure we were having an objective conversation.

    Our final customizations were in how we weighted each category. Instead of everything being equal, we decided to weight growth more heavily than cost savings. This allowed us to make sure we were doing more of the things that would help us succeed long term as a company, without completely ignoring the reality that we can’t just be a company that spends forever.

    Step 3: Prioritize Ideas

    Only now, once we had talked about goals, chosen a framework, and customized it, did we begin to put ideas into the model. I got to say yes to every idea that came my way, whether I thought it was good for our business or not. We placed them in the model, filled out the framework, and got our scores. A little final tweaking allowed us to make sure everyone felt comfortable with the results.

    The prioritization system switched our conversation. No longer was product responsible for prioritizing in a vacuum. The entire company had a voice in prioritization, and the model helped us understand whether we were making good choices or not. Now when someone comes to me with an idea I always get to say “Yes, let’s add it to our model!” and the data helps us say yes or no as a team.

    What if someone disagrees anyway? They’re upset because their item is still at the bottom of the list, and that’s understandable. At that point your response can be: “Okay, what do you think needs to be adjusted in the model? Do we need to weight things differently, do we need new categorizations?” It gives us an opportunity to talk about the goals for the product and company overall, and we decide as a team what the best next steps are.

  • End Squeaky Wheel Syndrome by Changing How You Prioritize

    End Squeaky Wheel Syndrome by Changing How You Prioritize

    Many people decide what to build next using the “squeaky wheel” prioritization method, where the person screaming the loudest gets their way. This session will not tell you the one true way to prioritize what you do next. Instead, we will focus on the basic principles of prioritization: customer needs, business outcomes, and available resources. Through some interactive exercises, we’ll look at a few of the most popular prioritization frameworks and examples of how they’re used in companies around the globe.

    “She talked about empathy. That allows us to say ‘we wanted to do that too, but we can’t.’ It puts you in a position where you’re not the only one saying ‘no.’ It turns it from an argument into a more strategic way to get to a goal. We all end up on the same side instead of being the gatekeeper. When something new comes up, we can ask, ‘Is it more important?’”

    TAKEAWAYS

    • We’re all bound by the space-time continuum. We only have 24 hours in a day, we can’t be in two places at once, and we can only work on one thing at a time.
    • Determine what people actually want when they come to you (“Why aren’t you fixing my problem?”). Have empathy for them.
    • We have this magic ability to help our customers, partners, and co-workers solve their problems, but we can’t solve them all at once. This is why prioritization matters.
    • We all already use a prioritization system. Most are reactive (squeaky wheels). “If you take what the world throws at you, that puts you up on your heels.”
    • Have a proactive system that allows you to be aggressive toward your goals and make deliberate choices. You’ll have better outcomes.
    • The prioritization system you choose doesn’t matter. Buy-in matters. This gives people a voice in your model. They’re not leading it — just providing insight.

    Which of these is leading your team?

    • Resources — Funding, hiring, and other internal needs.
    • Strategic alignment — There’s an overall goal, and teams have their own.
    • Business outcomes — Revenue targets. Increase conversion. KPI-driven.
    • Customer needs — All we want to do is get users.

    Bottom Line

    1. Know your goals
    2. Present your options
    3. Customize together
    4. Prioritize together

    “I’ve attempted to introduce prioritization in the past and had mixed success. Most recently, we’ve come to a more consistent way of coming to an understanding of company goals and let that prioritize things. It works well. We have a very solid reason that’s based on company goals as to why we can’t do their thing today. It definitely reduces the stress of having to tell people ‘no.’ In the past, when I’ve tried this and it hasn’t worked, we came up with the strategy internally and didn’t get a good job getting buy-in. This new company alignment has been really good and mapped closely to what she talked about.”

    This talk was delivered at INDUSTRY hosted by the Product Collective in October of 2018. Many thanks to the conference for the takeaways and audience quotes.

  • Privacy in the Age of Digital Sharing

    Privacy in the Age of Digital Sharing

    I’ll be sharing research on five privacy personas that I’ve developed around attitudes towards privacy. You’ll gain a better understanding of your own attitude towards putting your data up online and have the tools to assess the attitudes of the people you’re designing for. We’ll take a look at a few key design patterns that companies have used to target different kinds of users and what they do that works well.

    We’ve entered the sharing age—the mobile revolution allows us to share our cars, homes, and pet photos with ease. We trust companies to keep our most sensitive information secret, while at the same time posting personal information publicly. Boundaries between our digital and analog identities are dissolving. As designers, we make more and more products that collect user data and it’s time for us to have serious conversations about digital privacy.

    At the same time, just because people want to share their information with us doesn’t mean we should run wild. As designers, we have the responsibility to take care of our users and treat them with respect and integrity, and that includes their data. We’ll finish the presentation with a discussion of what kind of code of conduct we need to adopt as designers, and how to factor that into our day-to-day work.

    Sketchnote summarizing the privacy personas

    Many thanks to Veronica Erb for the sketchnote!

    Presented at IA Summit 2018, Chicago, IL.

  • The UX of DX: user testing in the invisible world of APIs

    The UX of DX: user testing in the invisible world of APIs

    If you want to cultivate loyal developers, you should treat the products you create for them the same you would any other user-facing offering. And that, according to Jenny Wanger in her DevRelCon London 2017 talk, means applying a UX design focus to your APIs. In this session, Jenny outlines some strategies for making this lateral leap, and suggests some important questions you should be asking.

    We do usability testing all the time when we’re building apps and sites with interfaces, but a good DevX team helps product managers and designers do the exact same type of testing with their APIs and SDKs. We’ll cover testing strategies and best practices when your user is a developer.

     

    Presented at DevRelCon London, December 2017.

  • The Rise of the Privacy-Conscious Consumer

    The Rise of the Privacy-Conscious Consumer

    When Elon Musk hopped on the #deleteFacebook bandwagon, it became clear that public perception of internet privacy is changing in light of Facebook’s recent issues with Cambridge Analytica. As a researcher on attitudes toward digital privacy and an advocate for user-friendly privacy practices, I’m excited by these developments. I’ve been following the conversation and have started seeing evidence of a long-term shift in consumer attitudes towards increased security and control. Welcome to the era of the privacy-conscious consumer.

    Reporting has focused on social media, but I doubt it will stay in that category. What makes the information Facebook collects on you different from the information Yelp gathers when you submit a review, or all the information Amazon has on each of its customers? The time of reckoning has come, and the era of indiscriminate data collection is ending. Whether you work for a social media company or any other digital organization, it’s time to get ahead of the conversation on digital privacy by doing more to protect your customers.

    The Privacy 2×2

    An individual’s feelings about sharing any information with a company at a given moment in time will always fall along two axes: how much they value the right to anonymity (versus the importance of transparency); and how much they trust the company’s ability and willingness to keep their data private. I developed this framework through a wide number of interviews with individuals, consultations with privacy experts, and combing through a wide amount of secondary research.

    The 2x2 of consumer privacy

    On the opposite end from anonymity lies the desire for transparency. While many people see the power that transparency and openness can have, they believe in the right to protect themselves and others through privacy. They see the online abuse of marginalized groups and the damage implicit bias does in hiring as good examples of why anonymity matters. Of course, whether you value transparency or anonymity can vary from topic to topic: some people are happy to talk in great detail about their professional lives, but don’t want to share information about their families. Others will share data in text format – for example, sharing information on where they’re traveling – but refuse to share photographic data, such as photos from that vacation.

    Trust vs Skepticism

    The other axis has to do with the consumer’s level of trust towards that company. This is driven by two questions: Does this company have my best interests at heart? and Does this company have the ability to keep my data safe?

    Tweet: If you would pay for Facebook, how much?

    In terms of best interests, this has to do with the perceived motives of the company. The biggest impact of the Cambridge Analytica revelations has been that people no longer believe Facebook is dedicated to its mission of giving “people the power to build community and bring the world closer together.” More users believe they are motivated by profit, rather than by idealism. Conversations have shifted from “Facebook allows me to share what I want and pays for that by advertising to me” to “Facebook sells my personal data.”

    People replying to the question about paying for Facebook

    The other side of trust has to do with the company’s technical capabilities: can the company protect my data against the bad actors across the internet who want to steal it? Equifax’s recent data breach is a perfect example of this. While some might have trusted them, the breach demonstrated their inability to keep user data safe. Consumers are hesitant to share a credit card number, location, or anything else if they don’t trust the company’s information security.

    Down and to the Left

    No individual is forever fixed on either axis. My research has shown that people often start in the upper-right quadrant as “frequent sharers.” As they become more technically savvy or learn more about the risks of data sharing, they drift down and to the left, becoming more cautious and private.

    People are beginning to understand how easy it is for their data to be shared without their knowledge or consent. Many are asking questions about how to use technology to protect themselves. As individuals learn more about psychographics and the spread of fake news, they have a greater desire for privacy and control. In combination, this technical sophistication and increased level of concern will lead to fewer people wanting to share information of any type.

    Get Ahead of the Trends

    Many companies’ business models rely on some form of data sharing – whether through placing advertisements or installing cookies to help provide a more seamless browsing experience. As we see more privacy-conscious consumers, these companies’ business models will be challenged.

    Consumers will not change how they feel about privacy and anonymity based on your app – that’s about their own personal attitudes and beliefs. But they will change how they feel about sharing with different companies. The most important thing companies can do is get ahead of the shift by being trustworthy. This includes supporting a privacy bill of rights. Europe’s GDPR privacy law forces companies to take the first step towards this, and it is probably only a matter of time before similar regulation comes to the US.

    Designing products with built-in privacy isn’t only about regulation; it also happens to be the right thing to do. It establishes greater trust because it allows you to take the moral high ground and demonstrate that you are actually trustworthy: you are giving your customers control of their own data and holding yourself accountable to taking care of them. Most people’s attitudes towards privacy and transparency are fixed, but how they feel about you as a company is under your control.

     

    Featured image photo credit: @iamconnorrm 

  • How Mature Are You? A Developer Experience API Maturity Model

    How Mature Are You? A Developer Experience API Maturity Model

    This API maturity model will help you answer a few key questions: How confident are you that your developer experience matches the expectations of your customers? How can you judge if you’re providing an adequate or best-in-class experience? What about your competition? How do you compare?

    We had the same questions at Arity, and so developed a maturity model for API programs. Based on a year of user testing with developers, this model covers categories such as support and documentation.

    This maturity model helps you focus your time and effort on the areas that will provide the greatest value for your customers. It’s a way to distill all the elements of the developer experience into an easily consumable document to give to stakeholders, helping you explain why the things you do as a manager of the developer community translate to increased sales for your organization.

    We’ll go through the model together so you can score your company’s program. You’ll leave the session with a score and roadmap of how this can help you influence your stakeholders.

    Session materials:

    Presented at API Strategy and Practice 2018, Portland, OR

  • Usability testing and APIs

    Usability testing and APIs

    Lucy Carey and Jenny sit down to talk about her upcoming presentation at DevRelCon in London covering the UX of APIs and how to design better developer tools through usability testing.

    Read more

    Article on Devrel.io

  • The best Developer Experience KPIs

    The best Developer Experience KPIs

    I spoke with various Developer Experience product managers about how they measure success–what KPIs they use and why. It became apparent that the responsibilities of each DX team shaped the KPIs they use. There are four potential domains that developer experience teams are responsible for, with different KPIs for each domain.

    The Four Domains
    Get people to the developer portalConvert people on the developer portal to customersRetain developersOperate the API gateway or program
    Primary KPIsIncreasing quality people landing on the dev portalConversion rateRetention rateUptime and latency
    Leading Indicators
    • Site analytics
    • Time on site
    • Click-thru rates
    • Bounce rates
    • Usability testing and developer satisfaction
    • Time to first hello world
    • Developer satisfaction
    • Adoption and use of tools
    • Deflected queries
    • Pull requests to open source projects

    Of the four areas, everyone I spoke with was responsible for the middle two sections. Depending on the company, the team also had one of the responsibilities on the ends, but no team I spoke with was responsible for all four domains. While not everyone tracked the same KPIs, I will highlight the ones that I found to be the best fit. When discussing the KPIs below, I define them as primary KPIs and leading indicators. I do this because each domain has one KPI that is the ultimate measure of success. Because the KPI can be hard to measure or slow to gather, many teams use leading indicators as secondary metrics to support their work.

    Get people to the developer portal

    Not every DX team is responsible for marketing to developers, but plenty of them have responsibility for developer evangelism. As Cristiano Betta explained to me, if you’re responsible for traffic to your website, then you’re really responsible for getting potential customers to the point of sale. Given that, your KPI should be focused on increasing the number of quality visitors that arrive on your site. This requires defining your target audience, figuring out how to target them, and serving the right content at the right time. A good analytics program is critical at this point.

    Convert people on the developer portal to customers

    Once you have people on your site, it’s time to convert them and, just as in ecommerce, your main KPI becomes your conversion rate. The KPI is easy to understand but hard to break down, and so leading indicators are especially helpful here. Bandwidth uses usability testing, time to first hello world, and site analytics together as leading indicators. The combination of qualitative and quantitative measures here seems especially helpful.

    Retain developers

    Once you’ve got your customers, it’s time to retain them. As with the conversion piece, all the product managers I spoke with talked about this domain in one way or another. Some phrased it as “supporting the developer community” or “working with customers”, but it comes back to retention. The main retention rate is straightforward enough, but leading indicators are less concrete. Possible metrics include adoption and use of tools, an increase in volume of API calls, and pull requests on open source projects. Returning to the ecommerce analogy, it’s equivalent to size of shopping cart.

    Operate the API gateway or program

    The least common responsibility of a DX team is actually managing the operations of their developer program. In one case the product manager explicitly told me that this is a DevOps role, and it was not the primary focus of any DX team I spoke to. However, for those who need to operate the program as a part of their responsibilities, standard DevOps metrics apply: uptime, latency, etc. The general consensus was that the more mature the company, the less likely this role would be part of the DX responsibilities.

    Developer Satisfaction

    While each specific area has corresponding KPIs to match, the one piece that touches the whole spectrum is developer satisfaction. Given that it’s an emotional goal, it’s very hard to measure with anything concrete. Some use net promoter score, but that gets fuzzy—it’s hard to separate out satisfaction with your developer experience program versus the company overall. Slack creates a few leading indicators for developer satisfaction by keeping an eye on documentation quality and adoption of tools. They’re also great at the most important part of measuring satisfaction– listening and talking with their developer community, whether through online tools or events, which allows them to really capture the qualitative side of this metric. Others mentioned deflected questions—questions that get answered through a knowledge base or support flow without requiring a person to intervene to help the developer find resolution.

    Choosing your KPIs

    Defining your KPIs is an opportunity to define the scope of your team’s responsibilities. Take the time to connect across your organization to figure out who is taking care of your customers and at what point; once you know your responsibilities, the KPIs should follow.

     

    This post originally appeared on Pronovix on August 24, 2017.

  • Pokemon Go: One Year On

    Pokemon Go: One Year On

    A year ago I wrote an article about the explosion of Pokemon Go. According to ComScore, PoGo scored 28 million active daily users at its peak and has stabilized at five million. Niantic, the game maker, confirms this. The game rakes in about $2 million every day and at the time of writing sits at #7 top grossing game in the iTunes store. Given this, I wanted to revisit my original article and talk about how the game has evolved in the last year, and what lessons there are for us product managers.

    While I’ve been speaking to players intermittently since the game came out, Niantic hosted a 20,000-person event called Pokemon Go Fest in Chicago this July. Fans flew in from all over the world to connect and play together. While the press largely focused on the event’s failures (deserving of an article in itself), it was a wonderful opportunity for me to conduct some user research.

    A Mobile Game Designed to be Mobile

    Last year I wrote about how the key elements of this game are perfect for a mobile phone. You need to walk to different locations to catch Pokemon, and you hatch eggs by getting a certain number of kilometers logged. In some ways this hasn’t changed at all – hardcore players still have chat groups and meet up after work and on weekends, though they’re no longer going for casual “PokeWalks”- they’re now raiding and attacking gyms together to get more valuable Pokemon and points.

    Gameplay for more casual players has shifted to an interstitial behavior instead of a deliberate one. I met a Lyft driver this spring who explained that he pretty much just logs in once a day to get his login streak bonus. He said he was really waiting for the release of the Legendaries, a set of ultra-rare, powerful Pokemon, before he jumped back in for more than that. Another casual player I spoke with explained that he only plays when he’s walking from one spot to another, such as from the train to the office. He has one co-worker he occasionally plays with, so sometimes they’ll try to finish lunch early and go for a little walk, but it is no longer an activity that they go out of their way for.

    There are some elements of the mobile game that I didn’t predict well: winter was an issue for many northern players. The desire to attack a rival gym when it’s snowing outside is much weaker than when the sun is shining. Several people mentioned playing less often in the colder months and picking it up again once the weather turned.

    Visible Use

    Until the recent raid and Legendaries releases this July, visible use dropped substantially. Fewer players in general made gameplay less obvious, and the skill of players in the game has increased, so that they no longer need to shift their grip on their phone to catch Pokemon. It means you no longer see funny poses from people on the street.

    The latest release of raids and Legendaries has brought crowds of players back to the game in an obvious way. Raids are opportunities for PoGo trainers to team up together to attack a particularly powerful Pokemon; at the end you get the opportunity to catch that Pokemon and add it to your own fighting collection. The only way to catch Legendaries is with these mechanics, which has made the gyms with Legendary Pokemon very popular. These past two weeks we’ve seen crowds of people gathered outside these gyms, working together to fight for new creatures to add to the collection.

    Easily and Naturally Social

    Since writing the first article I’ve learned much more about the game’s more passionate players. One of the things you do within your first few days of playing Pokemon Go is pick your team, which in essence is just selecting the color blue, red, or yellow. You then battle other trainers to have possession of your local Pokemon Gyms, which are landmarks in the game, and you get points and street cred for every gym that your Pokemon defend.

    Attacking and defending gyms requires multiple people to team up, and it’s hard to do this by random chance. Therefore, to be a top PoGo player you need a group of people to play with, and these people are extremely loyal to their teams. They’ve got chat channels specific for their team and region. I spoke with a man from Orlando about why he founded one of these communities: “I was just getting so sick of the damn red team so I decided to do something about it.” His team’s dominance is a source of pride, as he told me about his ability as team leader to declare that the blue team is taking over a zip code and then seeing it happen. Of course, when I then asked him a question about which Pokemon are good to defeat a certain legendary in a gym, he looked down his nose at me: “Oh, you’re one of those casual players.”

    The social elements of the game still exist for the casual players, people will talk to each other if they see someone playing the game, but it’s more muted than before. But the biggest change in PoGo dynamics is the emergence of in-person events. July’s Pokemon Go fest in Chicago – 20,000 people from around playing Pokemon Go together – proved how fundamental the social element is to this game.

    Nobody Cares About AR…Still

    The AR feature of Pokemon Go, despite getting tons of press, is still only used if you can get a special Pokemon photo in a very unique place. The vast majority of screenshots shared in the chat communities and Facebook groups don’t use AR; as a product manager, I wonder why they don’t kill the feature entirely. Perhaps those occasional funny photos of a Pikachu boarding a train are a good form of social advertising, though I even doubt that.

    Lessons Learned

    Pokemon Go has seen continued success not only because of features added to the game, but because of the features that players have added around the ecosystem, such as in-person teams and raids, chat channels, blogs, YouTube stars, and other forms of community. It no longer has the mass appeal that created the original buzz; Niantic, to its credit, has encouraged these community features while focusing development time on increasing its appeal to the casual players. Ultimately, there still isn’t another game like this on the market, and while the Nintendo franchise contributed to the initial adoption of the game, much of the continued attention is due to great game design and creativity on behalf of its makers.

    This post originally appeared on Mind the Product.