Every argument clarity score on this site is built from rows on this page. Each
question and answer was assessed with names hidden, the host's own answers included, on
four things from 1 to 5:
directness (does it answer the question asked), coherence (do the ideas follow),
precision (concrete details and clear references), compression (says a lot per word). The weighted
mix (30/30/25/15) is the exchange score. A person's published score averages their exchange
scores on raw tape only, at least 8 of them, shrunk toward the cohort mean.
Full method →
Answered raw tape
D 5 · C 5 · P 4 · Cm 4 4.60
Q Have you ever had someone being really bad, and if so, what did you not see? How did they get through that process?
A When I got better at hiring, there were relatively few of these where it was just, you know, they're, they're bailing on week one. It's just a total disaster because we got better for screening, but we did have a fair number that just didn't make a cut at month three. You find is, A, they don't take ownership or don't want to, Either they don't want to or can't. By month three, you should really see them start leaning in, have a strong point of view, take ownership, have some conviction and priority, and they're just not there for whatever reason. Maybe they didn't have the base skills to form a point of view. Maybe they're a little timid about creating, communicating a point of view. Maybe they don't collaborate. Well, these things can be a little harder to test for and show up in within the first few months.
AI assessment note: “these things can be a little harder to test for and show up”
Answered raw tape
D 5 · C 5 · P 4 · Cm 4 4.60
Q Is that a way to get promoted though? If we think about like, I'm in GitLab, how does having a strong opinion on the ICP help me get noticed by leadership and get a promotion?
A If you really understand them, Then you're going to tee up the right work, which is going to drive results. Ultimately you want to drive results, but how do you get there? I think the building block is having a ton of. Perspective on the target user and what they need to build the right stuff for them. And if you demonstrate that, you know, the target user sales are going to trust you. Marketing is going to come for you to you to make sure that your thing is marketed the right way. Engineering is going to believe you and trust you and not fight you on every decision you make. It just, everything flows from that. So that's the very first thing I would do. And then from there, you're trying to prove business impact. So make sure you have a KPI that leadership cares about, that maps to the work that you report on regularly and openly and honestly.
AI assessment note: “you're going to tee up the right work, which is going to drive results”
Answered raw tape
D 4 · C 5 · P 5 · Cm 4 4.55
Q Okay. Sorry. Just breaking those down. Who do you present those to? How are they used internally? Can you just share that? If I'm a founder listening and I'm like, Ooh, that's a good point. One pager and a six pager.
A Well, I'll start with the six pager because that's sort of the longer arc one that, that should help you drive more focus. At GitLab, we had these things at my level for the whole product line. The directors had them for product areas. If you think about GitLab, there's dev, sec, and ops. So we had a dev strategy, a sec strategy, an ops strategy, and then each PM underneath those directors had their own strategy for their area. Maybe it was agile planning or road mapping or, or continuous integration or whatever. And when you have these laddered strategies, it helps each level make sure that the things they're working on are connected to other levels. I don't want to over-complicate it. You're mostly dealing with startups here, so you probably just need one of these. The point is you want a little bit of a longer arc than your typical planning cycle. So at GitLab, we had a one-year planning cycle. Plenty of companies have quarterly planning cycles. Make sure it's two or three iterations larger than a planning cycle. So if you plan every quarter, make sure it's at least a year. If you plan every year, make sure it's two. So that you can kind of get out and over the planning cycle into like, where are we going over a longer R and it should make trades. It should say, Hey, we're going after this segment and not this segment. We're going to focus on these use cases and not these us…
AI assessment note: “when you have these laddered strategies, it helps each level make sure that the things”
Answered raw tape
D 4 · C 5 · P 4 · Cm 4 4.30
Q Okay. Sorry. Just breaking those down. Who do you present those to? How are they used internally? Can you just share that? If I'm a founder listening and I'm like, Ooh, that's a good point. One pager and a six pager.
A Well, I'll start with the six pager because that's sort of the longer arc one that, that should help you drive more focus. At GitLab, we had these things at my level for the whole product line. The directors had them for product areas. If you think about GitLab, there's dev, sec, and ops. So we had a dev strategy, a sec strategy, an ops strategy, and then each PM underneath those directors had their own strategy for their area. Maybe it was agile planning or road mapping or, or continuous integration or whatever. And when you have these laddered strategies, it helps each level make sure that the things they're working on are connected to other levels. I don't want to over-complicate it. You're mostly dealing with startups here, so you probably just need one of these. The point is you want a little bit of a longer arc than your typical planning cycle. So at GitLab, we had a one-year planning cycle. Plenty of companies have quarterly planning cycles. Make sure it's two or three iterations larger than a planning cycle. So if you plan every quarter, make sure it's at least a year. If you plan every year, make sure it's two. So that you can kind of get out and over the planning cycle into like, where are we going over a longer R and it should make trades. It should say, Hey, we're going after this segment and not this segment. We're going to focus on these use cases and not these us…
AI assessment note: “helps each level make sure that the things they're working on are connected”
Answered raw tape
D 4 · C 5 · P 4 · Cm 4 4.30
Q Tell me, Scott, as a product leader, you have a, hopefully a team that has is full of ideas and does a lot of opportunity canvases. How do you ensure focus? And velocity, which is speed in a given direction that's hopefully right, but also not ensure that a team doesn't feel crushed and stifled of innovation and ideas.
A It's, it's a tricky balance because this sounds a little heavy, right? PMs always have two tracks going. At least that's how we ran it in Sengri and GitLab. There's a validation track where you're doing your homework on the things you want to pump into engineering, and then you have a build track. The build track's always moving. You're going sprint to sprint to sprint. Every place I've ever been, there's been an enormous backlog for engineering. So it's, in my opinion, if it's well run, doing a proper validation shouldn't slow down engineering. They have more than enough to do. This is about making sure that the next thing you tee up for them is well conceived. But to my far earlier point, PMs need half their time available to be doing this kind of validation work. So it shouldn't have slowed down in engineering. It should speed them up because there's less back and forth between PMs and designers and engineers if the project is well conceived. Where you get a lot of back and forth and slow down is when you're like, are we doing it for that or that? Who is this for? Who cares about what? If that shit's unclear, the product development process can get really chaotic. So in my experience, it's sped up engineering.
AI assessment note: “PMs always have two tracks going... There's a validation track... and then a build track.”
Answered raw tape
D 4 · C 4 · P 4 · Cm 4 4.00
Q Our product leaders generally A science led product leader or an art led product leader? Is the unicorn the one that does both?
A I think, yeah. Uh, uh, if I think about my own career, I've been more of the later stage. Let's bring some science to this thing. Let's bring some rigor to how the PM job is done so that we can raise the average performance level for PMs on a, on a medium to large team. It's more of like thinking of your product team. As the product, because they have to go to the individual work versus if you're a very early stage, either founder or a person who's come in to run it, a lot less data. Maybe it's just you. You gotta be scrappier. You gotta work on less data. You gotta use your gut a lot.
AI assessment note: “I think, yeah. Uh, uh, if I think about my own career”
Partly raw tape
D 3 · C 5 · P 4 · Cm 4 4.00
Q Tell me, Scott, as a product leader, you have a, hopefully a team that has is full of ideas and does a lot of opportunity canvases. How do you ensure focus? And velocity, which is speed in a given direction that's hopefully right, but also not ensure that a team doesn't feel crushed and stifled of innovation and ideas.
A It's, it's a tricky balance because this sounds a little heavy, right? PMs always have two tracks going. At least that's how we ran it in Sengri and GitLab. There's a validation track where you're doing your homework on the things you want to pump into engineering, and then you have a build track. The build track's always moving. You're going sprint to sprint to sprint. Every place I've ever been, there's been an enormous backlog for engineering. So it's, in my opinion, if it's well run, doing a proper validation shouldn't slow down engineering. They have more than enough to do. This is about making sure that the next thing you tee up for them is well conceived. But to my far earlier point, PMs need half their time available to be doing this kind of validation work. So it shouldn't have slowed down in engineering. It should speed them up because there's less back and forth between PMs and designers and engineers if the project is well conceived. Where you get a lot of back and forth and slow down is when you're like, are we doing it for that or that? Who is this for? Who cares about what? If that shit's unclear, the product development process can get really chaotic. So in my experience, it's sped up engineering.
AI assessment note: “PMs always have two tracks going... There's a validation track... and then a build track.”
Answered raw tape
D 4 · C 4 · P 4 · Cm 4 4.00
Q Our product leaders generally A science led product leader or an art led product leader? Is the unicorn the one that does both?
A I think, yeah. Uh, uh, if I think about my own career, I've been more of the later stage. Let's bring some science to this thing. Let's bring some rigor to how the PM job is done so that we can raise the average performance level for PMs on a, on a medium to large team. It's more of like thinking of your product team. As the product, because they have to go to the individual work versus if you're a very early stage, either founder or a person who's come in to run it, a lot less data. Maybe it's just you. You gotta be scrappier. You gotta work on less data. You gotta use your gut a lot.
AI assessment note: “later stage. Let's bring some science to this thing... early stage... gotta use your gut”
Answered raw tape
D 4 · C 4 · P 4 · Cm 4 4.00
Q What happens post product review? Like, how do you ensure that the learnings are codified, shared, and then enacted?
A I think that's where these monthly reviews came in. So let's just say We agreed that they should move on with a project, and we liked the concept, and we liked the, kind of, the design prototype. Then it gets fed into the development cycle, and then as they're talking about their KPI review, they can reflect on what we did last month, what we're going to do next month, and then you start to see how this thing's getting iterated on as it projects out towards the ultimate customer value. So that's why I separated them out a little bit, because the first two are more about making sure this is something we want to take on as a good investment, and the other is more like Managing the ongoing priorities is at least a building. That makes sense.
AI assessment note: “I think that's where these monthly reviews came in.”
Partly raw tape
D 3 · C 4 · P 3 · Cm 3 3.30
Q What happens post product review? Like, how do you ensure that the learnings are codified, shared, and then enacted?
A I think that's where these monthly reviews came in. So let's just say We agreed that they should move on with a project, and we liked the concept, and we liked the, kind of, the design prototype. Then it gets fed into the development cycle, and then as they're talking about their KPI review, they can reflect on what we did last month, what we're going to do next month, and then you start to see how this thing's getting iterated on as it projects out towards the ultimate customer value. So that's why I separated them out a little bit, because the first two are more about making sure this is something we want to take on as a good investment, and the other is more like Managing the ongoing priorities is at least a building. That makes sense.
AI assessment note: “as they're talking about their KPI review, they can reflect on what we did”