In 2020, I was given the opportunity to lead the Product team at Ouster. This post details the process and framework I used to define the core functions of the team and figure out where to start.

Ouster’s core business is the design and manufacture of high-resolution lidar sensors supporting a wide variety of robotics applications. As a result of the unique digital lidar architecture taken at Ouster, we’re able to develop lidar systems that are smaller, lighter, and less expensive without sacrificing on core performance. Ouster currently has 600 customers and recently launched it’s second generation lidar sensors. The product offering expanded beyond the original OS1 lidar sensor to include the OS0, optimized for short range performance, and the OS2, which supports applications regarding longer ranges.

Previously, I was responsible for Product Management of another project which uses the Ouster lidars as a core component of an after market safety system for commercial vehicles. While some of the technologies are similar, there are some unique challenges inherent in the after-market safety product that differ from those of the core lidar business.

While both after-market safety systems and lidar sensors have existed for decades, there continues to be a significant amount of product discovery to understand how lidar sensors can be uniquely leveraged to solve commercial vehicle safety systems. The markets are also very different and demand different solutions. Commercial fleet operators expect an end-to-end solution that is both reliable and easy to use. This differs from the lidar sensor clients who primarily intend to integrate the lidar sensor in the development of their own application. Lastly, the scale of the customer base between the after-market safety system and the lidar sensor pose different challenges for managing user feedback, customer support, and overall roadmap development.

As a result of the success and growth of the lidar sensor business, the need arose for a dedicated product function to support the continued development of the lidar sensors. As I started to tackle this challenge, I had two initial objectives:

1. Define the responsibilities of the Product team and ensure alignment with the Executive team
2. Figure out which problems to start addressing that would have the biggest impact and start building some trust and credibility

Stakeholder Interviews

I spent the first two weeks talking to as many stakeholders as I could. I tried to get at least 30 minutes of time, and ideally an hour, to go through some basic questions. This wasn’t a strategy brainstorming session and I avoided giving my opinion on any of the topics. This was mostly a user research style conversation to better understand the perspectives and motivations of the people that I would depend on for success. I talked to over 20 people across the Business Development, Marketing, Engineering, Customer Success, Reliability, and Operations Departments. I took inspiration from Keavy McMinn’s post, “Where to Start” and asked each person the following questions:

• Have you worked with product before? What was good or bad?
• What causes friction currently?
• What has been tried before & why that hadn’t worked?
• What do you expect product to be responsible for?
• What would a successful outcome for the product team would look like?
• What do you think will be the threats and obstacles to the product team’s success?
• What you would focus on, if you were doing my job?

Everyone has different experiences working with product teams and therefore has different expectations of what the product team should be working on. I wanted to understand what had worked for people in their previous interactions with Product teams and under what circumstances they interacted. Some people were straight from school and had never worked with product teams before. Some had worked at large companies with Product organizations of 30 people or more. Others had never worked with a Product team that they thought added value.

This conversation also helped me understand what people expected from the Product team. While most people’s opinions aligned with my own vision, there were some areas of responsibility and accountability that I didn’t think were appropriate given the resources of the product team. While it’s ultimately the Executive team’s call, it was good to identify potential areas of disagreement early so that I could go back and manage expectations once I had a clear mandate.

The “threats and obstacles to success” question was also insightful. I thought this was really helpful to identify the real-world complexities of operating in a high-pressure environment with other highly motivated individuals. The org chart doesn’t mirror reality. I started to get a better understanding of how information flowed in the system, who were the key influencers and decision makers, and what was the best way to structure an argument for certain people. The Product team doesn’t build the product, instead we rely on influencing others to execute a shared vision. Understanding how the organization functions at a human level helped me avoid potential landmines and leverage people’s specific motivations to get some of the first initiatives off the ground.

The last question, “what would you focus on first?” was a great way to get ideas on the areas where my team could have an immediate impact. The Product team was created based on an internal assessment that it was needed. Therefore, there were clearly some people passionate about some existing gaps and they were more than willing to pass those observations along. The biggest takeaway was to improve the communication and information flow between the Business, Engineering, and Operations functions. This is likely a common problem that results from a rapidly scaling team. Business Development wanted more stability in the roadmap so they could be more confident talking to customers. Engineering wanted to understand the business case for the features being developed and know why certain features were prioritized over others. Operations wanted more insight into planned changes so the Supply Chain and Manufacturing teams could be more proactive to design changes.

It was a bit time consuming to talk to everyone, but I think it was worth the investment. I started building relationships with people I hadn’t worked with directly before, got a better sense of how the organization was functioning and could be improved, and learned some tactics that had worked well for Product teams at other companies.

Defining the Role

The Product Management function manifests itself at different companies in different ways. The Product function also evolves as the company evolves. We needed to define the role so that we could manage expectations with the Executive team as well as other departments. The role definition also helped set expectations internally on the Product team and was useful in one on ones.

To start, myself and the other PM went online and found a bunch of Product Manager job descriptions for roles at similar companies. We looked for companies operating in the automotive space so we could capture requirements around Functional Safety and compliance. We looked at roles working IoT devices and edge computing platforms to get ideas about how to capture the unique aspects of building hardware devices with limited connectivity. Lastly, we looked at roles from large and successful companies, regardless of industry, to make sure we had all the basics covered.

We cut up the job descriptions and put each requirement on a post-it note. We also spent a few minutes coming up with our own ideas and putting them on individual post-it notes. On the wall, we created columns for the following categories:

• Responsible & Accountable for
• Coordinate on
• Informed about
• Unknown?

The core of the team’s responsibilities would be pulled from the “Responsible & Accountable” section. The items in the “Coordinate on” are areas where the Product team will collaborate with another department, but the other department has the lead on that specific task. In the “Informed about” section were items that the Product team didn’t need to be involved in directly, but would want to know more about what decisions were made and why since we could be potentially impacted by them. In the “Unknown?” section, we put items that might require a more in-depth conversation with the Executive team before making a determination.

The conversation we had as a Product team going through this exercise was also really helpful. We went through each post-it note one at a time and talked about which category it should get placed into. We got to talk about our own vision for the product team, what tasks we thought we should own given our limited resources and which ones we would let other teams lead, and identify areas where we had different perspectives.

We synthesized the post-its in the “Responsible & Accountable” section into the following core components:

• Product Vision, Strategy, and Roadmap
  • Define and deliver a compelling roadmap based on customer needs and strategic opportunities
• Product Discovery
  • Interact with users to understand their needs, core issues, and problems in order to proactively define and drive product objectives, requirements and constraints
• Competitive Analysis
  • Assess market trends and competitive threats and identify product requirements that enable sustained competitive advantage
• Product Ownership
  • Develop a good working knowledge of the product and be recognized as a credible product owner by engineering, reliability, and operations teams
• Product Execution
  • Work closely with engineering and operations to develop PRDs, prioritize requirements, and manage change requests for software and hardware features
• Measure Success
  • Own and report product KPIs and leading indicators to understand performance metrics and identify opportunities to better optimize the customer experience

We also identified a couple areas where our support would be critical, but we would defer to other departments to lead the efforts.

• GTM Strategy
  • BD/Marketing leads product messaging and positioning, pricing, product collateral, sales training efforts
• Support Documentation & User Training/Onboarding
  • CS/FAE/Marketing leads user onboarding and technical sales enablement. Product owns Spec Sheet and Manual
• Functional Safety Requirements
  • Reliability determines requirements while assisting Product and Engineering with prioritization decisions
• Enterprise Business Tools
  • Product informed about additions/modifications of BD/CS tooling (ERP, CRM, CMS, Support Desk)

This breakdown may be different than how the Product team functions at other companies and that’s okay. This was how we defined the role for our team and the specific circumstances at the time.

Putting it all Together

After the interviews and initial role definition, it was time to seek alignment with the company’s leadership. I compiled the ideas into a deck and presented it to the team. A subset of the slides is shown below.

The deck was divided into two sections, “What is Product?” and “Where do we Start?”

For the first section, I wanted to define Product at a high level and then define the specific responsibilities of the Product team at Ouster.

I started with this quote from Marty Cagan’s book, Inspired, that resonated with me.

Combine technology and design to solve real customer problems in a way that meets the needs of the business.

I think this captures the mission of a product team accurately and succinctly. It clearly indicates that the focus is on solving customer problems, not building features that are dictated by the customers or even internal stakeholders. These problems aren’t solved by the Product team alone, but require constant collaboration with our design and engineering colleagues throughout the product discovery process. Lastly, we must prioritize the problems we address and focus on the few that will have the largest impact to the business.

Next, I pulled up the Product Management principles from “The First Principles of Product Management” by Brandon Chu.

The first principle is similar to the original quote by Marty Cagan.

The second one is also important to recognize.

Sometimes organizations don’t see the value of Product teams because they don’t directly build the product. Many organizations can survive without a product function, and even Ouster had been successful for years without a dedicated product function. So how does the Product team add value? By making sure the organization is focused on solving the right problems and driving the organization to solve those problems through collaborative efforts. This reminds me of the military term, “force multiplier” which means “a factor that gives personnel or weapons (or other hardware) the ability to accomplish greater feats than without it.”

After reviewing the high level concepts, we presented the tasks that the Product team would be responsible for.

This was then followed up by the list of items the Product team would support, but not lead.

We went though each item one by one and discussed the more in detail.

Once we had alignment on the role, we transitioned to the next section, “Where do we Start?”

First, we presented a basic framework for identifying product opportunities.

This framework was helpful for providing structure on the initial focus areas the Product team would tackle.

There are a confluence of areas that the Product team needs to understand in order to properly identify product opportunities and properly prioritize them with the other requirements necessary for building a successful product.

Lastly, we summarized with a list of initial focus areas. This list was based on the feedback from the stakeholder interviews, the things we felt we needed to do as a Product team to develop a solid understanding of the product and market, as well as areas we could target to have some quick wins and build credibility with our peers.

I also found Nikhyl Singhal’s post, “How to Craft Your Product Team at Every Stage, From Pre-Product/Market Fit to Hypergrowth” helpful in determining where the Product team’s efforts should be focused based on the maturity of the company.

While our company has initial product traction, the product function is new. Nikhyl talks about young product teams initially focusing on a tactical level (building schedules, running standups, publishing product requirements and coordinating releases) to understand how the organization functions before starting to operate at a strategic level and prioritize work.

Another thing I wanted to focus on was the development and iteration of core product processes. The company grew rapidly both in numbers and locations. We not only had more Business Development team members, but they were spread across Europe and Asia. I wanted to introduce the right amount of process focused on:

• Receiving customer feedback from sales, customer service, and field application engineering
• Prioritizing product requirements into releases and roadmaps
• Communicating status updates and key feature timelines to various stakeholders

All of these considerations consolidated into the list of initial focus areas.

Finally, we reviewed a list of specific tasks to get done in the next 30 days.

After some minor adjustments based on the feedback, we now had a document that could be used to set expectations with the various team.

Hopefully this overview of the process and framework I used to integrate a young product team in a scaling startup is helpful to others in a similar situation. Good luck!