Elevate the Individual Contributor | Claire Vo (CPO LaunchDarkly)

I think ICs of a certain level of experience, let's say 8 to 10 years of experience, really start to hit the ceiling of leadership or management as the only path for them because levels have been set up in that way. And I think it's a big problem. It is not the same on the engineering side. It's a very common ladder for high performance engineers to continue on an IC track. It is just a much less common model for PMs. I think it's because product leaders have not been creative enough when it comes to how to structure their product teams. And so it's something I've really focused on is ensuring that I have a ladder, an IC ladder that goes all the way up to the C suite. It's totally defined. And I actually there's a Chief Product Innovation Officer that is C suite executive level person that reports to me that is an ICPM and is fabulous and has been at the company for many years and it's been a really effective role. So, you know, I think that IC path is really important and I also believe that even if you branch into management as a product leader, you should still have some pretty good ICPM skills and still get your hands on the work.

Today I want to share an interview with Claire Vo X, Chief Product Officer of Color and Optimizely Clairvoyance. That is finally time for the individual contributor Product manager to shine. We spoke about why PM performance year needs to end, how to pursue the super IC PM career path and how IC PMs can use AI to excel at their job. Claire has so many hot takes and I think you'll love this interview. Enjoy. All right, Claire, well, it's great to have you here today. I really love your hot takes on X and your exploration of AI. Yeah. So let's talk about a few of your hot takes. Actually, let's talk about, maybe we can start with, you know, what do you think like this PM performance theater is. And like what should PM's doing instead?

Yeah, yeah, I, you know, I said recently and I say this sometimes in our team meetings when we start to trend this direction, I say can we just talk less about how we do our work and more about the content of the work itself. I find often in, you know, product meetings and even in the discourse on X, you hear a lot about sort of the abstract frameworks of product management, like how do you think about product discovery, how do you run planning, how do you prioritize a roadmap, you know, bring structure around design sense or product sense and you hear nothing about what people are actually building, like the actual ideas that they have, the, the features that they're shipping, the things that they're working on, the content of the work itself. And even inside teams, we have a PM weekly team meeting and you know, on occasion we start to bias the agenda towards, like, how are we collaborating with stakeholders and what's our framework for soliciting customer feedback? And you know, is this meeting working well or is that meeting working well? And I think that's all important to do. It just shouldn't be, you know, 60, 70% of what you're talking about. I want to make sure that the majority of the time we spend as a team and I'm trying to influence the discourse around product management to say actually what matters is the content of your work. And while frameworks can speed up or different strategies, different processes can speed up the way you come to high quality ideas and the way you execute against high quality ideas and help you hold yourself accountable to performance, a framework itself is not going to build a great product. And as I say, you can't put an idea in like a framework factory and get success out the other end. That's not how it works. And so I think it's really important that we, as product leaders or voices in the product community, stop rewarding performance theater more than we reward like high quality work and proof of work. And so that's something that I really think is important inside teams. I think it's important when we talk about what it means to be a successful, successful product manager.

Yeah, I totally agree. I mean, just because you memorize a hundred frameworks doesn't mean you know how to craft a good product. It's very messy.

Yeah. Even if you use a great framework and you build what is, you know, on paper or encode a great product, sometimes it just doesn't work. And knowing how to adapt in that situation I think is very important. I do think these frameworks give a lot of product managers a sense of false confidence when it comes to the products they build. Because if they do the user research, if they, you know, design it the right way, if we bring in the right stakeholders, like, of course a great product will come out the other end. And like, I've been a product manager, I've been a product leader for a very long time. I've built a whole bunch of duds and I think I'm pretty good. So I think understanding that some of it is like, you know, speed, which I've said some of it is Luck. Some of it is like the right problem space, right time and that frameworks can help you accelerate again, but they're not going to guarantee your success success.

So if you look at the PM career ladder at a lot of companies, like a lot of it is like.

You know, innovation officer, that is C suite executive level person that reports to me, that is an ICPM and is fabulous and has been at the company for many, many years and it's been a really effective role. So you know, I think that IC path is really important. And I also believe that even if you branch into management as a product leader, you should still have some pretty good IC PM skills and still get your hands on the work. So those are maybe my two strong opinions on this topic.

Do you think like the industry is changing a little bit? Like when you talk to your VP or CPO peers, do they have the same opinion like do you want to make an IC track or is it still very much?

You know, I think that 2022, 2023 has not been particularly kind to tech companies in general. We've seen a lot of reorganizations, a lot of layoffs, a lot of like constraints on, on expenses and spend. Teams are getting smaller. And so I do think there's an industry wide sort of reality that all teams are being asked to do more with less headcount. I mean this is not 2020, 2021 where everybody was hiring everybody. You could get headcount in a minute. Most teams are just operating in a very different reality. That reality means that leaders are having to adapt to running a different style of team with different expectations and in a, you know, more resource constrained or scrappier team structure. You're going to look at people, for example, who only do management work, you know, only do the care of feeding of like one on ones and prioritization and managing stakeholders and bringing the team together, all those things and say, you know what friend? Like we need you to jump in and ICPM something we need you to actually get hands on with some of our product because we are just simply capacity constrained. And so I think you're seeing that just across the board is the necessity of the way teams are changing. And then I think that's allowing people, that's giving people a moment to say, hey, what was really working about the time where maybe I had a larger team and people were more specialized and what do I want to continue? But what if that wasn't serving my product organization? What if that wasn't serving my company or what wasn't serving My culture and I think in these times of industry or economic shifts, people really rethink management and leadership practices and, and really, you know, I'm not saying there weren't great things and you know, everybody doesn't want a bigger team and that good work can come out of that, but I do think it's a moment that teams are reevaluating their operating model and saying, is there a different way, is there a better way? Or just candidly, is there a more appropriate way for the time we're at right now?

Yeah. And I think with this AI stuff it might not change anytime soon, right? Yeah. So you have this model called Fast Speeds Write. And, and I really love it because one of the Z is like as companies get bigger they become more risk averse and like, you know, as a pm, you're trying to incrementally move some metric. So I guess how do you keep this like why is it important to keep alive and how do you keep this principle alive as a company scales?

Yeah, I often, again, I think this goes back to where we started this conversation is PMs often believe there is like a capital R right answer to every problem. Right. If I just, if I do the right user research, if I just talk to the right customer, if I think, think really hard, if I structure my PRD and make sure I have a problem statement metric like I will nail it on its head, I will build the right thing and goodness will come out of the other end of that process. And just honestly, after two decades of being in tech and being a founder and working for amazing startups like that is just not true. It's not how the real world works out. If people are really honest with themselves, good work can sometimes turn into bad outcomes. Sloppy work can sometimes trip into good outcomes. And so you want to be right sized with how much you convince yourself you can gold plate your thinking to get the right answer on the other side. And what I can tell you is absolutely true is the more at bats you have, the more likely you are to strike gold in the pursuit of something interesting. And so I do believe it's not how the real world works out. If people are really honest with themselves, good work can sometimes turn into bad outcomes. Sloppy work can sometimes trip into good outcomes. And so you want to be right sized with how much you convince yourself you can gold plate your thinking to get the right answer on the other side. And what I can tell you is absolutely true is the more at bats you have, the more likely you are to strike gold. In the pursuit of something interesting. And so I do believe that real things into market that customers can actually touch, feel, talk about use is the path towards accruing more and more wins over time. And I don't think this is just the fact in larger companies where maybe like risk aversion or process or any of those things may slow down the process. I also believe this to be true at a very, very startup kind of like early stage. And one of the things that I tell startups that I sometimes advise is they sometimes get kind of paralyzed or you know, really try to get on paper like what their strategy is. And they're like, well we have option A or option B or option C and all seem pretty good. Which, and I say, you know what, we're probably in a world in which all of those are viable. Six billion, you know, multibillion dollar businesses like it is possible, you know, in technology, in products, there's a lot of greenfield for great products, but you're never going to be that if you don't pick one. And so I actually think the confidence of like picking a direction and starting to execute is actually the thing you need to do to drive good outcomes. And so I just, I've always seen this. The team that ships faster, the team that makes decisions quickly, often accrues the market insight, the customer feedback and candidly the capacity to build that wins versus the team that like can run a beautiful process and have gold plating thinking but can only ship a couple things a year.

Yeah. Because if you ship like then you just, you probably make mistakes and you learn faster. Right. Like that feedback loop is like so important.

Yeah.

To get going.

Yeah, yeah. And you know, the other thing that I say here is like fastbeats. Right. And the other thing I say is like no genius product managers in that I don't think product managers sort of like divine from the universe what's right and what's wrong. I also think it's important in this pursuit of speed to be able to take in input and ideas from anywhere. I think engineers often have great ideas that get overseen because they're looking, you know, constantly looking to the product manager for what's important or what needs to be prioritized. I certainly think we as an industry undervalue designers and I think there's, there should be more of a design voice in product ideation and execution and those sorts of things. And like people won't like that. I say this but you know, sales is the tip of the spear and I wish sometimes we weren't so actively frictionful when it. It comes to the product sort of sales relationship as a. As sort of like a practice. So I really do think two things that are really effective are moving fast in recognizing great ideas can come from anywhere.

Yeah, this is the problem. This is my pet peeve of the term, like product sense. It kind of implies that, you know, you kind of build it once and then you're done with it. But, like, you know, the market is changing all the time. Customers change all the time. Like, you gotta be humble and, like, listen to other people and listen to customers to figure out what you want to build.

Yeah, yeah, exactly.

So let's talk a little bit more about the Super IC as a alternative career path for PMs. I listened to your podcast with Brian, and he had this good framework about coaches, captains, and players. Do you remember what that is, or can you quickly recap?

I can try my best. Brian will do it better. But, you know, and I actually like this metaphor because I use a similar one when it comes to frameworks. So I'll start that first, which is, like, if you think about a great sports team, a great soccer team, and like, my metaphor is going to fall apart because I don't watch a lot of sports, but let's say a great soccer team, no soccer team says, like, if I just run this framework, I'm going to win. What they do is they attract star talent, they develop plays, so they have a predictable way of working together and a common language on the field. But they also know there's luck and competitors and weather and all these things at play that result in a good outcome. And so I think Brian's, you know, model of thinking about three types of teammates is very important. You have coaches recruit and manage the team, manage the resources of the team. You have captains who are star players who are star players, but also are seen as sort of leaders on the field. This sort of, like, super ic, tech lead, sometimes icpm. And then you have players, talented people that are out there executing plays, you know, kicking balls, doing the work on the ground. And there are, again, as I said, by necessity, there are never going to be as many coaches as players, and there are also never going to be as many captains as players because of the way the team is structured. And that's okay, and you should accept that, but you want to make it sort of like, more attractive to be a player and a captain, or at least equally attractive to be a player and a captain as it is to be a coach, because not everybody can Be the coach. And quite frankly the coach job is very different from the captain job or the player job. And so I think this is a really interesting framework. And the thing that Brian says that I love is like in order to make coaches captions and players equally attractive they have to be equally attractive from a title perspective and they have to be equally attractive from a comp perspective. And I think that's where we you know, kind of mess up which is like why is it a necessary fact of physics that quote unquote managers get paid more than equally leveled ICs. It's not always the case but it can kind of be the case if you do any of these comp studies. I don't think that's necessarily true. And so if you can level out sort of on a level adjusted basis compensation across these like sort of three types of players, I think you can make it attractive to being other take other roles especially that more align with your strength.

I like this framework because like you know, like captain itself kind of gives it a little bit of prestige. Like you know like people say like just an ic but you're not going to call like Tom Brady just an ic. Right? It's kind of like a nice label for suprisey.

Yeah, yeah, yeah, totally. And Tom Brady's bringing home a lot of money. A lot of money.

Defensive coordinator and you mentioned you have this like chief innovation officer, right? And so like what are some traits of really great ICs who can really get to this level?

Yeah, yeah. So incredibly high context on the company is one like they need to be a reference point for the company on the details of the product on the business model. I mean it, it they contain a lot of internal knowledge. I've seen in most, most super senior. It's. They're highly capable at their craft. So if they are a pm, they are exceptionally capable at hard and soft skills of product management. Meaning that literally anything you toss to them they can catch and execute well. So they are highly skilled. But then these ICs are really detail oriented. Like they know the details, they sweat the details. They're very flexible when it comes to the type of work that they do. They know how to make decisions and drive teams towards decisions. They basically they know how to and when is they influence without authority. They know how to direct without authority which is like I think very different. It's not like they're whispering into somebody's ear saying I think we should do like they're like they have the cultural carry inside the company to Say we're gonna do X. Doesn't matter that you don't report to them. Like people believe and get it done. They tend to be, you know, pretty low drama. Well liked. Like it's hard to be a super seater. I see that people don't really love. And then I also think one of the things that they do really well is they're very, just well networked internally. So, you know, they know every engineer, they know rpm, they, it's not weird for them to like DM the cmo. All those sorts of things I think are very important. So those are some of the things. But mostly they just get stuff done really fast.

Okay, so do you think as a super IC you need some sort of like air cover from execs or like it's kind of hard to come into a new company as a super IC and like succeed. Right. Because you don't have those relationships or like, you know what?

I've done more on the engineering side. You know, I rarely see somebody hired in to like very senior ICPM role. It's often more of a promotion path for somebody internally who has a lot of credibility that doesn't want to go into management. Right. So I do think there it's, it's sort of usually as a more of a promotion path than a higher end. Although on the engineering side I've absolutely seen super icy engineers hired in and be very effective and it's because they're excellent at their craft. They're excellent at their craft, they're quick and they know how to build consensus and community. So I don't think it's impossible. I've seen it done many times before. I think on the product side it's often a result though of just having done good work and proof in the company.

Got it. So like, let's say there's some PMs hearing this, this thing and like, you know, they want to, you know, they love like, you know, working with the engineers and designers. They love crafting products. But like, you know, in their current company, their ladder is just like, hey, you know, if you want to get paid more, you gotta become a manager. Like, like how do they find a company that actually cares about surprises? Yeah, or what's the.

Yeah, I mean, fine. I think there are a lot of, I mean there's not that many actually, but like people that actually still work at companies and are influencing product sort of thinking in the broad community. But you can't find people like me who talk about this who can probably connect you to other leaders. Who are thinking like this. I think the other thing is I really believe in shooting your shot when it comes to careers and roles that you want. And so I often believe that there are, like, no hard and fast rules when it comes to what roles exist inside most technology companies. Just no one's going to go out of their way to change something for you out of the goodness of their heart. So I've had personally a lot of success. I've done this multiple times in my career where I have walked in with a one sheet, like one pager on. This is the job that I want to do. Sometimes it's promotion, sometimes it's a new team, sometimes it's restructure, sometimes it's just, I see this is a job I want to do. How do we get there? And your manager or your leader can then partner on you with you, getting you into that role. I think it's very different to be like, can you figure this out for me? Like, no, come, come with an answer and like, help me execute versus asking me to solve a problem for you. So I really, I always say this to anybody who's asking me for career advice. Know what you want out of this job and know what you want your next job to be. Always have an answer to that question very crisp. Because then people can help you more than they could if you. You're not clear on that.

Yeah, I think that's really good advice because a lot of times these like, really good ICs might not be working on the most important problem for the company or like, because of Org or whatever. So maybe you can't come in and like, you actually be like, hey, I actually want to work on this problem and think is more important.

Yeah, yeah, exactly.

So like, you also spend time like building chat, PRD and like your own AI stuff. Maybe let's wrap this section with like, you can maybe give me some idea of like, what your time is like as a CPO and like, you know, how do you protect your own craft time?

Yeah, so I've talked about, about this pretty broadly and, you know, everything changes with the season. But one of the things I realized earlier this year is I was in meetings 80% of my day. And I have a pretty strong philosophy that no one in my org, including me, gets away with not producing IC work. And if you're in meetings 80% of your day, you have no builder capacity. So I am privileged enough. I lead a senior team, right. I'm chief product officer. I have many VPs and directors, etc. Very senior folks in their career reporting to me. And I just canceled my one on ones. I said I'm spending 40% of my time meeting in silos with individuals and they're in these 30 minute fragments. And we spend 10 minutes, you know, just catching up personally and 10 minutes, you know, figuring out a couple things but not actually getting deep on them. And then we move on with our lives. And I just, I couldn't do it anymore. I couldn't do it personally. It wasn't serving the company. I don't think we were getting effective production out of those meetings and so I just canceled them and I got back half of my time and then I could consolidate all my time to where I was getting like full afternoons off or like full Fridays where I could be more responsive the team. I could be more available to the team. I could actually go heads down and work on things, produce documents, PM projects, all those sorts of things that I think are actually critical to my success as a job or as a leader. And it may, I mean like trans life changing. I don't know how to describe, describe how good this thing was for me. It's like a life changing. And also I don't think anybody like wakes up as a, you know, kindergartner and says when I grow up I really hope that I'm in one on ones all week in unassumed meeting. Like no one dream dreams of that. Maybe there are people out there. I don't want to erase people's ambitions, but I want to create, I want to build. I got into technology because I like building things. And so protecting building time is actually a very productive force for me as a leader because it keeps me engaged in why I choose to do this work and why I choose to have these kinds of roles. And so that's been really important for me and something that's been successful. And then what I replaced those one on ones were with were much longer, like hour and a half long meetings with either individuals or groups of people actually go deep on the problems that we're solving. We had a lot more sort of casual synchronous time together where we'd all just like hop on a zoom with no agenda and just hang out and work together. It just really changed how I thought about how I could work and I think it's been really effective and I highly recommend, highly recommend rethinking your schedule as a product manager or leader.

How about your reports? Are they happy to get time back or do they miss you or they're Good.

We check every now and then. They get me. That's the thing is what was really interesting is when I was so booked, people couldn't get me when they needed me. Right. If you have something come up, well, Claire's back to back so I'll talk to her tomorrow. Or if you're like, I really need to go deep, but I can only find 30 minutes on your calendar. Like it actually has made me more available, if that makes sense than less. It's not like I don't allow a one on one. It's just that people can choose to put it on my calendar when they want. And then we have these like more infrequent but regular check ins where it's like I meet with everybody at least once a month. We get together as a team every week. It's not like I don't see people, it's just I'm not sitting serializing like 30 minute check inside with very senior adults who know how to do their job and can like slack me anytime. So you know, and I think it would be harder, it's maybe harder to do if you have a day coach, like a more junior sort of employee who needs more active coaching. But I have just a very strong, very senior team. The questions they come to me with are more strategic in nature really discussing long term things about the business. You know, if they need my advice, they can give me a call on something tactical. But it's worked for me. Now would it work? It's also worked because I have three years of credibility with this organization, with this company. Like do I think you can show up as a new product leader and do that right off the back? Probably not. You could think about how do I want to structure how I meet with my team for maximum effect and don't just default to one on ones.

Yeah. I think bottom line is like most product people, like you said, want to spend time crafting stuff.

Right.

Like that's what gives them energy. Yeah. So maybe your reports also like to spend more time doing that too.

Yeah, yeah, yep, exactly.

So let's talk about, let's talk about your AI journey. So like you recently had a hackathon, right, or something in your company?

Oh, we have hackathons all. We're in the middle of a hackathon right now. Right now. I need, after this I'm going to go code. So we do, we have two big hackathons a year. It's usually like hot hack summer and hacky holidays. So we do one in the summer and one in the winter. But this year with all this Gen AI stuff, we have basically done a hack half week, like two or three days, about every six weeks because there's just so many ideas and so much energy and we're able to carve out and protect the time and have it not be disruptive. And we think it's a priority. So I think this will be the last hack week of the year, but we've definitely done a handful this year.

So like for chat prd, like maybe we can talk a little bit about it, what actually does.

Yeah, yeah. So Chat BRD comes out of me trying to build myself a copilot. As I said, I do IC work for product management and I have a lot of company product context. But the communication of that context, especially in an asynchronous working environment, it takes investment of time to get your thoughts that are inside your head pretty clear into a structured document or something that could be shared to be discussed in a remote remote or a distributed team. And so with ChatGPT I was consistently working on like how do I prompt ChatGPT to actually be an effective copilot? And I think over several months got to something that I think really works for me. And so chat prd, basically me productizing the product copilot that I have built for myself and the things that are is particularly good at it is very good at scaffolding fairly robust PRDs from ideas or like low context outlines of what you want to build into something that I think is much more robust that can be completed by a product manager. But I say it can type, I mean it can think faster than you can type kind of, kind of situation where like it could take the 22 seconds of GPT processing time and get out like what you would probably have done but had to sit down for like an hour and really get it from your brain into your fingers. So it's very good at taking ideas and expanding them out to prds. It is also, I think, pretty excellent at taking existing PRDs and inspecting them for gaps in like reasoning gaps in features. It often finds features that are like, in my mind obviously table stakes features that like I just kind of forget to put in. So it's pretty good at giving feedback on PRDs and then it's a good sort of like thought partner or coach given some of that context on how you as a PM could do better. So it'll give you reflections like, you know, based on this PRD or The set of PRDs that you shared, you really under you under Invest in talking about metrics and outcomes in your documents. Like you're very vague about those things. You should probably develop more hard data skills. So I think those are the three things it does really well and I've gotten a lot of positive feedback from it and basically Pm saying like I was gonna spend an hour and a half on this thing and I was able to get it to like 80% in five minutes and then I could spend the time really going into the details and going deep. And it just saved me a lot of time and it helped me with this like blank page problem. And I've also had them say it just compared to out of the box, ChatGPT is a lot more effective. So I think it's working. People are signing up, people are using it. I use it daily. So we'll see.

Maybe give me some like how the sausage is made. Like, is this like a very long prompt or are you using like non.

Yeah, as people say. I say it is just a prompt, but it is my prompt. So a lot, it's a very long prompt and a lot of energy has gone into it. It's a prompt. Plus I did actually, you know, I distributed it as a GPT on chat GPT. I think like over 5,000 chats have been PRD'd. So people are out there generating PRDs with, with chat PRD. But it's also its own standalone web app. So I launched it on ChatPRD AI. If you don't have a ChatGPT plus subscription, you don't have 20 bucks a month to pay for it. Pretty affordable price point directly that you can use it as a web app. And then once I have that web app, I'm going to be able to do things like extended into Google Docs and extended into Jira or Confluence. So yeah, we'll build more stuff. I have a goal to do a release every weekend, so while my kids nap and then on Sunday I do a release and you will get improvements on the like web app, the ChatPRD AI that you won't get on the GPT.

That's amazing. Yeah, I play around with it a little bit and yeah, it takes away a lot of like the boilerplate stuff that you have to do around writing prd. So it helps a lot.

Yeah, great.

So. So I guess we can wrap up with this question, last question, like a year or two from now, like how would a PM's job change with this AI stuff? Like do you think like all the, like the meeting notes and like all this stuff will Be like abstract away or like, how do you think of pm?

Yeah, yeah. What I'm really excited about my friend Waylon, who's one of the co founders of this company called Patch. It's like Patch Tech. He worked for me at Optimizely. He's superstar product thinker. I mean, top tier. And he has this idea of like the Proto manager, which is like a prototype manager. And I actually think that's the more interesting way product management could go, with these AI tools, which is like. Sure. Summarizing meetings and creating requirements documents and all these things. Yes. We're going to have tools and agents that are going to automate those things. But like, that's not the interesting part of the job. The interesting part of the job is like actually participating in the building of something. And what I love in terms of Gen AI is the ability to go from idea to product without necessarily strong technical skills. Now I'm a software engineer. I can code. So, like, it's easy for me to say that, but I do think we're at this place where you can take natural language and ideas and actually get a prototype going that you could put in front of customers or you can iterate yourself on like. No, that's not exactly how I want the experience to work. That doesn't feel right. You can sit side by side with designers. So I think product managers are going to be forced to candidly build more because the tools will allow them to build more without necessarily coding or software development skills. So that's how I hope it changes is that the lines between prod and design sort of blur and allows everybody to be more creative, allows people to contribute more to the business.

Yeah. So then we can actually. Product manager can actually like, deliver stuff for a customer as opposed to like only just internal stuff. Right. For internal stakeholders.

Exactly, exactly. Or they can at least produce artifacts that are much more closely aligned to what the actual experience would be versus a document.

Yeah, My engineers say, like, you know, like, my engineers say that I can write better AI prompts than them, so, like, they actually rely on me to write the prompts.

Yeah, exactly.

Yeah, exactly.

Yeah.

Cool. All right, well, thanks so much, Claire, for your time. Yeah, this was a great conversation.