Starting the Planning Process

[00:00:00]
>> One of the hardest parts about and this is kind of just in general for being a PM and probably even just working in an office environments is sometimes it's just really hard to get started. This is hard about writing docs. This is but particularly roadmaps that this is where I really struggle with them, which is why I put this in this section.

[00:00:19]
Where do I start? And the answer is just, just start [LAUGH] my secret hack to this and like it's it works with like doing courses and writing course materials and planning and writing product specs. Generally when I'm thinking about my roadmap, I have some idea in my head.

[00:00:39]
I have one idea in my head that like I'm really kind of just hyper focusing on. And I just start there which is usually in the middle somewhere, right? Usually I have like one project that I'm really excited about. And I'm really decided to just like, get on this project.

[00:00:53]
I will start my roadmap by just writing out the projects that are that I'm pumped about. And pretty soon once I was like unblocked from that, getting started, generally the rest of stuff for me just kind of starts to flow out. So that, I don't know. I shared that tip just because it really helps me and it's really applicable to me when I'm in planning season.

[00:01:15]
But just start and start with what's in your head. There's some catharsis in just getting stuff out of your head and onto paper. And I'll also say I almost always delete the first thing I write and that's really okay as well. I'll write something down and then I'll write the rest of the document and realize this is actually not the format that I wanted from it or I thought of something better.

[00:01:37]
I'm gonna delete that. But I think there's something probably physiological about just typing and activating a different part of your brain that gets stuff flowing out better. Yeah, you just wanna get the wheels turned in there. This was another thing that intimidates a lot of PMs. Most of your roadmap isn't all of your ideas.

[00:01:59]
You are not expected to be the all-idea person. I dare say that at a certain organization size most of the ideas shouldn't be yours. It should be a reflection of what your users are telling you, what your metrics are telling you, what your team is telling you, what your customer facing organization people are telling you.

[00:02:20]
Some of them should be your ideas or probably ideas. Some of them should be your bets, right like I'm making a bet that I think ChatGPT things probably here to stay, right? And so we're gonna do some stuff on that. But yeah being a PM doesn't mean coming up with all the ideas.

[00:02:38]
It does mean being the shepherd of all the ideas, right? And generally it means, you are taking other people's ideas and then you become the owner of them and then you have to develop them and go further with them, right? It does mean that but it doesn't mean you are like having to write down all of the work that you're gonna do from your own brain.

[00:03:00]
So like I sat down with my recent roadmap and I would say 50% of it for me was ongoing tasks just like ongoing things that we were trying to get done. 40% either came from my team or like my greater company organization and just 10% came from me.

[00:03:18]
Now, I think if you went back to like some of the stuff I was doing like on VS Code. It was much higher me like I think I was working on like 50% of stuff that came from me. And I think at stripe it was almost entirely stuff that had come from customers try to do.

[00:03:36]
I don't necessarily think I worked on any like any big project that came from my brain and that doesn't make me sad at all. I don't care where the ideas come from. I care that they're good, Follow the themes. I like looking at my colleagues roadmap and my greater organization not like all of snowflake but like in the smaller organize that I'm in and then see what they're working on.

[00:04:03]
And if I have, prior roughly equivalent priority stuff to work on that aligns with their work. Some of those synergies can be helpful. Stripe did a really good job and actually snowflake does a good job too of publishing as a company. Here are themes for this quarter plan around these kinds of things.

[00:04:24]
So if you have some of those, those are good to follow. This one, it sounds like a truism kind of is it But don't say things like improve web performance. When are you done improving web performance? When is that a done thing? It's never done, right? It's a continually, you can always make it 0.1 second faster, right?

[00:04:50]
So don't say things that aren't completable say that like swap out framework for a new framework. There's a point where that goes from being not done to being done, right? Make them basically a fact that can be proven or disproven or a binary statement that is like this is either true or it is false.

[00:05:09]
But it should be something that you can check off that is a completable Unit of work.
>> When you talk about these completable quantifiable units of work I've been given this advice as a contractor consultant as well it's hard to get paid when you set really generic criteria.

[00:05:29]
Is this of a similar intent that you want to make sure that your product projects and the products that you're trying to bring to completion are actually considered complete. And you're trying to influence without authority that you mentioned yesterday, would this be a practice of it?
>> Right cuz what's gonna happen is you're gonna get to the end of your quarter.

[00:05:52]
Your goal was improve web performance. And maybe it's like, all right, we used to take 5.1 and now we take 5.0. Great, good job everyone, right? It's also just an infinite bucket of work, right? And I don't like infinite bucket of work. I wanna do something and get done.

[00:06:12]
Sometimes, let's say that you have identified that users are having an awful time on your website and it's because it's very slow and you don't know why. My suggestion there is timeboxing and say we have a two week perf push, right, and so we're gonna go do this for two weeks.

[00:06:31]
And either we're gonna discover what it was and fix it or we'll come up with an actual project at the end of that. But that's what I would plan for. And that is a completable thing is like for two weeks we did work on this and we started it and we finished it and it's over, right?

[00:06:46]
But it helps for accountability to you. It helps for other people in your organization to know what you're actually working on. And it's just good practice as well. Yeah and honestly it's gonna be good for your career where you can go back and say, here's projects that I work on instead of saying, I improved web performance.

[00:07:14]
You can say, here's a list of actual concrete things that I was able to get done with my team. The next one here is make long projects have milestones. Some of the projects you're gonna take are year long projects, two year projects, three year projects. You could have probably even longer horizons too.

[00:07:29]
When you have those things, break those down into milestones that fit within whatever your unit of measurement is. If it's a quarter, right? Let's say I'm migrating from SWS to Azure or something like that I would make every quarter, like in this quarter I expect to accomplish this part of the migration.

[00:07:51]
It's gonna be databases and object caches. Next one is compute layer, next one is messaging buses and the last one is AI services or something like that. So that way it's still, you still end up with completable packets of work within your quarter. It makes it reportable, it makes it alignable.

[00:08:14]
Those are all good things to have. Because rather than having this same thing on your timeline, on your roadmap every single time you'll end up with completed projects, which is always good. So break things down into completable packets of work if they're too long to fit inside of a particular quarter or half year or year or something like that.