Why Accessibility Needs To Be A Top Priority In 2025

Read The Transcript:

We’re trying out transcribing our podcasts using a software program. Please forgive any typos as the bot isn’t correct 100% of the time.

Hannah Clark: I think it's time we admitted that talking about accessibility tends to make us uncomfortable. In a product context, we tend to prioritize features with the biggest impact and the largest percentage of users. So when we talk about building for accessibility, it feels like a loaded topic. Where on the roadmap do we fit in features that make a big impact for a relatively small percentage of users? How do we know what accessibility should look like for our product when accessible means different things to different people? And how do we do all of this without making assumptions or inadvertently offending the users we're trying to support?

My guest today is Prerna Ramachandra, Principal Product Manager at Yahoo. Prior to joining Yahoo, Prerna was a Senior Product Manager at Slack, where she was instrumental in auditing and developing accessible features for the product's diverse user base. What you're about to hear is part case study, part playbook on the business case for accessibility and the most efficient and ethical ways to make your product more welcoming to everyone. Let's jump in.

Welcome back to The CPO Club Podcast. We are here today with Prerna Ramachandra.

Prerna, thank you so much for making time in your busy schedule to join us today.

Prerna Ramachandra: Thank you so much for having me. It's great to be here.

Hannah Clark: Can you tell us a little bit about your background and how you got to where you are today?

Prerna Ramachandra: So I'm currently a Principal Product Manager at Yahoo. I've been here for about a year and a half now. And prior to Yahoo, I was working at Slack and I was at Slack right before they got acquired by Salesforce and then through the Salesforce acquisition. And at Slack, I was primarily leading the accessibility and design systems team before I transitioned over to working on their core desktop experiences app.

My work from one team to the other kind of, they both bled into each other, which I'd love to dive into later today. And then prior to Slack, I was working at the Washington Post where I led the redesign of their homepage and the replatform of the article page experience. So I've had some media experience, some big tech experience.

And I like to say that my interest in product specifically aligns with the intersection of product technology and storytelling. And the ways in which people use stories to communicate with one another and how tech can be an effective tool to do that.

Hannah Clark: Which is so perfect since you're here today telling your story.

Obviously it's something we're both passionate about, storytelling, and today we're going to be focusing on something that's maybe a little bit more niche, but definitely an issue that I think we don't talk about enough, which is accessibility, and specifically the intersection of accessibility and user onboarding.

So just to kick us off, why would you say, like in your experience working in this field and in this space, Why does accessibility often get treated like an afterthought? And what's the business case for baking it in from the beginning?

Prerna Ramachandra: Definitely. So I like to just start by speaking to a statement that I truly, truly believe in my heart, which is we live in a day and age when I don't believe technology is a luxury anymore.

I grew up in the nineties, dating myself a bit here where technology was still a novelty. The internet was still a novelty. Not everyone had access to it, nor did everyone need to, but we live in a day and age where every one of our essential services is in some shape, way, shape or form digitized. And that means that every single person in the world should be able to use it easily.

And people with disabilities are generally treated as an afterthought in our society. I think so many of our services are not as accessible, but technology is uniquely positioned to actually quite easily bake in accessibility into what it does. And technology is also uniquely positioned to make the lives of everyone, including people with disabilities, a lot easier.

And so I think this is one of the main reasons, like a moral and ethical standpoint, I think it's really important to prioritize. Why it gets treated as an afterthought, quite frankly, is because I don't think most organizations fully understand the business case for it. That's number one. And number two, I think it's because People feel like accessibility requires some really deep technical expertise.

And so they don't always feel like they have that expertise or they don't always think about it. It's not baked into our processes. And as a result, we just ignore it until someone is worried that they're going to get sued. Or that they're going to lose a customer that has accessibility requirements.

And all of a sudden your teams are scrambling to try to figure out what's wrong and how to build it in. To answer the second part of your question, which is like, what is the business case for accessibility? And I did touch on this in my first point. The reality is that for technology to succeed, you want to have more users, right, and for most of us, we get paid the more our product gets used.

And the way more people use it is if they can access it. So at a core level. Accessibility is just really important because more people can use your products and when more people use your products you just make more money. The flip side of it is you don't want to get sued and if you get sued there's a chance you're gonna have to pay out a lot of money.

And so from both standpoints, there's like a business case to be made for accessibility. And the other thing I want to add, and I'll dive into this more in detail, and something that I'm personally very passionate about within the field of accessibility, which is we always limit the idea of accessibility to Ensure that it's usable by screen readers.

Ensure that you can do keyboard navigation, but I think we need to move beyond that definition of accessibility and really think about how do you ensure that everyone in every circumstance, like your users in every circumstance can use that product because oftentimes we don't think about accessibility as something that can be situational and conditional.

So one example I always like to give is voice commands or using voice to use your product. We always think it's something that's easier if you have low eyesight. Like my dad, he's like much older, he might not be able to see small text on his screen, so he likes using his voice to control a lot of things on his phone.

But if you're driving, you don't have use of your hands either, you don't have use of your eyes in the same way, so you could still use voice commands. And so when you think about accessibility, you can think about it as encompassing a situation rather than an individual or an individual problem, and that actually expands your definition and makes you realize you're actually leaving on the table a huge use case and a huge user base.

Which is probably not good for your business. And so there is like a practical business case to be made for why this is important to prioritize from the very beginning.

Hannah Clark: I think that that's so resonant. I think that applies to accessibility and digital products as well as physical products and physical spaces. I really love the framing of being accessible to a situation rather than a specific use case. I experienced that myself when I was pushing around a stroller and I noticed how many spaces were designed for, you know, a single pedestrian, you know, single file kind of thing.

And you realize that there are so many different contexts in which someone might require an accessibility feature or accommodation or have something designed with accessibility in mind, because that is so cross applicable to many ages and stages and phases of life. So, yeah, I really like that way of thinking about it, and I'd love to dig a little bit deeper into that in a moment.

You mentioned that you want to talk a little bit more about your experience at Slack, and I would really like to dig into some of the projects that you worked on during that time, and particularly accessibility onboarding workflows through a lens of accessibility.

Walk me through a little bit, how did you approach like a state of affairs analysis to evaluate what the product's current accessibility status was and how did you move forward from that?

Prerna Ramachandra: Definitely. So when I started at Slack, one of the first projects that I worked on was actually figuring out how accessible the product was and what we could do to exactly what you said.

How, what kind of frameworks did we have to do a state of product analysis? And we didn't have anything when I joined Slack was at a point where it was really going after big enterprise customers that have kind of done really well in the small to medium business market. And as it was going after these big enterprise customers, it was realizing that there were a very strict set of regulations for their vendors in terms of accessibility.

And so the first thing I did was actually develop an internal set of standards, which we call the Slack accessibility standards. Which used preexisting standards like WCAG, but also took into account Slack's unique products and what accessibility would mean for those products. And we put together like a framework that allowed you to go through the product and analyze whether it met certain criteria.

And as a result of that analysis, we assigned a grade like A, B, or C to different features within the product to analyze how accessible they were. And this was very much a quantitative plus qualitative analysis. So we had the list of criteria. Some of it was based on just like very simple, like task management, like, is everything keyboard accessible?

Is everything screen reader accessible? And then other things would be something that were a little bit more intangible. So, for example, Snap Slack is a communications product. And one thing it does really well is notifications. You need to be notified, but this was during the pandemic. So a lot of people were working from home.

A lot of people were working remotely. And so we did hear from customers that there was notification overload and it specifically impacted anyone who identified as neurodivergent because they would feel really overwhelmed and they wouldn't be able to do their tasks properly. So that was a little bit more intangible.

It's not something that you really see in a lot of accessibility guidelines out there. So we incorporated all of that to create this framework. They use this framework to assign grades to each of the feature areas and the grades were purely based on can they do the task and how quickly can they do it.

So it helped mark a sense of urgency to the issues and what was most important and what was not. So that was the first thing we did. We used that to do a state of product analysis and then we went to leadership and said, okay, this is the entire product. This is how it falls into the range. And these are the issues we believe need to be fixed immediately because they're actually fundamentally the product.

broken for a group of customers as a result of this not being done. The cool thing about this framework was also that it wasn't just applied to existing products, but if you were developing new products, you could very well apply that framework in order to understand what you need to check off before you can launch this.

It was also something that you could use the future thinking and you could use for future products as well. So that was the first thing we did. And then we did a lot of work. I did a lot of work to specifically work with individual teams in order to help them know what to prioritize based on this framework.

Because everyone has a roadmap. No one wants to blow up their roadmap in order to meet something new that's coming up. Everyone has like a set of things they've committed to. So I worked with these individual teams so that they knew exactly what the critical items were for them. So that when we went to leadership as a collective and said, This is what needs to be prioritized.

This is what needs to be fixed. We could go to them with a very clear plan, and we could also tell them what the tradeoffs were. So, what would be the level of effort to fix each of these items, and what would get pushed out of the roadmap if we had to accommodate this, and what would the impact be? So, I always believe that when it comes to accessibility, and this is true for a lot of things within product, but with accessibility I saw specifically, you have to understand the balance between working with the individual team that is responsible for the feature area, As well as navigating, how do you work with leadership to get buy in to prioritize this work?

And I was very fortunate that the leadership at Slack was very committed to prioritizing this work and doing it right. What they really needed from us was the clear information. Okay, what's the level of effort? What's the timeline? What are the tradeoffs? And what's the impact. So that's what we were able to go to them with.

So it's, it was a lot of work in people management and also a lot of work with your engineers technically to provide the analysis that they needed.

Hannah Clark: This is so critically important. I think that the buy in there's nothing more critical to making sure that these features get shipped than to actually get the buy in and like you said, to do it right.

I would really like to get a little bit more granular as far as you mentioned the trade off. So what would a trade off look like? Like how exactly would you, you know, if you were to kind of give an anecdote or like an example of how that might be presented, how would you phrase that in order to kind of put everything in context and kind of explain the scope of the project and how, where it falls on the critical items list?

Prerna Ramachandra: The team that I would say was most impacted by the work that we did was a team that was working on the core messaging part of the project. And it's because they had, they owned the largest surface area. They owned everything from the experience of like someone typing a message and sending it, to receiving a message in that entire message portal.

They had members on their team who owned channels. If you use Slack, like you just know this is the core of the Slack experience. So it made sense that they would have like the largest number of items they had to tackle because not only did they own the largest surface area, it was also the most critical surface area.

Like Slack exists because people send and receive messages. So it was the most critical surface area. It had the most high impact issues with an accessibility that they had to handle. So to give you a very specific example, when we went to them with this list of issues, I'm not going to give specific numbers here, but I'm going to give some hypotheticals.

I'm going to use 100 just because it's easier to like do percentages. So I went into them with, let's say a list of 100 issues and said, this is all that needs to be tackled in order to ensure that your product is at minimal usable for every single person who uses a screen reader, who uses keyboard navigation, who identifies as someone with a disability.

So the first thing I did was sat down with the PM and said, Okay, this is a list of issues that we've identified based on this framework we have. This was actually a very critical step, but that PM was able to like work with me to say, Okay, I understand why you said these hundred items are critical, but I actually only think 80 percent of this is critical.

Because this is the user data we have and the user information we have on how people are using this. So if you think this particular workflow is really critical, they are actually doing it differently. There's actually workarounds and solutions for this. So that first analysis was really important because we were able to then cut down that 100 to 80.

And I think anyone who has an accessibility, central accessibility org, it's really important to have that conversation with the product manager of the product itself. Because they actually know their users the best. And so we were able to cut down that list quite a bit. Then the second thing we did was, okay, look at the issues and see which of them are in product areas or feature areas that are going to be either redesigned or deprecated soon.

So that helped us say, okay, if this particular area, feature is being redesigned, then let's just make sure it's accessible in the redesign and we don't have to fix this issue right now. Right, if this particular area is going to be deprecated, we don't have to fix this issue right now. So that got rid of, let's say, another like 10 issues.

So then we had about 70 that we had to tackle with the team. We sat down with their engineers, this is where it's really important to have at least one in house accessibility expert. We were really lucky we had a really, really solid engineer with that expertise. He was able to come in and work with their engineering team to help them understand and do like a level of effort analysis for each of those 70 issues.

We then sat down with the product manager and said, okay, how many of these 70 issues can you just prioritize in your current sprint or your upcoming sprint within this quarter without worrying about anything slipping? How much of it can you just fit it in? Most teams usually tend to have some buffer, especially if you're a team that's working on a product that's already released to manage like incoming bugs and issues like that.

So this kind of got pulled into that workflow and they said, okay, we could probably do like 20 of these without having severe roadmap impacts. So we didn't even need to worry about that with leadership. So then we were left with maybe half of that. So we were able to really cut it down and then with the remaining, let's say 50 issues, that's where we had to say, okay.

What are some big product areas this quarter that could potentially get pushed out or delayed if all of these issues were prioritized? And that is the moment where we needed leadership to step in and like help us navigate and negotiate on what to do. And so there was a feature area, there was a feature that the team was set to release within that quarter that was really important for a big customer, but the same big customer was also the one that was asking us to fix these accessibility issues within a certain time frame.

And so then we were able to sort of go to leadership and say, this is the trade off. This is what we're working with. And then we were able to use their help. We were able to work with the account managers for that customer, go to the customer and say, okay, this is where we're at. Like, what would you like to see?

And so I think the, the most important thing here is to do as much work as you can do at your level, at the individual contributor level, at the, at the Senior PM, principal PM, group PM level to ensure that you have done as much as you can to prioritize all the work you can do creatively within your team and you bring in leadership only when they're going to be like big areas.

And in this case, what was helpful was that it was the same customer that was being impacted by both sets of issues. And so we were able to work with them to negotiate which one they wanted first and which ones could come later. And then based on that, we were able to say, okay, let's fix these 10 issues in this quarter that would not delay the other feature so much.

Let's fix these 10 issues in the next quarter. And then this was really the first quarter that we did all this. And then in subsequent quarters, what we were able to do was actually in the quarterly planning cycle itself, work with the teams to just carve out dedicated time where they would just do accessibility.

And this is where it's really important to get the full organization involved, because what we were able to do was do these like accessibility sprint weeks. We used to coincide them with global accessibility awareness day, whenever the quarter felt there. So everyone on the team, all the different engineering squads were working together to just work on accessibility issues for that sprint. And it also was like a nice community environment.

We also had some workshops where we tell teams about accessibility. So it was like, it worked out really well, but I can say there's a lot of hard work in the beginning. And especially when there are those big trade offs between features, that is where you have to loop in leadership in order to help you negotiate and navigate what to prioritize and when.

Hannah Clark: This is really cool and I really love to hear about, you know, the whole organization coming together specifically to prioritize and make time for accessibility. And then it turned out to be such a positive working experience as well. That sounds so awesome.

But now that we're on the topic of collaboration and kind of working as a team across different kinds of teams. I'm wondering how this all works out when you are working with an organization that's got maybe several products in the portfolio and there's multiple teams that are trying to address accessibility issues across those different, you know, different products and features.

So how do you collaborate between product teams in order to, you know, work in lockstep and kind of minimize the amount of effort and communication that's involved in order to ship these products?

Prerna Ramachandra: Yeah, that's a great question. So I think there are two different ways or two pillars I would like to say to tackle this problem.

The first pillar is like structural. If the organization has a central accessibility org, and I think most organizations today do in some capacity, like where do they sit within the organization, right? Like if they sit within a single vertical, then it's going to be very hard to break through organizational silos to work with other teams.

So you really have to ensure that your team is positioned in the right place. And if it's not, then you as the product manager has to do the work to reach out to all these other teams to like, understand their roadmaps, get to know them, so you can work well together. I think that's the first thing. The second piece is ensuring that, and this is also twofold, both for the person managing and leading the central accessibility org, and then the individual feature team PMs.

Which is ensuring that you are both in constant communication about your roadmaps. If you know what's coming up, this was the biggest I guess, this was one of the biggest challenges for our team, and also the biggest area of opportunity when I was working on accessibility at Slack. And later, when I started working on the desktop product, I suddenly went from being in the central accessibility team to being one of those feature teams myself.

The most important thing is to ensure that when you're doing roadmap planning at the beginning, you Are looping in the accessibility experts you need to loop in. And it starts right from the planning process through the design process. I like to say that accessibility actually doesn't start with the engineers, even though it requires engineering expertise.

Sometimes it starts with the designer. One of the things we got into, and if you're using tools like Figma, they have a great tool set to actually do accessibility designs or like an accessibility specific workflow within your design. So, our designer would be involved from the very beginning of the product development and design process to say, Okay, how do you ensure the designs you're creating are accessible?

Are there things that are working? Are there things that are not working? So this is where anything future thinking for anything that's an existing issue, right? Like, if you're already identified a set of accessibility issues within your product. That is where that framework came in very handy. So it's like much as I tried my best, I, when I was in the central org, I couldn't keep track of every single change, every single roadmap change, everything that the team was doing.

But because we had this centralized set of frameworks that everyone was aware of as a feature team, product manager, they could just refer to it and like hand it to the designer, hand it to their engineer, look at it themselves and say, okay, this accessibility bug came in. Based on this framework, this is critical, medium, or low priority, and then I can use that to determine whether or not I need to prioritize it immediately, I can prioritize it later.

So having that central standards was really helpful because it ensured that someone who doesn't have that expertise still had something to refer to when these bugs came in and they can help prioritize. And that also ensured that there's not one single person in charge of trying to sort of herd the cats, for lack of a better word.

And say, okay, are you doing it or not? Because what I really wanted to ensure when I was working on accessibility was I don't want to be like a school principal trying to tell you what to do. And I don't think anyone wants that. We're all adults here. And I also like to believe that every single person involved actually does care about this.

Like nobody I talked to said, oh, I don't want to do this. Everyone was like, I really care about this. I want to make sure our product is accessible. I either don't know how, or I don't know if we're going to be given the authority to prioritize this or we're going to have the time to do it. And that's what we were really trying to solve for.

And so I would say if you're a feature PM who's trying to make your product accessible, see if you can develop a framework or work with someone in your org to develop a framework that you and other people can refer to. So you're not constantly having to like wait for someone to respond to you as to whether something is important or not.

You'll know yourself. And you'll be empowered, and then you're creating something new, and you're building a new product, ensure that you can reach out to the people with the right expertise, and bake in accessibility into the design process from the very beginning. Because then that avoids a problem where these bugs come in in the future, and suddenly you're scrambling to prioritize it. You know it's going to be accessible from launch.

Hannah Clark: This is really interesting, and I, I want to talk a little bit more on the level of implementation and iteration because it's one thing to kind of analyze the features that you have and prioritize and implement changes and improvements to the existing version of the product or whatever your enterprise clients are asking for, but as time goes on, new features are introduced, features become antiquated or replaced with updates.

How do you integrate that analysis process or, or what's like the proactive approach in order to ensure that future features that are introduced into the roadmap are accessible from the day one as well?

Prerna Ramachandra: Yes, that's a great question too. So I'll give a very specific example. And since you talked about user onboarding specifically in the beginning, as I said, the first thing when you're creating your roadmap is to look at every feature, everything that you have going on, anything new that you're building and know that.

You have to think about accessibility. I think that is something as a PM you have to keep in mind every single time. The other thing I would say is knowing when, and this is a little bit of PM intuition that develops over time, and a little bit of like looking at actual data. It's knowing who in your customer base can actually help you ensure that something is accessible or something is not accessible.

Because I think as PMs, we rely a lot on user research to help us know what to build. But we often forget that there are actually customers and people out there who are using our product in a way that require, like, who are, you know, users with disabilities, who use these accessibility features. So ensure that you have ways to incorporate them right from the beginning into like your user research process.

So when you're thinking about that future, future thing. So the example, as I said, I was going to give was user onboarding. So another feature area we found when we were doing our initial analysis within Slack was the onboarding experience had accessibility gaps that we wanted to address, but we also knew that the onboarding team at Slack was going through making some big redesigns to the onboarding experience because the product had evolved and grown since the first time they did this.

And they needed, they wanted to make sure they incorporated everything. So we were actually able to work from, with that team from the very beginning to ensure that the core onboarding flow that they were redesigning was accessible. And so the way we did that was we were intimately involved in their roadmap planning from the very beginning.

And this is a very big project. So whenever you have these major projects is, I think, when it's really important to get the right experts involved. And our designer was actually involved throughout the design process, so when they did user research, when they were doing user testing, when they were creating their designs in Figma, he was creating the accessibility spec for those designs side by side along with them to make sure that things were accessible from the very beginning.

It was the same process we used at Slack when we were redesigning the desktop app. But secondly, what we found was there was a real opportunity here to have an onboarding experience specifically centered around accessibility for the users who needed it. I think the best example of this is Mac's, is Apple.

So Apple's products I think are really, really solid when it comes to accessibility. And so when you buy a new Mac, You can actually choose to go through an onboarding workflow that specifically shows you where the different accessibility features are, how to use them, et cetera, et cetera. So we actually, our team, the accessibility team, actually built out that core onboarding experience right from when you enter the app when you enter the regular onboarding flow, we ask you, do you care about accessibility?

If you say yes, we take you through a step by step workflow that shows you where the different tools are, the different how to use keyboard navigation, what the different commands are, et cetera. And then the other thing we were able to do is use the data. So when someone tells us they're interested in accessibility, we take them through the workflow.

We were able to show them strategically different tooltips within the product that allowed them to continue that accessibility journey. And the reason that all of this was possible is because when, one, when we realized there were issues, When we were actually outlining all the issues with the existing workflow, we saw that there was like a huge gap because there was no accessibility onboarding experience.

And then the second thing was we talked to a lot of customers. So we talked to customers who were sending in these accessibility bug tickets to us. Who were helping us figure out how accessible the product was. A lot of them said, you know, there was nothing to help me figure out how to navigate Slack. I had to figure it out myself.

And most of them are used to doing that, unfortunately, because a lot of our products don't do that for them. But it's still not like, you know, in my opinion, it's not the ideal workflow. And so I would say that when you're thinking about ex, you know, future thinking, what are the products I wanna build?

How is my product looking? Rely a lot on user research. Like, I don't know why it's not being talked about in our industry as much, but you have to talk to your customers. Like nothing replaces that. I don't think AI is going to tell you what to build. It's the people who are using it. We're going to tell you what to build.

So you have to talk to them. And today there are companies and tools that help you do that. So if you're a big enterprise company, for example, and your customers are enterprise clients, I guarantee you they will have an ERG, like an employee resource group of some sort that has employees with disabilities who would, I am quite certain will be very active in ensuring they vet their vendors.

So that's a resource you can tap into. The other resource are, there's a company we used to work with called Fable, that specifically recruited users with disabilities to do accessibility user testing. So it's like usertesting.com, but specifically for accessibility. So like work with those entities, work with those organizations, to kind of help you understand like, what you're building, how you're building.

And then, the second thing I would say is as you're starting the design process, and the iteration process, Include someone, either have your designer take a course to understand designing for accessibility or have someone with expertise and accessibility be involved in the process right from the design process. Make sure that your designs have accessibility specs.

Because that is what your engineers are going to refer to when deciding and figuring out how to build something. Make sure that those designers and those accessibility experts are involved in testing. That's how you sort of ensure that everything you're building is going to be accessible moving forward.

Rather than having to, again, as I said, scramble and then redoing it later.

Hannah Clark: Anyone who's listened to the show for a long time knows I love prescriptive advice. That's very specific in detail. So thank you for offering these very specific recommendations just to kind of put a bow on things because we're, we'll be wrapping up shortly, but I do want to make sure that we touch on analytics.

We brought up data not too long ago, and I want to bring this back around to how are we going to measure success of our accessibility features and the things that we've implemented and put so much effort into working together to create. Naturally, I imagine, you know, when you're measuring activation rate or some of those other kinds of really key adoption metrics, when we're thinking about the general populace, we're looking at a very different or possibly a somewhat different process for segmenting how effective your accessibility features are, whether that's from an onboarding standpoint or any other accessibility feature throughout.

It's a multiple part question. First of all, how do you segment what you're measuring to ensure that you're measuring the success of the accessibility features that you've built rather than just the product at large, are there any tools that you would use for that? And do you have any other tips or tricks for ensuring that you're able to integrate that kind of data into future iterations?

Prerna Ramachandra: Definitely. So I'm going to give an answer that is probably going to make a lot of PMs uncomfortable. And it's also something that I'm uncomfortable with, which is you cannot rely on quantitative data to Understand whether your accessibility features are working and whether your product is accessible.

And some of it is because morally and ethically you cannot really segment users based on accessibility because you're trying to make assumptions about whether or not someone has a disability. And even if you use data like measuring how many users are using keyboard navigation or how many users have turned on screen reader commands, That still can potentially exclude a large group of the population, like, for example, I mentioned neurodivergence, like, are people with neurodivergence are able to use your product or is it too overwhelming?

There's certain specific features around that. For example, it's Slack and a lot of any, any product that has any sort of form of animation, you have the ability to turn off that animation because for some folks it can cause seizures. So that's another thing that's kind of hard to measure. So, there's only so much you can get from your quantitative measurement because there's, it's really hard to segment users in the way that you would normally segment your user base because you're making a lot of assumptions about someone that you generally don't want to do.

And also, it's probably not going to be very effective, right? There's a lot of things around like hidden disabilities and also it fails to take into account the situational thing that I was talking about at the beginning of the episode. What I've found works the best for accessibility and measuring whether or not your product is accessible.

And whether or not features that are specifically around accessibility are working is going back to your users and just like asking them. So qualitative research is the best way to measure the success of accessibility in my opinion. And also it's based on a lot of what I've seen working on accessibility in the past and now.

I'll give another very specific example. So another accessibility feature that we built at Slack was essentially an API. That a lot of different teams could leverage to easily build keyboard navigation into their product. So, like, a keyboard Navi because a lot of teams didn't really, it does require specialized expert knowledge.

So the API was supposed to make it easier for teams. So the way we measured success in that case was actually seeing how many teams were leveraging that API. Because it wasn't something that was required, teams could try to build it on their own. So we were like, okay, if your team is leveraging this API, it means we, as an accessibility team, were successful in building something that you were able to leverage because we know it works really well.

So that was less of a user measure and more of like an internal team measure. The way we measure success for our users, as I said, was really just asking. So when we launched the onboarding workflow, we got some quantitative data in terms of how many users were opting into the accessibility onboarding experience. But for the most part, we had worked very hard to assemble together teams of users who we would talk to about accessibility.

But also, generally, whenever you launch something, I'm assuming you're going to do some qualitative research to understand the impact. We made sure that those groups included users. Who had asked about accessibility, were using accessibility features, et cetera. And it was a lot of like conversation, qualitative measurement, qualitative research.

Because not only do you want to know whether someone's using your product, but you want to know whether someone's able to use it properly. Properly in order to complete the tasks they want to complete. So quantitatively, if your product is doing very well with the majority of users, that's already giving you directional indication of the fact that whether or not your product is accessible, but if you're wanting to talk to those specific users about accessibility, you're going to have to find those users and you're going to have to like specifically do the qualitative research and analysis to make sure that it's like working the way you want it to work.

And I know that's not a great answer because as a PM, you're really looking for the numbers and the data. But I also think part of the job of PM is to be okay with that level of uncertainty. And I will say this, which is again, probably not going to be the best answer, but you're never going to be perfect.

No product is ever going to perfectly check off every single box when it comes to accessibility because again, like a lot of this is situational, which is again, why it's really important to continue to have those conversations with your users. And I will say, especially users who care about accessibility are going to be very vocal because they're not used to getting the things they need to just do their jobs.

So they have to be vocal in order to just survive and like, do their jobs properly. And so I think that you have a huge resource there and like something I had to learn more than ever in my career as a PM, it was when I worked on accessibility that I really truly understood the importance of talking and listening to your users because they could give you the best information of what you need to hear about how your product is doing.

And people are not talking about how important that qualitative research is and that human to human connection is. But I think that's truly going to tell you whether your product is working. And when it comes to accessibility, it's really important to make sure you talk to people.

Hannah Clark: I couldn't agree more. Yeah, this is a very pro user research show. We did an episode a while back with Steve Portigal on how to interview users. That's like one of our favorite of all times, because it's, it's all about just talking to people, letting people really tell you their authentic experience and not trying to guide the conversation, eliminating your own bias. So important for a product development process.

Well, thank you so much for this has been like such a fun conversation. I really appreciate your perspective on this matter. And what's such specific stories to tell around and such a well known product. So we can all really understand and get behind, you know, how these features kind of come to life.

So I really appreciate this. Where can people follow your work online or connect with you?

Prerna Ramachandra: I'm going to be on LinkedIn. It's just my first name, last name, Prerna Ramachandra. You can also reach out to me through my website. It's just PrernaRamachandra.me.

Hannah Clark: Fabulous. Well, thank you so much for being here.

Prerna Ramachandra: Thank you so much, Hannah. This was great.

Hannah Clark: Thanks for listening in. For more great insights, how-to guides and tool reviews, subscribe to our newsletter at theproductmanager.com/subscribe. You can hear more conversations like this by subscribing to The CPO Club, wherever you get your podcasts.