AUTHOR NOTE

This was originally posted on my WordPress blog, which I have deleted after migrating the blog's posts to this website in November 2025. Differences from the original are minimal and include: grammatical improvements throughout the post, adjusting the text formatting, adding in paragraphs to reduce the wall of text, and linking to Jen's bsky profile instead of Xitter.

If you’ve known me for longer than a week, you’ve heard me talk about my role as a user advocate and how important it is for a company to invest in someone like me. One thing I specialize in is translating “user” to a variety of audiences, something my flavor of autism lets me do by masking into a social group. I’ve always considered myself a social butterfly, easily fitting into every group, making it possible to understand how those different groups communicated and engaged with each other. This superpower thrives in autistic women and is one of the things that often sets them apart from their male counterparts.

It’s something I unconsciously do when I am introduced to a new group; I absorb how they like to be spoken to by just interacting with and observing people. This makes me incredibly effective at explaining almost anything to a wide range of colleagues, and convince them to fold the feedback into a business decision. A lot of people may know what I’m describing as “social listening” when you account for what my experience is in, but I feel there’s another aspect to it when it’s a part of product decisions instead of marketing - it uses data to improve the product directly rather than determining social content.

There are two things I do when advocating for a product’s community, a) fight for a single user issue I truly believe needs to be adjusted for the betterment of the product, and b) build a story around complaints/feedback combined with user research to bring about product change. I’ve been successful with both over my career! I once escalated a single report I considered a decent accessibility issue - when using a screen reader on the browser’s themes page, it wasn’t entirely clear what the color was because it only read the theme’s marketing name. I explained to the accessibility champ that a blind person likely won’t know if “mango” meant the color or if there were a collection of mangoes on the screen, and crafted a great user story to help him go to bat with marketing to change the screen reader descriptions.

On the other side, I partnered with the User Research team at Microsoft to interview under-represented groups and identify pain points with technology, asking questions I designed based on what my community talked about, then drove the presentation of a user story with direct product feedback and related external research about tech in low-income areas to the entire Edge team (which inspired product change to help improve data sync issues).

There is a very fine line dividing when and how to use these processes; it’s a good combination of trusting your gut, sticking to your principles, and simple experience. It’s hard to tell you exactly which way path you should take because each situation is unique, but in general you want to start your time at a company with building around a collection of voices rather than a single report. Over time, you will learn to identify the single-user battles you want to fight for. Here’s how I have built user stories - and tips on what one can do - to present to my colleagues across a few role types I’ve worked with over my career.

You first need to understand how users speak. This is often quite different than how engineers, marketing, and product managers speak - users aren’t building a closed-source product and typically don’t know the technical terms of the features in the product. To them, what outsiders colloquially call something in your product is the feature name.

An excellent example I use is the browser’s omnibox. You have the general users, people who use a browser for every day things, who talk about the “address bar” because that’s what they’ve known for most of the existence of browsers. But you can also have the tech enthusiasts, like developers, bleeding tech users, or sysadmins, who will call tools and features by their technical names because they use those terms in their daily life, so you may hear them say “omnibox”. If you don’t understand the nomenclature that your community is using, you cannot translate that feedback to anyone, let alone leadership.

On that note, let me start with leadership audiences. Get to the point fast - you can craft a beautiful story, but if you don’t get through the key points quickly you will lose this audience. Touch on both the positives and negatives of the situation, highlight important data points that support your story, and bring it all together with an elevator pitch of what you believe should be done. The best part about utilizing user feedback in your story is that you have a cheat sheet! You can source your elevator pitch solution directly from your users. 👌🏻

Some users eloquently explain what they would rather see and it helps one see it from a product perspective - but remember to look at all the data so that you can tell the difference between what your users say and how they use your product. Using data to support your users’ voices will force you to look at the bigger picture and may help you see other, non-obvious solutions to offer to leadership, especially if what users are saying is counter to their behavior. As an early-in-career employee, I presented to leadership after convincing my manager (you know, my leader) that (their) leadership needed to hear what our users were saying. I often worked with the feature owners and engineers to support my story before I got in front of leadership.

Engineers and product managers can be spoken to essentially the same way in my experience, especially if they built the feature and know the ins and outs. This is why understanding what your users call product features is incredibly important in your role as a feedback owner or customer voice expert. I like arming myself with a ton of information when I approach an engineer or PM.

To ensure I know precisely what the user is saying before I go to my colleagues, I ask the user deep probing questions. If it’s a bug, I get as much information about when it started and the device info to help with slicing through released versions to find the change that broke. If it’s feedback, especially negative feedback and the user seems very willing to give more details, I probe into how they feel it could best work for them over an active conversation devoted to their user story. Having this conversation helps you have an intimate understanding of what the user wants, and when you have that plus the ability to translate that feedback into internal terms, it sets everyone up for success.

If there’s a lot to go over, be sure to have your raw data ready, but I find a lot of people really enjoy word clouds to sort verbatim data. It’s amazing how quickly you can throw together a PowerPoint deck for your story and include links to the raw data. When this is properly done, the product managers and engineers know what they can do to alleviate the concerns, and the user had an active hand in shaping the product. 👏🏻 It also builds a lot of trust between you, your teammates, and the community! This is how I tackle my colleagues, and I do this before tackling leadership - sometimes even before I go to my manager.

One of my favorite things is learning from engineers. I learned a lot about A/V technology in chromium browsers thanks to my time on the Microsoft Edge team - the media team built an internal browser page to help gather details needed for troubleshooting their issues. I escalated issues so often that they decided it would be more beneficial than the risk of exposing the data. Learning from the engineers is very valuable when figuring out how to translate internal terminology to a user. I verify with them when I offer public responses to ensure it makes sense to the engineers in addition to being digestible by the consumer. This way I know that what I translated is accurate, and I learned something new about a complicated piece of software. Win-win!

Marketing is an interesting one to cover because there’s a variety of marketing partners you may work with. Some you will want to talk to like leadership because they are; more often than not marketing leadership will be in the meetings along with product leadership so you’ll naturally end up treating them similarly. Always make sure that you have explanations for numbers you are presenting because the marketing leaders I have worked with dig much deeper into data than the engineers.

Now we have traditional marketing and product marketing. When I translate user feedback from a technical community to a traditional marketing manager who is new to tech, I often talk to them like I would a general consumer but also try to explain how users speak versus how we present the brand as a product. I had to learn how to not sound condescending in text when I do this, so that may be something you want to watch for in your own conversations. 😬 In my case, if I felt like I was being too robotic or flat in my response in text, I’d have a teammate look it over for peace of mind. “Hey, do I sound like a dick in this?” - a phrase I became comfortable asking.

Product marketing managers have been my best allies because many have come from unconventional backgrounds like myself - one of my favorites to work with at Microsoft was a sysadmin before he was a PMM for Commercial GTM. These conversations I had to flip a little - most are tech savvy but don’t know the audience well enough to understand how to market to them, and their responsibilities included doing user research to find new product directions. In these cases, I share feedback from the community to help support what they were digging into after doing competitive analysis on my own - this is an interesting way of influencing product decisions since PMMs often drive new features.

And then you have consumer and commercial product marketing. 🫠 In my experience, consumer product marketing managers in tech don’t think like regular tech users. They tend to make assumptions based on their predefined audience buckets. I have found that general consumers just don’t give a shit about the technology or what you are putting into the product; only your biggest fans care and those tend to be a more technically-inclined audience. When you approach these types of marketers with community feedback, I’ve found you need to have the product manager who owns the feature on your side for back up (like the themes example at the beginning of this post).

The commercial product marketing managers I’ve worked with have been my best partnerships as I look over my career. I think that’s largely because they understand the nuances that go into enterprises which are filled with not only technical people setting up the product but non-technical end users. They tend to understand that a lot of enterprises are stuck on older technology, so it’s easier to come to them without translating exact feedback from sysadmins too much. I have found that I need to treat some product marketing managers as if they were new feature owners, normally because they are new to either the company/product or simply aren’t waist deep in the community yet. I worked with product marketing managers for way too many things to actually list here, but I was the only customer voice expert for the Microsoft Edge team and I felt quite comfortable bringing up community concerns without fear of being dismissed.

I once asked Jen Gentleman, “How do you get people to listen to you with community feedback?” and she responded, “They just do.” This is when I realized that my relationships with my peers were going to be way more valuable than I expected and I needed to win over others. I’ve found that being passionate but humble, detailed yet brief, actively listening and learning when provided valid criticisms of your work, and coming with data to back you up will build up really solid professional relationships with your peers.

I was known on the Edge team for being a ball of positivity who would get shit done, a great teacher who made people immediately comfortable, and legitimately the heart and soul of the team. It takes work to do this but it’s very important if you want people in any role to listen to you, and I would say that building solid relationships with your colleagues needs to be a top priority when acting as a user advocate. Learning how to speak publicly can help you advocate for your users, making it easier to communicate their needs without faltering.

A lot of this is advice that I encourage people to seek from their mentors at work. Find a mentor who can educate you in these things, one who will also advocate for you, and you can flourish as a user advocate in any role. Remember to learn how your community speaks, understand and learn how each role at your company likes to be spoken to, ensure you look at your product’s usage data in addition to what your users tell you, and build a foundation of trust with your peers, and you’ll be able to drive product change from your community as a collective or push a single-user report with ease throughout your career. At least in this one’s experience right here. 😉

-🧜🏻‍♀️🦄