My First 90 Days as the First Product Hire

Last week was a big week for Cockroach Labs. We released our 1.0, announced our Series B, and fleshed out our team with several new hires…

Last week was a big week for Cockroach Labs. We released our 1.0, announced our Series B, and fleshed out our team with several new hires. Given the importance of these milestones, I’ve poked my head up to conduct a much needed personal post-mortem.

Looking back, one of the biggest challenges I faced was onboarding into a department that hadn’t existed before I joined. I also faced several personal barriers: (1) I had just left VC and had never worked in product before, (2) I did not have an engineering background, and distributed systems are complicated, and (3) there were already 20+ engineers in the organization, so I had to find a way to fit into their existing processes.

Step 1: Gather Information. Listen and Absorb.

I knew that it would take time for me to ramp up, so I fully committed to spending the first month focused on learning over executing. For the first couple weeks, I sat in on a bunch of meetings just to soak up information. Honestly, every engineering meeting sounded like it was conducted in a foreign language. I vividly remember not knowing what “GC” (garbage collection) meant. There were a bunch of other things I didn’t understand, but I can’t remember since they flew right over my head. We were also in “code yellow,” which meant that all the engineers were focused on improving the stability of the product.

However, “code yellow” turned out to be a blessing in disguise. While the engineers focused on stability, I spent time understanding the product and how it fit in the competitive market. This was something that I was quite familiar with given my time working in VC and in technology investment banking. I developed documentation on our competitors with a focus on our core differentiators and presented those findings to the rest of the team.

I also used the “code yellow” period to think about what questions to focus on next given the stage of the company. By the end of the first month, I came away with some key findings:

(1) Based on my knowledge level and the current status of the product, the engineers didn’t need me to get involved in their day-to-day processes

(2) We needed to better understand our target customers and figure out which pain points and value propositions resonated with them the most

(3) I personally needed more time to fully understand the product

Step 2: Clarify unknowns. Start executing by leveraging what you do know.

Despite blundering around in month 1, I did come away with an action plan. First, I knew that there was still much to learn. I didn’t understand the product well enough to have an opinion on priorities and development areas. I decided to spend more time understanding the product, including going to tech talks where I could hear how we were presenting our product to external organizations. Second, I knew that I could start executing on better understanding our customers, since that was something I was familiar with doing in VC. Investing in VC is all about understanding the pain points that start-ups are addressing and validating those pain points in the market, so I was comfortable with moving ahead with that task.

As a result, I spent month 2 at Cockroach Labs running user interviews with people within our network. I spread a wide net that covered different personas across various categories of seniority, industry, and company maturity. After conducting a number of interviews, I started to hear common trends that highlighted the value propositions and pain points that we most closely addressed. I also started to understand how our target customers made decisions, what messages resonated with them, and the barriers they faced in adopting our product.

Step 3: Execute on things that move the needle.

Moving into month 3, it was now time to leverage my findings from user interviews to move the needle. There were a lot of areas we could have focused on, but what made the most sense at the time was utilizing our findings through user research to revamp our messaging and define our product.

We realized that our messaging was too focused on the “what” versus the “why.” Potential users who hit our website had to dig in to understand how CockroachDB was different. This ended up driving a complete re-design of our website that took quite some time to accomplish.

We also wanted to better understand how we could differentiate in the market with our product. CockroachDB is meant to support mission critical applications, so we needed a really compelling use case to drive early adopters to use our product. Based on our user interviews, we had a sense for what pain points existed in the market. However, we also wanted to position ourselves in a way that clearly differentiated us in the market and highlighted the new use cases that we were enabling. We ended up testing our theses with potential customers by pitching our ideas and measuring their responses. This process, which also took more than a month, helped us define and validate a new product feature.

Lessons Learned:

• Don’t be afraid of digging too deep. Since I don’t have a technical background, I used that as an excuse to avoid digging in on really technical topics in my first month. I’ve since completely thrown that idea out the window and have decided that nothing is too technical for me to dig into. I believe that having a firm understanding of the foundation on which the product is built allows for more flexible decision making in the future.

• Be ready to course correct. I was often putting out fires on a daily basis. Some customer was always waiting for a response or needed a follow-up, some partnership needed attention, some copy needed to be reviewed… In the daily grind, it’s hard to step back and make sure everything is still moving in the right direction. It’s important to start projects with goals in mind and continuously make sure that projects still align with where the company is going. Don’t be afraid to drop a project if it is no longer relevant for the company. Giving up quickly is better than hanging on and dying a slow death.

• Remember to think about execution. One area that I should have spent more time on in my first month was understanding the barriers to execution internally. I’ve come to learn that with almost any project, creating alignment and facilitating communication across stakeholders is essential both to getting things done and to making sure the team stays engaged. Sometimes, I was so swamped with the things I was doing that I didn’t have the time to communicate as well as I should have with stakeholders, and the biggest consequence of neglecting that is reduced efficiency.

• Make sure to define your role formally. This lesson is in many ways related to the prior bullet. When I first started, I was singularly focused on ramping up and executing as quickly as possible. However, as the first product hire, it would have made sense to clearly define the things I was focusing on and the value I was going to try to bring to the organization. I did not do that, and it came back to bite me when it came to defining processes, assigning owners to projects, and ensuring company-wide alignment.

Ultimately, the learning process never ends.

Things move so quickly at a startup that it feels like every day is the first 90 days. The most important take-away is to make sure to set up a feedback loop when approaching anything new. Start with understanding and framing what needs to be done, explore the unknowns while executing on the things you do know in parallel, and execute while constantly taking temperature checks to make sure things are going in the right direction.

Perhaps most importantly, it’s all about the team! Make sure to build alignment early on and leverage the unique expertise of everyone on the team to generate better results. I continue to hone my process every day, and hopefully things will only get better going forward!