Ashley Gutierrez Siler We want to be able to move as quickly as our product team wants to move. So our goal is: how can we work more iteratively, without having to have every single question answered immediately?
Jen Weaver Today I'm so excited to share this talk I had with Ashley Gutierrez Siler from YNAB, where I used to work. With a background in teaching, Ashley is a perfect fit for her unique enablement role on the YNAB support team.
As a product support liaison, she works with customers for about half her time, and the rest with the product team on their fast-paced product release cycle. She's one of the most organized people I know, and to be honest, I'm a little bit jealous that you get to spend your next half hour with her.
We'll dig into a very repeatable enablement process that allows customers to have a great experience, and for support team members to always be up to date on what they need to answer in the queue.
Ashley All right, Jen, thanks so much for having me. I'm so excited to see your face again.
My name is Ashley, I work at YNAB, so we make spendfulness software for helping you manage your money and love the way you spend and give and save joyfully.
At that company I am what we call a product support liaison, so I have a hybrid role. I'm on the support team, I'm in the queue, I answer questions — but I also sit on product development teams and provide voice-of-the-customer perspective and insights for the designers and devs and PMs, to help them understand what our customers want, what they need, what kind of blockers they're hitting.
And then once we get ready to release whatever feature we're working on, I then kind of project-manage that on the support side. So I make sure that the entire support team is ready to go before we even enable the feature flag — that we've got resources updated, that we know how the feature works, that our support specialists are confident replying to those questions in the queue.
Jen That's fantastic. I love it. I worked at YNAB for many years, and we overlapped there — and yes, I was your manager.
Ashley Gosh, I forgot you were my manager. It was fantastic, you were a great manager.
Jen The halcyon days of 2020, which was a wild time to be a manager.
Ashley Yeah. But also way more than that — we've done many things together.
Jen Oh yeah, absolutely.
Ashley Tickled. You are one of the people I miss the most. Your name still comes up: "What would Jen do about this?" So you were definitely missed.
Jen Flattery will get you — yeah. So, we start every episode with a joke. Do you have a joke for me?
Ashley I do. It's really more of a story. So I recently heard about this young adult novel in which Schrödinger's cat and Pavlov's dog team up for a cross-country adventure. And so I was really trying to find it. I went down to the library to see if they had a copy, and the librarian said that description rang a bell, but she wasn't sure if it was there or not.
Jen Love it. That's fantastic. That's a little physics there for you.
Ashley Yeah, but also books — as is appropriate. My two loves.
Jen Exactly. Fantastic. Speaking of your loves, I want to dig into the purpose — the heart of our podcast is processes that somebody could replicate. Maybe somebody who's in support who's doing more of a product enablement role like you are.
And I happen to have experienced the extreme amazingness of your process. I know that for the product support liaisons on your team, you created a good portion of this process. And to make sure I understand: it's a process that is both giving feedback to the product team, and then also educating the support team and customers about what those new features are as they come. Is that right?
Ashley Yeah, that's exactly right. I started this role gosh, just a few months after starting at YNAB. We did things very differently five years ago. Every support specialist changed their non-queue work every six weeks. We did our best, but there were definitely times where support was going to be surprised by a release — or just, even if they knew about it, weren't fully brought up to speed on what the release would impact or how it would work.
These roles over time developed into what we call a product support liaison, and we're an official team now. There's, I think, eight of us. We're all on a specialty team on the support team, and so we have really good opportunities to work really closely together and collaborate on not only our releases but our processes, and what we're trying to do, and how we want our support team to be nimble and respond to product really quickly.
Because we never want to slow the development team down. We never want to prevent a release from going out. But at the same time, we do want to be prepared for our customers in the queue when they write in.
Jen So it sounds like that was an opportunity for you to develop a process around making it more streamlined.
Ashley Yeah. Our leadership team saw the need for more processes, and so every time I did a release I would just make note of: okay, what are the things that have to happen for every release? What are the things that made this successful? What are the things that our support team needed, that maybe I did or I didn't do, that I could do for the next time?
And to document this, we use a knowledge management tool called Guru. So this would get documented in Guru. My goal was, let's move these spreadsheets into something that everyone can access, that are consistent and replicable.
And then our company moved to using Asana. Everyone works in Asana, everyone is responsible for working in Asana, we all understand that if there is something that's happening, it has to happen in Asana. And they have a cool feature called templates, so you can create a project, convert it to a template, and then assign roles to it. So it makes it really easy to duplicate that project out.
Our support communications owner came to me and said, "Hey, I know that the PSLs have this process that they follow, but the other support stakeholders don't always know where they fit in, and every PSL handles it a little bit differently. Can we work together? Let's make a project, let's make a template." And so I built that in Asana.
Of course, we have some releases that are really big and really intensive and are going to change a lot of things, and some releases are super quick and no one even notices on the customer side of things. So we ended up with three or four different types of templates to fit those various needs, but all of them follow the same basic structure.
It's just communicating what's happening and when, what resources need to be updated and when and who's doing it, what training is there if needed, any kind of internal process changes that need to happen, and then the schedule — when's it happening, how many people are getting it, on what platform. And all of the people involved in that: our training experts, our technical writers, our people who handle our help database and our help articles. All of them are assigned to the project. Our queue process folks, so people who monitor our queue and direct conversations where they need to go.
Jen I'm just going to interrupt here to let you know that Ashley's template for Asana in PDF form is available when you sign up for our newsletter, along with all of the other resources from our other podcast episodes. So head to that link in the description and sign up to get emails when we release new podcast episodes.
Ashley Every single person's in that room — that virtual Asana room — and we're collaborating all in Asana, and everyone's clear on what they have to do and when. It's really helped things move quickly and smoothly at the same time, which is exactly what I want.
Jen That's fantastic. So it sounds like it started out and you saw a need for some consolidation. Every product support liaison had created their own spreadsheet and they were all slightly different, so there were probably some meetings that happened among the PSLs to say, "Hey, let's compare notes."
Ashley Yeah, absolutely. As soon as our senior leaders moved us into, I guess, a specialized knowledge team, we were able to get together, meet, figure out what everyone was doing, learn from each other at the same time.
And then that is when I came in. I was like, let's write this down. Note-taking is a surprisingly powerful tool that often gets skipped, but it was really helpful. Okay, what are you doing? What are you doing? Oh, that worked really well, let's replicate that. Basically creating some standardization in how we worked, while still allowing for that flexibility for things to change.
Jen It sounds like you were taking notes and seeing the need to standardize that information and get on the same page, and then somebody on your team, somebody in leadership, said, "Oh, Ashley is really on it — let's assign Ashley the job of making that official."
Ashley Yeah. Because I was handling all the feature requests that come in in the queue, and responding to them and digging and asking more questions. So that's where I got my sense, or my skill, in hearing what people are saying, hearing what they're not saying, hearing what they're trying to do, and then hearing where our releases may have not quite met that for them, for that specific user.
Jen So step one was basically getting in meetings with people doing the same kind of product enablement that you were doing. Step two was to take notes on that. And then step three was to get that into some kind of format that was shared among the other folks. And then at some point you moved that into Asana as a template.
Ashley Yeah, absolutely. And you don't have to have Asana — our company decided on Asana. I'm an Asana nerd, I love it, so I'm really glad we made that choice. But you can do this in Google Sheets, and that's what we worked on for a really long time. We did make efforts to standardize the Google Sheets that we were using. We moved to people duplicating the master copy.
I don't think Google Sheets are quite as easy to work with as something like Asana or another project management tool. But the tool is less important than everyone agreeing on the process, and everyone using the tools similarly. It's when someone insists on doing something their own unique way where it begins to fall apart a little bit — just because that's where people get missed. Not intentionally. You forget to loop in your technical writer, or you forget to loop in the marketing team, or you forget to loop in somebody, and that's where things can begin to feel a little bad on the user experience side of things.
Jen I've experienced that move to one tool, and even if there are some pain points — it doesn't work quite as well as something else — just the power of one team working with one tool can be really amazing. And Asana is really powerful. You mentioned templates and the ability to set dates and assign to people. Sounds like that totally supercharges the process. Can you tell me a little bit more about that?
Ashley Yeah. Our knowledge experts — their job, they're basically technical writers, right? They write our internal and public and customer-facing resources. And we have our knowledge management team, and so they run our help database. Our articles are as good as they've ever been because this team is able to really focus on that work.
And so PSLs are now one of those expert roles. When we're not in the queue, our job is to make our releases as good as they can be for the support team and for our customers. It's a really unique role that requires a lot of project management skills, a lot of advocacy skills, and a lot of flexibility. A lot of quick-moving parts.
Jen For sure. So it sounds like you spend a good chunk of your time in the queue helping customers, and then another chunk of your time doing this knowledge work, this product work.
Ashley Yeah, it's about half and half. Being in the queue is really important because that is our main touchpoint with our customers. We also process feature requests, so we see those explicit feature requests come in — "I want this feature for this reason." And then the queue is a lot of implicit feature requests, or confusion, or maybe it's highlighting a pain point that our app has. There may be a solution available to them that they don't know about, because maybe it's just not discoverable in the app, or something's not working the way we think it will work.
So being able to be in connection with our customers regularly is really important. We're in the queue about half the time, collecting — even as we're helping people in the queue doing our regular support work, we're also in the back of our head always going, okay, I think this is pointing back to this one pain point. And we file it away and we document it.
That's another thing that our PSL team has done. We have finally collected the top — it was going to be top 10, and now I think it's top 14, so maybe we should just make it 15 for a round even number. But: here are the top issues that our customers hit regularly because of something that's not working as well as it could in the app. Those are things that we track, those are things that we keep an eye on. So that if a product team is going to work on an area of the app that might overlap with that pain point, we can say, "Hey, while we're working on this, can we also try to fix this more core problem?"
It's just this constant feedback loop of hearing our customers, taking that to the product team, working on the feature, and then hearing what our customers say — and just really working together to make those issues less painful, or go away ideally.
Jen Do you feel like you get to know the personality of your product manager and learn how to work best with that person?
Ashley Oh yeah, absolutely. We have a team of PMs, and each of them has a little bit of a different way of working, each of them has a little bit different expectations of what a PSL will do. So part of it is just making sure that they're aware: hey, this is the knowledge that I bring, this is the experience that I bring, here's what I can tell you, here's what I can help you with, and then here's what my job is on the support side of things.
And our goal is to help the product team move as quickly as possible. We never want to slow down a release, because that delays it getting into the hands of our customers. Our job is never to say "hold on, don't do that because we've got to do this." It's never to slow them down.
But a lot of times it just takes learning how they work, learning what they want to hear from us, and how to communicate that with them. Really learning their goals, their purpose as a PM. It's not necessarily "here's this one specific feature that we are doing, we're going to get it out." We have our part of our strategic vision, and it's important to keep in mind that the PMs have theirs, and our job is to intersect with them and see where those overlap and how we can support each other in that.
Jen That's fantastic. So back to your process. Working with the PM is probably several task items in Asana on that template. You mentioned you have three or four different versions depending on — essentially, I think you said — how much a release will affect customers. So that probably has to do with anticipation of queue volume based on that feature, anticipation of how much every support specialist on your team will need to know. What goes into that determination of how intense the release is?
Ashley So we have — we should have a rubric. It feels like my teaching days, where it's like we have a rubric that we can just fill out. And it asks things like: how many help articles will need to be created or edited? How many snippets will need to be created or edited? Is this a highly visible change, so when people log in to YNAB are they going to be shocked because — I don't know — a color is different or a button moved? Is this something that's going to really change people's workflows, both as a customer or in support?
The more things that you tick off "yes," the higher impact it will be. And that's where we start to consider things like, do we need a special team to answer these questions?
So for example, when we had a price change earlier in the year, we knew that was going to have some responses in the queue, as price changes do. That's when we activated a specialized team of support specialists who were in the price change queue, and that is what they did when they were in the queue. They had their toolkit of snippets and help articles, and they had a deeper understanding of what went into the price change, and what necessitated it, and all that kind of thing. So they were really highly trained to answer those questions.
And then once the flurry of messages died down, then it's something that every specialist can be trained on and enabled to handle. That really helps us respond really quickly, because we're having to train seven or eight people versus 70-plus people. So it allows us to work a lot more quickly.
Jen So it just comes back to how many things, how many resources, how many people, and then queue volume.
Ashley Definitely. And then, is this specialty knowledge — maybe it's a unique bug that only a certain group of people has the ability to answer? Just those kinds of questions that we check off the rubric. And obviously there's room for flexibility there, but we err on the side of over-preparedness. It's better to be prepared than be surprised.
Jen I'm getting this picture of, for a more intense release, a two-stage enablement process, where you're training this core group and they're going to be more expert and be able to iron out anything and deal with maybe unexpected questions, and then figure out what the bulk of the questions really are going to be, what the customer volume is going to be, and then educate the rest of the team.
Ashley That's exactly right. Our launch teams — when we have a release that we expect to be higher impact, our launch teams are in front of the line, they see things. As a PSL we do our best to guess and anticipate, and we rely a lot on beta feedback for that. Any time we have a feature in beta, the PSL is in there reading that feedback, anticipating what the questions will be from our more general queue.
But those launch teams are the ones who never know what they're going to hear. We try to prepare them as best we can, and so they'll have a dedicated Slack channel where they can collaborate in real time — "Hey, I don't know how to answer this question" — and maybe then the PSL can jump in and go to the PM or the designer or the dev or whatever it is and get that answer. And then boom, we've generated a snippet, because that's become a question that we didn't anticipate but now we have the resource for it.
And all those people are in that Asana project from day one. When I create the project and when I invite people to it, one of the things that I do is I make a video walking them through the new feature, and/or walking them through the Asana project — if I know I have new people on those teams — to say, "Hey, this is what we're doing, this is how we're going to work together, here's where we can collaborate."
Setting expectations is nine tenths of the job. It really makes things work so much smoother when everyone knows where to go when they have questions, or what to do when they have questions. Because questions are inevitable, and it's just great to have a dedicated place to figure those out as a team.
Jen Yeah, it's where they can come back and say, "Hey, I don't think this is quite going to work the way you think it will, let's figure it out."
Ashley And that's great for me too, because I don't necessarily have the depth of knowledge that my knowledge expert has in her Guru collection or her snippet collection. But she does, and so she's able to say, "Hey, it's actually going to affect this and this too — did you think about that?" And I'm like, "No, I did not. Thank you for bringing that up, so that we can prep."
Jen And that brings up Guru. You're creating Guru cards both for your core team and their private collection that go into detail about the features. So you're at the end of the process now, you've gone through most of your Asana board, you're releasing this feature, you need to update the whole team. How do they get alerted to this new information?
Ashley Each team has a dedicated Slack channel for their team. My team, we have a Guru card in our collection that's just a weekly update — it's just rolling. Every time a change is coming, I'll go into that card and post, "Hey, we're going to be changing how the account sidebar looks, it's coming on this day, here's the release card."
Every release has a new release card in Guru that explains what the change is, how it's going to work, when it's happening, the snippets and help articles they can use to answer queue questions, and then who to contact if they have questions. So I'll link that, the team will read it and get caught up on it.
Guru has a feature where you can send a notification to people on the team when that card is published or updated, so I'll do that. And then our team is just on it — they'll read it before I even have a chance to ping them, usually.
Jen So you're using the notification system within Guru and expecting your team to keep up with their notifications and check those off so that they're updated. And then you've got this release card. What happens to that when this wave is over and you're moving on into just general knowledge?
Ashley After about two weeks — it depends on the size and impact of the release, but generally after about two weeks we'll have seen the bulk of conversations that we're going to see — that's when we will then convert that release card to a regular queue collection card, if it makes sense to do so.
A lot of times that information will have already been published on our existing cards and I can just archive that release card and call it a day. Sometimes it'll turn into a new queue collection card, but it just gets merged or migrated into the existing collection in whatever way is appropriate for that release.
And that's when our snippets will get moved out of our temporary folder into the permanent collection. That's where we evaluate: do we need this one? How many times did the snippet get expanded? How many times did we get this question in the queue? We can probably archive that knowledge, because we know that we're not going to encounter it very often.
Jen Can you dig into that a little bit more? I'm guessing that part of the Asana project is to create new snippets and iterate on those.
Ashley Yeah, and this is where the PSLs work really closely with our knowledge expert. So if it's new content, the PSL will draft a new help article, a new snippet, a new Guru card. And if we already have that information available, or that knowledge published in our collection, then the knowledge expert is responsible for editing it and updating it. So we work hand in hand. I love our KEs, they are so on top of it.
Jen Your knowledge experts are the ones in TextExpander handling those snippets?
Ashley Yeah, they write, they edit, they are wizards. We use a Smart Brevity framework at YNAB, and so they are all trained on that framework, and they're such good writers and they have such command of our knowledge.
Jen I'm getting this picture of you, essentially in your role as the leader of a cross-functional team, driving this project forward for a relatively large group of specialists that you're leading. That's a very sophisticated role.
Ashley Yeah, it's project management. I love it, love it so much. I love a good checklist, it's my favorite thing in the world.
Jen So this team has updated everything, the release has gone out, the first wave of conversations has come into the queue, and now it's just the new normal. What happens last? What happens with the Asana and other tools that you're using?
Ashley We get to mark it complete, and we get to archive it, and we get to send out a little celebratory unicorn emoji. It's fantastic. And then it's on to the next one.
Jen On to the next one.
Ashley Before a release has even ended, a new one has started. So you migrate and you archive that information as needed, and then you are back at it again. So it's never-ending, in the best way.
Jen That's great. So you archive the Asana project and it remains for future reference as archived, so you can pull it up if you need to.
Ashley You need to sometimes — not very often. Most of the stuff that I need to come back to is technical developer questions, like: what is the expected behavior? Did we mean for the arrow to be a hyphen-caret, or did we mean for it to be something else? And why is this even coming up? I don't know, but it is.
That's when I can dig back through those conversations with people, we can find out who the developer was, ask them what did we think was happening, did we mean for this to happen. But that's pretty rare. We have worked through all those things during beta, during the early waves of the queue conversations. It's nice to be able to archive it and for the most part leave it and move on.
Jen That's fantastic. So what's your favorite part of that whole process?
Ashley Iterating on the process. Going back in and editing the template.
We want to be able to move as quickly as our product team wants to move, and that's great — and it's also hard, because we are a team who is so passionate about YNABers, and we want to be able to answer their questions immediately to the fullest extent that we can. And so that can cause a roadblock with getting a release out quickly, if support's going, "No, hold on, I need to update this."
So our goal is: how can we work more iteratively, without having to have every single question answered immediately? And that of course requires our processes as PSLs to be more nimble, to sit in not knowing everything — when our desire is, of course, I want to know everything. I'm really nosy, I want to know everything.
So being able to balance the need for speed with an acceptable level of knowledge to get the job done.
Jen Kind of what we were talking about before we started recording — perfect is the enemy of good.
Ashley Enough is as good as a feast. And having enough instead of the feast is truly okay. I think I am learning that lesson.
Jen I cannot believe that we have burned through all of our time. But I have a joke for you.
Ashley Yes, I think so — ending our podcast with a joke might be our new thing.
Jen So I went to the doctor and said, "I just don't feel good." And the doctor was like, "What's up?" And I said, "Sometimes I feel like I'm a teepee, and sometimes I feel like I'm a wigwam. Just teepee, and then wigwam." And the doctor said, "Your problem is that you're too tense."
Ashley I feel that deeply in my bones.
Jen Again, like all my jokes, that's my dad's joke.
Ashley Love it. Love it, full credit. Now that we have a three-year-old, my husband has become the dad joke —
Jen You're kidding. Three?
Ashley Three and a half.
Jen Three and a half, which is bananapants. Oh my gosh. Wow. You have to send me pictures.
Ashley I will, I'll do it.
Jen Cool. Awesome.
Ashley Thanks so much, Jen, so good to talk to you.
Jen Me too. Thank you so much, you're just an absolute delight.
Ashley You're the best, can't stand it. Let's just flatter each other all day long.
Jen This is Jen here, just wrapping up. Thanks for joining me for another episode of Live Chat with Jen Weaver.
My hope is that this podcast will improve your life in customer support and give you some processes that you can replicate. So please do reach out, let me know what you think — if you have thoughts for future episodes, or if you'd like to be a guest because you have a process you'd like to share, I want to hear about it all.
And remember, you can build your own product release process for your support team following Ashley's steps, which are available in a PDF playbook, so you can use all the same tools and processes that Ashley uses. Subscribe to our email newsletter to download this and all of our support playbooks for free.
If you found this helpful, please give us a like, subscribe for more actionable tips, and share this with your team. Let's keep making customer support smoother, one process at a time. See you next time.