January 21, 2025 • 36 mins
Accessibility often sits uncomfortably on the fringes of roadmap discussions. Many organizations prioritize features with the biggest impact, sidelining those that benefit a smaller percentage of users. Yet, the dialogue on accessibility is not just about inclusion but also intersects with business ethics and market expansion.
In this episode, Hannah Clark is joined by Prerna Ramachandra—Principal Product Manager at Yahoo—to delve into the business case for accessibility and effective strategies to integrate it seamlessly into product development.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Hannah Clark (00:01):
I think it's time we admitted that talking
about accessibility tendsto make us uncomfortable.
In a product context, we tendto prioritize features with
the biggest impact and thelargest percentage of users.
So when we talk aboutbuilding for accessibility,
it feels like a loaded topic.
Where on the roadmap do wefit in features that make a
big impact for a relativelysmall percentage of users?
How do we know whataccessibility should look
(00:24):
like for our product whenaccessible means different
things to different people?
And how do we do all of thiswithout making assumptions or
inadvertently offending theusers we're trying to support?
My guest today is PrernaRamachandra, Principal
Product Manager at Yahoo.
Prior to joining Yahoo,Prerna was a Senior Product
Manager at Slack, whereshe was instrumental in
auditing and developingaccessible features for the
product's diverse user base.
(00:44):
What you're about to hearis part case study, part
playbook on the business casefor accessibility and the
most efficient and ethicalways to make your product
more welcoming to everyone.
Let's jump in.
Welcome back to TheProduct Manager Podcast.
We are here today withPrerna Ramachandra.
Prerna, thank you so muchfor making time in your busy
schedule to join us today.
Prerna Ramachandra (01:04):
Thank you so much for having me.
It's great to be here.
Hannah Clark (01:06):
Can you tell us a little bit about your
background and how you gotto where you are today?
Prerna Ramachandra (01:10):
So I'm currently a Principal
Product Manager at Yahoo.
I've been here for abouta year and a half now.
And prior to Yahoo, I wasworking at Slack and I was
at Slack right before theygot acquired by Salesforce
and then through theSalesforce acquisition.
And at Slack, I was primarilyleading the accessibility
and design systems teambefore I transitioned over
to working on their coredesktop experiences app.
(01:33):
My work from one team to theother kind of, they both bled
into each other, which I'dlove to dive into later today.
And then prior to Slack, Iwas working at the Washington
Post where I led theredesign of their homepage
and the replatform of thearticle page experience.
So I've had somemedia experience, some
big tech experience.
And I like to say thatmy interest in product
(01:54):
specifically aligns withthe intersection of product
technology and storytelling.
And the ways in which peopleuse stories to communicate with
one another and how tech can bean effective tool to do that.
Hannah Clark (02:05):
Which is so perfect since you're here
today telling your story.
Obviously it's somethingwe're both passionate about,
storytelling, and todaywe're going to be focusing
on something that's maybe alittle bit more niche, but
definitely an issue that Ithink we don't talk about
enough, which is accessibility,and specifically the
intersection of accessibilityand user onboarding.
So just to kick us off, whywould you say, like in your
experience working in thisfield and in this space, Why
(02:27):
does accessibility often gettreated like an afterthought?
And what's the business case forbaking it in from the beginning?
Prerna Ramachandra (02:33):
Definitely.
So I like to just start byspeaking to a statement that
I truly, truly believe in myheart, which is we live in a
day and age when I don't believetechnology is a luxury anymore.
I grew up in the nineties,dating myself a bit here where
technology was still a novelty.
The internet wasstill a novelty.
Not everyone had access to it,nor did everyone need to, but
(02:55):
we live in a day and age whereevery one of our essential
services is in some shape,way, shape or form digitized.
And that means that everysingle person in the world
should be able to use it easily.
And people with disabilitiesare generally treated as an
afterthought in our society.
I think so many of ourservices are not as
accessible, but technologyis uniquely positioned to
(03:17):
actually quite easily bake inaccessibility into what it does.
And technology is also uniquelypositioned to make the lives
of everyone, including peoplewith disabilities, a lot easier.
And so I think this isone of the main reasons,
like a moral and ethicalstandpoint, I think it's
really important to prioritize.
Why it gets treated as anafterthought, quite frankly,
is because I don't think mostorganizations fully understand
(03:40):
the business case for it.
That's number one.
And number two, I think it'sbecause People feel like
accessibility requires somereally deep technical expertise.
And so they don't alwaysfeel like they have that
expertise or they don'talways think about it.
It's not bakedinto our processes.
And as a result, we just ignoreit until someone is worried
(04:02):
that they're going to get sued.
Or that they're going tolose a customer that has
accessibility requirements.
And all of a sudden yourteams are scrambling to try
to figure out what's wrongand how to build it in.
To answer the second partof your question, which is
like, what is the businesscase for accessibility?
And I did touch onthis in my first point.
The reality is that fortechnology to succeed, you want
(04:22):
to have more users, right, andfor most of us, we get paid
the more our product gets used.
And the way more people useit is if they can access it.
So at a core level.
Accessibility is just reallyimportant because more people
can use your products and whenmore people use your products
you just make more money.
The flip side of it is youdon't want to get sued and
if you get sued there's achance you're gonna have
(04:42):
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 toadd, and I'll dive into this
more in detail, and somethingthat I'm personally very
passionate about within thefield of accessibility, which
is we always limit the idea ofaccessibility to Ensure that
it's usable by screen readers.
(05:02):
Ensure that you can do keyboardnavigation, but I think we
need to move beyond thatdefinition of accessibility and
really think about how do youensure that everyone in every
circumstance, like your users inevery circumstance can use that
product because oftentimes wedon't think about accessibility
as something that can besituational and conditional.
So one example I always liketo give is voice commands or
(05:24):
using voice to use your product.
We always think it'ssomething that's easier
if you have low eyesight.
Like my dad, he's like mucholder, he might not be able
to see small text on hisscreen, so he likes using
his voice to control a lotof things on his phone.
But if you're driving, you don'thave use of your hands either,
you don't have use of youreyes in the same way, so you
could still use voice commands.
(05:44):
And so when you think aboutaccessibility, you can think
about it as encompassinga situation rather than an
individual or an individualproblem, and that actually
expands your definitionand makes you realize
you're actually leavingon the table a huge use
case and a huge user base.
Which is probably notgood for your business.
And so there is like a practicalbusiness case to be made for why
this is important to prioritizefrom the very beginning.
Hannah Clark (06:06):
I think that that's so resonant.
I think that applies toaccessibility and digital
products as well as physicalproducts and physical spaces.
I really love the framing ofbeing accessible to a situation
rather than a specific use case.
I experienced that myself whenI was pushing around a stroller
and I noticed how many spaceswere designed for, you know,
a single pedestrian, you know,single file kind of thing.
(06:28):
And you realize that there areso many different contexts in
which someone might requirean accessibility feature or
accommodation or have somethingdesigned with accessibility
in mind, because that is socross applicable to many ages
and stages and phases of life.
So, yeah, I really like thatway of thinking about it, and
I'd love to dig a little bitdeeper into that in a moment.
(06:49):
You mentioned that you want totalk a little bit more about
your experience at Slack, andI would really like to dig into
some of the projects that youworked on during that time,
and particularly accessibilityonboarding workflows through
a lens of accessibility.
Walk me through a little bit,how did you approach like a
state of affairs analysis toevaluate what the product's
current accessibilitystatus was and how did you
move forward from that?
Prerna Ramachandra (07:09):
Definitely.
So when I started at Slack,one of the first projects
that I worked on was actuallyfiguring out how accessible the
product was and what we coulddo to exactly what you said.
How, what kind of frameworksdid we have to do a state
of product analysis?
And we didn't have anythingwhen I joined Slack was at
a point where it was reallygoing after big enterprise
(07:31):
customers that have kind ofdone really well in the small
to medium business market.
And as it was going afterthese big enterprise customers,
it was realizing that therewere a very strict set of
regulations for their vendorsin terms of accessibility.
And so the first thing I did wasactually develop an internal set
of standards, which we call theSlack accessibility standards.
(07:51):
Which used preexisting standardslike WCAG, but also took into
account Slack's unique productsand what accessibility would
mean for those products.
And we put together like aframework that allowed you to go
through the product and analyzewhether it met certain criteria.
And as a result of thatanalysis, we assigned a
(08:12):
grade like A, B, or C todifferent features within
the product to analyzehow accessible they were.
And this was very mucha quantitative plus
qualitative analysis.
So we had the list of criteria.
Some of it was based onjust like very simple, like
task management, like, iseverything keyboard accessible?
Is everything screenreader accessible?
(08:33):
And then other things wouldbe something that were a
little bit more intangible.
So, for example, Snap Slackis a communications product.
And one thing it does reallywell is notifications.
You need to be notified, butthis was during the pandemic.
So a lot of peoplewere working from home.
A lot of people wereworking remotely.
And so we did hear fromcustomers that there was
notification overload and itspecifically impacted anyone
(08:55):
who identified as neurodivergentbecause they would feel really
overwhelmed and they wouldn't beable to do their tasks properly.
So that was a littlebit more intangible.
It's not something thatyou really see in a
lot of accessibilityguidelines out there.
So we incorporated all ofthat to create this framework.
They use this framework toassign grades to each of
the feature areas and thegrades were purely based
(09:16):
on can they do the task andhow quickly can they do it.
So it helped mark asense of urgency to the
issues and what was mostimportant and what was not.
So that was thefirst thing we did.
We used that to do a stateof product analysis and
then we went to leadershipand said, okay, this
is the entire product.
This is how it fallsinto the range.
And these are the issueswe believe need to
(09:36):
be fixed immediatelybecause they're actually
fundamentally the product.
broken for a group ofcustomers as a result
of this not being done.
The cool thing about thisframework was also that it
wasn't just applied to existingproducts, but if you were
developing new products, youcould very well apply that
framework in order to understandwhat you need to check off
before you can launch this.
It was also something thatyou could use the future
(09:58):
thinking and you could usefor future products as well.
So that was thefirst thing we did.
And then we did a lot of work.
I did a lot of workto specifically work
with individual teamsin order to help them
know what to prioritizebased on this framework.
Because everyone has a roadmap.
No one wants to blow up theirroadmap in order to meet
something new that's coming up.
(10:20):
Everyone has like a set ofthings they've committed to.
So I worked with theseindividual teams so that
they knew exactly what thecritical items were for them.
So that when we went toleadership as a collective
and said, This is whatneeds to be prioritized.
This is what needs to be fixed.
We could go to them witha very clear plan, and
we could also tell themwhat the tradeoffs were.
(10:41):
So, what would be the levelof effort to fix each of these
items, and what would getpushed out of the roadmap if
we had to accommodate this,and what would the impact be?
So, I always believe that whenit comes to accessibility,
and this is true for a lotof things within product,
but with accessibility I sawspecifically, you have to
understand the balance betweenworking with the individual
(11:03):
team that is responsible forthe feature area, As well as
navigating, how do you workwith leadership to get buy
in to prioritize this work?
And I was very fortunate thatthe leadership at Slack was
very committed to prioritizingthis work and doing it right.
What they really needed fromus was the clear information.
Okay, what's thelevel of effort?
(11:23):
What's the timeline?
What are the tradeoffs?
And what's the impact.
So that's what we wereable to go to them with.
So it's, it was a lot of workin people management and also a
lot of work with your engineerstechnically to provide the
analysis that they needed.
Hannah Clark (11:38):
This is so critically important.
I think that the buy inthere's nothing more critical
to making sure that thesefeatures get shipped than to
actually get the buy in andlike you said, to do it right.
I would really like to get alittle bit more granular as far
as you mentioned the trade off.
So what would atrade off look like?
Like how exactly would you,you know, if you were to kind
of give an anecdote or like anexample of how that might be
presented, how would you phrasethat in order to kind of put
(12:01):
everything in context and kindof explain the scope of the
project and how, where it fallson the critical items list?
Prerna Ramachandra (12:08):
The team that I would say was
most impacted by the workthat we did was a team that
was working on the coremessaging part of the project.
And it's because they had, theyowned the largest surface area.
They owned everything fromthe experience of like someone
typing a message and sendingit, to receiving a message in
that entire message portal.
They had members on theirteam who owned channels.
(12:29):
If you use Slack, like youjust know this is the core
of the Slack experience.
So it made sense that theywould have like the largest
number of items they hadto tackle because not only
did they own the largestsurface area, it was also the
most critical surface area.
Like Slack exists because peoplesend and receive messages.
So it was the mostcritical surface area.
It had the most high impactissues with an accessibility
(12:50):
that they had to handle.
So to give you a very specificexample, when we went to them
with this list of issues, I'mnot going to give specific
numbers here, but I'm goingto give some hypotheticals.
I'm going to use 100just because it's easier
to like do percentages.
So I went into them with, let'ssay a list of 100 issues and
said, this is all that needsto be tackled in order to
(13:11):
ensure that your product isat minimal usable for every
single person who uses a screenreader, who uses keyboard
navigation, who identifiesas someone with a disability.
So the first thing I did wassat down with the PM and said,
Okay, this is a list of issuesthat we've identified based
on this framework we have.
This was actually a verycritical step, but that PM
was able to like work withme to say, Okay, I understand
(13:32):
why you said these hundreditems are critical, but
I actually only think 80percent of this is critical.
Because this is the userdata we have and the user
information we have onhow people are using this.
So if you think thisparticular workflow is
really critical, they areactually doing it differently.
There's actually workaroundsand solutions for this.
So that first analysis wasreally important because
(13:53):
we were able to thencut down that 100 to 80.
And I think anyone who hasan accessibility, central
accessibility org, it'sreally important to have that
conversation with the productmanager of the product itself.
Because they actuallyknow their users the best.
And so we were able to cutdown that list quite a bit.
Then the second thing we didwas, okay, look at the issues
and see which of them are inproduct areas or feature areas
(14:16):
that are going to be eitherredesigned 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 theredesign and we don't have
to fix this issue right now.
Right, if this particulararea is going to be
deprecated, we don't haveto fix this issue right now.
So that got rid of, let'ssay, another like 10 issues.
So then we had about 70 thatwe had to tackle with the team.
(14:38):
We sat down with theirengineers, this is where
it's really important tohave at least one in house
accessibility expert.
We were really lucky wehad a really, really solid
engineer with that expertise.
He was able to come in and workwith their engineering team
to help them understand and dolike a level of effort analysis
for each of those 70 issues.
We then sat down with theproduct manager and said,
okay, how many of these 70issues can you just prioritize
(14:59):
in your current sprint oryour upcoming sprint within
this quarter without worryingabout anything slipping?
How much of it canyou just fit it in?
Most teams usually tend tohave some buffer, especially
if you're a team that's workingon a product that's already
released to manage like incomingbugs and issues like that.
So this kind of got pulledinto that workflow and they
(15:20):
said, okay, we could probablydo like 20 of these without
having severe roadmap impacts.
So we didn't even need to worryabout that with leadership.
So then we were leftwith maybe half of that.
So we were able to reallycut it down and then with
the remaining, let's say50 issues, that's where
we had to say, okay.
What are some big productareas this quarter that could
potentially get pushed outor delayed if all of these
(15:42):
issues were prioritized?
And that is the moment wherewe needed leadership to step
in and like help us navigateand negotiate on what to do.
And so there was a featurearea, there was a feature that
the team was set to releasewithin that quarter that was
really important for a bigcustomer, but the same big
customer was also the onethat was asking us to fix
(16:02):
these accessibility issueswithin a certain time frame.
And so then we were able tosort of go to leadership and
say, this is the trade off.
This is what we're working with.
And then we were ableto use their help.
We were able to work withthe account managers for
that customer, go to thecustomer and say, okay,
this is where we're at.
Like, what wouldyou like to see?
And so I think the, the mostimportant thing here is to do
(16:23):
as much work as you can do atyour level, at the individual
contributor level, at the, atthe Senior PM, principal PM,
group PM level to ensure thatyou have done as much as you
can to prioritize all the workyou can do creatively within
your team and you bring inleadership only when they're
going to be like big areas.
And in this case, what washelpful was that it was the
(16:45):
same customer that was beingimpacted by both sets of issues.
And so we were able to workwith them to negotiate which
one they wanted first andwhich ones could come later.
And then based on that, wewere able to say, okay, let's
fix these 10 issues in thisquarter that would not delay
the other feature so much.
Let's fix these 10 issuesin the next quarter.
And then this wasreally the first quarter
(17:07):
that we did all this.
And then in subsequent quarters,what we were able to do was
actually in the quarterlyplanning cycle itself, work
with the teams to just carveout dedicated time where they
would just do accessibility.
And this is where it'sreally important to get the
full organization involved,because what we were able
to do was do these likeaccessibility sprint weeks.
We used to coincide themwith global accessibility
(17:27):
awareness day, wheneverthe quarter felt there.
So everyone on the team, allthe different engineering
squads were working togetherto just work on accessibility
issues for that sprint.
And it also was like anice community environment.
We also had some workshopswhere we tell teams
about accessibility.
So it was like, it workedout really well, but I can
say there's a lot of hardwork in the beginning.
(17:49):
And especially when thereare those big trade offs
between features, that iswhere you have to loop in
leadership in order to helpyou negotiate and navigate
what to prioritize and when.
Hannah Clark (17:59):
This is really cool and I really love to hear
about, you know, the wholeorganization coming together
specifically to prioritize andmake time for accessibility.
And then it turned outto be such a positive
working experience as well.
That sounds so awesome.
But now that we're on thetopic of collaboration and kind
of working as a team acrossdifferent kinds of teams.
I'm wondering how this allworks out when you are working
(18:20):
with an organization that's gotmaybe several products in the
portfolio and there's multipleteams that are trying to address
accessibility issues acrossthose different, you know,
different products and features.
So how do you collaboratebetween product teams in
order to, you know, work inlockstep and kind of minimize
the amount of effort andcommunication that's involved
in order to ship these products?
Prerna Ramachandra (18:40):
Yeah, that's a great question.
So I think there are twodifferent ways or two
pillars I would like tosay to tackle this problem.
The first pillaris like structural.
If the organization has acentral accessibility org,
and I think most organizationstoday do in some capacity,
like where do they sit withinthe organization, right?
(19:01):
Like if they sit within asingle vertical, then it's
going to be very hard to breakthrough organizational silos
to work with other teams.
So you really have toensure that your team is
positioned in the right place.
And if it's not, then youas the product manager has
to do the work to reach outto all these other teams
to like, understand theirroadmaps, get to know them,
(19:22):
so you can work well together.
I think that's the first thing.
The second piece is ensuringthat, and this is also twofold,
both for the person managingand leading the central
accessibility org, and then theindividual feature team PMs.
Which is ensuring that you areboth in constant communication
about your roadmaps.
If you know what's coming up,this was the biggest I guess,
(19:44):
this was one of the biggestchallenges for our team,
and also the biggest area ofopportunity when I was working
on accessibility at Slack.
And later, when I startedworking on the desktop product,
I suddenly went from beingin the central accessibility
team to being one of thosefeature teams myself.
The most important thing isto ensure that when you're
doing roadmap planningat the beginning, you Are
(20:06):
looping in the accessibilityexperts you need to loop in.
And it starts right fromthe planning process
through the design process.
I like to say that accessibilityactually doesn't start with
the engineers, even though itrequires engineering expertise.
Sometimes it startswith the designer.
One of the things we gotinto, and if you're using
tools like Figma, they havea great tool set to actually
(20:27):
do accessibility designs orlike an accessibility specific
workflow within your design.
So, our designer would beinvolved from the very beginning
of the product development anddesign process to say, Okay,
how do you ensure the designsyou're creating are accessible?
Are there thingsthat are working?
Are there thingsthat are not working?
So this is where anythingfuture thinking for anything
that's an existing issue, right?
(20:49):
Like, if you're alreadyidentified a set of
accessibility issueswithin your product.
That is where that frameworkcame in very handy.
So it's like much as Itried my best, I, when I
was in the central org, Icouldn't keep track of every
single change, every singleroadmap change, everything
that the team was doing.
But because we had thiscentralized set of frameworks
that everyone was aware of as afeature team, product manager,
(21:11):
they could just refer to it andlike hand it to the designer,
hand it to their engineer, lookat it themselves and say, okay,
this accessibility bug came in.
Based on this framework,this is critical, medium,
or low priority, and thenI can use that to determine
whether or not I need toprioritize it immediately,
I can prioritize it later.
So having that central standardswas really helpful because
it ensured that someone whodoesn't have that expertise
(21:33):
still had something to referto when these bugs came in
and they can help prioritize.
And that also ensured thatthere's not one single
person in charge of tryingto sort of herd the cats,
for lack of a better word.
And say, okay, areyou doing it or not?
Because what I really wantedto ensure when I was working on
accessibility was I don't wantto be like a school principal
trying to tell you what to do.
(21:54):
And I don't thinkanyone wants that.
We're all adults here.
And I also like to believe thatevery 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, Ireally care about this.
I want to make sure ourproduct is accessible.
I either don't know how, orI don't know if we're going
to be given the authority toprioritize this or we're going
to have the time to do it.
And that's what we werereally trying to solve for.
(22:16):
And so I would say if you're afeature PM who's trying to make
your product accessible, see ifyou can develop a framework or
work with someone in your orgto develop a framework that you
and other people can refer to.
So you're not constantly havingto like wait for someone to
respond to you as to whethersomething is important or not.
You'll know yourself.
And you'll be empowered, andthen you're creating something
(22:37):
new, and you're building a newproduct, ensure that you can
reach out to the people withthe right expertise, and bake
in accessibility into the designprocess from the very beginning.
Because then that avoidsa problem where these bugs
come in in the future,and suddenly you're
scrambling to prioritize it.
You know it's going to beaccessible from launch.
Hannah Clark (22:55):
This is really interesting, and I, I want to
talk a little bit more on thelevel of implementation and
iteration because it's one thingto kind of analyze the features
that you have and prioritizeand implement changes and
improvements to the existingversion of the product or
whatever your enterprise clientsare asking for, but as time goes
on, new features are introduced,features become antiquated
(23:17):
or replaced with updates.
How do you integrate thatanalysis process or, or what's
like the proactive approachin order to ensure that future
features that are introducedinto the roadmap are accessible
from the day one as well?
Prerna Ramachandra (23:32):
Yes, that's a great question too.
So I'll give a veryspecific example.
And since you talked about useronboarding specifically in the
beginning, as I said, the firstthing when you're creating your
roadmap is to look at everyfeature, everything that you
have going on, anything new thatyou're building and know that.
You have to thinkabout accessibility.
I think that is somethingas a PM you have to keep
in mind every single time.
(23:53):
The other thing I wouldsay is knowing when, and
this is a little bit of PMintuition that develops over
time, and a little bit oflike looking at actual data.
It's knowing who in yourcustomer base can actually
help you ensure thatsomething is accessible or
something is not accessible.
Because I think as PMs, werely a lot on user research
(24:14):
to help us know what to build.
But we often forget thatthere are actually customers
and people out there whoare using our product in a
way that require, like, whoare, you know, users with
disabilities, who use theseaccessibility features.
So ensure that you have waysto incorporate them right
from the beginning into likeyour user research process.
So when you're thinking aboutthat future, future thing.
(24:36):
So the example, as Isaid, I was going to
give was user onboarding.
So another feature area wefound when we were doing our
initial analysis within Slackwas the onboarding experience
had accessibility gaps thatwe wanted to address, but we
also knew that the onboardingteam at Slack was going through
making some big redesignsto the onboarding experience
because the product hadevolved and grown since the
(24:57):
first time they did this.
And they needed, theywanted to make sure they
incorporated everything.
So we were actually able towork from, with that team
from the very beginningto ensure that the core
onboarding flow that they wereredesigning was accessible.
And so the way we did that waswe were intimately involved
in their roadmap planningfrom the very beginning.
And this is a very big project.
So whenever you have thesemajor projects is, I think,
(25:17):
when it's really important toget the right experts involved.
And our designer was actuallyinvolved throughout the design
process, so when they diduser research, when they were
doing user testing, when theywere creating their designs
in Figma, he was creatingthe accessibility spec for
those designs side by sidealong with them to make sure
that things were accessiblefrom the very beginning.
It was the same process weused at Slack when we were
(25:38):
redesigning the desktop app.
But secondly, what we found wasthere was a real opportunity
here to have an onboardingexperience specifically
centered around accessibilityfor the users who needed it.
I think the best exampleof this is Mac's, is Apple.
So Apple's products I thinkare really, really solid when
it comes to accessibility.
And so when you buy anew Mac, You can actually
(26:00):
choose to go through anonboarding workflow that
specifically shows you wherethe different accessibility
features are, how to usethem, et cetera, et cetera.
So we actually, our team, theaccessibility team, actually
built out that core onboardingexperience right from when
you enter the app when youenter the regular onboarding
flow, we ask you, do youcare about accessibility?
(26:21):
If you say yes, we takeyou through a step by step
workflow that shows you wherethe different tools are, the
different how to use keyboardnavigation, what the different
commands are, et cetera.
And then the other thing wewere able to do is use the data.
So when someone tells us they'reinterested in accessibility, we
take them through the workflow.
We were able to show themstrategically different
(26:41):
tooltips within the productthat allowed them to continue
that accessibility journey.
And the reason that all ofthis was possible is because
when, one, when we realizedthere were issues, When we
were actually outlining allthe issues with the existing
workflow, we saw that therewas like a huge gap because
there was no accessibilityonboarding experience.
And then the second thing waswe talked to a lot of customers.
(27:04):
So we talked to customerswho were sending in these
accessibility bug tickets to us.
Who were helping us figure outhow accessible the product was.
A lot of them said, youknow, there was nothing
to help me figure outhow to navigate Slack.
I had to figure it out myself.
And most of them are used todoing that, unfortunately,
because a lot of our productsdon't do that for them.
But it's still not like,you know, in my opinion,
(27:24):
it's not the ideal workflow.
And so I would say that whenyou're thinking about ex, you
know, future thinking, whatare the products I wanna build?
How is my product looking?
Rely a lot on user research.
Like, I don't know why it'snot being talked about in our
industry as much, but you haveto talk to your customers.
Like nothing replaces that.
I don't think AI is goingto tell you what to build.
It's the peoplewho are using it.
(27:45):
We're going to tellyou what to build.
So you have to talk to them.
And today there are companiesand tools that help you do that.
So if you're a big enterprisecompany, for example, and
your customers are enterpriseclients, I guarantee you they
will have an ERG, like anemployee resource group of
some sort that has employeeswith disabilities who would,
I am quite certain willbe very active in ensuring
they vet their vendors.
(28:06):
So that's a resourceyou 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 doaccessibility user testing.
So it's like usertesting.com,but specifically
for accessibility.
So like work with thoseentities, work with those
organizations, to kind of helpyou understand like, what you're
building, how you're building.
And then, the second thingI would say is as you're
(28:29):
starting the design process,and the iteration process,
Include someone, either haveyour designer take a course
to understand designing foraccessibility or have someone
with expertise and accessibilitybe involved in the process
right from the design process.
Make sure that your designshave accessibility specs.
Because that is what yourengineers are going to refer
to when deciding and figuringout how to build something.
(28:51):
Make sure that those designersand those accessibility experts
are involved in testing.
That's how you sort ofensure that everything you're
building is going to beaccessible moving forward.
Rather than having to,again, as I said, scramble
and then redoing it later.
Hannah Clark (29:04):
Anyone who's listened to the show for
a long time knows I loveprescriptive advice.
That's very specific in detail.
So thank you for offering thesevery specific recommendations
just to kind of put a bowon 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 toolong ago, and I want to bring
this back around to how are wegoing to measure success of our
accessibility features and thethings that we've implemented
(29:26):
and put so much effort intoworking together to create.
Naturally, I imagine, you know,when you're measuring activation
rate or some of those otherkinds of really key adoption
metrics, when we're thinkingabout the general populace,
we're looking at a verydifferent or possibly a somewhat
different process for segmentinghow effective your accessibility
features are, whether that'sfrom an onboarding standpoint
(29:47):
or any other accessibilityfeature throughout.
It's a multiple part question.
First of all, how do you segmentwhat you're measuring to ensure
that you're measuring thesuccess of the accessibility
features that you've builtrather than just the product
at large, are there any toolsthat you would use for that?
And do you have anyother tips or tricks for
ensuring that you're ableto integrate that kind of
(30:09):
data into future iterations?
Prerna Ramachandra (30:11):
Definitely.
So I'm going to give an answerthat is probably going to make
a lot of PMs uncomfortable.
And it's also somethingthat I'm uncomfortable with,
which is you cannot rely onquantitative data to Understand
whether your accessibilityfeatures are working and whether
your product is accessible.
And some of it is becausemorally and ethically you
(30:32):
cannot really segment usersbased on accessibility
because you're trying to makeassumptions about whether or
not someone has a disability.
And even if you use data likemeasuring how many users are
using keyboard navigation orhow many users have turned on
screen reader commands, Thatstill can potentially exclude a
large group of the population,like, for example, I mentioned
(30:54):
neurodivergence, like, arepeople with neurodivergence
are able to use your productor is it too overwhelming?
There's certain specificfeatures around that.
For example, it's Slack and alot of any, any product that has
any sort of form of animation,you have the ability to turn off
that animation because for somefolks it can cause seizures.
So that's another thing that'skind of hard to measure.
(31:15):
So, there's only so much youcan get from your quantitative
measurement because there's,it's really hard to segment
users in the way that you wouldnormally segment your user base
because you're making a lot ofassumptions about someone that
you generally don't want to do.
And also, it's probablynot going to be very
effective, right?
There's a lot of things aroundlike hidden disabilities and
(31:35):
also it fails to take intoaccount the situational thing
that I was talking about atthe beginning of the episode.
What I've found works thebest for accessibility and
measuring whether or notyour product is accessible.
And whether or not featuresthat are specifically around
accessibility are workingis going back to your users
and just like asking them.
(31:55):
So qualitative research is thebest way to measure the success
of accessibility in my opinion.
And also it's based ona lot of what I've seen
working on accessibilityin the past and now.
I'll give anothervery specific example.
So another accessibilityfeature that we built at
Slack was essentially an API.
(32:16):
That a lot of differentteams could leverage to
easily build keyboardnavigation into their product.
So, like, a keyboard Navibecause a lot of teams didn't
really, it does requirespecialized expert knowledge.
So the API was supposed tomake it easier for teams.
So the way we measuredsuccess in that case was
actually seeing how many teamswere leveraging that API.
(32:36):
Because it wasn't somethingthat was required, teams could
try to build it on their own.
So we were like, okay, if yourteam is leveraging this API, it
means we, as an accessibilityteam, were successful in
building something that youwere able to leverage because
we know it works really well.
So that was less of a usermeasure and more of like
an internal team measure.
The way we measure successfor our users, as I said,
was really just asking.
(32:57):
So when we launched theonboarding workflow, we got
some quantitative data interms of how many users were
opting into the accessibilityonboarding experience.
But for the most part, wehad worked very hard to
assemble together teamsof users who we would talk
to about accessibility.
But also, generally, wheneveryou launch something, I'm
assuming you're going to dosome qualitative research
(33:18):
to understand the impact.
We made sure that thosegroups included users.
Who had asked aboutaccessibility, were
using accessibilityfeatures, et cetera.
And it was a lot oflike conversation,
qualitative measurement,qualitative research.
Because not only do you wantto know whether someone's
using your product, but youwant to know whether someone's
able to use it properly.
Properly in order to completethe tasks they want to complete.
(33:40):
So quantitatively, if yourproduct is doing very well
with the majority of users,that's already giving you
directional indication of thefact that whether or not your
product is accessible, butif you're wanting to talk to
those specific users aboutaccessibility, you're going to
have to find those users andyou're going to have to like
specifically do the qualitativeresearch and analysis to make
sure that it's like workingthe way you want it to work.
(34:03):
And I know that's not agreat answer because as a
PM, you're really lookingfor the numbers and the data.
But I also think part of thejob of PM is to be okay with
that level of uncertainty.
And I will say this, which isagain, probably not going to
be the best answer, but you'renever going to be perfect.
No product is ever going toperfectly check off every
single box when it comesto accessibility because
(34:24):
again, like a lot of this issituational, which is again,
why it's really importantto continue to have those
conversations with your users.
And I will say, especially userswho care about accessibility
are going to be very vocalbecause they're not used
to getting the things theyneed to just do their jobs.
So they have to be vocal inorder to just survive and
(34:44):
like, do their jobs properly.
And so I think that you havea huge resource there and like
something I had to learn morethan ever in my career as a
PM, it was when I worked onaccessibility that I really
truly understood the importanceof talking and listening to
your users because they couldgive you the best information
of what you need to hear abouthow your product is doing.
(35:04):
And people are not talkingabout how important that
qualitative research is and thathuman to human connection is.
But I think that's trulygoing to tell you whether
your product is working.
And when it comes toaccessibility, it's
really important to makesure you talk to people.
Hannah Clark (35:16):
I couldn't agree more.
Yeah, this is a verypro user research show.
We did an episode a whileback with Steve Portigal
on how to interview users.
That's like one of our favoriteof all times, because it's,
it's all about just talkingto people, letting people
really tell you their authenticexperience and not trying
to guide the conversation,eliminating your own bias.
So important for a productdevelopment process.
(35:36):
Well, thank you so muchfor this has been like
such a fun conversation.
I really appreciate yourperspective on this matter.
And what's such specificstories to tell around and
such a well known product.
So we can all reallyunderstand and get behind,
you know, how these featureskind of come to life.
So I really appreciate this.
Where can people follow yourwork online or connect with you?
Prerna Ramachandra (35:56):
I'm going to be on LinkedIn.
It's just my first name, lastname, Prerna Ramachandra.
You can also reach outto me through my website.
It's just PrernaRamachandra.me.
Hannah Clark (36:05):
Fabulous.
Well, thank you somuch for being here.
Prerna Ramachandra (36:07):
Thank you so much, Hannah.
This was great.
Hannah Clark (36:12):
Thanks for listening in.
For more great insights,how-to guides and tool reviews,
subscribe to our newsletter attheproductmanager.com/subscribe.
You can hear more conversationslike this by subscribing to
The Product Manager, whereveryou get your podcasts.
I think it's time we admitted that talking
about accessibility tendsto make us uncomfortable.
In a product context, we tendto prioritize features with
the biggest impact and thelargest percentage of users.
So when we talk aboutbuilding for accessibility,
it feels like a loaded topic.
Where on the roadmap do wefit in features that make a
big impact for a relativelysmall percentage of users?
How do we know whataccessibility should look
(00:24):
like for our product whenaccessible means different
things to different people?
And how do we do all of thiswithout making assumptions or
inadvertently offending theusers we're trying to support?
My guest today is PrernaRamachandra, Principal
Product Manager at Yahoo.
Prior to joining Yahoo,Prerna was a Senior Product
Manager at Slack, whereshe was instrumental in
auditing and developingaccessible features for the
product's diverse user base.
(00:44):
What you're about to hearis part case study, part
playbook on the business casefor accessibility and the
most efficient and ethicalways to make your product
more welcoming to everyone.
Let's jump in.
Welcome back to TheProduct Manager Podcast.
We are here today withPrerna Ramachandra.
Prerna, thank you so muchfor making time in your busy
schedule to join us today.
Prerna Ramachandra (01:04):
Thank you so much for having me.
It's great to be here.
Hannah Clark (01:06):
Can you tell us a little bit about your
background and how you gotto where you are today?
Prerna Ramachandra (01:10):
So I'm currently a Principal
Product Manager at Yahoo.
I've been here for abouta year and a half now.
And prior to Yahoo, I wasworking at Slack and I was
at Slack right before theygot acquired by Salesforce
and then through theSalesforce acquisition.
And at Slack, I was primarilyleading the accessibility
and design systems teambefore I transitioned over
to working on their coredesktop experiences app.
(01:33):
My work from one team to theother kind of, they both bled
into each other, which I'dlove to dive into later today.
And then prior to Slack, Iwas working at the Washington
Post where I led theredesign of their homepage
and the replatform of thearticle page experience.
So I've had somemedia experience, some
big tech experience.
And I like to say thatmy interest in product
(01:54):
specifically aligns withthe intersection of product
technology and storytelling.
And the ways in which peopleuse stories to communicate with
one another and how tech can bean effective tool to do that.
Hannah Clark (02:05):
Which is so perfect since you're here
today telling your story.
Obviously it's somethingwe're both passionate about,
storytelling, and todaywe're going to be focusing
on something that's maybe alittle bit more niche, but
definitely an issue that Ithink we don't talk about
enough, which is accessibility,and specifically the
intersection of accessibilityand user onboarding.
So just to kick us off, whywould you say, like in your
experience working in thisfield and in this space, Why
(02:27):
does accessibility often gettreated like an afterthought?
And what's the business case forbaking it in from the beginning?
Prerna Ramachandra (02:33):
Definitely.
So I like to just start byspeaking to a statement that
I truly, truly believe in myheart, which is we live in a
day and age when I don't believetechnology is a luxury anymore.
I grew up in the nineties,dating myself a bit here where
technology was still a novelty.
The internet wasstill a novelty.
Not everyone had access to it,nor did everyone need to, but
(02:55):
we live in a day and age whereevery one of our essential
services is in some shape,way, shape or form digitized.
And that means that everysingle person in the world
should be able to use it easily.
And people with disabilitiesare generally treated as an
afterthought in our society.
I think so many of ourservices are not as
accessible, but technologyis uniquely positioned to
(03:17):
actually quite easily bake inaccessibility into what it does.
And technology is also uniquelypositioned to make the lives
of everyone, including peoplewith disabilities, a lot easier.
And so I think this isone of the main reasons,
like a moral and ethicalstandpoint, I think it's
really important to prioritize.
Why it gets treated as anafterthought, quite frankly,
is because I don't think mostorganizations fully understand
(03:40):
the business case for it.
That's number one.
And number two, I think it'sbecause People feel like
accessibility requires somereally deep technical expertise.
And so they don't alwaysfeel like they have that
expertise or they don'talways think about it.
It's not bakedinto our processes.
And as a result, we just ignoreit until someone is worried
(04:02):
that they're going to get sued.
Or that they're going tolose a customer that has
accessibility requirements.
And all of a sudden yourteams are scrambling to try
to figure out what's wrongand how to build it in.
To answer the second partof your question, which is
like, what is the businesscase for accessibility?
And I did touch onthis in my first point.
The reality is that fortechnology to succeed, you want
(04:22):
to have more users, right, andfor most of us, we get paid
the more our product gets used.
And the way more people useit is if they can access it.
So at a core level.
Accessibility is just reallyimportant because more people
can use your products and whenmore people use your products
you just make more money.
The flip side of it is youdon't want to get sued and
if you get sued there's achance you're gonna have
(04:42):
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 toadd, and I'll dive into this
more in detail, and somethingthat I'm personally very
passionate about within thefield of accessibility, which
is we always limit the idea ofaccessibility to Ensure that
it's usable by screen readers.
(05:02):
Ensure that you can do keyboardnavigation, but I think we
need to move beyond thatdefinition of accessibility and
really think about how do youensure that everyone in every
circumstance, like your users inevery circumstance can use that
product because oftentimes wedon't think about accessibility
as something that can besituational and conditional.
So one example I always liketo give is voice commands or
(05:24):
using voice to use your product.
We always think it'ssomething that's easier
if you have low eyesight.
Like my dad, he's like mucholder, he might not be able
to see small text on hisscreen, so he likes using
his voice to control a lotof things on his phone.
But if you're driving, you don'thave use of your hands either,
you don't have use of youreyes in the same way, so you
could still use voice commands.
(05:44):
And so when you think aboutaccessibility, you can think
about it as encompassinga situation rather than an
individual or an individualproblem, and that actually
expands your definitionand makes you realize
you're actually leavingon the table a huge use
case and a huge user base.
Which is probably notgood for your business.
And so there is like a practicalbusiness case to be made for why
this is important to prioritizefrom the very beginning.
Hannah Clark (06:06):
I think that that's so resonant.
I think that applies toaccessibility and digital
products as well as physicalproducts and physical spaces.
I really love the framing ofbeing accessible to a situation
rather than a specific use case.
I experienced that myself whenI was pushing around a stroller
and I noticed how many spaceswere designed for, you know,
a single pedestrian, you know,single file kind of thing.
(06:28):
And you realize that there areso many different contexts in
which someone might requirean accessibility feature or
accommodation or have somethingdesigned with accessibility
in mind, because that is socross applicable to many ages
and stages and phases of life.
So, yeah, I really like thatway of thinking about it, and
I'd love to dig a little bitdeeper into that in a moment.
(06:49):
You mentioned that you want totalk a little bit more about
your experience at Slack, andI would really like to dig into
some of the projects that youworked on during that time,
and particularly accessibilityonboarding workflows through
a lens of accessibility.
Walk me through a little bit,how did you approach like a
state of affairs analysis toevaluate what the product's
current accessibilitystatus was and how did you
move forward from that?
Prerna Ramachandra (07:09):
Definitely.
So when I started at Slack,one of the first projects
that I worked on was actuallyfiguring out how accessible the
product was and what we coulddo to exactly what you said.
How, what kind of frameworksdid we have to do a state
of product analysis?
And we didn't have anythingwhen I joined Slack was at
a point where it was reallygoing after big enterprise
(07:31):
customers that have kind ofdone really well in the small
to medium business market.
And as it was going afterthese big enterprise customers,
it was realizing that therewere a very strict set of
regulations for their vendorsin terms of accessibility.
And so the first thing I did wasactually develop an internal set
of standards, which we call theSlack accessibility standards.
(07:51):
Which used preexisting standardslike WCAG, but also took into
account Slack's unique productsand what accessibility would
mean for those products.
And we put together like aframework that allowed you to go
through the product and analyzewhether it met certain criteria.
And as a result of thatanalysis, we assigned a
(08:12):
grade like A, B, or C todifferent features within
the product to analyzehow accessible they were.
And this was very mucha quantitative plus
qualitative analysis.
So we had the list of criteria.
Some of it was based onjust like very simple, like
task management, like, iseverything keyboard accessible?
Is everything screenreader accessible?
(08:33):
And then other things wouldbe something that were a
little bit more intangible.
So, for example, Snap Slackis a communications product.
And one thing it does reallywell is notifications.
You need to be notified, butthis was during the pandemic.
So a lot of peoplewere working from home.
A lot of people wereworking remotely.
And so we did hear fromcustomers that there was
notification overload and itspecifically impacted anyone
(08:55):
who identified as neurodivergentbecause they would feel really
overwhelmed and they wouldn't beable to do their tasks properly.
So that was a littlebit more intangible.
It's not something thatyou really see in a
lot of accessibilityguidelines out there.
So we incorporated all ofthat to create this framework.
They use this framework toassign grades to each of
the feature areas and thegrades were purely based
(09:16):
on can they do the task andhow quickly can they do it.
So it helped mark asense of urgency to the
issues and what was mostimportant and what was not.
So that was thefirst thing we did.
We used that to do a stateof product analysis and
then we went to leadershipand said, okay, this
is the entire product.
This is how it fallsinto the range.
And these are the issueswe believe need to
(09:36):
be fixed immediatelybecause they're actually
fundamentally the product.
broken for a group ofcustomers as a result
of this not being done.
The cool thing about thisframework was also that it
wasn't just applied to existingproducts, but if you were
developing new products, youcould very well apply that
framework in order to understandwhat you need to check off
before you can launch this.
It was also something thatyou could use the future
(09:58):
thinking and you could usefor future products as well.
So that was thefirst thing we did.
And then we did a lot of work.
I did a lot of workto specifically work
with individual teamsin order to help them
know what to prioritizebased on this framework.
Because everyone has a roadmap.
No one wants to blow up theirroadmap in order to meet
something new that's coming up.
(10:20):
Everyone has like a set ofthings they've committed to.
So I worked with theseindividual teams so that
they knew exactly what thecritical items were for them.
So that when we went toleadership as a collective
and said, This is whatneeds to be prioritized.
This is what needs to be fixed.
We could go to them witha very clear plan, and
we could also tell themwhat the tradeoffs were.
(10:41):
So, what would be the levelof effort to fix each of these
items, and what would getpushed out of the roadmap if
we had to accommodate this,and what would the impact be?
So, I always believe that whenit comes to accessibility,
and this is true for a lotof things within product,
but with accessibility I sawspecifically, you have to
understand the balance betweenworking with the individual
(11:03):
team that is responsible forthe feature area, As well as
navigating, how do you workwith leadership to get buy
in to prioritize this work?
And I was very fortunate thatthe leadership at Slack was
very committed to prioritizingthis work and doing it right.
What they really needed fromus was the clear information.
Okay, what's thelevel of effort?
(11:23):
What's the timeline?
What are the tradeoffs?
And what's the impact.
So that's what we wereable to go to them with.
So it's, it was a lot of workin people management and also a
lot of work with your engineerstechnically to provide the
analysis that they needed.
Hannah Clark (11:38):
This is so critically important.
I think that the buy inthere's nothing more critical
to making sure that thesefeatures get shipped than to
actually get the buy in andlike you said, to do it right.
I would really like to get alittle bit more granular as far
as you mentioned the trade off.
So what would atrade off look like?
Like how exactly would you,you know, if you were to kind
of give an anecdote or like anexample of how that might be
presented, how would you phrasethat in order to kind of put
(12:01):
everything in context and kindof explain the scope of the
project and how, where it fallson the critical items list?
Prerna Ramachandra (12:08):
The team that I would say was
most impacted by the workthat we did was a team that
was working on the coremessaging part of the project.
And it's because they had, theyowned the largest surface area.
They owned everything fromthe experience of like someone
typing a message and sendingit, to receiving a message in
that entire message portal.
They had members on theirteam who owned channels.
(12:29):
If you use Slack, like youjust know this is the core
of the Slack experience.
So it made sense that theywould have like the largest
number of items they hadto tackle because not only
did they own the largestsurface area, it was also the
most critical surface area.
Like Slack exists because peoplesend and receive messages.
So it was the mostcritical surface area.
It had the most high impactissues with an accessibility
(12:50):
that they had to handle.
So to give you a very specificexample, when we went to them
with this list of issues, I'mnot going to give specific
numbers here, but I'm goingto give some hypotheticals.
I'm going to use 100just because it's easier
to like do percentages.
So I went into them with, let'ssay a list of 100 issues and
said, this is all that needsto be tackled in order to
(13:11):
ensure that your product isat minimal usable for every
single person who uses a screenreader, who uses keyboard
navigation, who identifiesas someone with a disability.
So the first thing I did wassat down with the PM and said,
Okay, this is a list of issuesthat we've identified based
on this framework we have.
This was actually a verycritical step, but that PM
was able to like work withme to say, Okay, I understand
(13:32):
why you said these hundreditems are critical, but
I actually only think 80percent of this is critical.
Because this is the userdata we have and the user
information we have onhow people are using this.
So if you think thisparticular workflow is
really critical, they areactually doing it differently.
There's actually workaroundsand solutions for this.
So that first analysis wasreally important because
(13:53):
we were able to thencut down that 100 to 80.
And I think anyone who hasan accessibility, central
accessibility org, it'sreally important to have that
conversation with the productmanager of the product itself.
Because they actuallyknow their users the best.
And so we were able to cutdown that list quite a bit.
Then the second thing we didwas, okay, look at the issues
and see which of them are inproduct areas or feature areas
(14:16):
that are going to be eitherredesigned 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 theredesign and we don't have
to fix this issue right now.
Right, if this particulararea is going to be
deprecated, we don't haveto fix this issue right now.
So that got rid of, let'ssay, another like 10 issues.
So then we had about 70 thatwe had to tackle with the team.
(14:38):
We sat down with theirengineers, this is where
it's really important tohave at least one in house
accessibility expert.
We were really lucky wehad a really, really solid
engineer with that expertise.
He was able to come in and workwith their engineering team
to help them understand and dolike a level of effort analysis
for each of those 70 issues.
We then sat down with theproduct manager and said,
okay, how many of these 70issues can you just prioritize
(14:59):
in your current sprint oryour upcoming sprint within
this quarter without worryingabout anything slipping?
How much of it canyou just fit it in?
Most teams usually tend tohave some buffer, especially
if you're a team that's workingon a product that's already
released to manage like incomingbugs and issues like that.
So this kind of got pulledinto that workflow and they
(15:20):
said, okay, we could probablydo like 20 of these without
having severe roadmap impacts.
So we didn't even need to worryabout that with leadership.
So then we were leftwith maybe half of that.
So we were able to reallycut it down and then with
the remaining, let's say50 issues, that's where
we had to say, okay.
What are some big productareas this quarter that could
potentially get pushed outor delayed if all of these
(15:42):
issues were prioritized?
And that is the moment wherewe needed leadership to step
in and like help us navigateand negotiate on what to do.
And so there was a featurearea, there was a feature that
the team was set to releasewithin that quarter that was
really important for a bigcustomer, but the same big
customer was also the onethat was asking us to fix
(16:02):
these accessibility issueswithin a certain time frame.
And so then we were able tosort of go to leadership and
say, this is the trade off.
This is what we're working with.
And then we were ableto use their help.
We were able to work withthe account managers for
that customer, go to thecustomer and say, okay,
this is where we're at.
Like, what wouldyou like to see?
And so I think the, the mostimportant thing here is to do
(16:23):
as much work as you can do atyour level, at the individual
contributor level, at the, atthe Senior PM, principal PM,
group PM level to ensure thatyou have done as much as you
can to prioritize all the workyou can do creatively within
your team and you bring inleadership only when they're
going to be like big areas.
And in this case, what washelpful was that it was the
(16:45):
same customer that was beingimpacted by both sets of issues.
And so we were able to workwith them to negotiate which
one they wanted first andwhich ones could come later.
And then based on that, wewere able to say, okay, let's
fix these 10 issues in thisquarter that would not delay
the other feature so much.
Let's fix these 10 issuesin the next quarter.
And then this wasreally the first quarter
(17:07):
that we did all this.
And then in subsequent quarters,what we were able to do was
actually in the quarterlyplanning cycle itself, work
with the teams to just carveout dedicated time where they
would just do accessibility.
And this is where it'sreally important to get the
full organization involved,because what we were able
to do was do these likeaccessibility sprint weeks.
We used to coincide themwith global accessibility
(17:27):
awareness day, wheneverthe quarter felt there.
So everyone on the team, allthe different engineering
squads were working togetherto just work on accessibility
issues for that sprint.
And it also was like anice community environment.
We also had some workshopswhere we tell teams
about accessibility.
So it was like, it workedout really well, but I can
say there's a lot of hardwork in the beginning.
(17:49):
And especially when thereare those big trade offs
between features, that iswhere you have to loop in
leadership in order to helpyou negotiate and navigate
what to prioritize and when.
Hannah Clark (17:59):
This is really cool and I really love to hear
about, you know, the wholeorganization coming together
specifically to prioritize andmake time for accessibility.
And then it turned outto be such a positive
working experience as well.
That sounds so awesome.
But now that we're on thetopic of collaboration and kind
of working as a team acrossdifferent kinds of teams.
I'm wondering how this allworks out when you are working
(18:20):
with an organization that's gotmaybe several products in the
portfolio and there's multipleteams that are trying to address
accessibility issues acrossthose different, you know,
different products and features.
So how do you collaboratebetween product teams in
order to, you know, work inlockstep and kind of minimize
the amount of effort andcommunication that's involved
in order to ship these products?
Prerna Ramachandra (18:40):
Yeah, that's a great question.
So I think there are twodifferent ways or two
pillars I would like tosay to tackle this problem.
The first pillaris like structural.
If the organization has acentral accessibility org,
and I think most organizationstoday do in some capacity,
like where do they sit withinthe organization, right?
(19:01):
Like if they sit within asingle vertical, then it's
going to be very hard to breakthrough organizational silos
to work with other teams.
So you really have toensure that your team is
positioned in the right place.
And if it's not, then youas the product manager has
to do the work to reach outto all these other teams
to like, understand theirroadmaps, get to know them,
(19:22):
so you can work well together.
I think that's the first thing.
The second piece is ensuringthat, and this is also twofold,
both for the person managingand leading the central
accessibility org, and then theindividual feature team PMs.
Which is ensuring that you areboth in constant communication
about your roadmaps.
If you know what's coming up,this was the biggest I guess,
(19:44):
this was one of the biggestchallenges for our team,
and also the biggest area ofopportunity when I was working
on accessibility at Slack.
And later, when I startedworking on the desktop product,
I suddenly went from beingin the central accessibility
team to being one of thosefeature teams myself.
The most important thing isto ensure that when you're
doing roadmap planningat the beginning, you Are
(20:06):
looping in the accessibilityexperts you need to loop in.
And it starts right fromthe planning process
through the design process.
I like to say that accessibilityactually doesn't start with
the engineers, even though itrequires engineering expertise.
Sometimes it startswith the designer.
One of the things we gotinto, and if you're using
tools like Figma, they havea great tool set to actually
(20:27):
do accessibility designs orlike an accessibility specific
workflow within your design.
So, our designer would beinvolved from the very beginning
of the product development anddesign process to say, Okay,
how do you ensure the designsyou're creating are accessible?
Are there thingsthat are working?
Are there thingsthat are not working?
So this is where anythingfuture thinking for anything
that's an existing issue, right?
(20:49):
Like, if you're alreadyidentified a set of
accessibility issueswithin your product.
That is where that frameworkcame in very handy.
So it's like much as Itried my best, I, when I
was in the central org, Icouldn't keep track of every
single change, every singleroadmap change, everything
that the team was doing.
But because we had thiscentralized set of frameworks
that everyone was aware of as afeature team, product manager,
(21:11):
they could just refer to it andlike hand it to the designer,
hand it to their engineer, lookat it themselves and say, okay,
this accessibility bug came in.
Based on this framework,this is critical, medium,
or low priority, and thenI can use that to determine
whether or not I need toprioritize it immediately,
I can prioritize it later.
So having that central standardswas really helpful because
it ensured that someone whodoesn't have that expertise
(21:33):
still had something to referto when these bugs came in
and they can help prioritize.
And that also ensured thatthere's not one single
person in charge of tryingto sort of herd the cats,
for lack of a better word.
And say, okay, areyou doing it or not?
Because what I really wantedto ensure when I was working on
accessibility was I don't wantto be like a school principal
trying to tell you what to do.
(21:54):
And I don't thinkanyone wants that.
We're all adults here.
And I also like to believe thatevery 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, Ireally care about this.
I want to make sure ourproduct is accessible.
I either don't know how, orI don't know if we're going
to be given the authority toprioritize this or we're going
to have the time to do it.
And that's what we werereally trying to solve for.
(22:16):
And so I would say if you're afeature PM who's trying to make
your product accessible, see ifyou can develop a framework or
work with someone in your orgto develop a framework that you
and other people can refer to.
So you're not constantly havingto like wait for someone to
respond to you as to whethersomething is important or not.
You'll know yourself.
And you'll be empowered, andthen you're creating something
(22:37):
new, and you're building a newproduct, ensure that you can
reach out to the people withthe right expertise, and bake
in accessibility into the designprocess from the very beginning.
Because then that avoidsa problem where these bugs
come in in the future,and suddenly you're
scrambling to prioritize it.
You know it's going to beaccessible from launch.
Hannah Clark (22:55):
This is really interesting, and I, I want to
talk a little bit more on thelevel of implementation and
iteration because it's one thingto kind of analyze the features
that you have and prioritizeand implement changes and
improvements to the existingversion of the product or
whatever your enterprise clientsare asking for, but as time goes
on, new features are introduced,features become antiquated
(23:17):
or replaced with updates.
How do you integrate thatanalysis process or, or what's
like the proactive approachin order to ensure that future
features that are introducedinto the roadmap are accessible
from the day one as well?
Prerna Ramachandra (23:32):
Yes, that's a great question too.
So I'll give a veryspecific example.
And since you talked about useronboarding specifically in the
beginning, as I said, the firstthing when you're creating your
roadmap is to look at everyfeature, everything that you
have going on, anything new thatyou're building and know that.
You have to thinkabout accessibility.
I think that is somethingas a PM you have to keep
in mind every single time.
(23:53):
The other thing I wouldsay is knowing when, and
this is a little bit of PMintuition that develops over
time, and a little bit oflike looking at actual data.
It's knowing who in yourcustomer base can actually
help you ensure thatsomething is accessible or
something is not accessible.
Because I think as PMs, werely a lot on user research
(24:14):
to help us know what to build.
But we often forget thatthere are actually customers
and people out there whoare using our product in a
way that require, like, whoare, you know, users with
disabilities, who use theseaccessibility features.
So ensure that you have waysto incorporate them right
from the beginning into likeyour user research process.
So when you're thinking aboutthat future, future thing.
(24:36):
So the example, as Isaid, I was going to
give was user onboarding.
So another feature area wefound when we were doing our
initial analysis within Slackwas the onboarding experience
had accessibility gaps thatwe wanted to address, but we
also knew that the onboardingteam at Slack was going through
making some big redesignsto the onboarding experience
because the product hadevolved and grown since the
(24:57):
first time they did this.
And they needed, theywanted to make sure they
incorporated everything.
So we were actually able towork from, with that team
from the very beginningto ensure that the core
onboarding flow that they wereredesigning was accessible.
And so the way we did that waswe were intimately involved
in their roadmap planningfrom the very beginning.
And this is a very big project.
So whenever you have thesemajor projects is, I think,
(25:17):
when it's really important toget the right experts involved.
And our designer was actuallyinvolved throughout the design
process, so when they diduser research, when they were
doing user testing, when theywere creating their designs
in Figma, he was creatingthe accessibility spec for
those designs side by sidealong with them to make sure
that things were accessiblefrom the very beginning.
It was the same process weused at Slack when we were
(25:38):
redesigning the desktop app.
But secondly, what we found wasthere was a real opportunity
here to have an onboardingexperience specifically
centered around accessibilityfor the users who needed it.
I think the best exampleof this is Mac's, is Apple.
So Apple's products I thinkare really, really solid when
it comes to accessibility.
And so when you buy anew Mac, You can actually
(26:00):
choose to go through anonboarding workflow that
specifically shows you wherethe different accessibility
features are, how to usethem, et cetera, et cetera.
So we actually, our team, theaccessibility team, actually
built out that core onboardingexperience right from when
you enter the app when youenter the regular onboarding
flow, we ask you, do youcare about accessibility?
(26:21):
If you say yes, we takeyou through a step by step
workflow that shows you wherethe different tools are, the
different how to use keyboardnavigation, what the different
commands are, et cetera.
And then the other thing wewere able to do is use the data.
So when someone tells us they'reinterested in accessibility, we
take them through the workflow.
We were able to show themstrategically different
(26:41):
tooltips within the productthat allowed them to continue
that accessibility journey.
And the reason that all ofthis was possible is because
when, one, when we realizedthere were issues, When we
were actually outlining allthe issues with the existing
workflow, we saw that therewas like a huge gap because
there was no accessibilityonboarding experience.
And then the second thing waswe talked to a lot of customers.
(27:04):
So we talked to customerswho were sending in these
accessibility bug tickets to us.
Who were helping us figure outhow accessible the product was.
A lot of them said, youknow, there was nothing
to help me figure outhow to navigate Slack.
I had to figure it out myself.
And most of them are used todoing that, unfortunately,
because a lot of our productsdon't do that for them.
But it's still not like,you know, in my opinion,
(27:24):
it's not the ideal workflow.
And so I would say that whenyou're thinking about ex, you
know, future thinking, whatare the products I wanna build?
How is my product looking?
Rely a lot on user research.
Like, I don't know why it'snot being talked about in our
industry as much, but you haveto talk to your customers.
Like nothing replaces that.
I don't think AI is goingto tell you what to build.
It's the peoplewho are using it.
(27:45):
We're going to tellyou what to build.
So you have to talk to them.
And today there are companiesand tools that help you do that.
So if you're a big enterprisecompany, for example, and
your customers are enterpriseclients, I guarantee you they
will have an ERG, like anemployee resource group of
some sort that has employeeswith disabilities who would,
I am quite certain willbe very active in ensuring
they vet their vendors.
(28:06):
So that's a resourceyou 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 doaccessibility user testing.
So it's like usertesting.com,but specifically
for accessibility.
So like work with thoseentities, work with those
organizations, to kind of helpyou understand like, what you're
building, how you're building.
And then, the second thingI would say is as you're
(28:29):
starting the design process,and the iteration process,
Include someone, either haveyour designer take a course
to understand designing foraccessibility or have someone
with expertise and accessibilitybe involved in the process
right from the design process.
Make sure that your designshave accessibility specs.
Because that is what yourengineers are going to refer
to when deciding and figuringout how to build something.
(28:51):
Make sure that those designersand those accessibility experts
are involved in testing.
That's how you sort ofensure that everything you're
building is going to beaccessible moving forward.
Rather than having to,again, as I said, scramble
and then redoing it later.
Hannah Clark (29:04):
Anyone who's listened to the show for
a long time knows I loveprescriptive advice.
That's very specific in detail.
So thank you for offering thesevery specific recommendations
just to kind of put a bowon 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 toolong ago, and I want to bring
this back around to how are wegoing to measure success of our
accessibility features and thethings that we've implemented
(29:26):
and put so much effort intoworking together to create.
Naturally, I imagine, you know,when you're measuring activation
rate or some of those otherkinds of really key adoption
metrics, when we're thinkingabout the general populace,
we're looking at a verydifferent or possibly a somewhat
different process for segmentinghow effective your accessibility
features are, whether that'sfrom an onboarding standpoint
(29:47):
or any other accessibilityfeature throughout.
It's a multiple part question.
First of all, how do you segmentwhat you're measuring to ensure
that you're measuring thesuccess of the accessibility
features that you've builtrather than just the product
at large, are there any toolsthat you would use for that?
And do you have anyother tips or tricks for
ensuring that you're ableto integrate that kind of
(30:09):
data into future iterations?
Prerna Ramachandra (30:11):
Definitely.
So I'm going to give an answerthat is probably going to make
a lot of PMs uncomfortable.
And it's also somethingthat I'm uncomfortable with,
which is you cannot rely onquantitative data to Understand
whether your accessibilityfeatures are working and whether
your product is accessible.
And some of it is becausemorally and ethically you
(30:32):
cannot really segment usersbased on accessibility
because you're trying to makeassumptions about whether or
not someone has a disability.
And even if you use data likemeasuring how many users are
using keyboard navigation orhow many users have turned on
screen reader commands, Thatstill can potentially exclude a
large group of the population,like, for example, I mentioned
(30:54):
neurodivergence, like, arepeople with neurodivergence
are able to use your productor is it too overwhelming?
There's certain specificfeatures around that.
For example, it's Slack and alot of any, any product that has
any sort of form of animation,you have the ability to turn off
that animation because for somefolks it can cause seizures.
So that's another thing that'skind of hard to measure.
(31:15):
So, there's only so much youcan get from your quantitative
measurement because there's,it's really hard to segment
users in the way that you wouldnormally segment your user base
because you're making a lot ofassumptions about someone that
you generally don't want to do.
And also, it's probablynot going to be very
effective, right?
There's a lot of things aroundlike hidden disabilities and
(31:35):
also it fails to take intoaccount the situational thing
that I was talking about atthe beginning of the episode.
What I've found works thebest for accessibility and
measuring whether or notyour product is accessible.
And whether or not featuresthat are specifically around
accessibility are workingis going back to your users
and just like asking them.
(31:55):
So qualitative research is thebest way to measure the success
of accessibility in my opinion.
And also it's based ona lot of what I've seen
working on accessibilityin the past and now.
I'll give anothervery specific example.
So another accessibilityfeature that we built at
Slack was essentially an API.
(32:16):
That a lot of differentteams could leverage to
easily build keyboardnavigation into their product.
So, like, a keyboard Navibecause a lot of teams didn't
really, it does requirespecialized expert knowledge.
So the API was supposed tomake it easier for teams.
So the way we measuredsuccess in that case was
actually seeing how many teamswere leveraging that API.
(32:36):
Because it wasn't somethingthat was required, teams could
try to build it on their own.
So we were like, okay, if yourteam is leveraging this API, it
means we, as an accessibilityteam, were successful in
building something that youwere able to leverage because
we know it works really well.
So that was less of a usermeasure and more of like
an internal team measure.
The way we measure successfor our users, as I said,
was really just asking.
(32:57):
So when we launched theonboarding workflow, we got
some quantitative data interms of how many users were
opting into the accessibilityonboarding experience.
But for the most part, wehad worked very hard to
assemble together teamsof users who we would talk
to about accessibility.
But also, generally, wheneveryou launch something, I'm
assuming you're going to dosome qualitative research
(33:18):
to understand the impact.
We made sure that thosegroups included users.
Who had asked aboutaccessibility, were
using accessibilityfeatures, et cetera.
And it was a lot oflike conversation,
qualitative measurement,qualitative research.
Because not only do you wantto know whether someone's
using your product, but youwant to know whether someone's
able to use it properly.
Properly in order to completethe tasks they want to complete.
(33:40):
So quantitatively, if yourproduct is doing very well
with the majority of users,that's already giving you
directional indication of thefact that whether or not your
product is accessible, butif you're wanting to talk to
those specific users aboutaccessibility, you're going to
have to find those users andyou're going to have to like
specifically do the qualitativeresearch and analysis to make
sure that it's like workingthe way you want it to work.
(34:03):
And I know that's not agreat answer because as a
PM, you're really lookingfor the numbers and the data.
But I also think part of thejob of PM is to be okay with
that level of uncertainty.
And I will say this, which isagain, probably not going to
be the best answer, but you'renever going to be perfect.
No product is ever going toperfectly check off every
single box when it comesto accessibility because
(34:24):
again, like a lot of this issituational, which is again,
why it's really importantto continue to have those
conversations with your users.
And I will say, especially userswho care about accessibility
are going to be very vocalbecause they're not used
to getting the things theyneed to just do their jobs.
So they have to be vocal inorder to just survive and
(34:44):
like, do their jobs properly.
And so I think that you havea huge resource there and like
something I had to learn morethan ever in my career as a
PM, it was when I worked onaccessibility that I really
truly understood the importanceof talking and listening to
your users because they couldgive you the best information
of what you need to hear abouthow your product is doing.
(35:04):
And people are not talkingabout how important that
qualitative research is and thathuman to human connection is.
But I think that's trulygoing to tell you whether
your product is working.
And when it comes toaccessibility, it's
really important to makesure you talk to people.
Hannah Clark (35:16):
I couldn't agree more.
Yeah, this is a verypro user research show.
We did an episode a whileback with Steve Portigal
on how to interview users.
That's like one of our favoriteof all times, because it's,
it's all about just talkingto people, letting people
really tell you their authenticexperience and not trying
to guide the conversation,eliminating your own bias.
So important for a productdevelopment process.
(35:36):
Well, thank you so muchfor this has been like
such a fun conversation.
I really appreciate yourperspective on this matter.
And what's such specificstories to tell around and
such a well known product.
So we can all reallyunderstand and get behind,
you know, how these featureskind of come to life.
So I really appreciate this.
Where can people follow yourwork online or connect with you?
Prerna Ramachandra (35:56):
I'm going to be on LinkedIn.
It's just my first name, lastname, Prerna Ramachandra.
You can also reach outto me through my website.
It's just PrernaRamachandra.me.
Hannah Clark (36:05):
Fabulous.
Well, thank you somuch for being here.
Prerna Ramachandra (36:07):
Thank you so much, Hannah.
This was great.
Hannah Clark (36:12):
Thanks for listening in.
For more great insights,how-to guides and tool reviews,
subscribe to our newsletter attheproductmanager.com/subscribe.
You can hear more conversationslike this by subscribing to
The Product Manager, whereveryou get your podcasts.
Popular Podcasts
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Intentionally Disturbing
Join me on this podcast as I navigate the murky waters of human behavior, current events, and personal anecdotes through in-depth interviews with incredible people—all served with a generous helping of sarcasm and satire. After years as a forensic and clinical psychologist, I offer a unique interview style and a low tolerance for bullshit, quickly steering conversations toward depth and darkness. I honor the seriousness while also appreciating wit. I’m your guide through the twisted labyrinth of the human psyche, armed with dark humor and biting wit.