Introduction

“The biggest difference between building a highly-technical enterprise infrastructure product and a more traditional SaaS product is that you’re not just designing for human users, you’re also taking into account machine users,” says Nate Stewart, Chief Product Officer of Cockroach Labs.

The company is the creator of CockroachDB, a cloud-native distributed SQL database that’s designed to build, scale and manage data-intensive applications. (As the founders put it, they named their startup after the resilient insect because it’s nearly impossible to take down — which is quite the tall order for Stewart to live up to as a product leader.)

Regardless of who you’re designing for, with the end of the year fast approaching, annual planning is likely top of mind — analyzing whether you hit your marks in the previous plan and what might guide your work for the following year. But the best-laid plans can easily stall when your strategy makes its way off the page and the rubber meets the road.

“In a market as large as ours, there are different possible strategies that can be successful. When we decided to focus our product strategy on mission-critical, transactional workloads that focus on keeping data close to users, other feasible strategies opened up for our competitors,” says Stewart. “You start to see customers whose feature requests you said no to go into the arms of your competitors — and that can be demoralizing if you don’t have conviction in your path and its long-term success.”

There’s a lot written about startup strategy and how you can use OKRs to go from strategy to execution. But there’s not a lot of literature out there about why some strategies fail in the real world.

As product folks start sharpening up their annual plans, Stewart unpacks his playbook for gaining conviction and creating a resilient strategy that’s still standing this time next year. In this exclusive interview, he shares the failure modes for product leaders to keep an eye out for (like focusing on customer quality over quantity), and how he’s sidestepped those mistakes in his role at Cockroach (including a new approach to design partners).

Let’s dive in.

FAILURE MODE #1: YOU’RE DODGING THE CONTROVERSIAL CALLS.

When a startup is just beginning to tread its path, it can seem like there are seemingly unlimited routes on the map to product/market fit. Cockroach faced a similar point of contention in the early days when deciding what to build. “Databases work in every industry and in many different use cases. As the first Head of Product, I had to put in place the processes for making decisions around what to build. What are the capabilities that we should say yes to, and what are the features that we should avoid?” he says.

Even in the beginning, you need some way of saying no and filtering out all of the requests and potential use cases for your product.

So Stewart began looking at the different ways of segmenting the database market, eyeing the edge cases where Cockroach might slot in most naturally. This led the team to a fork in the road, an early choice that would go on to be one of the defining decisions for the company.

“We could build a database that was an analytics system like Snowflake, that’s excellent at running large aggregations and doing computations across many rows of data. Or we could build a database that was very performant when it came to writing and reading transactional data,” says Stewart. “The most natural early decision point was: What types of queries do we want to make Cockroach most performant for?” he says.

It’s a question that many product leaders have faced in the early days: Where should you focus the ICP? “Ultimately, the big decision that we made was to focus on transactional use cases — because the thing that makes CockroachDB unique is the product’s resilience. If your analytics database goes down for two seconds, that’s okay. You just hit refresh and run the analytics again. But if the database that’s powering your payment processing goes down for two seconds, you can lose millions of dollars. Our secret sauce is keeping your data online, up and running, and close to users,” he says.

This drew the line in the sand that Stewart (and all other product leaders) are looking for as they begin to sketch out the product roadmap. “Getting alignment with the founders and the revenue team that we were going to be a transactional database helped us say no to a lot of things that would push us closer to competitors like Snowflake, and enabled us to say yes to things that would build upon our product’s strength over a long period of time,” he says.

But, as Stewart puts it, this was a controversial choice amongst the team and the retelling of this story smoothes over some of the sharper edges. “There were some real-world pressures that made it difficult to hold the line on this decision to become a transactional database. At the time we were pre-revenue and had some large customers saying, ‘We’ll give you your first $100,000 or $200,000 — but only if you build out these analytical capabilities. It’s incredibly hard to say no to a startup’s first potential revenue sources,” he says.

FAILURE MODE #2: YOU’RE NOT INTENTIONAL ABOUT YOUR DESIGN PARTNERSHIPS.

To shore up conviction in the choice to focus on transactional databases, Stewart formed close design partnerships with potential customers. But here, he notes a key difference when it comes to building enterprise infrastructure versus other kinds of SaaS tooling. “Enterprise infrastructure buyers tend to be more conservative — by definition, the infrastructure is what supports some core business process. If your infrastructure is unstable or goes down, your core business can go down,” he says.

All told, folks weren’t exactly lining up the door to be early testers. “It wasn’t as easy as I expected to get people to give feedback on the beta software — because there was such a huge engineering investment required for a new feature that wasn’t fully baked. It wasn’t really worth it to our customers to test at the beginning — they just wanted the product to work,” says Stewart.

And while most folks want the latest tech— the newest iPhone release, or the brand-new car model off the lot — with enterprise infrastructure, buyers tend to take the opposite approach. “When our customers were purchasing the software, they didn’t want the latest and greatest. They wanted it to be six months or even a year behind,” he says.

So an already long product feedback loop was stretched even further. “A lot of the feedback that we got from our customers was based on decisions that we made a year ago — which means that you’re driving through the rearview mirror,” says Stewart.

So the Cockroach team leaned heavily on dogfooding the product in the early days, even if it wasn’t quite so elegant. “There was a point where I insisted that all of the product analytics were done on the CockroachDB database. CockroachDB is not an analytical dashboard, but it was a way for us to see what the SQL interface was like and how easy it was to get data in and out of CockroachDB,” says Stewart. “Initially some of those dogfooding opportunities were a little contrived, and frankly quite painful, but it was necessary for us to test the edges of the product and paid huge dividends later on.”

But the transition from dogfooding with your internal users to putting your product out in the real world can be a sizable leap. That’s where design partners can help cushion the fall. But rather than approach design partnerships in a traditional way, Stewart tried a different approach. His advice to other product leaders facing similar headwinds is to bucket your design partners into different categories so that you can de-risk specific aspects of the business.

Strategic Design Partners: “With these folks, we really talked about where we thought the database market was going. What were some of the macro problems that people were experiencing and the pains that their organization was going through?”

Roadmap Design Partners: “These were people providing feedback on the actual roadmap and the capabilities that we want to add to the database. For example, it was clear over time that if people are installing a mission-critical database, they want it to plug into the rest of the organization and ideally send updates to other systems in real-time. So we talked about adding a real-time data streaming capability to the roadmap — there was a lot of excitement around that idea and these design partners helped us de-risk the capability and the engineering investment it would take to build.”

Feature design partners: “This is the most difficult design partnership, which is getting feedback on particular features and getting engineers to try to use them. These are the design partners who feel the most pain that your product can solve. For example, we had an early customer that was doing a significant amount of payment processing, and all of that processing was happening in a single data center. If that data center went down for any reason, whether there was an operator error or something out of their control like an earthquake or a power surge, their business would be completely offline. They had to get outside of a single region and build a more resilient system. They were willing to invest a couple of engineers to make sure that what Cockroach built would help them on that journey to a cloud-native architecture.”

MBA-style reports about market size are great. But when you start to see the conviction from your design partners, you get a picture not just academically of how big a market is — you start to feel it viscerally. It’s a little art and science.

FAILURE MODE #3: YOU’RE COMMITTING TOO EASILY TO PROSPECTIVE CUSTOMERS.

Particularly in the early days, when the product roadmap is a bit squishier and customers are fewer and far between, it can be tempting to commit to new features, in the name of signing a contract. But from the beginning, Cockroach has made it incredibly difficult to commit features to customers. “When new product managers and new sellers join our team, they’re often caught off guard by our unwillingness to commit to building something for a particular customer. It’s like getting a bill through Congress,” says Stewart.

This is quite rare in the early startup phase — when plans are amorphous, commits are much more common. “You can say, ‘Hey, we don’t have product/market fit yet. So if a customer will pay us revenue, we can commit to building features A, B and C.’ If you can get your first 500K customer through customer commits, that can materially change your run rate. But it also significantly changes your agility. The opportunity cost is huge,” he says.

Customer commits are tech debt for product teams. You limit your flexibility — and what’s more valuable to a startup than the ability to change course quickly?

He estimates that in his five years at Cockroach, they’ve made 5 or 6 customer commitments total. “That flexibility has been huge as we’ve navigated the changing database landscape,” says Stewart.

Here’s how the Cockroach team decides which customer commits make the cut:

“The first is that it has to be something that we were planning to build anyways, or is somehow better for the company than what we were otherwise planning to do. The customer commits are roadmap accelerators, not detractors.”

“We have to understand the solution from a technical point of view — do we have the engineering team and the key partners necessary to accept the commitment?”

“There has to be a massive reward at the other end. We have to know that if we build this feature, the prospect will become not just a customer, but someone who will deploy and grow their usage with CockroachDB immensely.”

Stewart also flags that if user requests are coming up over and over again, you’ve got to start digging deeper with the go-to-market motion.

The request for customer commits is an interesting indicator that you may not have product/market fit or you have a misaligned GTM.

“If the sales team is feeling like they have to stretch, this is a chance to look at the entire GTM function. Do they not know how to position the product? Or are they not seeing the types of customers in the pipeline that they expected?” he says. “You also have to dig into the sales incentives, which tend to be more short-term focused. What does this deal mean for someone’s quarter or someone’s year? They may be making a commitment that they don’t have to deal with the longer-term impacts. You have to be mindful of that, especially when you’re in the enterprise space with a larger sales team.”

FAILURE MODE #4: YOU’RE UNREALISTIC ABOUT WHAT YOU CAN EXECUTE.

One of the biggest tripwires that Stewart sees, particularly for resource-and-manpower-strapped startups, is that folks dream big when it comes to the strategy — without taking into account the true capabilities of the org. “You have a couple of options here: you can have an honest accounting of your team’s capabilities, given your strategy, and figure out how you can close the gap between the two. Or you can decide that this is the team you have, and figure out a strategy that this current team can execute,” he says.

There have been a few inflection points in Cockroach’s journey where Stewart has faced this exact predicament. “This was a challenge we experienced directly as we started moving into more of a SaaS product by delivering CockroachDB as a service, where our customers don’t run the database themselves — we run the database for them. There was a macro trend pushing more people to offload their operations to vendors, and it had become increasingly clear that we needed to offer CockroachDB as a service,” says Stewart.

So his next question is something he suggests that all product folks ask themselves repeatedly when crafting any sort of strategy:

What needs to be true for this strategy to be successful?

“The first thing that we realized is that our customers were having trouble hiring these database operators — but now we have to find a way to hire them. And these site reliability engineers aren’t going to just run one database, they’re going to run thousands of them. How do we find these SREs? How do we interview them? How do we integrate them into our culture and make them successful? If we decide to pursue this strategy, it’s a huge capability that we have to build out,” he says.

Stewart sketches out another example of how your strategy needs to leap off the page. “We’re in the business of handling mission-critical payment ledger data. If we’re asking people to trust us with that data, we need to build a substantial security skillset. So we have to hire security experts on the product and engineering side to help us pull that off. If you’re not very specific about outlining all the different contingencies with your chosen strategy, your strategy will fail,” he says.

FAILURE MODE #5: YOU’RE FALLING FOR THE MYTH THAT COMPETITION DOESN’T MATTER.

There’s an oft-repeated startup adage that competition doesn’t matter — just keep your head down, and don’t get too distracted by what folks around you are doing. Stewart has been caught up in this mantra but has since changed his tune. “I initially thought that competition didn’t matter. Just focus on the customers, work through first principles, and you’ll end up in a good place. But when it comes to landing an enterprise sale or going through a thorough evaluation process, it’s inevitable that competitors are involved. It’s useful to understand where your competitors are strong and where you’re strong, and how to talk about those differentiators in a way that favors you,” he says.

So when it comes to crafting company strategy, keep your competitors in your peripheral vision. “We have a class of competitors that have made fundamentally different strategic decisions than us. As an example, Amazon Aurora is a great database. Rather than make the entire database cloud-native, they’ve made just the lowest level cloud-native. For them, that’s a strategic choice because it means it’s a much simpler migration to take an existing database and run it on Amazon,” says Stewart.

“The thing that’s in our favor is that those databases aren’t all cloud-native, so you don’t get the same resilience characteristics. You can’t move your data anywhere in the world, and you can’t scale to the same level as you can with CockroachDB — that’s a fundamental trade-off,” he says. This key differentiator then arms the sales team with the messaging they need to position the product to win customers.

When you think about the strategic investments that you can make, invest in the core differentiators that set you apart from competitors.

FAILURE MODE #6: YOU’RE SKIPPING CROSS-FUNCTIONAL FEEDBACK.

As Stewart puts it, he leads his product teams like a product operating system: “Product Managers are taking external inputs from the market — what customers are saying and what competitors are doing. They’re also taking internal inputs, like feedback from the sales team and what pre-sales and post-sales folks are talking about. They’re distilling all of that information through the lens of a strategy and then figuring out the ways that we might change or enhance our product to move us closer to our mission,” he says.

The questions that arise at this stage include:

How deeply do we understand the problem?

How can we better frame the problem?

Risk-adjusted, is this a good investment for the company, given the engineering cost?

If we add something to the roadmap, something will have to fall off. Are we okay with the trade-off?

As these features start to come to fruition, how do we de-risk them?

But these decisions can’t happen in a vacuum — that’s where your cross-functional partners come in. Stewart recommends building out product councils to help integrate these insights from across the company. A product council is a monthly business review, where a PM for a particular product area will sit down with a cross-functional group of stakeholders to talk about how things are going. “It’s a course-correction and information-sharing mechanism that we have monthly in the context of this broader annual plan,” he says

Here’s Stewart’s step-by-step guide to conducting a product council:

1. Rather than creating a deck or providing a score card, write a six-page narrative around what’s working and what’s not working.

2. Bring 7-10 people from across the org into the meeting.

3. Set aside one hour for the meeting; begin the first 20 minutes by letting people individually read through the memo and add their comments.

4. The product manager then pulls out the main themes, questions and discussion points, which are debated for the remainder of the meeting.

Stewart warns against making this meeting an open invitation. “The more people you have in the room, the fewer people are willing to raise their hands and say something. Strike the balance where you have representation from pre-sales, post-sales, support, engineering, product management, design and marketing. But don’t open the floodgates.”

WRAPPING UP: FEEDBACK IS THE ANTIDOTE TO FAILURE MODES.

Like most startups, Cockroach has gone through a few different permutations during Stewart’s tenure — and he’s been riding those waves, too. “When I joined Cockroach it was an open-source company. Then we started commercializing — that’s a different business. Then we started moving into managed services — that’s a different business. Now, we’re in product-led growth mode,” he says.

Here’s his advice for other org leaders looking to stay afloat with similarly shifting tides: “If someone joins a new company and they report to the CEO as a functional expert, it’s unlikely that the CEO is going to be able to coach them on how to do well in that function — that’s why they’re hired to be the functional expert. You need to be able to take a hard look at where you’re succeeding and where you’re not on a fairly regular basis,” says Stewart.

Here are a few tactics he’s leaned on to do just that:

Create peer networks. “Connect with other people who are running product teams at akin stages. What are the challenges that they’re going through? What is their advice for navigating similar situations?”

Find your role. “If you have a visionary CEO and that person is looking for an operator product leader, don’t try to be the visionary product leader and fight with the CEO on the vision. What is your ‘better together’ story with the CEO? How can you help them achieve their vision, provide a sounding board, or hold up a mirror when something might be working? It’s important to understand what role you need to play to support the entire business.”

Tap investors. “One of the things that I did very early on was I had a conversation with some of our investors around failure modes they’ve seen for different Heads of Product at all sorts of companies. What are the things that I should be looking at now to get ahead of the skills that I need to build to be successful as Cockroach continues to grow?”

And his final piece of advice for startup folks up and down the org chart is to get very specific about asking for feedback. “I request very candid feedback from my peers about where I’m falling short, given their vantage point. People have different ways they prefer to give feedback. Some prefer a phone call, others want to take a moment and write down their thoughts, so I’ll share the meeting agenda ahead of time with the areas in which I’m looking for feedback. Understanding someone’s communication norms is helpful for getting actionable feedback,” says Stewart.

But regardless of the format, it’s what you do next that matters most: “If you ask for feedback and you get defensive, it’s very unlikely that you’re going to get the same level of feedback in the future,” he says.

What I’ve found is that it’s not necessarily the way you ask for feedback that matters. It’s how you show up when you receive that feedback that increases your chances of getting high-quality insights.

This article is a lightly-edited summary of Nate Stewart’s appearance on our podcast, “In Depth.” If you haven’t listened to our show yet, be sure to check it out here.