Give The People What They Want

Nate: Hi, I'm Nate Stewart. I'm Head of Product at Cockroach Labs.

Suzanne: Welcome, Nate Stewart. We're here in cold New York City.

Nate: Cold New York.

Suzanne: Have you always been in New York, by the way?

Nate: No, I was born in Michigan and went to New York, then Boston, and Seattle, and now I'm back here.

Suzanne: All the cold and rainy cities.

Nate: Exactly. I've been unlucky.

Suzanne: You are a developer by trade. Was that your original out of school or what I wanted to do with my life?

Nate: Yeah, absolutely. I started as a computer science undergrad at the University of Michigan, and then moved to New York to work at Bloomberg as a financial software developer.

Suzanne: When did you make the pivot into product?

Nate: At Bloomberg, I was on a team responsible for doing portfolio analytics, so seeing how the price of your portfolio or the value of your portfolio would change if something happened in the world. It was a very stressful job. It was a job where I was always on call and could be woken up at 3:00 in the morning. I realized that there were this other group of people who were able to say, "Hey, here are the problems that we're solving. Here's what we want the software to look like." They could really get all the fun of building the software without having to worry about the implementation detail, and I realized-

Suzanne: No calls at 3:00 AM. They just left at 5:00 PM and went drinking.

Nate: Exactly. I realized that was the product management team, and I wanted to learn a little bit more about that. So I decided to apply to business school and was accepted and enrolled at MIT Sloan.

Suzanne: Have you known, in your career, a lot of developers to make that same change? One of the themes that comes up, I think, in our show is I'm in a PM-adjacent role, and I want to get into product management. Is it common for developers to long for that more strategic center, or do you consider yourself to be anomalous in that regard?

Nate: You'd think it would be more common. It's tricky, because on one hand, development's a lot of fun. With some of the advancements in things like cloud computing and platforms as a service, it's actually a lot easier to do, and there's a lot less grunt work that needs to be done there. Developers may not always feel that pull to make their lives easier by going to product management. I've hired a lot of product managers, and I'd say, out of maybe the dozen or so that I've managed, only two have been developers by training. So it doesn't seem to be that common.

Suzanne: There's the parallel, I think, is you have to like solving problems in both of those roles.

Nate: Exactly.

Suzanne: Developers like to solve very specific types of problems, in my experience.

Nate: Yeah, correct.

Suzanne: Product managers like to solve the world's problems.

Nate: Exactly. One of the things that I think is different when moving into product management is really stepping back and figuring out what is that problem you're trying to solve in the first place, so framing the problem. I spend a lot more time there as opposed to actually coming up with that solution.

Suzanne: So you went to business school. You're like, I'm going to go start all over again, learn the business side of things, and you did a startup competition at MIT. Tell us about that.

Nate: When I was looking at business schools, I was really focused on ones that had strong computer science programs, because I wanted to learn how to work with some of the best engineers in the world with that product management hat on. MIT has a great competition called the MIT 100K Business Plan Competition, where you have your MBAs, you have your developers, you have your scientists that come together and try to figure out what are the next big businesses that are going to come out of MIT. I had a chance to work with another MBA and a couple engineers from the MIT media lab. We helped them commercialize a product, or at least put together a business plan for a product, that was a new way to interact with mobile devices. The thinking was that as screens were getting smaller, as people were moving to wearables, touch would become less and less important. So, they had a way to, rather than touch the screen, control the interface by manipulating the 3D things around the device. So you could do things-

Suzanne: Like Minority Report, like swiping the air?

Nate: Exactly. So, the pitch was this was the next type of interface. We were doing for wearables what the mouse did for the personal computer. We saw a lot of excitement around that idea from everyone from handset manufacturers to chip set manufacturers, and it was a really exciting business that did pretty well. So we were able to win the grand prize in the MIT 100K Business Plan Competition, and it was just a great example of some of the good things that can happen when you combine great product managers with great engineers.

Suzanne: Was that your first kind of application of the product management skills or lens that you had been learning when you went back to school, or were you already, at that point, working as a product manager somewhere else?

Nate: No, this was my first time in that product management function. For example, in this case, the initial plan was to create an attachment or a dongle that you would plug into your phone, and it became really clear that that wasn't something that anyone wanted to buy. So trying to figure out not only what problem were we solving but what was the first form factor to deliver it in a way that would make sense for the consumer but also for the handset manufacturer. That was something that, again, with that product management hat, I could provide some great input on.

Suzanne: So, what happened after that? Give us kind of the punctuation of your career. What steps led you here to Head for Product at Cockroach?

Nate: Absolutely. One thing that's always been interesting to me is enterprise software. Specifically, some of the ways that technology has evolved as the cloud has taken off. So, after business school, I joined Microsoft. They had a rotation program in their cloud and enterprise group, and this was around the time that Satya was starting to take the reins at Microsoft. It was really exciting in terms of building out the basic PM skill set, because in this rotation program, you did three things. You spent four months on pricing and licensing, so how do you commercialize software. The second thing was on product marketing, so how do you actually position a product and work with a B2B salesforce to take that to market. The third was really interesting. It was around operations. We were selling what was called converged systems, where we would combine HP hardware with Microsoft software to basically create a private cloud in a box. What did you have to do from an operations perspective to actually take a physical product to market? With that experience, it gave me a really good set of tools for defining problems, solving problems, working with teams of engineers and teams of sales and marketing teams to actually take it to market.

After that, I decided I wanted to do something a little bit smaller. Moved to New York. Joined a Sequoia-backed marketing SaaS company called Percolate, and that was my first classic product manager role. I joined as a second product manager.

Suzanne: But you kind of worked your way up while you were at Percolate, right?

Nate: Yeah, absolutely. I started managing one team. It was a digital asset management product, so it was a way to help marketers centralize and make sense of all of the photography that they created or purchased and how that photography or those digital assets actually made their way into marketing campaigns. Knocked that out of the park and then started getting more and more responsibilities. So I started taking over the social media products, started taking over the planning products. Eventually, I was able to hire out a product management team and get promoted from product manager to senior product manager to group product manager and, finally, director of product, where I was responsible for all of Percolate's web and mobile applications.

Suzanne: You said that Percolate was a little smaller. Microsoft, I guess, is kind of big.

Nate: Kind of big.

Suzanne: How big is Percolate, or how big was it at the time that you were there?

Nate: When I joined, Percolate was around 150 people, and when I left, it was around 300. So I joined when they were a Series B, and the time I was there, they also raised their Series C. It basically doubled while I was there.

Suzanne: Were you the only product manager when you came in, or there were already other product managers?

Nate: There was one other product manager. Actually, back to your original question, that was an engineer by trade, someone who started from the engineering team and joined the product team. By the time I left, we had around 15 product managers. On my team, there were six product managers, not including myself.

Suzanne: What I'm feeling into and wanting to ask about here is what are the triggers? You join this company. It's you and one other product manager. At what point is it determined we need another product manager and then four more after that? Can you help us understand what's happening operationally that would warrant this growth of the product team specifically?

Nate: Yeah, absolutely. The places where I usually look to bring on another product manager, or the times, are when you start making really bad decisions. You know there's some problem. Marketers want to centralize and make sense of their digital assets, but the way that you come up with the solution, it starts getting really hand-wavy. You start losing the rigor. You're not able to write decent user stories that specifically say what specific problem are we solving for this particular user and why do we think that's interesting. That stuff starts to fall by the wayside. At a startup, you can tolerate quite a bit of that. It's okay to be hand-wavy when you need to be. You have to be able to cut corners, but eventually you start building products that aren't successful, and that's really when you need to start bringing in more brain power on the product management side.

Suzanne: I guess what it calls into question is this classic question of, how should a product manager be spending their time? Certainly, we recognize that it's cyclical. If you're in the midst of a launch, then the activities and the nature of the activities are going to be different. If you think about being a product manager who is, I'll say, balanced, meaning you're not overextended. You have the appropriate number of folks on the team, either in supporting roles or in the form of other product managers. What do you think a cross-section of the average day or week should look like in terms of I should spend this much time writing stories, I should spend this much time doing XYZ?

Nate: That's a great question, and it's something I spend a lot of time thinking about at Cockroach Labs when I'm trying to right-size our product management team. I think a well-balanced product manager is spending their time doing four activities. The first would be roadmapping, of course, figuring out what to build and when to build it. The second would be working with engineers and designers to actually get something built and participating in all those stand-ups and the meetings to iron out some of those smaller decisions. The third thing would be something that also gets lost in the shuffle, is taking the product to market. Assuming you're in a B2B company, how do you work with marketing, how do you work with sales to enable them or help them tell the story and make sure you get credit for what you built in the market. The last is actually looking at numbers and getting feedback from the market to figure out if the things you're building, if the way you're taking it to market is working well. Those are the four things that I really look for product managers to do. If they're failing at one of those, there may be a bandwidth problem or a development opportunity.

Suzanne: I know for a lot of us, sometimes there's that question of, am I doing this right? everyone does operate a little bit differently. Launching a product, it's good busywork. Once you've launched a product, at least it's been my experience, there's a moment sometimes of, what should I be doing right now? You have to kind of reground yourself a little bit. So this notion of having these core pillars of focus, I think, can be helpful for people to say, "Oh yeah, okay, so the product is out. Let's look at some analytics. Let's think about what's next. Let's think about how we're going to collect inputs to determine what's next."

Nate: Exactly. One of my favorite post-launch activities is what happens when you ship a feature and no one uses it? A lot of things can be wrong. So you go into this debugging mode, right? Did we misunderstand the problem? If so, why are we just now finding about it? Did we not help marketing position it correctly? Was sales not incentivized to talk about it? There's lots of things that can go wrong, and it's a really fun exercise to go fix it and make it right.

Suzanne: Of course, to not do that would suggest that the thing that we planned was always the right thing, which is almost never the case.

Nate: Exactly.

Suzanne: We'd like to think that it's always the case, but it's almost never the case. How quickly do you typically seek to iterate ... So let's use this example. You've just rolled out a new feature. You thought you did the right research. You thought you got the reasonable evidence. You implemented it a certain way. Is it a week? Is it a month? What's that right timeline to start to question whether or not it's performing as hoped?

Nate: Let me use Percolate as an example, because we shipped a lot faster at that company. For a database, it's a mission-critical system. We ship once every six months. When I was managing product at an enterprise SaaS company, this is something we're doing on a daily basis. We had a lot of features in various stages of development, and those are lots of opportunities for us to test and learn and see what's working. On one hand, you just have product managers just pitching an idea to a customer, to a group of customers, and seeing how that's resonating. Is it something they're excited about, or is it something where we're missing the mark? Then we have low-fidelity designs. Then we have high-fidelity designs. We can do prototypes. One of the process changes we made or infrastructure changes we made at Percolate was introducing the idea of gating features. We could ship a feature into production, but only make it available for certain types of users. We could get feedback on specific user stories with real customer data and iterate on those. As we started more checks and more ways to get feedback, it made it a lot easier and a lot faster to make changes.

Suzanne: When you talk about doing low-fidelity wires, high-fidelity prototypes, were you inviting customers to give feedback? Did you have those types of relationships with customers to say, "Hey, let me show you this sketch that we're working on. Is that exciting to you?"

Nate: Yeah, definitely. One of the big differences between a B2C and B2B product management is for a B2B company, if you're doing really well, you may only have 500 customers that you're working with, so it's not that hard for a product manager to build a relationship with a named customer or a particular user in one of those accounts. For the biggest features, especially if we're doing something that hasn't been done before, we would create what were called design partnerships. We would get three to five customers and have them commit to going through this journey with us, to being a touchpoint that we could constantly go back to and say, okay, here's the changes we made based off the information we have. Is this tracking towards something that would be a solution to the problem that we all agreed is big for your team? Building those relationships and having those design partnerships is one of the things that we did that helped us increase the chance that our upcoming releases were actually successful when they landed.

Suzanne: I like that you bring up the distinction between B2B and B2C, because I think sometimes when we're talking about product, it's easy to think we're only talking about consumer products. It's easy to think we're only talking about software products. Of course, we're not. In building for businesses, and certainly working within enterprise organizations, as I've seen, the functions of product get sliced up a little bit more specifically. So you might have a dedicated product manager, but you would also have a product marketing manager. In a smaller organization, a product marketing manager just usually means a product manager who knows the marketing side of the business, but in enterprise, they're actually two separate functions.

Nate: Exactly.

Suzanne: So when you spoke earlier about the four pillars, you spoke about the activities around launch. Say I'm a product manager in an organization that doesn't have a dedicated product marketing team. What is it that I need to know about launching products, aside from just shipping them feature complete?

Nate: The main thing to keep in mind is how customers become aware of your product. How can you essentially build the brand of your product in their mind? There's a great book called How Brands Grow, and it talks about mental and physical availability. On mental availability, it's what are the activities that you can do to make people think about your product more often and in more situations? For your audience, maybe they learn about your product through blogs. Maybe they learn about your product through huge, out-of-home advertisements. As a product manager at a startup or a medium-sized company, you have to understand what are all those different ways that someone can become aware of your product, and what's the best way to spend your time in terms of reaching people through those different channels? The other thing that's really important, especially if you're at a very small company, is understanding the best channels to use to reach your audience. If it's just a SaaS company, you have your channel. It's your website. For other types of products, you may be going direct. You may be going through a partner. There may be another way you reach your market. Understanding, through those channels, what are the ways the different incentives align so you can make sure those actually pull on the other end of that channel?

Those are the two things that I like to think about, making sure that there's mental availability and making sure that there's physical availability. For most modern startups, it's really about the mental side.

Suzanne: Cockroach Labs. We're here. What's Cockroach Labs?

Nate: Cockroach Labs is a company that builds a distributed SQL database called CockroachDB. It's interesting because it makes it really easy to build web services in the cloud. The big shift that's happened in the last 10 years is that, initially, relational databases worked by putting all your data on one really expensive machine. If you wanted to get twice the power, you'd have to take that machine down and buy an even bigger machine, and that gets really expensive in a hurry. What we do is take some of the best practices and patterns that came from microservices development, where rather than having this one big monolithic thing, we're going to take your database and split it up into many different parts while still providing the same guarantees of your traditional SQL database. That's interesting now, because you can say, "Okay, I have my data. It lives on premises. Now I want to slowly move it to the cloud." You can do that without having to bring things down, spin them back up. You can take advantage of all the power of the cloud now. If you need more capacity, you simply add more commodity machines, and we just scale naturally that way. So it's a really compelling and exciting use case for anyone working with relational data in the cloud.

Suzanne: Who is the customer, typically? Is it chief technology officers, people within companies that are making the decision about the database?

Nate: Yeah, that's a great question. We have two types of customers. We look at it from a top-down perspective, where you have a chief technology officer. They see that their company is doing some sort of cloud transformation, and they need a database that will help them make that transition. That's one approach, but we're an open source company. Anyone can download our product and use it for free, no strings attached. The more interesting customer is the bottoms-up developer, the developer who's working in a large company. They have some seemingly intractable problem. They go on Hacker News, they Google a little bit, and they find CockroachDB and start to deploy it to solve their problems in their company. What we find is that you can take a large company and have 10, 15, 20 different projects running CockroachDB. Then, eventually, it'll get on the CIO or CTO's desk, and then they'll think about adding a support contract or buying some of our enterprise features. So we're really excited about that bottoms-up developer adoption.

Suzanne: How old is the company?

Nate: The company was started in 2015, so about three years old.

Suzanne: So we're right here in the moment?

Nate: Exactly. We just shipped the 1.0 release of our product in May of 2017.

Suzanne: Wow, exciting. Tell us a little bit about your team structure here. You're the head of product. How many product managers do you have?

Nate: I have four product managers on my team, and each one of them is responsible for a product area. The way Cockroach Labs works is I built the PM team in layers. One layer is core and SQL, so that's the internals of the database. This is like what the database can actually do at a really low level and the types of guarantees that it provides. The next level is what we call ops and tools. This product manager is responsible for taking the database and figuring out what are the different ways that this can actually plug into the rest of your IT environment. Maybe you care about hooking it up to a data warehouse. Maybe you care about automating it. These are all different APIs and different types of services that that product manager is responsible for. The next level up is our web UI product manager. That's a really interesting role, because there are lots of database UI tools, but those are all designed for those monolithic databases, those databases that live on one giant machine. As soon as you start thinking about splitting your database up to a cluster that could span the entire world, there are new types of interesting questions that you need to be able to answer. So you need new types of visualizations to help answer them. That's what that product manager is responsible for. Then, lastly, we have a channel and hosting product manager, which is responsible for figuring out what is the best way that we can take CockroachDB and help customers deploy it in the way that they want. One obvious answer is to just download the binary from our website. On the other end of the spectrum, it's providing CockroachDB as a hosted database as a service.

Suzanne: Did you know and foresee that structure, or have you had to kind of structure it and then go, "No, wait a minute. This isn't working," and restructure and restructure?

Nate: Yeah, there were several reorgs that had to happen. We backed into this the hard way. We started off with just core and SQL, and we saw where we were getting friction when it came to adoption. People would say, "Oh yeah, this sounds great. Everything on your website looks good, but I can't actually operate this in production. Where is your support for our monitoring tools?" We're like, "Oh." Then, we started seeing that was a theme. Hey, people actually need this sort of tooling for a database. They need these APIs to help orchestrate this database. So we're like, okay, this needs first-class thinking. We need a roadmap around this problem. Then, we saw that a lot of people wanted to experience CockroachDB as a database as a service. Just saying that lets you know there's another product team that needs to evaluate it. One of the big questions there is, what's the right time to do it? So the channel and hosted team has a very small engineering team right now, because we don't want to build too much before we, again, can go back and really understand and frame that problem and figure out when is the right time to deliver CockroachDB in that form factor.

Suzanne: What about dependencies? When you have the team ... Doesn't really matter how much you carve up the team, or the product rather, and then assign teams around it. Inevitably, there's going to be these kind of convergent points. It's like coding, right? It's like, is that in my bailiwick? That's in your bailiwick. How do your product managers kind of handle those conflicts of ownership and dependencies in planning? Is it just let's get everyone in a room together? Is it not as harmonious as that? Tell us about those challenges.

Nate: Yeah, that's a challenge that's come up in every company that I've ever worked at. There are a couple patterns for alleviating this problem. I don't think there's a full solution for it. The way that I like to do it is create, essentially, platform teams and let product managers know if they're working on, essentially, a platform, and I'll explain what that means. You have applications, right? So things that solve particular problems for particular users, but every once in a while, they'll need some sort of shared service. A great example of that is, hey, we have an auditing solution, and each one of these applications needs to be able to create an audit record in a particular form so that a company can be compliant with some who-knows-what regulation. Now, that's a cross-team product. Just left to their own devices, everyone would have their own file formats. People would release it at different cadences, and you would never actually get to that full, across-the-board auditing solution.

So, what you can do is say, "Okay, you are the product manager for this platform that provides the ability of logging what's going on in the system, and you are responsible for saying, what is this top-level user story that we're trying to accomplish? You need to work with each one of the product managers, pitch the idea of logging, why it's important, get it into their roadmap. Again, so they can make trade-offs of adding logging versus whatever else is there, and then letting that work itself out." If it doesn't work itself out, that's when you have to escalate it to a group product manager or a director of product management, because you can end up where a team is basically getting to a local optimum for the customer as opposed to a global optimum when you look across the entire product team. That's one way that I saw that. So application product managers versus platform product managers. Another example of this is when you have workflows that aren't platform workflows but just threads that go across multiple product areas. Going back to the idea of digital asset management, one workflow is I want to upload an image and post it to Twitter. That goes through the upload flow. It goes through the asset selection flow. It goes through the social flow and the analytics flow. That would touch many different PMs.

This is when you would create, essentially, virtual team or these teams that cross product areas. They wouldn't be formal teams, but they would have a formal product manager that's responsible for that workflow, formal engineer that's responsible for that workflow, and they would shepherd that thread along.

Suzanne: Right. So we're releasing a new workflow, and somebody is going to be responsible for architecting the user experience of that. In this virtual team scenario ... I'm always fishing for the conflict. I'm fishing for the conflict now. I'm the appointed product manager of this kind of covert ops team that's going to implement this great workflow. Does that product manager who typically owns one section of that product, whose product is going to be interfered with, like that?

Nate: The great thing about doing it the virtual team way is that the output of this virtual team is going to be a bunch of, essentially, feature requests that need to be prioritized like everything else. So the onus is on the product manager in that virtual team to make the case for why this workflow or why this thread is so important. If they do a good job there, there's not a problem. Each PM will want to say, "Hey, yeah, I want assets to work better in that workflow. Yes, I will bump up that priority." If they're not making the case, two things could be true. Maybe it's just not a valuable workflow. If people aren't excited about it, maybe there's something fundamentally wrong there. We want to know about that conflict. If you're fishing for conflict, one place where people can get stuck is if they have customer commitment. It's like, hey, we agree that it's important, but we have these five customers that we promised these five features to, so we just don't have the bandwidth to do it. That's when you need to escalate and figure out how can we make it happen, again, if it makes sense.

Suzanne: Who sets the roadmap here? Is that your function, as head of product, or do you empower your individual product managers to plan out? Then, if that's the case, how do you integrate that?

Nate: I try to stay away from roadmap setting. I will work with the CEO to set some high-level themes for the company, but in terms of saying what we build and when we build that, I defer that to the product managers and the engineers. The reason I do that is because they're closest to the problem. They're closest to the customer. As a product manager, when you start getting promoted, in many cases, you do move further and further away from those specific customer pain points. You don't want the person with the least information to be making the decisions that impact the actual end users. I definitely empower the product managers to come up with their own roadmaps. It's also the only way that it scales. As you have a team of 3 people to 5 people to 10 people, you can't have one person setting the roadmap. One thing that we do do is we bring everyone together for roadmap reviews. We do this because we want to make sure that the company-wide roadmap, or the cross-product roadmap, makes sense. There may be themes, there may be threads that aren't really being addressed when you leave it to individual product managers, so those types of meetings and those types of reviews are great ways to nudge the teams in the right direction.

Suzanne: How often are you doing those kind of alignment meetings for the roadmap?

Nate: We typically do these on a quarterly basis. At Cockroach Labs, we ship a generally available release every six months. We'll do a big review, roughly on a six-month cadence, but even then, we have quarterly check-ins on the roadmap, and then we do monthly business reviews, which are just seeing for the things that we're shipping, for the things that we have in alpha, how is it performing and what tweaks do we need to make?

Suzanne: Would you share, for context, an example? I love themes for roadmaps, because you can get lost in initiatives pretty quickly, but themes are succinct. They're easy ideas to get behind. An example of a theme that you've used here at Cockroach. It doesn't have to be a current one.

Nate: Yeah, sure. A great theme right now for us is performance. This is something that I definitely underestimated when working at a database company, because I was under the impression that, hey, if we built something that's solving this huge problem, people are willing to give up a little bit of that performance. It turns out, they weren't willing to give up as much as anyone had considered. Creating performance as a theme has meant that we've had to take huge chunks of the roadmap and ear mark it for the research and development required to make a database fast. Another type of theme would be IT automation. CockroachDB solves and automates a lot of the types of problems that developers have when running these massive, globally distributed databases, but it can still be better. From the feedback we get from our users, they want it to work better in these orchestrated environments. They want it to work better when run on AWS and GCP. We're seeing that that is a point of friction. So we're always looking for ways to figure out what are the big reasons that people do adopt and don't adopt, and how can we bake those reasons into one theme? Just making sure we're making incremental progress on each one of those.

Suzanne: Your product is inherently technical, right?

Nate: Yes.

Suzanne: It's as technology solution, and you're a developer, as we've discussed, so that's easy, right? You know databases. Do your product managers all have to have a tremendous amount of technical capacity in order to be able to work here? Even the team structure you outlined sounds technical.

Nate: Interestingly enough, none of the product managers on my team are engineers by trade. None of them come from traditionally technical backgrounds. That's a strategy and a technique that I've employed all throughout my career as a manager. The reason that I don't think you need to be technical, even if you're working on something like this, is because problems are problems. People are smart. They can understand what someone wants to do and why they can't do it. We have the benefit of having great engineers and great engineering management that can partner with product managers to help them rationalize the technical side of things. So we get to a really nice partnership where product managers can understand big things that are happening. Hey, there's this move to containerization, and this is what it can mean for a distributed database. Then, they can work with the engineering team to actually see how that breaks up into a series of projects and, again, go through the product management process. Now we have these solutions. How do we prioritize them? How do we work with engineers to get them built? How do we take them to market, get those design partners, help marketing understand why we build and why it's interesting, and then, again, looking at the analytics to make it better. I don't see any issue with product managers not being technical. I know it's a maybe contrarian point of view.

Suzanne: Yeah, well, people listening in are going to start hitting you up, and they're like, "Nate, I heard you on 100 PM, and I'm a nontechnical product manager. Hire me." I do see, actually, the merit in what you propose. This goes back to the piece about interfacing with sales and marketing or even having to kind of take some of those activities up yourself as a product manager, depending. By virtue of needing to communicate with other people in languages you don't understand or about things that you don't understand, you have to figure out a way to understand it.

Nate: Exactly.

Suzanne: Sometimes that work then makes you, as a product manager, a very valuable stakeholder in being able to further take that information and communicate it down the road to somebody who's even less technical than you are, someone who doesn't even interface with engineers on a regular basis, which is such an important part. It's like the stakeholder alignment part of product management.

Nate: The role that I've hired from the most in my career is customer success, because A, they already understand the product. B, and more importantly, they understand the customer. Particularly in B2B companies, they're in a really great position, because they can see the product that has been sold to the customer versus the product that is actually delivered to the customer and where exactly those gaps are and how those gaps generate real customer frustration or real customer happiness. In bringing those types of people to the product management role, they come with a huge amount of empathy that's really difficult to teach.

Suzanne: These are the softer skills.

Nate: Exactly.

Suzanne: What else is important for a product manager to have? I mean, you've already said you don't think that being technical is a fundamental requirement. What is a fundamental requirement in this kind of softer side of PM?

Nate: On the softer side of things, the first, I'd say, is being a cheerleader. That is really important. As you start talking to customers, sometimes you'll see people that are really happy. Sometimes you'll run into people that hate your guts or don't like your product. Being able to take all that information in, not take it personally, but more importantly, smooth out those highs and the lows to make sure your team has a real view of the world but it's not overly negative or overly positive, that's a really important skill set. The other thing is building credibility. This is really interesting for someone who's in a technical product that doesn't have a technical background. You can do that by, again, sharing those customer insights, understanding, hey, I've talked to 50 customers, and while Gartner says this is the trend in the market, here's the real rend among telecom as it relates to cloud computing. Product managers that are able to paint a realistic but positive view of the world, they get more done. Product managers who are able to paint themselves as that credible leader, they get more done. I always like to talk about the idea, when working with engineers, of what they can do for you versus what they will do for you. For product managers that are negative and not credible, those two can be pretty far apart.

Obviously, they can build feature XYZ, but they just don't like you. They just don't believe it, and you're not going to get 100%. Product managers that are able to close that gap consistently outperform their peers.

Suzanne: Great. It's a perfect segue for a segment we like to do here called get the job, learn the job, love the job. If I am one of these people working in a PM-adjacent role, maybe developer, as was your past, but maybe customer success person, as you described, how do I get noticed by management? How do I sort of petition effectively for making the move into product?

Nate: I can provide some real-world examples there of how people from customer success have gotten on my radar and ultimately become product managers. The most important thing is visibility. You can do that a couple different ways. One great way is just presentation. If there's company all-hands and there are departmental updates, really lobbying to talk to the company and paint yourself as someone who is a leader and someone who communicates well. Another place that is overlooked, but I think this is a place where people really separate themselves, especially for customer success, is the quality of the feedback that you provide. Some customer success people will just say, "Hey, this customer wants feature A." Other customer success people will say, "Hey, this customer is experiencing this problem. Here's how it manifests. Here's what they were doing during their day. When it worked this way, this is how they felt." Really drilling into the problem and showing that, hey, you're not just looking for solutions. You have product sense. You understand problems. You understand how to communicate them. That's something that can differentiate you, as well.

Then, third is taking the initiative, reaching out to the product leader on your team, and asking for projects. There's more work to be done than there is people to do it. I'd be surprised if they didn't have a research project for to do. That's another way to show that you can operate at that level. You can show some of the skills it takes to be a great product manager.

Suzanne: I love that last one, in particular, because one objection I've raised, on this show in fact, around the taking initiative part is how much initiative can I take before people start to get annoyed with me. We have to remember that work environments are political. If there's a good culture, it should feel really collaborative and inviting, but it's not always that culture. I think some people listening in are in those roles, do want to make that move, do hear the advice that people offer, and then it's like, but how am I really going to make that desire known without stepping on someone's toes? Another product manager is going to be like, "Hey, you're in customer success. Stay in your lane." This idea of helping out, it's like showing up after class and being like, "Hey." I like that a lot, and you're absolutely right. There's always more work than the team can handle, so good practical advice. What about the hard stuff? Where have you seen product managers that you've led struggle in the role because it's harder than sometimes we make it sound?

Nate: That's a great question. The things that are hard for new product managers, and I mentioned this earlier, are working with engineers, so getting the most out of an engineering team by, again, motivating them being a credible leader and being a cheerleader and celebrating success. That is something that has a learning curve. The way you see when someone is struggling here is they'll go to an engineering team and they'll use questions like, "Hey, would it be possible to ..." It's like we shouldn't be talking about possibility when we're solving hard problems. It's like, how long will it take? Let's talk about cost and time frames, not possibilities. You've already limited yourself and what your team can do. That's a big pitfall that I see a lot. Another pitfall, and this is usually for the MBAs, is people who use too many ROI frameworks. It's like, okay, obviously the roadmap is we're going to see cost benefits, what's our net present value, and we're going to do what maximizes shareholder value. It's really fun to talk about, but in practice, it falls down. A, because it doesn't take into account strategy. It doesn't take into account opportunity cost. It doesn't take into account the human aspect of building software. It's a good crutch when you're getting started, but in practice, it falls down pretty quickly.

Suzanne: This is a little off book, but it made me think. You mentioned earlier about Cockroach ships a little less frequently because of the nature of what you all are doing, so more like in six-month increments. How does that impact the ability to adjust to changes in the market? When you're working in an environment where you're shipping regularly, if there's a change, you can clear out the roadmap and put something else in. It would seem to me like there's a lot more readjusting if you have to go left when you were traveling right.

Nate: Exactly. It's very, very hard to build a mission-critical relational database in an agile manner. What that means is the cost, for us, of making a wrong decision is much, much higher. What we do is we just lean in on the tools that we do have at our disposal. We lean in at having design partnerships. We have the ability to do alpha releases or unstable releases. What that means is rather than do the six-month release, we can put out something in two months. Maybe there's some bugs. Maybe there are even stability issues, but if we can make the case that this feature is exciting enough, we can get people to try that bleeding-edge code. We just need to make sure the people who are trying it, they're giving us the information we need to make any course corrections. It's a much, much harder role, and I don't think I'd be able to do it without seeing the tools that were at my disposal in a marketing SaaS company. Yeah, it's hard. There's no right answers. It's just learning as early as possible and as much as possible and making sure that, of course, you're not overbuilding. What's the problem we're solving? Let's solve that problem and nothing more and then learn from there and try to get it in the next release.

Suzanne: Yeah, well, the key reflection that you offer in that statement, which is so, so valuable and, again, core to the theme of this show, is that Agile ways of doing, validated learning, move fast and break things, while it can work, it also can not work for some organizations. Understanding the implications of what you're doing means maybe I do need to invest a little more heavily in upfront user research, whereas a different product team in a different organization can maybe go light on that user research, because hey, if we're wrong, we'll just change it and change it again based on what the analytics tell us.

Nate: Exactly.

Suzanne: Cool. All right, what do you love about product, Nate?

Nate: Oh, I love a lot of things. The thing that I love most about product is I get to take all the fun that I had in engineering without having to worry about writing test cases or being on Pager Duty. I get to build things without the tax of maintaining them technically. I also like mentoring new product managers, because I've made a lot of mistakes on my way to being head of product. It's really fun to take someone who hasn't been a product manager before, help them avoid the mistakes I've made, and help them get to where they're going faster than I did. Then, lastly, as head of product, I really like working with the CEO, Spencer Kimball, a great product leader. Working with him to set the theme and set the strategy for the company, that's always what I wanted to do when I got into product management, so it's great to finally be in a position to do that.

Suzanne: You mentioned before How Brands Grow. Are there any other recommended books, blogs, podcasts that you'd like to contribute to ... We have a growing list of resources are 100productmanagers.com/resources. Anything that's been really impactful for you personally?

Nate: Yeah. From a management perspective, Radical Candor. I'm sure that's already come up, but that is a great book around giving feedback in a way that challenges directly while also caring personally, and it's a great way to course correct. Then, also, not in terms of a specific book, but I find myself spending a lot of time on YouTube now watching conference talks. YouTube's been a great way for me to build a domain expertise. If there's some bleeding-edge technology, you can see all the talks from a conference specifically centered around that, watch it on 2X speed, and then you can become an expert in a short amount of time. So that's a great resource that I've been leaning on more in the last year than I have before.

Suzanne: Great. What about personal or professional philosophy, something that just tells us a little bit about how you like to move and operate through the world. I mean, it's clear from what you've shared, you're a great leader and one who believes in empowering your team, but who are you, as evidenced by a quote?

Nate: I think the quote that I always think about is "Give the people what they want." It's a very simple quote. It's a very obvious quote, but it's also the thing that falls by the wayside the fastest when you actually become a product manager and have a real backlog. Then, all the needs from the CEO, the engineers have their own roadmap. You have your own biases. It's really clear to start building stuff that you think customers want versus what they actually want. That's something that I have to remind myself to constantly, and it's been a great guiding quote for me.

Suzanne: Give the people what they want. I think you gave our people what they wanted. Nate Stewart, Cockroach Labs, thank you so much for being a part of our show.

Nate: Thank you.