Joining us is master root project manager at Google and a Darnell alumnus. Thanks for joining us, Nasdya. >> Thank you, good to be here. >> You are a growth PM at Google, what's a day in the life for you? >> So I think every single PM will tell you that we don't have day in the life, because every day will be different. But I think I'd like to categorize what we do in three different buckets. One is brainstorm, one is evaluate, and one is execute. And your day kind of falls within these three buckets. You brainstorm what you want to achieve, your ideas, the features, how [INAUDIBLE] users, whatever works for you. You evaluate what is a good idea, what is not a good idea, and how you can prove it and build a business case, because a lot of times you will go to your business partner and actually try to present your case. And the third one is execution. It's day-to-day. It's meetings, it's working with engineering. It's working with yourself, writing PRDs, for companies who write PRDs or write user stories for other companies, all around this, my theory of three buckets. [LAUGH] >> And I know that as a 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 is when you're launching newer products you're also very sensitive to what will come up. You have no ID action. And every single time end user contacts you with a problem, it's a good sign that maybe one user actually called in. There might be tens of hundreds of thousands of people who didn't and just got frustrated. It's a great way to start looking for improvement and looking for ideas. That's the brainstorming part of it, right? For example, I had this customer who was very upset with us. And when we analyzed why the customer was so upset coming from support, and saw that they actually have an issue. And now we're going to build features around that, because we understood that there was more than one customer complaining about it. And it just was unclear to the user what's going on, and it was major kind of fail now parts. So, we're working on improving that. >> And 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 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 presume we get with a service like your's, how do you instrument that kind of observation into the way the cases are closed out and described? >> I think a [INAUDIBLE] a good sense, because if you get x amount of cases in certain type of user frustration, or user error ,or product error, you understand that they have an issue. That's actually how we found some of the bugs. You just see multiple cases in the same area and you start questioning why is this happening. And then the one was lower, and yet support can always can back the quality analysis. Basically look at the quality of calls, and if they see patterns, and it's maybe not statistically significant, like let's say ten people called. But if you see this same pattern from every single [INAUDIBLE] calls, that should probably be a wake up call and you should start thinking what is wrong there. So, it's not one of them most of the time, and actually can be to your advantage can be more disadvantage. And then you need to really dig into deeper and really [INAUDIBLE] for each case and try to see where we can do better. >> And one of the things is we like close with is a top three list. What are your top three pieces of advice for the product manager who wants to improve their interface with their supports unit? >> 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 it's not happens in every company, but the best piece of advice I can give in any building relationship is, go have a cup of coffee, glass of beer. Whatever you do, just go there, meet people, shake hands. Even all technology cannot replace human instruction. And if you have these personal base, it's always make it easier. Another, have a follow-up meetings and show that you're actually following up on the action items. I think all the people get very frustrated, they get really excited, they sit down together and come to kind there is no follow up. The moment there is no follow up, why would they help you? You will just create the frustrational counterpart. So it's always good to have a good relationship, and a follow-up, and regular meeting when you actually update each other and try and keep each other in touch. >> That's great, some very practical advice on working with support from Nasdya at Google. Thanks for joining us, Nasdya. >> Thank you.