Exploring Product Principles With Scott Williamson of GitLab

Kayla: Thanks for tuning in. On today's episode of Product Chats I talk with Scott Williamson who is the chief product officer at GitLab. And we talk about his product principles and career development framework. So, hope you enjoy the show, leave us a review and check out some other episodes.

Kayla: Hey Scott. Thanks so much for joining us today.

Scott: You're welcome. Thanks for having me, Kayla.

Kayla: Yeah. So tell us about yourself.

Scott: I am the chief product officer at GitLab. I've been here about three years prior to GitLab. I had a six year run with a company called SendGrid that was eventually acquired by Twilio.

Scott: So the last nine years, that really sort of high scale environments, both went public and involved a lot of hiring and setting up, uh, product systems that can scale across a lot of PMs. I live in Boulder, Colorado, two high schoolers, uh, and for fun, if you could call it that I like to train and race triathlons, uh, Olympic distance triathlons.

Kayla: So basically, if anyone wants to talk to you, they should also train with you. Right?

Scott: Yeah, that's a good way to do it.

Kayla: And then I'm curious. So it seems like you've had a really strong journey in product, but how did you get into product?

Scott: It was a very circuitous, unusual path. I grew up in a small town in Kansas. My undergrad was in business. Wasn't particularly exposed to technology early in my life. In my early twenties ended up kind of stumbling into the software industry out in the Bay Area, kind of moved out there on a whim really, and found a sales job.

Scott: So I was in sales for the first four years. Very quickly while in that sales job realized that product management was of interest to me. So a year or two into that, I actually applied for a PM role. Didn't get it, you know, was told that my experience was too far, too far from what they were looking for.

Scott: So I went back to grad school. I went to Haas School of Business, got a specialized in management technology to try to bridge over to product management. Uh, when I graduated, it was actually a tough market. It was 2003. There had been a downturn and it was actually really hard to get a PM role, even though I had the MBA because I hadn't done it before.

Scott: So I took a job in strategic alliances. It was very close to product. And after a few years in that role was able to finally bridge over because I had built relationships with product leadership at that role. So it took me a long time, but yes, ever since I got into it, it's been a great steep career trajectory, probably because I knew I wanted to do it.

Scott: I worked hard to get there. And so it's been a great run since.

Kayla: And so for anyone in sales right now that wants to get into product, what's your advice for that?

Scott: Yeah. I, you know, hopefully it doesn't take you seven or eight years, like it did me, but I think you have to demonstrate to a hiring manager that you're serious about wanting to be a product manager. The skillset, and the, there, there are some overlaps in skillset, but there are definitely things about product management that you don't get to flex in sales, you know?

Scott: So. Maybe build your own app or work at a company where, or be the liaison to the product team or take a product management training course. There are lots of ways that you can demonstrate that you're really serious about product management, but it's quite a leap from sales to PM direct without laying some groundwork.

Kayla: And I think a lot of times to go off of that, when I talk to a lot of product leaders, it's about the skillset nowadays, more so than the experience. Right. Hey, how do we like hire? What are the skillset that is valuable in sales that could be like applicable to product. And is that like how you hire now or how do you hire?

Scott: Yeah. It's well, first let me make a comment that I do think my background in sales and biz-dev differentiated me once I finally got into product management, because I thought about customers right away when we were building something, I would think about how are we going to talk about this? How might we position this?

Scott: How would marketing talk about this as a differentiator. That wasn't a big leap for me to consider that stuff, but it is for some product leaders who might have come up from a technical background or just haven't been schooled in business. So it was a differentiator and those kinds of things can really help you as a PM.

Scott: Another thing that's really important as a PM is being able to interview and talk to customers and pull insights out and sales people do that all day long. So that's super helpful.

Scott: In terms of how I hire. Now, we have a career development framework. We call it at GitLab. We also had one at SendGrid. And there's four different buckets that I'm looking for generally.

Scott: And it's articulated at different levels. So there's a PM level, a senior PM level and a principal PM level. There's also a track for people managers, but let's stay on the individual contributor track.

Scott: Uh, the four buckets, one is validation skills, and I just hinted at that. So can you talk to customers?

Scott: Do you have an appetite to go interview customers and draw insights out from them? That's one, two is I call it build skills, but it's a demonstrated ability to work with engineering to negotiate. Scope versus, uh, timelines to be able to prioritize, to be able to iterate and break things down. Those are things we're looking for in build.

Scott: Then the other is business skills. I strongly believe that a PM needs to understand the business of what they're doing and link the development activity to the business outcome. So can you think in terms of what are we trying to move here? Are we trying to drive upgrades? Are we're trying to drive retention? Are we're trying to drive cost down?

Scott: What are we trying to do here business wise and how might this link to that? And can you build a, at least a simple business case to connect the dots?

Scott: And then the third is, or the fourth is communication skills. PM involves a lot of stakeholders, you might be talking to the exec team in one meeting, and then you're talking to engineering peers, in the next, those are very different conversations and very different altitudes.

Scott: Well, not everyone is good at knowing what altitude they need to speak at. Sometimes I just have one level. And so we're looking for someone who's nuanced in the way to communicate.

Kayla: And with that, I think two, two of the pieces you've touched on are about understanding, right? Understanding your customer and understanding your business.

Kayla: And so out of curiosity, like when your team is listening to your customers what are you doing? Are you doing user interviews? Are you doing surveys? What does that look like for your team?

Scott: Yeah, we call it at GitLab, we call them customer inputs. And there could be a lot of times it's interviews. So when we start the process, we have a, what we call it a product development flow and the front end of it is the validation cup, the validation track, and then the validation track you want to validate the problem you're trying to solve first, and then you validate the solution to the problem.

Scott: And those typically at least for new stuff where you're trying to learn, maybe it's a new use case you're going after. New customer type, brand new feature. You definitely want to be doing this kind of interviewing and they tend to be qualitative interviews, five to ten.

Scott: You're looking for patterns. And so in any major endeavor, you'd probably expect a PM to have done 10 to 20 qualitative interviews. But things that are already out in the market, you might use more quantitative data sources like product usage trends, data from sales about what's driving sales, NPS feedback, uh, that kind of thing.

Scott: So it's a mix of written inputs, qualitative inputs, and quantitative inputs put all that together. And as a PM, hopefully you can start to synthesize what really matters.

Kayla: And so it's like starting with listening to your customers, what are the steps after that? You've gotten this feedback, you're kind of understanding, right, what the problem is, and then you get this feedback. What comes next?

Scott: The next is we call it the solution validation phase. So typically a designer then hops behind the wheel and takes the lead. The designer will put some kind of a prototype, could be high fidelity. It could be low fidelity in front of the same kind of target user that you identified in the problem validation as having that problem.

Scott: So, Mrs. Target customer, we know you have problem X, does this solve it for you? And so that's, that's usually how we validate the solution. Once we gain confidence in that, then it's time to build it and GitLab is really good at iteration. So the game is to break it down as small as you can, while still adding value and ship as many value, adding increments as fast as you can to learn.

Scott: And then you sort of build your way into the eventual full solution.

Kayla: And when you're listening to your customers about all these different things, how are you figuring out like what to prioritize over something else?

Scott: Yeah. Uh, there's different tactics we have for that on the problem validation phase, we use an artifact called the opportunity canvas.

Scott: It's a one pager and on one page you can get a pretty succinct. For what we're trying to do. I've seen hundreds of these things. And so after you seen a bunch of them, you can kind of pattern match and it's fair. I'm not going to say it's easy, but it's, it's fairly easy to compare the relative value of one versus another.

Scott: So that's one tactic is sort of, at that, we call it epic level. Like when you're trying to do something pretty major, you're going to have an artifact like that and you can compare.

Scott: You can also use a scoring system. Uh, I've used RICE? What what's called RICE. It's a system that, uh, Intercom came up with. RICE is reach I is impact, C is confidence, E is effort. I multiply the first three divided by the fourth and you come up with the score and that can allow you to a bit more quantitatively, a bit more objectively compare two different things from one another or multiple different things. And sometimes you'd be surprised about what rises to the top.

Scott: I think people oftentimes underestimate the effort involved and something can rise to the top when it's light in effort. And, you know, people sometimes fall in love with the upside of something that's actually quite large, but when you look at things objectively with a consistent scoring framework that can help you organize what you do when

Kayla: Yeah, and I think like the, you can also fail quicker, right? If the effort is very small, it allows you to fail quicker. And that's something we talk about all the time, right. Is fail quick and build better. Right. So not just like taking on a huge project it's Hey, let's look at the smaller things that probably require only a little bit of effort compared to some bigger things.

Kayla: And maybe that will have a bigger impact than something that's huge, or maybe won't, but at least you didn't put all this development time into this really big thing that fails.

Scott: Yeah, I've learned a lot about iteration at GitLab. One of the company's values is iteration. I've never seen another company where one of the values was iteration.

Scott: And so I think what drove this is GitLab is an all remote company and always has been. And when you're in an all remote company with, we now have 1800 employees, if you don't break things down small and you have to have a lot of coordination across multiple people that are all working remotely, it can get ugly fast.

Scott: So the name of the game is to break things down so that an individual can control their own destiny and run fast without needing a lot of coordination. And so it's kind of in the company's DNA and you see it in our release process. We release once a month on the 22nd, like clockwork, the train just runs and we load as much on it as we can.

Scott: And so each team is thinking about, Hey, what can I do that can make that next train next month? Because it's leaving. Whether I have something ready for it or not. And it just sort of gets the teams used to shipping. And it gets the PM in the mindset of breaking things down so that they have things to show monthly.

Scott: I should also clarify that. We have a self-managed on-premise version. And that's what I'm talking about. We also ship even faster than that in our SAS version. But nevertheless, once a month we sort of package everything that we've done up and we'd number it into release.

Kayla: And so something I actually want to go back to is you talked about your team members controlling their destiny and working remotely. And I think this ties into retention, right? Like you're really good at hiring. You're growing super quick. How do you, I think that's around like that career development, but let's talk a little bit more about how once you've hired.

Kayla: Right? Cause you've put a lot, that's everyone's thinking about hiring. How do you actually keep those team members around and make sure that they're happy? Like what do you, what do you do at GitLab?

Scott: Well, it takes, uh, takes work. You have to make it a priority. It's the kind of thing that a lot of companies short change because the value of it isn't clear until people start walking out the door.

Scott: So it's like staying healthier, eating, having a good diet. You just have to do it. It has to be a regular part of, of your cycle. So we have what we call a career development framework. You can look it up on our handbook, 98% of what GitLab does is published transparently and what we call our handbooks.

Scott: So you can look this up it's career development framework. Search for GitLab career development framework for product, and you can find it. Anyway, I already described it. It's got expectations at each level. So once every two to three months, the manager will update their thoughts about where each person is against each of those criteria.

Scott: So one was validation skills. So what have you done in the last two to three months that either demonstrates that skillset or falls short and you can provide constructive feedback? So it's a way to kind of get out of the weekly tactical, what am I doing this week one-on-one and have a real career conversation that can help that PM understand where they are.

Scott: Am I meeting expectations? Am I exceeding expectations? And might I be on, on path for the next level? It helps the manager and the person get crisp on that because you don't want the PM to think they're ready and manager to think they're not and those two not have a conversation about it.

Scott: So keeps the manager employee relationship in sync and it gives constructive, actionable feedback that the PM can work on in areas where they need to get more mature in their skillset in order to either do a better job at that level or qualify for the next level.

Kayla: And with that, are the frameworks different for someone who wants to become a people manager versus someone who wants to stay in an ICP role? What does that look like?

Scott: Yeah, we do have a separate one for people managers.

Scott: And so people manager track is group manager. It's at the same level as a principal PM. And then director senior director, VP, CPO, and each level has expectations on the same four dimensions I already mentioned. There's also a people management track. So the real difference between the two is the addition of this fifth people management track, which outlines expectations around managing, providing feedback, that kind of thing.

Kayla: And with the frameworks, what have you seen as some of the strongest people and who have developed like the quickest in their careers? What are those skill sets, or obviously it's an openness to seeing your weaknesses and improving, but what are those things that kind of run true that you see this person is super valuable to my organization?

Scott: You know, different people have different strengths. I think if I were to pick one that I think is most important, I think it's that validation skills area. Well, that and communication.

Kayla: All areas.

Scott: Yeah. They're all pretty important. People, I, I think people who have an affinity for validating stuff and getting out there and talking to customers and uncovering insights and for whom that is maybe not easy, but at least it's just part of the rythm.

Scott: Those are the PM's that do the best because they get the best insights. They build the best stuff. They end up with the best results. Uh, you can have a great business case, or you can work well with engineering, or you can speak well about your stuff, but if you're not out there validating it and coming up with the very best product concepts, then the rest of those things don't shine as much.

Scott: So I would say that. And then there's also this underlying, I think there's one trait that underlies all of these expectations, which is systems thinking. And it's can you like product management is just one giant problems solving cycle after another. Can you, can you understand the problem and come up with the solution and get the thing built and launch it and learn from it and go around?

Scott: And I I'm sure there's many ways to describe it, but I, I kinda, I kind of boil it down to systems thinking like, can you tie what you're doing here to all of the downstream impacts from it because there's a lot and people who think systematically do better as PMs, rather than somebody might think in a very haphazard way.

Kayla: I think on that, right around thinking about systems, I think this is a perfect segue into your product principles. And let's talk a little bit about that, about the different tactics and frameworks that you use at GitLab.

Scott: Yeah. When I joined GitLab again, about three years ago, the very first thing that I rolled out was a set of nine product principles.

Scott: And just as an example, the first one is hiring is job one. And so each of those product principles allowed me to describe to my boss, to my peers, to my team, through the fundamentally how, what I thought, what I think is important for a product organization. I didn't come in and say, hey, we're going to run product development exactly this way.

Scott: We're going to run our hiring cycle exactly this way. But it did allow me to say, hey, this thing is important and I'm going to keep pushing on it until I believe that we're sort of clearing the bar as far as this principles, explain what kind of leader I was and what kind of system I wanted to set up.

Scott: And so over the last three years, we've been chipping away at clearing the bar on each of those nine product principles. And over the last six to nine months, I've been reviewing a product principle per PM team meeting. And it's been really rewarding to go back through that because we made a ton of progress on each one.

Scott: There's still ways to get better. And so it gave me a chance to remind the team about the principal. Celebrate progress against it and emphasize what we need to do to keep getting better. And all nine are still there and they're still important and they haven't really changed. So it's nice to have something that's solid because product is a really fluid, dynamic, challenging role.

Scott: And so having these things that you sort of to your core believe in can help you make decisions about what to do and what not to do. Does it honor that principle or not? And it's really helped me in the last few years.

Kayla: And I would say to that, right, a lot of the like product leaders that I talk to are more about frameworks rather than kind of prescribing.

Kayla: And that's what I see as like a trait in the best leaders is, hey, here's our goal and here's the framework to get there, but you can kind of choose your own path, right?

Scott: Yeah. Yeah. I think that's smart because every company's different, products are different. They're architected different, the DNA and the values of the company are different.

Scott: And so, lots of different ways to get there, but, you know, for example is hiring job number one. Do we prioritize it enough? Are we, is the bar high enough? You're only as good as the quality of your team. And so are you living up to that? If so, then who cares exactly how you get there?

Kayla: Exactly. So, can you tell us about a few more of your product principles and what's at the top of your list?

Scott: Yeah, sure. The, uh, the next one, number two is care personally and challenge directly. And this is a phrase that I borrowed from a book called Radical Candor, uh, written by Kim Scott. And so if you think about the order of it, we got to bring in great people. And then once they're here, we've got to manage them effectively.

Scott: And so care personally is people want to work in a system where they feel valued, where they feel safe, but you also have to be willing to, to provide direct feedback because it's, it's actually a gift to them to get direct feedback. And it's a disservice to the people that they work with to not provide that.

Scott: So are you caring for the team, but also challenging them? That's sort of how I want the performance management to feel.

Scott: Third is always be learning. PM. Look, tech is moving fast. Product management is moving fast. If we don't have a learning growth mindset as an organization, we'll fall behind real quick.

Scott: So do we have training available? Do we encourage our team to go learn things. Do we do performance management so that they know what they need to do to get better?

Scott: Uh, number four is you're not the customer. It's very tempting for people who make product decisions to assume that they know what the customer wants, but, you know, we work for a high tech company we're sort of exposed to the latest and greatest.

Scott: We're doing our own thing. We're not actually a dev ops professional at the billing software. So go sit with them, go understand what their life is like, what their problems are like, uh, and build some empathy.

Kayla: And I think that goes back to a point, right, about the skillset of understanding, right. Understanding your customer and understanding your business and that's what you're interviewing for.

Kayla: And so obviously that would be one of your principles because it has to align on what you hire for and how you're actually living day to day. Right?

Scott: Yeah, exactly. I think they all hang together like that. You know, they all reinforce one another.

Kayla: And so with those product principles in mind, it seems like obviously aspiring product leaders should live through those nine principles, but what's one piece of advice you would give to an aspiring product leader.

Scott: Yeah, actually, I'm going to reflect on one of the product principles we didn't cover, which is prioritize relentlessly. And, you know, it's intended mostly for product team members who are making prioritization decisions, but I think it also applies to a product leader who is focused on building the system.

Scott: For example, when I joined GitLab . Yeah, it's a big company. There's a lot going on. It's complicated. There's a thousand things I could have focused on, but I knew we had to triple the size of the team over the next two to three quarters. And so I said to anyone who would listen, my number one goal is hiring. Period full stop.

Scott: Uh, and so I invested a lot of my time in making sure that the process was solid and interviewing candidates myself was second only in priority to taking customer calls and I did things, I, you know, I invested a ton in that and I ignored things that you would normally expect a new CPO to dive into. I didn't talk to customers as much as you would have expected.

Scott: I didn't dig in on the product as much as you would have expected because I knew hiring was my number one priority. And if we didn't get the team staffed, then it doesn't matter what I do personally. And so, that's an example of heavy prioritization. It's know the thing that you're trying to fix within your system, what's the number one, or maybe two things? Feed that make sure that happens and then move on to the rest.

Scott: It's tempting to try to solve 10 or 20 things at once, but ultimately I don't think it works as well as if you just, you know what your number one thing is. Work on it until it clears the bar and then move on.

Kayla: And on that note of hiring, what roles are you hiring for?

Scott: We have a number of senior product management roles.

Scott: So check out the GitLab jobs page, and please apply if you're interested.

Kayla: And where can people find you?

Scott: I hang out mostly on LinkedIn, so check out my profile there, feel free to hit me up, uh, connect with me or send me a DM via LinkedIn.

Kayla: Perfect. Well, it was great having you today.

Scott: It's great talking with you. Thank you, Kayla.

Kayla: Thanks Scott.

Kayla: Thanks again to Scott for coming on the show. If you want to check out some product management resources, feel free to head to canny.io/blog. See you next time.