Cutlines & Roadmaps

[00:00:00]
>> Ooh, this is a good one. The cutline. The cutline is basically, I have scheduled for work these things. Here is my cutline of stuff that I would work on if I had more resourcing. So, I have projects A through F. I was like, but if you gave me more engineers or gave me more time, more blah, I could accomplish this, this, this and this.

[00:00:29]
And this is where I stick my like, I wanna work on this. I would like I would bet big on this, but I don't have time or staffing to work on it at. Why is this useful to do? One, it just expresses intentions at the very least. It's like, I can't work on this now, but maybe next quarter I can work on this.

[00:00:48]
But what's actually more powerful about this is, I've had this happen to me, someone will come to me and say, I also think this is really cool, and I also think this is very important. Here's more staff or don't work on this, work on this, right? And I get buy in from teams around me or, hey, the sister team is similar enough that they can take on the work that you're wanting to do or they can take work from you so you can work on this.

[00:01:12]
It's a powerful tool to communicate. I wish I could be working on this, maybe we should talk about it. So I use this to a lot of advantage to get the things done that I actually wanna get done. And I do that every roadmap. Here's my cut line, here's stuff I want to work on.

[00:01:28]
It's very, very helpful. This is a mistake that I consistently keep doing. [LAUGH] By the time it makes it onto your roadmap, it should already be researched. To take that a step further by the time it gets on your roadmap, you probably should have a product spec. Ideally, most of the time, you should have a product spec before it's on your roadmap, which is to say, you should be thinking about what's going on to your next roadmap pretty much as soon as you finish the previous roadmap.

[00:02:04]
Why? One, if you plan for work, this is basically the thing that is the artifact that you're gonna hand to your engineering partner and said, here's what we're gonna work on for the next three months. And if you have large open questions on that, you can end up with idle engineers which is the cardinal sin here of planning, right?

[00:02:22]
If you end up with an engineer, is like I am done with my previous task and I have nothing to do, you as the product manager have failed them, right? Now generally I have a couple of things and the wings always. So that if an engineering is sitting idle, it's like, you're idle, here's a bunch of cool stuff I'm excited about, right, and I have it ready for them.

[00:02:42]
But that almost never happens to me cuz I'm usually pretty good about making sure that everything that's on my roadmap is actionable and workable. Very rarely do I run out of time for, or run out of stuff for engineers to do. But that's because frequently I follow this.

[00:02:58]
And the times that I don't follow this, I'm pretty sure that I don't have blockers there. Yeah, please research things. Please have them almost ready for work by the time it makes it on your roadmap. Yeah, because what has happened where this can bite you in the butt is like, you'll put something on your roadmap and you'll find out it's actually impossible.

[00:03:25]
We wanna do this thing and then we realize, no, we have this hard dependency on this thing and we simply cannot accomplish that. That has happened to me before. Cool, questions here?
>> You could change depending on organizational needs or regulatory needs or something to,
>> Your road map?

[00:03:52]
>> What's that?
>> Your road map?
>> Yeah, I think.
>> I did say roadmaps should never change, in fact they absolutely should change, right? So absolutely if a seismic event in your industry happens then it causes a shift, that'll happen, your company will get sold, that's gonna change it or you'll have layoffs.

[00:04:12]
That was my big challenge at stripe is we had layoffs in the middle of when I was working there and I had to literally half my roadmap, right? I couldn't just leave it unchanged It's a living document, you should definitely modify it as you need to and communicate as like, hey, we were planning on doing this, X changed, we're gonna do this instead.

[00:04:34]
We have delays here, we're not gonna be able to accomplish this in time or we're ahead of schedule here, we can work on this sooner, all those kind of things. But having big blocks of work suddenly get removed from it, that's unnecessary change, right? What we're describing right now, like regulation, necessary change.

[00:04:53]
We have no control over that, right? But you didn't research this enough and it's on your roadmap, that one's on you, right? Unnecessary trash.