Ep. #12, Managing Stakeholder Relationships

Rimas Silkaitis: Today's guest is Kathy Simpson.

Kathy Simpson: Hello.

Rimas Silkaitis: Who is a newly minted product manager at...

Kathy: GitHub.

Rimas: Welcome.

Kathy: I wouldn't say I'm newly minted. I've been a product manager for a long time, but I just started at GitHub.

Rimas: I should have clarified, yes. Just started at GitHub, not newly-minted.

Craig Kerstiens: The details in communication are very, very important.

Rimas: Today we're going to talk about stakeholders and stakeholder management. So could you, Kathy, give us your definition of what a stakeholder is?

Kathy: Yeah.

I like to think about my stakeholders as my executive team but it goes way beyond that. And the larger your product is the more stakeholders you're going to encounter along the way.

And they can be sales, marketing, other engineers, engineering managers, other product managers. Basically if your product touches any one then that person is probably going to consider themselves your stakeholder.

Craig: That sounds like everyone.

Kathy: Yeah.

Craig: How do you narrow in on it? Is it always the case that you've got to please everyone? Because that sounds already out of the gate impossible.

Kathy: Absolutely not. So that's why I like to think of my immediate stakeholders as my boss. And then also my executive team, and those are the people who care about the business. And so that's usually what I narrow in on and then also the people who are selling my product and the people who are marketing my product.

And that's usually one person on sales, one person on marketing. And you want to develop a relationship with those people because they're going to tell you who else you need to talk to on the team or they can be your evangelists.

Rimas: So far you've named a lot of stakeholders that are internal to the organization. What happened to all the customers?

Kathy: Who cares about customers? Yeah, customers are a huge part of your stakeholder team and those are the people that you're going to want to engage with early on and then throughout the process. Especially as you start to think about releasing your product. You want to get it out in front of customers and get early customer feedback et cetera.

Rimas: I thought when you build products you don't have to talk to customers if you don't want to. So are they really your stakeholder?

Kathy: You don't have to talk to customers if you don't want to. But if you do that then you're likely going to release something that's pretty risky. It could totally fail. I like to talk to customers so that I know what their temperature is and I can engage with them. I can start to wrap their feedback back into what I'm building. And you can start to develop a narrative with them, and so they know kind of what's coming down the line, they know what your themes are.

And also as a product manager my customers are usually really excited to talk to me even if their feedback isn't going to get into the product itself, they just want to be heard.

Craig: That sounds like a lot of work. I prefer just to build the right thing and not have to talk to customers, it's a lot easier that way.

Kathy: Only if you're Craig then you can do that.

Craig: So, there's some things in there that you hit on like your boss is a common stakeholder, but that's kind of a constant stakeholder. How about on like a project-by-project basis. How do you go about saying, "you are my stakeholder for this project." What's that inventory that you do? Or do you just kind of know out of the gate? For someone going through this the first time, what input would you give of, it's a new project, what do you start with?

Kathy: I look at the different integration layers. And so let's say, I'm building something that touches billing and so then I want to start to talk to the people who are in charge of the billing system. I work primarily on the front end, and so usually my stakeholder involves an engineering manager who is operating the API and building out the backend. So that's another person that I want to talk to.

So I look for those integration points and then I identify those key players as my stakeholders. Likely, I will be working with their teams specifically. Maybe even them to actually build out those systems. So we all need to be on the same page. I need to create buy-in. I need them to buy into the project et cetera.

Craig: So how's that process work? So from the initial buy-in, like we talked to the high-level, but like what cadence are you setting up? Is it like one kickoff meeting? Is it weekly check-ins? You said, build that relationship, build that rapport. How are you going about doing that like kind of day to day basis?

Kathy: So yes, a kickoff meeting is awesome. And then I usually try to set up one-on-ones. I err on the side of weekly one-on-ones. And this is going to vary from PM to PM and how much time you have. I put a lot of stake in my relationships and making sure that I'm clearly communicating.

A lot of times as you're engaging with different stakeholders, it could be that they have never talked to a product manager before and they feel kind of slighted by the product management team.

And so if you encounter that, I encourage you to really go there and talk to that person often and build that relationship.

Because likely they either were just forgotten or a product manager didn't have enough time to talk to them. And they just didn't have the opportunity to build that relationship with the product team. And so if that happens to you, you have that opportunity. And once you start building that relationship, your product is going to be that much better because of it. It'll become easier for you to collaborate with that stakeholder. So I do weekly one-on-ones.

I don't like bi-weeklies because they usually get canceled. And I don't like monthlies because it tends to be too much time. So I really like weekly one-on-ones and it can just be 15 minutes. It doesn't have to be a whole hour. And depending on the level of the stakeholders involvement I'll include them in stand-ups.

Craig: Because the CEO usually shows up to your weekly standup?

Kathy: Always. The CEO is so interested in what I'm doing, they're always there.

Rimas: Also to play off that a little bit. Is it possible to build those relationships just through written communication, just through email or Slack, let's say?

Kathy: Yeah, I mean I think it's important to do email and to do Slack. I think it depends on what level of relationship you are looking for. And also it depends on, like I was saying earlier the relationship that that person has to the product team maybe slightly damaged. And if that's the case, I would encourage you to do it face to face. Whether that's actually in person or over hangout or something like that, just to start to develop that communication style. Because there's a lot that is said just in looking at somebody, and that stuff can be totally lost in email.

Rimas: So what I'm hearing is that, no, you cannot build relationships via Slack and email.

Kathy: It depends on the level of involvement you really need from them. And I guess my example here would be, if they are somebody who could totally squash your project, you do not want to surprise them in any way. And that's probably going to require a one-on-one time. So the people that in my life that could squash my projects they're usually VP level or above. And those people are really hard to get a hold of, so there are certain tactics that you can use to get those people's attention.

They're probably not going to read your email. And so what I do is I stand outside the meeting room that they're in and I grab them as they're coming out and I'll say, "Hey, I really need you to look at this real fast." You have 10 minutes, you have five minutes, you have two minutes, you have time to grab coffee, that kind of stuff.

Craig: Let me walk with you to your next meeting and chat, is a great kind of quick tactic which doesn't feel like it's on their calendar but you get that face time. But I also think it comes back to their style. I find this more in engineers. They love that written communication but sometimes it's engineering managers as well that for them a written communication is just concise clear, it's the way they communicate.

Now you've hit on a couple times. What if the relationship to product management is damaged? How do you know that? Like how do I like not just assume it's good? What are the signs that they probably had some bad relationship with product before, not engaging with them. What is the sign that I actually need to put more time in without having known that?

Kathy: They'll tell you that they have never had a conversation with product management before, that's a huge sign. There's other things like, I talked to this one product manager and I completely didn't disagreed with what they said or I didn't understand what they're saying, or things like, "I always get left out of the conversation." that kind of stuff. This happened to me while I was at Heroku, I worked on a lot of the UI pieces there. And a bunch of the projects I worked on cross many different teams, specifically the team that was managing our billing system.

And the billing system was really complicated, so it was almost scary if you're a product manager or an engineer. It always scary for you to interact with it because it was so nimble and so large, it was really hard to get any momentum there and so people would just avoid working on projects that touch the billing system. I had to because we had to make it possible for customers who removed their credit cards, it was costing us a lot of money.

You still could, but it was costing us money in support. I want to make it possible for them to self-serve there and so I started to build a relationship with that team. And with some of the tactics that I talked about weekly one-on-ones and really starting to listen to what their pain was working with the product management team. When I presented what we were going to build to the person who led that team, the feedback was, "I want every single product manager to run their project the way Kathy's running this project."

And so that's when I knew I was successful and that's also when I knew there was so much pain there that came before I even tried to do anything.

Craig: Now how much can like us as product manager start to preempt some of this. So we're talking about stakeholders and specific projects but that was because you had a project with the billing team. What's the opportunity to improve things ahead of time?

Kathy:

If you ever have any downtime I think you should pick somebody in the org and have a 30 minute discovery conversation with them.

Right now at GitHub I just started, so it's a really great time for me to do this as I'm onboarding and getting to know the organization, but I don't plan to stop. Especially as new people, new people join the organization and things change, there are reorgs and things like that. I plan to continue to have conversations with people whether it's actually booking a meeting which the company is largely remote, so that'll probably happen.

Or if it's just, let's go grab coffee or let's go grab lunch or whatever. Usually product managers are pretty extroverted. I am not, and so it's not always easy for me to meet new people but it's critical for my job.

Rimas: You could have fooled me. I think you're pretty extroverted already. One of the things that I noticed when I talk to stakeholders no matter what is they always ask about deadlines. How do you manage that with stakeholders, especially those that are VP level and above that or care about the business and when you're going to deliver things? Or even sales or marketing for that matter.

Craig: Yeah, I've seen cases where a CEO heard a deadline or a timeline for something once, immediately repeated it to a customer and then had to apologize profusely as that time line came and went, and the project was still nowhere in sight.

Kathy:

In my experience, dates are somewhat arbitrary and they start from rumor.

And so what I try to do is dig in on what is behind the date, what's the driver. And if it's something I can navigate around then I'll try to do that. But I think the most important thing for a stakeholder to understand is not necessarily that you are or are not going to ship by that date but what are the ramifications of that? What is it that you are actually trying to get done.

And that's a conversation that you can have with your stakeholder around like, okay, if you want to ship by February 1st, what does that mean to you? What is included in that product that you're going to ship? And so maybe if I'm feeling like this is too much for us to get done by that date and we're going to have to push it out to March, there are probably things that I can cut back from scope so that I can meet their goals and ship on February 1st but maybe not with the whole product.

Rimas: But the stakeholder keeps pressing you, I want all this stuff by this time. They don't understand the triangle of project management. I said project management, right? No? Yes? Time, scope, money, right? They want all of it. Why can't they have it?

Kathy: I mean there's a reality we're working with here. There's a lot of pressure that they're putting on the team.

Craig: But they're giving you more engineers to go get it done faster.

Kathy: Then I'll get it done faster. I mean there is, you work with scope, you work with the levers that you have. And so, you need to understand "okay, they promised it to a customer, what does that mean?" How important is that if we slipped on the date, then what is that going to mean for the business? Are we going to lose money?

Or if it's like, we need to get this ship for the specific conference. I think those things are really important to understand so that I know how to cut scope, I know how to push my team and I know all of the parameters that I'm working with, so when I need to pull those levers, I can. And my team doesn't feel like they're being lashed all over the place.

Rimas: You ever fired a stakeholder?

Kathy: I don't know. I don't know that I have.

Rimas: Never once you've just said, "Look, you're not a good input to this project." Maybe it'd be a customer, an executive, an individual on a team.

Kathy: One time I was working, it was when I was an engineer. This is like my transition into product management, where I feel like this happens to a lot of product managers, were you're doing product management before you realize that that's what you're doing. And so I was working as an engineer. This is when I worked at an agency, a design agency, so we did a lot of greenfield work. And we were trying to figure out what the infrastructure systems were that we wanted to use for the specific product. It had a front end and mostly mobile.

And this woman was a newly minted director of engineering and she didn't understand what a staging server was. And when I realized that, I realized that she was going to be, one, hard to work with, but then two, she was probably going to slow our project down because I would then have to do a lot of education about what we were trying to accomplish. Because we had deadlines.

And also that kind of a level of understanding of what we were trying to do it just, it seemed like we were going to butt heads a lot and she was going to derail the project and things like that. So, after I realized that I didn't necessarily fire her directly. But I did talk to my boss about it, and she wasn't on the project after that. So I think it's important. I was very young in my career too, I definitely could have handled that differently but I did recognize that that was a threat to our success, and so I tried to go and do what I could to solve that situation.

Rimas: Any instances where you've done that for a segment of customers?

Craig:

I think anytime you fire a customer it's really interesting because it's a hard conversation. What I find is it invigorates the engineers. It's like you have their back.

This was a customer causing problems, it wasn't the right fit, support was over-the-top or whatever reason. And it was causing some pain that you had to fire them. Hopefully it wasn't just for no reason. In which case, that's a very different whole other episode conversation.

Rimas: I tend to find the firing of customers to be really a one-off thing, not necessarily pulling out particular personas from the product. So I find this more prevalent in B2B style software companies, where you have more hands-on with the customers that you're working with in which you know the use case that they have does not meet what you're trying to build anymore. And in those cases, that's when you need to divorce them from what you're building or what you're serving.

Kathy: In my experience particularly working on the front end and shipping products around front end experiences and UI/UX. It's not necessarily that we're firing a customer, it's that we're refocusing our efforts somewhere else.

Craig: So it's like you're firing a lot of customers at once?

Kathy: Yeah. We'll get one nasty support ticket about something that might not necessarily impact a lot of our customers, but it feels really embarrassing to the engineers. And they want to fix it but it's going to take a long time. That's a conversation you have to have with them about, what is the most important thing that we need to be working on here? Can we live with this pain for a little bit? Sometimes you can't, sometimes it means incurring technical debt that all of that kind of stuff and so you have that conversation. But a lot of times it means you're just refocusing.

Craig: So we started to talking a little bit about like the engineers that we collaborate with on these things. How much do you communicate everything that learned and engaged with from the stakeholders down to the engineers. Or is it kind of attracted the way that like you're this barrier so that they don't have to see it or deal with it? Or is it very transparent of, I got this from them and we're changing because of this. How much are you kind of a buffer? Or is it like, you take it but then distill it and let it flow through to them?

Kathy:

I try to be as collaborative as I can with my engineering team. And sometimes that's great, sometimes that's really scary for certain engineers.

And I think you kind of have to step in it as a product manager to feel that out. But I would err on more information. Because what I see, if I try to buffer the team from what's happening at the stakeholder or executive level. What I see happening is, they develop a fear of stakeholders, then you're kind of their safety blanket. Also they're not included in those decisions.

At that point when I'm taking the work of my team and I'm presenting it on behalf of them to my executive team, and then we have a conversation about that work. My team needs to understand that I'm not trying to change anything, I'm not trying to brainstorm around them. And so it's really important for me to distill that or to translate that information to them in a way that's really collaborative.

Rimas: Now what about when it's like terrible news?

Kathy: Even when it's terrible news.

Rimas: Nope, you've got a ship it twice as fast because we have to have it for X Y Z.

Kathy: I would say especially when it's terrible news, you need to be as collaborative and open and honest about it as you can. If marketing comes back and says we need to ship it twice as fast for X Y Z, the people who are going to be able to execute on that, they're the team. And they're the people who can be creative about that and try to think through. First, they're going to be pissed. And they're going to be pissed at the messenger, and that's you.

Craig: It all depends on how you point the finger at marketing. They could be totally fine with you.

Kathy: Yeah, totally. I mean like yeah, behind closed doors or whatever, but they're still going to be pissed. And that sucks to piss your team off with that kind of information. And there's probably things that you as a product manager feel like you could have done differently to avoid that situation. Fact of the matter is these situations come up and

If you have bad information don't be an ostrich. Just tell your engineering team what's going on.

Craig: I usually like mourn through it, "Alright, let's grab a beer, let's grab a bottle. Let's vent and then let's figure out how to get it done."

Kathy: Yeah, exactly.

Rimas: So what's the worst experience you've had with stakeholders?

Kathy: I've probably had worse than this, but in recent memory, It really, really sucks when your stakeholders yell at you in front of other people. It happens and I was trying to, this one time I was trying to figure out this really complicated project. It was like one of those projects were you start to uncover more bits of information and there's just like more squirrely worms under there. I was uncovering all of the information I needed for my project, but then getting really distracted by all of these different intertwined pieces that were then going to result in other projects.

And I wanted to solve all of it, and before I was able to really package it in a really cohesive way, I went to one of my stakeholders and I asked, "What should I do here?" And I kind of explained what I was seeing but I didn't explain it in the right way. This is kind of a lesson to know your audience. I really should have done the heavy lifting to present the information in a better way.

But I was trying to be pretty collaborative about it and he basically said, "I think you're being schizophrenic right now." and it was to the whole, he said it to me in front of all of the rest of the product managers on my team.

Rimas: I feel like my jaw would just drop.

Kathy: I still had a goal which was to find a path forward through all of this project cruft. So I still, I had that on my brain, I was pretty determined to get to it. But I remember looking around the room and there was the design director sitting on the other side of the table and she stopped the conversation and said, "Wait, let's just thank Kathy for what she's doing here." And that was that that moment that I realized how serious the conversation was and how inappropriate it was for him to call me schizophrenic.

Craig: Yeah, I mean I can think of my reaction. I think that would frown more on the person that made the statement.

Rimas: The person making the statement. That's definitely a faux pas, just in terms of work and interacting with other individuals on the teams because it's one thing to say something like that. It's another to attack the work that's being done. I think a clear distinction there is that, it's one thing to talk about the actual work being done and what is being presented rather than focus on the individual making those statements.

Kathy: For me coming out of that conversation, the biggest risk there was that I would not want to bring information to my stakeholders after having an experience like that with them. And I think as I become a stakeholder on other people's projects, I think about that moment and I think about how important it is for me to stay engaged with them so that they don't feel afraid to talk to me about things.

Rimas: So we've talked a lot about kind of like managing proactively up front, engaging in a good way. There's probably a lot of people listening that come into this and think, " I'm in this situation, I haven't done X Y Z, I'm in the middle of a project." Where do you start there?

Kathy: I always tell people in this situation and I always remind myself when I get in this situation, it doesn't matter how senior I get. There's always times I forget to talk to somebody. And

The moment I realized that I have forgotten something or that I realized that something is off the rails is the moment I have to go talk to that person. Don't wait any longer, and you can apologize and say, "I'm sorry I didn't get you in the beginning."

Take the blame for it, don't let your ego get in the way, just have that conversation.

Rimas: So let's bring it back to tactics for stakeholders. How do you present to those stakeholders? What kind of information are you looking to provide? And frankly do product managers just create PowerPoint decks all day?

Kathy: Yes, they do. There's like Google documentation too and Slack messaging and all of that. In terms of tactics, it totally depends on where you are in your project and who is the stakeholder that you're talking to. If I'm talking to my boss, I'm probably going to show them some of my early thinking, so that I can collaborate with them, even though there's stakeholder I'm still kind of leveraging them as a collaborator.

Rimas: Are those just DesignDocs?

Kathy: Yeah, all kinds of artifacts. And since I sit on the front end of the product, usually I will document stuff out in a flow so that it's easier for me to talk through it. Also learning how your boss takes information and learn how these people are, who your kind of collaborating with at that lower level and a stakeholder conversation, how do they take information?

Because if I just write up like a huge long RFC or something like that, my design director, they'll probably fully understand it but they won't like it. And maybe I should be actually whiteboarding with them instead. I think as a product manager, you innately have a bunch of skills to communicate in different ways.

So pick up on those ways that other people are taking in information and meet them. Provide documentation and workflows and things like that where that they can easily digest, because that's when they're going to be the most collaborative with you, and be able to give you a lot of information you need.

Rimas: It's somebody that maybe new to a team or new to an organization. Do you just guess? Can you just go into them and say, "How do you like your information? Straight up?"

Kathy: You totally can. You totally can. You can say, "How is this going to be most useful for you? Would you like me to document this out? Should we whiteboard it?" Sit next to a whiteboard so you can kind of pick up on those cues in the moment and say like, "Hey, you know maybe it's easier if we draw than diagram." Or something like that.

Craig: And I think you'll see it in the way they like naturally communicate. You can ask them, but if they write up huge long emails, that's one way. If they're constantly in Slack, it's more ad hoc interactive. If it's, "Hey, we want to see it wireframed." If it's marketing, they want a draft blog post before they look at the product features like, how do they most interact?

And you can see that coming out I think as product managers we have to adapt to everyone else and their style to make their life easier. Whereas most other people when you're in that same role you're interacting that way constantly. So I think shaping to whatever they're just naturally doing is key.

Rimas: Got it. So really it depends on the person that you're really working with.

Kathy: And I'll just add that, I like to engage my executive team, my stakeholder team at key moments in the project. And so you can invite some of them to the kickoff. I probably wouldn't invite all of the higher level ones but you can send them an email update on what happened in the kickoff. What I like to do also is prepare a presentation. Do the keynote, do the PowerPoint, and then get on the agenda at their executive briefing meeting and then go in and do like a five minute update on, what are my product principles?

What am I trying to accomplish? Here's some early mocks or something like that of what we think this project is going to look like. Chances are they really care about what's going on and they can give you some really good feedback about the direction you're trying to take. And so I'd like to do that early on so that I'm kind of protecting myself from surprises later on in the project and I can get that feedback.

So when I do that before taking a step back from that meeting as I'm preparing that documentation, I'll shop it around. I'll go to a few of those key people. Let's say if I'm presenting it to the CEO, VP of Product, VP of Engineering, VP of Sales. I'll go to the VP of Product and I'll say, "Hey, here's my deck. Here's what I'm thinking." I'll go to the CEO and say, "Here's my deck. Here's what I'm thinking." and then I'll go to the larger group as a whole.

And I like to kind of err on the side of over preparing for that, so I know what's coming and how the conversation will go. I usually get some surprise questions, but you can kind of navigate through that. Especially if you do over prepare because then you're learning all the content yourself really well. And then I also like to follow that up with kind of a mid project check-in. Very similar style, I'm kind of building off of that deck.

And usually in my decks I'll say in the beginning that this is a living document, it'll change over time. And each time if I'm presenting on the same product, each time I'll present kind of the same style. And so if my deck is themed with like hearts and daisies then the deck and mid project is going to be themed hearts and daisies. So then they'll start to pick up, "Okay, we've seen this before." They're more comfortable with it. Especially if you're delivering bad news, they're not going to feel surprised.

Rimas: Got it. Is there particular information that you tailor to CEO level individuals, VP level individuals versus those that may be lower in the bowels of the organization. I mean, what I'm trying to really try to get at is, do you really need to go super deep on that information you're providing to those super high levels in the organization?

Kathy: No, you don't. So a lot of times

I'll prepare a larger document and then I'll print it back to an executive brief. I'll still include all that information in the executive brief, but I put it in an appendix.

And then I give them links to those pages if they really want to dig in on it. But I try to give them the snapshot of what's going on. And usually the only page they care about is the timeline.

Craig: So you'll put that right to the front, so they know the exact times that things are going to be delivered and they'll come and ask a week out is everything ok.

Kathy: That's another episode, the art of crafting a vague timeline I think is an important skill to have.

Rimas: So artifacts, we talked about how you might need to tailor at various levels of the organization. Once a project completes and you get to some notion of shipping this feature, product, whatever it may be. What do you do with stakeholders after that point? Do you still engage with them? Does anything need to happen?

Kathy: So in the beginning you should have had a hypothesis about how people were going to be interacting with your product and been implementing some level of way to collect information about to either prove or disprove that hypothesis. In my case it's usually user events and then I'm piping those user events to some database somewhere.

Craig: We love databases, but we particularly love SQL.

Kathy: I usually use Redis.

Craig: Wait. That's not a database.

Kathy: This is a future episode too. As a product manager who is not a data PM, don't try to recommend what database to use, let your engineers do that.

Craig: That sounds like it's a whole other story in there.

Kathy: We know where to get your data. You're using SQL to get your data and you're asking the right questions. What you're going to want to present back to your stakeholders is what's happening now that you've launched this thing. And how is it affecting your company's MAU? How are people spending their time with your product?

Rimas: Or their money.

Kathy: Are they spending money? And what does that look like? And then you start reporting that out and then you start thinking about how you're going to scale this thing? How are you going to improve it? Maybe you implemented some things in a weird way you need to go back and fix those. And so there's always follow along projects after you launch something that was potentially like greenfield or something like that, and so you want to present all that stuff out.

And chances are your company has some methodology for reporting out information, whether it's like a demo day or whether it's emails or like an internal company blog or something like that. There's probably going to be some kind of API to access or to use.

Craig: In my experience, executives are always going to ask what's next. Like, "Great, here's the report." But I'm already thinking about the next thing. So where do you go from here? What's next? Like going into that prepared of like some hypotheses, you may not know of the next project, like you're not ready to do the next kickoff yet. There's still cleanup work. They're already thinking about the next thing though. So having some idea and direction of that is usually helpful.

Kathy: And you don't have to come up with that idea on your own.

If you're in the meeting with them and stakesholders ask, "What's next, product manager? What is your like big idea for what we're doing?" You have full right to say, "I don't really know and let's talk about that, let's brainstorm about that."

Because they know the business probably better than you do. And if they're asking they probably have an idea, and they probably want to tell you, and so just ask them to tell you.

Craig: So we've covered a lot of strategic things, a lot of the coordination, give it a tactical. Any like other just practical tips that someone should keep in mind and know to leave people with. What have we not covered about this is the most useful thing I found in dealing with stakeholders that someone should having they're told to lux.

Kathy: I don't know if I sound like I'm comfortable talking with stakeholders and executive team or not, but I'm always a little bit terrified. And I think probably the most important thing that I think of is I am the expert in the room about this specific product. And once I start thinking about that, like I kind of think about it like skiing. I grew up in Alaska and so I grew up with skis attached to my feet.

And so I think about it as you're kind of like going into that executive room it's almost like you're standing at the top of a hill and you're about to take off and it's like, presenting is almost like going into the fall line. I'm in full control. I know where my edges are and I know what my hands are doing and everything and at that point it becomes really exhilarating.

Because then you know what you're doing. You're the expert on this product. You're presenting it to people who also really know the product well and they're going to be able to give you advice and steer you in the right direction. So for me as I'm going in there and as I'm preparing to be kind of slightly freaked out, it's important for me to remember how exciting it is.

Rimas: Thanks, Kathy for being on the show today. It was wonderful to have you on.

Kathy: Yeah, no problem. It was great to be here. And by the way, GitHub is hiring. So if your product manager and you're looking for your next role or you just want to talk to us about product management and what it's like there, reach out. You can go to GitHub job page and check us out.

Rimas: Thanks again.

Kathy: You're welcome.