Skip to 0 minutes and 0 seconds Joining us is Nastia Root product manager at Google and a Darden alumnus. Thanks for joining us Nastia. >> Thank you. Good to be here. >> You are a growth PM at Google. What’s a day in the life for you?
Skip to 0 minutes and 15 seconds >> So I think every single PM will tell they don’t have a day in the life, because every day will be different. But I think I like the categories that we do in three different buckets. One is brainstorm,one is evaluate, and one is execute. And they kind of fall within those three buckets. You brainstorm what you want to achieve, your ideas, your features, how to bring more users. Whatever works for you. You evaluate what is a good idea, what is not a good idea, and how we can prove business case. Because a lot of times you will go up to a business partner, and actually try to present your case. And the third one is execution, it’s day to day.
Skip to 0 minutes and 51 seconds It’s meetings, it’s working with engineering, it’s working for yourself, writing PRDs for companies who write PRDs or write user stories for other companies. All around us. My favorite three buckets. [LAUGH] >> And, I know that as growth PM, managing the customer journey is a big part of your job. Can you talk a little bit about specifically how you work with support to kind of smooth out bumps in the customer journey and make it better and better over time? >> Sure. In my case, I like working closely with support because a, when you are launching a newer product, you are also very sensitive to what will come up. You have no idea actually.
Skip to 1 minute and 29 seconds And every single time a user comes back with a problem, it is a good sign that maybe one user actually called in. They might be tens of hundreds of people who didn’t and just got frustrated, but it’s a great way to start looking for improvement and looking for ideas, brainstorming part of it right? For example I have this customer who was very upset with us and when we analyzed were the customer was so upset coming from support, and they said that they actually have an issue. And now we’re going to build features around that because we understood that there’s more than one customer complaining about it. And it just was unclear to the user what’s going on.
Skip to 2 minutes and 4 seconds And it was major kind of fail on our part, so we’re working on improving that.
Skip to 2 minutes and 11 seconds >> And how do you one of the things, that I’ve always found in my own work, as a manager, is that it’s natural for support to just say, all right, well, we answered so many tickets and so much time and things are going well, and that’s, of course, a really important part of their job. But to really make things better it’s important to look at okay, why did each of these cases kind of happen and then as you say, kind of brainstorm. How could we have made that ticket not exist in the first place? How do you, particularly with the volume of cases you must presumably get with a service like yours.
Skip to 2 minutes and 48 seconds How do you instrument that kind of observation into the way that the cases are closed out and described. >> I think plays into in a good sense because if you get x amount of cases and a certain type of user frustration or user error or user product error, you understand that they have an issue. That’s actually how we found some of the bugs. We just see multiple cases in the same area and you start questioning why is it happening? >> Mm-hm. >> And then the one was lower, support can always come back to IT quality analysis, basically look at quality of calls and if they see patterns.
Skip to 3 minutes and 21 seconds And it’s maybe not of statistical significance, because there’s only like ten people called. But if you see the same pattern from every single calls you should probably get your wake up call and you should start thinking what is wrong there? So one it can be to your advantage, most of the time [INAUDIBLE] lower can be more disadvantage. And then you need to dig in deeper and really read for each case and try to see where we can do better.
Skip to 3 minutes and 46 seconds >> And one of the things we like to close with is a talk through this one year top three pieces of advice for the product manager who wants to improve their interface with their support team. >> Get to know them. I know sometimes it’s harder but I took a flight and I went to visit my counterpart in support. And obviously this does not happen in every company but. The best piece of advice that can be given any building relationship is go have a cup of coffee, glass of beer, whatever you do just go there meet people shake hands. Even if all technology cannot replace human attraction and if you have this personal base it’s always makes it easier.
Skip to 4 minutes and 23 seconds Now and then I have follow up meetings ensure that you actually following up on your action items. I think a lot of people get very frustrated, they get really excited, sit down together. Kind of there is no follow up. As long as there’s no follow up, why would they help the next, it would just create the frustration on their part. So it’s always good to have a good relationship,and a follow up. And regular meetings where they update each other, and kind of keep each other in touch.
Skip to 4 minutes and 48 seconds >> That’s great, some very practical advice on working with support from Nastia Root at Google. Thanks for joining us, Nastia. >> Thank you.
Nastia Root on Creating a Strong interface with Support
In this video, Alex interviews a product manager at Google to gain her perspective on what it means to be a growth project manager. Nastia Root describes her job as having three parts: brainstorming, evaluating, and executing. When asked for her top three pieces of advice for the product manager who wants to improve their interface with their support unit, she lists: get to know them, follow up on action items, and keep in touch. Do you think this is advice you could follow in your organization?
© Copyright Rector and Visitors of the University of Virginia