9 Principles in Building World Class Product Organizations

Monisha Saldanha Welcome, Scott. Thank you so much for joining us today.

Scott Williamson Happy to be here. Thanks Monisha.

Monisha Saldanha Well, perfect. Well, we're going to dive right in. And I have a question for you, which is, you've had a unique path from sales into product leadership. What drew you to product management and what kept you there?

Scott Williamson Well, I really enjoyed working in sales. Let's start there. But the nature of it is that you react to whatever is given to you. You have to do your best to sell the product that's put in front of you and position it and sell it as best you can. And I pretty quickly learned that the product team were the ones that were deciding what the product was going to be and what the future of that was going to be. And that's about like a really.Monisha SaldanhaWelcome to Colorado Tech People, where we talk with the leaders shaping the future of technology from Colorado and beyond. I'm your host, Monisha Saldana, a product executive with 15 years of experience. Today's episode explores what it takes to scale product organizations and companies from startup to public markets. I'm joined by Scott Williamson, a seasoned product leader.Scott Williamsonhigh leverage role and a super fun role. And so it didn't take long before I realized that was the role I wanted to take on.Monisha Saldanhawho helped guide SendGrid and GitLab through their IPO journeys and now advises high growth companies. He will share nine principles in building world-class product teams, preparing for life as a product company, and how product strategy evolves at each stage of growth. Let's dive in. ⁓Scott WilliamsonAnd then you ask what keeps me in it. It's a super strategic job. What you do day to day is super dynamic. It's a very fun and interesting and high impact role.Monisha SaldanhaYeah, I totally agree having worked myself in product management for over 15 years now. ⁓ Across roles at SendGrid, Twilio, and GitLab, what core principles have guided your approach to building world-class product organizations?Scott WilliamsonWell, there's, I read a book called Principles by Ray Dalio in between my SendGrid and GitLab jobs. And I actually wrote down what my product leadership principles were there. I took them into that org and the very first thing I did was roll them out to the team. And I'm a firm believer in being firm on principles and loose. on tactics as to how you make those principles come true and that worked well for me at GitLab. So I'll just run through them. Number one is hiring is job one. As a product leader and as a product team, that role is so important. And you get tons of leverage out of hiring the right PM and you get negative leverage out of hiring the wrong PM and so investing a lot. in creating a system where you have A players has tons of benefits across the whole organization. So I always made that the number one priority. Number two, care personally and challenge directly. I lifted this term from a book called Radical Candor. the general idea is as a manager, you want to care about your people as human beings that have lives, but you also want to be willing to Challenge them directly and give them timely feedback so that they can do their best work And when those two things work hand-in-hand across all your leaders good things happen Third always be learning never more true than today you got to continuously invest in skill development in in Being your best self whether you're an IC or a leader and having that mindset as an individual and as a larger team is super important Four, you're not the customer. Talk to them. It's tempting to assume that we know what's best for our users, but the fact is most of us sitting in our chairs as product people do not adequately represent who the customer is. If you don't get out and talk to them regularly, you can make assumptions that are just flat out wrong. Five start with the problem not the solution. It's so tempting especially now when it's so easy to build stuff to just start with the solution But oftentimes that leads to ill-conceived product concepts and it's just way better to start with the problem Six, prioritize ruthlessly. It's better to do a few things really well than to do a lot of things poorly. Seven, assume you're wrong. Human intuition is often wrong. We overestimate our ability to be right at any given moment. So it's best to start with a hypothesis and try to invalidate it rather than assume you're right. Eight, iterate. ⁓ Leverage a fast-paced build measure learn loop rather than trying to plan something out all the way through. Much better to iterate, build in small chunks, get quick feedback. Finally, be data-driven. It's best to have a success metric, an outcome that you're trying to push towards rather than getting wrapped up in individual things that you ship and try to... engineer your activities to move those numbers in the direction you intend them to move.Monisha Saldanhathose are really great lessons and were those lessons hard won?Scott WilliamsonThat's a great question. ⁓ You know, I remember going through each of these with the team at GitLab. So I rolled them out and then I would do check-ins on them, maybe every quarter or two quarters. And I would reflect on where I thought we were against them. And it was a journey, like when we started, some were in good shape, some were not. And over time, you know, we chipped away. I would argue by the end of it, we were in decent shape on all nine, but... have to ⁓ your battles, so to speak, as a leader, figure out what matters most, ⁓ work towards an acceptable level of performance against each one. You can't go solve them all at once.Monisha SaldanhaCool. And how did your early experience in customer facing roles shape your philosophy around customer first product development?Scott WilliamsonI think it had a profound impact. I spent my first four years in sales, my next four years in strategic alliances where I was working with key partners. Both of those were external, outbound sales roles. And so it's very natural for me as I think about something we might do in product. Does anybody care? Do customers care? Can we position this? Can we sell it? Does it help our overall position? Is there willingness to pay? These questions are awesome. come up quickly and naturally for me and I think a lot of people who might come up from a tech background may not think of them naturally and so I think it's helped differentiate me as a product leader.Monisha SaldanhaAnd you've scaled product organizations through hyper growth. What changes when a product team grows from a handful of PMs to dozens?Scott WilliamsonWell, first of all, as the product leader, you can't make all the decisions yourself anymore or else you're gonna become a bottleneck. And so the first change is you have to let go, you have to delegate, you have to build a system and a team that you can trust to make good decisions independently or least relatively independently. So that's one big change. Two, as it... As the team gets bigger, gets increasingly complex, and you have to really start thinking about it as a system, you're not... I came to view the product org as a product in and of itself, and I applied product thinking to the system, and I would ask myself, you know, what's the of system ⁓ that's the least performant now? What's the part of this that's leading to suboptimal results? Let's go fix that. And so you get into this systems operational mindset where you kind of prioritize your problems as a product leader and you endeavor to go solve them so that each product person in each product team can do the best work of their careers. And whatever's holding them back from that, you have to go fix.Monisha Saldanha⁓ And what are the common mistakes that you see companies make when they're trying to scale product management too quickly?Scott WilliamsonOne, hire too fast. You hire to fill seats. You don't maintain the quality bar. That's ⁓ a killer because you pay for that down the line. ⁓ Two, you keep decision making too centralized. This is particularly challenging with founders who still own the product because they're used to really tight control and really owning everything. But if you don't... trust your team enough, end up with, you can end up with teams that don't operate independently enough, they don't feel trusted, they don't make great decisions. ⁓ ⁓ don't invest enough in leadership. As you grow and you end up with directors or managers, if they are ⁓ equipped to manage the performance of the PMs under them, ⁓ either they haven't been trained to be a good leader ⁓ ⁓ have a great system within which to work as a leader, ⁓ can end up with suboptimal results for the team underneath them. so investing in great leadership is a key part of scaling as well.Monisha SaldanhaAnd how do you know whether you've hired a great leader? What are the kind of characteristics that you look for?Scott Williamson⁓ I used to do skip level meetings with the team underneath the leaders that I managed. And so I would look for positive feedback on them from the people on the team. Like, are they learning? Are they doing great work? Do they sense clear direction? ⁓ they getting the right mix of guidance and independence? Those are things I was... So you look for signal from the teams that work for them. You also look for your own confidence level. Can I delegate to them confidently? Do I trust their strategy? Do I trust their decision making? Do I trust that things are healthy in their area? So kind of top down and bottoms up.Monisha SaldanhaCool. And was there a turning point during your time at SendGrid or GitLab where a difficult product decision significantly changed the company's trajectory?Scott WilliamsonYeah, of course. ⁓ At Sendgrid it was a moment of expansion. Sendgrid was a very successful product company for a long time. was an API for developers to add email ⁓ ⁓ mostly around ⁓ emails. And at one point, we'd made an explicit decision that we were going to also target marketers. And so we built a second product called Marketing Campaigns. which was a huge effort because it required us to serve a different persona. Marketers think and act and buy much differently than developers. And so we had to kind of retrain ourselves and add some new DNA around serving marketers, which was a big effort. But in the end, that product did quite well and allowed us to increase our total addressable market by four times. It ended up adding Material AR and it helped us position ourselves as a multi-product email communications platform. At GitLab, it was kind of the opposite actually. We had already positioned ourselves as a DevSecOps platform, so it was exceptionally broad. Everything from planning to source code management to CI to CD to monitoring. very expansive product. We were spread too thin. And so at one point we consolidated about 80 % of our engineering and product energy onto four of 10, what we called stages. And that focus on just a handful of areas really helped accelerate the value. It helped us match what sales was landing on with what we were focused on in the product. It made the key areas great. and allowed the other ones to grow more slowly. That was moment of leverage at GitLab.Monisha SaldanhaAnd what happened to the other six stages? Did they just go into kind of a holding pattern?Scott WilliamsonYeah, we had very small teams on them. on most of them, we would have something like a product manager and three or four engineers. And they would chip away on that feature set. But compared to another stage that might have three or four full teams with 30, 40 engineers, it was a much smaller investment. So was mostly about resource allocation. And for some of those, we had to. live with kind of a smaller investment at slower maturity of those stages.Monisha SaldanhaCool. And kind of shifting gears a bit, looking at how we explore how technology enables innovation, platforms, and new business models. You've worked across multiple go-to-market models, enterprise, open source, freemium, and product-led growth. How do you decide which model fits a company best?Scott WilliamsonYeah, the key thing here is to be clear about your ideal customer and buyer profile and be true to that and be disciplined about that. Once you know who that customer and buyer is, usually the good market model that they require becomes clear. You know, if you're selling to individual developers, maybe you'll have a freemium PLG offer. If you're selling to an executive, you know, CIO type or a security buyer, it's probably gonna be enterprise sales with a trial or a pre-sales team. And the meta point is base the go-to-market off of who is buying your thing and who perceives value. If you try to do it the other way around, like, oh, I really wanna be a PLG. or I really want to be open source, but those target users don't want to buy that way, then you end up with an unsuccessful product business. So as much as you want to be a certain type of company, you really end up needing to base it off of what customer.Monisha Saldanhareally good advice. So start with how the customer wants to buy and then you decide your model based on that. ⁓ How should product leaders balance short-term revenue pressures with long-term platform strategy?Scott WilliamsonYeah. think this one depends on the stage that you're at. If you're pre-product market fit, or let's say pre-predictable product market fit, then almost 100 % needs to be on driving short-term revenue in that core thing that you're building. You shouldn't distract yourself with a second product or some platform strategy at that point. You need predictability. You need to know that. When you hire a salesperson, what's going to happen? Or when you invest more in the marketing program, you know what's going to happen. And until you get there, don't distract yourself. Once you've found that predictability, then you can turn up the dial on the next big thing, whether that's a second product or a platform approach or what have you. And as the product matures, you can increase the proportion. that you spend on things that are gonna pay off in a year or two or three. It's product thinking. And if you're looking for a framework to manage it, I'd recommend the Three Horizons model.Monisha SaldanhaGreat. And as AI becomes more embedded in software development and product management, how do you see it changing the way product teams build and ship products?Scott WilliamsonWell, this is happening as we speak. The level of change is pretty stunning. Even over the past two weeks, I've had several calls with product leaders who say something along the lines of, everybody at our company is using Claude Code now. And ⁓ it's changing a lot. ⁓ In terms of product development, look, engineering has been using AI for a while and it's... Helping them, the percentage of code that's being written by AIs is increasing pretty rapidly, just about everywhere. But the impact for product people seems to be happening fairly recently. I think there's a couple big impacts. One is on the ability to bring to life your ideas. It's very easy to prototype now. It used to be much harder. It used to take much longer. Now you can use any number of prototyping tools or something like Cloud Code or Codex to prompt your way into a prototype. And so this whole upfront product validation process can be much faster by using AI. So that's an exciting trend. And I hope that everyone's learning and taking advantage of these tools. Secondly, it can help non-developers build faster. Again, in the last two weeks, the CTO mentioned that he had gone in and taken on a piece of development work that he never would have done two years ago. There was a product manager who'd been angling for some content change in the product where he couldn't get wording changed and was able to go on and use Claude Code and push a change himself. And so it's enabling PMs, designers, leaders, to get in and update the code base themselves without relying on a full-scale engineer to do so. Those are both exciting changes. It's also resulting in a lot of chaos because it's very easy to build now. And so you end up with bottlenecks elsewhere. I think you end up with bottlenecks before building and after building. Key constraints now are taste and context. Like, is this thing, should we build this thing? And then the other bottlenecks come on the backend with things like CI testing, security testing, merging changes, making sure the code makes sense. ⁓ But the middle part, the building is now quite fast. So it's evolving how we deal with all those things. And I don't know exactly how it will shake out, but it's clear that everything's changingMonisha SaldanhaYeah, got to ride the wave of change. Yeah. What advantages or challenges come with building and scaling global companies from Colorado rather than traditional tech hubs like Silicon Valley?Scott WilliamsonYeah, you gotta lean in on it. I've worked for SendGrid for six years, which was Colorado based. I've also worked for Silicon Valley based companies and I've advised around 50 companies, many of which are outside of Colorado. So I think I have a decent feel for the differences. Colorado, I think the main difference is the feel of the ecosystem. Brad Feld and Foundry, the VC, really kind of set the tone. Feld wrote a book called Give First, and the general idea is if somebody asks for help, just pick up the phone and help. And I definitely feel that here. It feels very collaborative. It feels a little less cutthroat, a little less hustle culture. You know, you get a lot of people here who are here for the lifestyle. They care about the outdoors. They're active. They want to have a life outside of work. And so I think that is an advantage as a person who works in Colorado to be able to find companies where, you know, you're valued as a person and it's not all about the financial results. So that's one positive to being in the system. One of the disadvantages, especially now, is the center of gravity for AI is clearly Silicon Valley. So if you're an AI-focused company and you want to hire talent, it's a little harder to find top-tier AI talent in Colorado. And conversely, if you're a product person, and you want to work for a high-end AI company. There aren't that many options here. Most of them are in Silicon Valley. So it felt for a while like these hub cities like Denver were developing their own kind of ecosystems and their own power. And it's shifting somewhat with AI with more of the startup energy shifting back to Silicon.Monisha SaldanhaThat's really interesting. ⁓ You were part of SendGrid's journey to IPO and its acquisition by Twilio. What was that experience like from a product leadership perspective?Scott WilliamsonIt was awesome. ⁓ When I started at Sendgrid I was the first product leader. There were a couple PMs, but they reported into a VPN marketing. They hadn't had a product leader before. So it was a chance to build a function from scratch, which is a unique career opportunity. And then there, we scaled, gradually matured, ended up going public. ended up with revenues exceeding 170 million. The product team grew north of 30 people, ended up running product marketing, product management, pricing. developer experience, docs, quite a few other functions. It's a very well-rounded experience in terms of being able to scale the team and run multiple functions. We added a second product and eventually went public and sold to Twilio for three billion. So was hard to beat. Also, there were really great execs there. The CEO, Samir, the CPO, Steve, the CFO, Yancy. The of Engineering, Craig, all just ⁓ awesome leaders. I a lot from them. ⁓ And the end of it, I felt like Sendgrid was a really well-oiled machine and just a great place to learn how to run a high-quality tech company.Monisha SaldanhaAnd GitLab also went public during your tenure as CPO. How did preparing for an IPO change the way product decisions were made?Scott WilliamsonNot much really. GitLab did a good job, I think, of staying the course. What got us there was what we were going to continue doing. So it didn't really change product decisions. We just had more work to do to deal with the S1 and the roadshow and all of the marketing we have to do to position the company. for going public, most of the, really didn't change our product strategy or prioritization.Monisha SaldanhaAnd what are the mistakes that you've seen the companies you advise make? I know there must be many different kinds of mistakes, but can you give us some examples of lessons that have been learned by the companies that you've been advising?Scott WilliamsonYeah, I would say one is not focusing enough. I've seen many founders who are very nervous to consolidate their energy around a specific, perhaps narrow ICP. I think they feel like doors are closing on them and that they're... lessening their chances to find a winner. But counter-intuitively, think this most times works against them because they end up not adding enough value in any one ICP. And if you're not clearly better than the alternatives, then people are not gonna change their behavior for you. They're not gonna try your thing. They're not gonna spend time on a sales process, and they're certainly not gonna. pay you. And so you have to be clearly better than their alternatives and usually the way to do that is to really focus on a particular market even if it feels narrow and really knock it out of the park and then expand from there once you've found some sort of repeatable product market fit. ⁓ Good ICPs early oftentimes feel fairly constraining and narrow. A second mistake that I've seen quite a bit is scaling based on the funding round they're on rather than where they're at as a business. So you get a big A round and all of a sudden you think you need to fill out the executive team and you need to hire a bunch of salespeople or engineers or what have you. But if you don't have the business behind it, you end up creating work. People come in and want to have an impact and they do stuff. But it might be distracting. It might create work that doesn't pull towards the main thing the company needs to get done at that point. It might pull away from what the founder's trying to do on their own. And so my general guidance is scale based on where you are with the business and not where you are with the funding around. Don't spend money just because you have.Monisha Saldanhareally good advice. And what is one book every builder should read and why?Scott WilliamsonI'm gonna go with the mom test. It's a very quick, easy read on effective customer interviewing. My general sense is that most people have not been trained on how to interview well. And most people screw them up. And they do not get what they need out of early stage customer interviews. And so I would recommend that all builders... whether you're a leader or an IC, whether you're a PM, designer, engineer. Read this book so that when you do talk to users, you pull the conclusions out that really truly matter.Monisha SaldanhaYeah, I've read that book, so I will second your recommendation. It's a good one. ⁓ Scott, this has been a wonderful discussion. ⁓ Love your nine lessons, ⁓ which I think will be the hook for this episode. So very interesting. I'd like to thank our listeners for listening to this episode of Colorado Tech People.Scott WilliamsonI hear it. That was good.Monisha SaldanhaIf Scott's insights on scaling product teams and navigating IPO's spark new ideas, we encourage you to share this episode with a founder or product leader in your network. Be sure to subscribe so you don't miss future conversations the builders shaping Colorado's tech ecosystem. ⁓ can find show notes and links to Scott's work in the episode description. Until next time, keep building, keep learning, and keep pushing what's possible. Thank you, Scott.Scott WilliamsonThank you, Monisha