Check out a free preview of the full Complete Intro to Product Management course

The "Fit into the Organization" Lesson is part of the full, Complete Intro to Product Management course featured in this preview video. Here's what you'd learn in this lesson:

Brian recommends shaping a planning process to align with the existing culture and organization. It's challenging to gain a consensus if the process doesn't fit. In some cases this may mean product managers focus on strategy while engineering managers create the plan.


Transcript from the "Fit into the Organization" Lesson

>> It wouldn't be a Brain Holt course I didn't put XKCD somewhere in this, my favorite comic. Estimating timings, estimating when stuff is gonna get done, it's all hard, we're all bad at it. And like this cartoon really resonates with me it was basically like, okay, I am trying to do some estimation here.

Here's the special, everyone says, like, think about how much time it's gonna take and then double it, right? And this is just making fun of that. I was like, yeah, and then you end up wasting a ton of time trying to think about it, right? Anyway, I thought it was pretty funny.

Everyone gets it wrong. So don't feel bad about that, rather than try and guess the magic secret, because humans are really bad at estimating time just in general, and particularly when it comes to packets of work. And particularly when it comes to multiple people doing things. And particularly when it comes to, you're gonna have stuff that's gonna come up in the middle, and new priorities, and new fires, and stuff like that.

So, you can never predict it. So just build a certain amount of unpredictability into it. Assume that all of your timelines are always going to change. And then just have good process around communicating delays. There was a reason that I chose a delay for the project that we talked about for most of these courses.

Because a lot of times our technical communication is around timelines, right, because those are the things that slide around the most, right. My product specs generally do not change like the problem statements. The goals and non goals do not change. The metrics do not change. The timelines change wildly, throughout the process of a project.

So, all of that said how do you plan for something so uncertain? How do you make it like a not a nonsensical event, right? That's what I'm gonna try and help you come to today. So, I'm very biased around planning for quarters. All of my jobs have been around quarters, Netflix did it, LinkedIn, Microsoft, Stripe, Snowflake basically it was just Reddit.

Reddit didn't really care about quarters but Reddit didn't really care about much of anything so it's probably unsurprising to most of you. I'm gonna talk about things centered around quarters. You might, there are some companies that plan in half years, there's some companies that plan by the year, there's some companies that really only go month to month.

And there's some startups that are really only worried about a sprint at a time, right? So, I'm happy for you to kind of adjust this. I'm just expressing to you my bias that quarters is generally how I think about everything. So yeah, that snowflake were very based around the fiscal quarter, which for us, fiscal year starts in February, right?

So everything's off by month. My brain melts around that but it's fine. First of all, yeah, well, we'll talk about the spin first. Fit into your organization. Don't try and reinvent the wheel every single time, it's better to be aligned than for you to have the perfect process.

So if you go into an organization and they're planned by fiscal quarters and so February is a really hard month for you then just do it, right? Unless you have some great efficiency gain to do there, I'm not into idealistically changing things for like that. But that just means go around ask people, how should we plan?

How should we get it done? Some organizations, Google famously, when you plan for a quarter you plan for more work than you can get done. And I'm gonna say most organizations work on this sort of system where, hey, we're gonna plan ten tasks and we only really intend to finish eight.

And at Google, they say if you get all of your tasks done, you didn't plan it enough. I like that planning because it means that, well, if I get all eight of them done and I got another sprint left, I'll do the ninth one, right? And I already have a prioritized list of things to get done.

There are other organizations that like to say, if it's on your plan, your roadmap for that quarter, you are guaranteed to the rest of organization unless something changes, I'm gonna get all of this done. The advantage to that is that now when I look at everyone else's roadmap, I can say I can pretty well guarantee, most of this is gonna get, all of this is gonna get done.

It gives you some dependability when you look around the organization that these people are being fairly conservative with their planning motion, right? So, I guess that's like how conservative are you in your planning? So, I prefer the more aggressive, let's try and, put 70% on there or 100% on there and we'll only get 70% done, or put 100% on there and aim to get 100% done, that's kind of up to you.

When I have it the way that it's more conservative, generally what I will do is I will make like a larger plan and then I will only put on my roadmap the committed part. But I still have a larger roadmap behind it, because that's how I think, right?

I think in a much more longer term than that. What if your org doesn't plan? You should start planning. I know a lot of start ups say, hey, we're just super agile and we're just ready for, we're doing daily sprints, and things like that, it's bull, don't do that.

Every organization that has any sort of alignment to drive should have some sort of plan. They should have a little bit of a roadmap, they should have some idea and alignment where everyone says, like, here's a group of tasks that we hope to accomplish in X amount of time and we're gonna go at it.

And everyone's like, yep, we're gonna do those things. There's a lot of alignment and power and a company coming together and saying, this is our collective plan to get work done. It drives alignment from the perspective of, if your customer service reps know that, then they can start telling people it's like, hey, we know this is broken, it's on the roadmap and we're gonna fix it.

Your sales team knows when to start selling something and when to start to deemphasize something. Your marketing team can get ahead of the curve and start marketing things like before your launches and get people on your apps. And your engineering team knows that like, hey, we got two things here that we have to do, this one's higher on the roadmap, we're gonna do this one first.

Shared prioritization of those things is critical to drive alignment across an organization. So, if you are a two person startup, you should plan. If you're a one person startup, you should plan, that's non negotiable in my book. Like if I met a startup founder is like, hey, we don't plan here.

I'd be like, hey, I don't work here, right? Like I'm not gonna deal with that. Okay, that was another Brian Holt rant for you. Yeah, and this is actually probably a big one here is like, without some sort of plan, you tend to suffer very strongly from recency bias.

That like something that just happened to you, tends to be the most important to you or something that you just learned about tends to become really important to you, really quickly. I'm trynna think of an example of this, like, I don't know, maybe you went into a customer meeting with someone that you viewed as an important customer.

Like, hey, we want this feature and you're gonna come out of that meeting and for like a week, that's gonna be really important to you because you just heard it from somebody even if it wasn't the most important thing, right? So this kind of inoculates you against that kind of recency bias as like, hey, about a month ago, we sat down and we looked at all of this stuff, and this range like ninth or wasn't on our plan.

You can adjust the plan, it might be really important, but that requires you to be intentional, and being intentional is what this is all about.
>> Or in the case of a small company, CEO driven development tends to happen a lot.
>> You don't know anything about that.

>> You have a great idea, and so now it's like, we're at the stage we're at, it's like, I have to file it away as an idea and I have a list of tons of ideas. So, when it's time to plan there's lots of documentation to go off of versus in the early stages like, well, I think this is the most important thing, but that changes frequently versus the more long term.

>> Totally, and I love that because then it forces the CEO to go through the same process as everyone else is like. And it could be the best idea, and like it is the CEO's call to say like, hey, I actually do think this is really important, but it forces the CEO to be really intentional about what bets they're making rather than being like, I woke up today and I chose violence, so I'm gonna go burn down the roadmap, right?


Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now