Justin Selig

Interview with The Startup Conversation

See the link below for my recent interview with The Startup Conversation.

Employee Spotlight #9 - Justin Selig, Product Manager at Cerebras

Content:

Justin Selig is a Lead Product Manager at Cerebras. He helped launch the Cerebras SDK, a software platform for developing AI and HPC applications on Cerebras systems. His background spans embedded systems, firmware, AI, and full-stack software development. Previously, Selig held engineering roles at SpaceX, Uber ATG, and several small-to-midsize startups. He received his Bachelors and Masters in Electrical and Computer Engineering from Cornell University. He currently resides in the San Francisco Bay Area.

Frederick Daso: What was your journey to becoming a product manager (PM) at Cerebras Systems? What were the prior positions you had that set you up for success in your current role?

Justin Selig: The short answer: The right people made a bet on me.

While I always wanted to go into Product, it was unclear how or when I’d get there. After being hired as an engineer at Cerebras Systems and before starting work in 2017, I committed to Andrew (Cerebras’ CEO) to do “whatever it takes to create the most value.” Still, I explained that I eventually wanted to go into Product. I worked hard to deliver that value and, as a result, took on increasingly challenging projects that cut across our engineering organization.

As a key member of our kernel team, I was responsible for creating the foundational software behind the deep learning applications that drive our core business. In time, I gained the track record and skills to stand out as a technical leader. That experience was important since it laid the groundwork for the product I’d eventually build as a PM.

In 2019, I went to our Product team with a 50-slide deck outlining a vision to create an SDK for external developers. It was a product that needed to exist but required buy-in from Product and engineering leadership. In retrospect, it was foolish to think that deck would lead anywhere. The project would’ve been a massive undertaking, and there was no one to lead the effort. But that meeting planted the seed for my relationship with the Product team. It showed that I had the motivation, technical insight, and product sense to build something of potential value. The team lobbied around me, and one of their star PMs, Jessica, took me under her wing. We refined that initial vision and worked tirelessly to get the SDK off the ground. We built a team from scratch and rallied leadership for support until the company was ready to take the plunge.

Suffice it to say; the Cerebras SDK has become a huge team effort. Like every PM, my success is judged based on the success of the products I work on. And the main drivers of that success are the talented employees of Cerebras.

Daso: There’s a lot of conventional career advice about being a successful PM, but are there any unorthodox lessons that you’ve learned through experience or mentorship that more of your fellow PMs should know?

Selig: To be frank, it’s hard to give valuable advice to a typical PM in the abstract. So much of the work is contextual. It’s like asking, “are there any lessons more students should know?” What are those students majoring in? What grade level?

So, perhaps that’s one lesson I’ve learned. There’s no cookie-cutter PM. There are as many types of PMs as there are product categories. Company size and stage, customer type, teams partnered with - they all matter. You could say I’m an (1) early-stage (2) B2B, (3) mostly technical, (4) software platform PM. But even those categories change as my product and company evolve.

I will say, though, that one of the most startling things I experienced in my transition from an engineer to PM was what it felt like to be on the left half of the learning curve. So many things had to be unlearned, so many things learned. It was surprising since I had done product-type roles in the past. But my mind has a way of grasping and acclimating to an identity (i.e. “engineer”) such that divorcing myself from that identity and the daily rituals and behaviors associated with that identity was materially difficult. It swept me off my feet and challenged who I fundamentally was. In retrospect, that was rapid growth.

I realize I didn’t answer your question, so here’s some stuff I’ll throw out there that could serve PMs of various flavors. A word of caution that these are still aspirational for me and represent mostly my observations. Whether or not this advice makes someone “successful” will greatly depend on the dynamics of their organization:

  1. Generators. Great PMs seem to generate copious amounts of productive work for themselves - new ideas, new projects, new processes, etc. Appearing “busy” is a side effect of having excess responsibilities created for oneself, not because one passively attends standups with little to contribute.
  2. Weaponizing self-awareness. Real insight comes from unmasking unstated assumptions, biases, or weaknesses that one recognizes in oneself and others. It helps to ask oneself, “What outcomes am I afraid of? Why would they happen?” These are great generator questions, the answers to which can be harnessed for product insight.
  3. Broken records of the obvious. Verbal and written. Good PMs initiate communication, even when they don’t feel like it. The target market or customers for a product are often top of mind for a PM, but there are often team members who don’t have that direct connection to the market or customers, or who might have forgotten.
  4. Aligners. Start broad, then align on specifics. Good PMs try getting directional alignment from everyone on their team and adjacent teams. It’s a terrible feeling when someone on a team not included in a decision says they don’t feel heard. Include even those who don’t express the desire to be involved in planning.
  5. Treat engineering like a partner, not a service. One insecurity I had when starting was that I felt like I should be responsible for crafting the vision of every part of the product. This was reinforced by Engineering asking, “What are the requirements?” with varying expectations on granularity. I always felt like I needed an answer. The reality is, for complex engineering projects in resource-constrained teams, the boundary between Product’s requirements and Engineering’s solution is blurred at a sufficient level of detail. It’s impossible for a PM with many responsibilities to define every component. Good PMs challenge their teams to take ownership in helping craft the product vision. Good PMs derive satisfaction from seeing their teams think uncomfortably deeply to answer product questions.
  6. Relationship builders. It helps when the people I work with feel comfortable telling me things they would otherwise keep to themselves. To do this, I need to build trust. I see some of the best PMs take most of their meetings 1-on-1, even if a larger format could’ve saved them time. It’s just easier to get to know someone. For a good PM, the product is not just the thing they build but the team they build.

Daso: What’s the toughest project (professionally or personally) that you worked on as a PM or in general? What were the most important lessons you learned from that project?

Selig: There are some obvious answers to this, especially if we’re talking about engineering challenges. I’ve been on wildly ambitious projects over the past few years: from writing mission-critical firmware for rocket engines and self-driving cars to building some of the first software to run on a wafer-scale chip. When something comes so close to working, then fails, then I stare at my screen until 3 A.M. wondering if I’ll ever fix it. That’s pretty tough technically.

As a PM, kickstarting the Cerebras SDK was a massive undertaking and proved challenging in many ways. At the outset, we were given three months to demonstrate value for the business; otherwise, the project would’ve been sunset. How do we build a team, create a minimum viable product, find potential customers, and onboard users in a compressed time frame? It was a scramble, but we did it. It helped to have a scrappy team who supported each other.

Nowadays, with a larger team, I might help define the technical components of the product, but technical implementation isn’t (and shouldn’t) be within my realm of control. My greatest levers are influencing priorities and the allocation of resources. Most often, the toughest challenges are dealing with my own psychology. It’s a boring answer. The reality is that most technical problems are soluble, given the time and resources. But that’s the thing: given the time and resources. How do we prevent churn with users and deliver features given limited engineering bandwidth and a tight schedule? These are the things I think about every day. It’s almost always a matter of de-scoping or re-scoping at every point in time.

Daso: Who are some of the most inspirational people you’ve gotten to work with during your career in tech?

Selig: To avoid the risk of leaving people out, I’ll limit myself to the folks at Cerebras with whom I’ve worked most closely. It takes a village, and many people in the past shaped my career. In no particular order:

Daso: How would you define your company’s culture, and how does it create an environment where you can do your best work?

Selig: Stealing a line from my CEO: We’re a “no BS” company. If you do prodigious, quality work, others will see it, and you will be recognized. When you don’t have to worry about being seen or playing politics to be placed on the best projects, you open up the marketplace of ideas and maximize the probability that the best one wins.

Daso: What’s one interesting thing (non-work related) that more people should know about you?

Selig: I love writing. Although, it’s not evident given the small volume of content I put out publicly. 99% of what I write, I write for myself. You could say it’s an act of catharsis.

Recently, I’ve been learning about cognitive and behavioral psychology - talking to researchers, experts, enthusiasts, or anyone who can help answer my strange questions. Something I’m thinking about now: why does consistent meditation practice lead to a decrease in episodic memory? Sometimes, I’ll write long-form explanatory blog posts if inspiration hits at justinselig.com.

Daso: What’s something you want to accomplish in your career that you haven’t yet? What motivates you to get there?

Selig: I love teaching, especially university students. If the opportunity ever presents itself, I’d surely take it.

· interview