Last week, Product School hosted Brendyn Alexander, Principal Product Manager at Microsoft, for an #AskMeAnything session. Brendyn has spent a lot of time thinking about building inclusive products, and we were lucky enough to get some of these DE&I insights, as well as thoughts on how to launch backend products, roadmaps, and Web Defense.
Brendyn is a customer-obsessed leader who loves to build inclusive products. Currently Brendyn is building at Microsoft as a Principal PM for their Web Defense Services. Brendyn is a proud member of the LGBTQ+ and Neurodiverse communities advocating inclusivity through products and practice.
How do you launch a new feature/improvement when the change is all on the backend? When the User can’t see the improvement, what’s the best way to let them know the product is getting better?
Thanks for this question. I’ve worked on multiple backend products so greatly appreciate the chance to address this topic.
As PMs, our most fundamental job is to keep the customer and solving their problems at the center of all the work our teams do. Every solution–whether implemented on the frontend or backend–should map to a known customer problem. So, I’d start there.
What is the customer problem your backend solution is solving? Why was it important enough for the team to dedicate engineering resources over other problems you could have solved? What user experiences are impacted by those backend changes? A story you can tell to customers will naturally evolve from those questions.
You might also be interested in: Product Templates: Product Launch
For instance, say your team is implementing a backend caching solution to improve requests per second your service can handle. That may be rooted in a reliability problem customers have experienced–so the story may be something like “We noticed every Monday that traffic to our application increased by 10x which significantly increased load times for customers [<– customer problem]. We got feedback from over 10,000 of you asking us to do something about that [<– why it’s important to solve now]. We listened, and are excited to share that we’ve implemented new performance optimizations to ensure your load times stay under 500ms no matter when you access our app. [<– a backend solution solving their UX problem]”
It’s true customers aren’t going to be interested in backend optimizations or changes if we frame them purely as such. But if we connect them to a customer experience problem, we can tell a great story that makes them care I hope that helps!
As a PM who focuses on building inclusive products – how do you make sure you keep DE&I a part of the conversation throughout the product life-cycle? What does that look like?
As is typical for me, the answer comes down to our customers. While DE&I is often talked about as a requirement from a moral perspective (which I agree with), we as PMs have a responsibility to apply DE&I from a business and product POV. If we fail to consider and take into account the diversity of customers who will use our product, we will deliver products which do not work for all of them.
So, I think about DE&I throughout the entire product lifecycle:
- Identifying customer problems: What are the demographics of the customers whose problems we’re aiming to solve with our product? Are we taking care to include them as we do quantitative and qualitative research? Are we representing their unique problems in our analyses?
- Identifying solutions: For the unique set of problems, are we engaging with the right customers to validate and test them? Are we tailoring aspects of our solutions to the needs of unique customer segments?
- Executing solutions: As we build, are we prioritizing the needs of all our unique customer segments? Are we including representatives from each segment in our beta testing programs? Are we considering the feedback of all segments?
- Launching solutions: Are we targeting our marketing and storytelling in a way that appeals to and reaches each unique customer segment? Are we measuring success in ways which surface how we’re doing with each unique segment?
In each of these phases, the work of keeping DE&I in mind boils down to always seeking out our biases and trying to offset them with data representative of all our customers. Then there’s what I’d term the “executional how” of DE&I. As you create docs, setup meetings, collaborate with your teammates, etc. to create these solutions for customers, are you leading by example? Are you putting your diversity out there proudly and unapologetically? Are you considering how your outputs may be interacted with by people of different abilities? Are you creating space for people with different personalities and approaches to contribute to the project?
That’s just a slice of applicable thoughts on the topic, but I hope it helps
What would you say is your biggest challenge working in Web Defense services?
Hands down it’s the “infinite game” aspect of that space. I compare it to virology. Scientists are never done coming up with vaccines for viruses like the Flu and Covid which plague us. The viruses constantly evolve. It’s the same with malicious actors. We’ll come up with a solution and they’ll work around it eventually. So, there’s a tireless treadmill of effort to stay ahead and build systems that help us stay ahead long enough to keep staying ahead. And while we’re doing this, real people are impacted–often severely–by these malicious actors. On a positive note, though, helping people defend themselves from these selfish, malicious actors is a great source of energy to get up every day and get back on the treadmill
I love that you’re dedicated to building inclusive products. Can you tell us a bit more about how you advocate for the users who may not always be at the forefront of the conversation?
I love the inclusivity focused questions. I have so much to learn here still, but I’ll share what I’ve gleaned thus far in my career.
I do my best to advocate for customers not at the forefront of the conversation by (1) engaging with experts who can help me understand who I might be missing; and (2) finding data to justify why it’s critical to address these customers.
For instance, 1 in 7 people in the world (over a billion people!) have a disability. 70% of these disabilities are unseen. If we think about any user base of a sufficient size, that means we’re always going to have products which need to be tailored in some way to folks with different abilities. And if we think about solutions for those folks in terms of how they help everyone, they’re easier to sell. I think of this whenever I come to a street crossing in Seattle: the slope that blends the sidewalk into the street is an ADA requirement for folks using wheelchairs, but we all benefit from it. Same with captions, a tool designed for folks who are hard of hearing but useful to anyone in a noisy room. All that is to say, it’s easier to sell the value of inclusive features when we show that everyone can benefit from them at one time or another and that those who benefit from them all the time are a significant portion of the population.
Another great read: Diversity and Inclusion in Product: Why It Matters
If we add to that the quantification of spending power of people of not just different abilities, but different races, genders, sexual orientations, etc. we add a powerful mechanism for appealing to the business side of justifying investing in inclusive experiences. That said, not every product will serve every type of customer, so it’s important to identify the highest impact areas of inclusivity and push for those first. Prioritization is a huge part of PMing as we live in a world of scarcity. I know that’s not really a simple answer, but I hope it helps.
Also, how do you run problem and solution discovery and follow-up delivery? Do you have any tips for new PMs to carry out excellent discovery and truly deliver value for customers?
I lean on both qualitative and quantitative feedback and iterating across consistent touchpoints with customers throughout the entire product development lifecycle. All of this can be expensive, though, so I like to rely too on becoming a user of the product I’m building–and encouraging the team building it to do so, as well–so we can supplement customer signal with our instincts as users ourselves. I may have some bias here, though, as I’ve traditionally worked in large corporations who have dedicated user research, design, and other experts who can help with problem and solution discovery. At the core of it all, though, is constant engagement with your customers.
Can you describe what you thing the ideal roadmap contains/looks like? How long are yours typically?
Great question, roadmaps are the bread and butter of building great products. They bring me joy when they’re well defined
The best roadmaps I’ve seen present the long-term picture of what needs to be done to solve customer problems but provide the most clarity on what needs to be done in the short to mid-term to do so. They’re prioritized, with every item mapped to the customer problem it’s solving (and supporting data) so the team can answer why they’re doing what they’re doing in the order they’re doing it. The best roadmaps are also centralized and tracked so the team can orient around a single source of shared truth. On a meta level, the best roadmaps are also open to change. We want to lock on a roadmap in the short term to avoid randomizing the team and to deliver complete customer value in a given timeframe, but Product Development is based on a feedback loop so we don’t want to hold too firmly to a mid-to-long-term view of the roadmap that doesn’t adapt to changing customer needs.
In terms of length, I’m taking that to mean time. This will vary based on the type of product you’re working on, but for me in the software space, I aim for a concrete, detailed roadmap for 6 months. Specifying too much detail for items beyond that timeframe risks investing energy in feature priorities which may change as you ship solutions to customers and learn from them.
I hope that helps!
What are the qualities that you look for during Product Interviews? What are the soft/hard skills that stand out to identify an excellent PM?
Great questions, interviewing is a critical topic for a business. PMs shape the products to meet customer needs, so it’s important we get hiring right.
In terms of qualities, at the core are curiosity and collaboration. Great PMs are self-motivated learners and sharers. They have an inner energy and passion for identifying and driving through tough problems to clarity of understanding and bringing those around them along on that journey.
Practically, I look to understand skills like communication (speaking and writing), storytelling, collaboration, time management, dealing with ambiguity, resilience, positivity, pushing for quality, and leadership of others. Hard skills will depend on the product area. I work in technical spaces, so I look for architectural competence, an ability to learn about and engage engineers on technical aspects, and things of that nature.
What are some ways an interview candidate can acknowledge product bias and solve for it?
I think this comes back to customer and business problems and goals. Bias is omnipresent and relative in terms of its positive or negative impact on a product. So, as an interviewee, it’s important to clarify business constraints, who the customers are, what are the most important problems to solve, then ensure the solutions bias toward those aspects. I hope that helps!
Any final tips?
For overall advice, find areas you’re passionate about or which you’re already a customer of the product, and use your energy and excitement to try and make the world a better place for as many people as you can through those products. When we build products which solve customer problems, they’ll use them and pay for the value they add. Approach every day with an open mind and learn as much and continually as you can. Change is the only constant