On a recent Agile Mentors podcast, I turned the tables on host Brian Milner and interviewed him about a resource he created for our community called the
definitive guide to the what and when of product owner responsibilities.
The link to download the free PDF guide should be appearing just above my head as I speak, and it's also in the description.
In this video, I want to give you a sneak peek into that interview.
We'll start at the moment when I asked Brian to tell me more about one of the activities he recommends product owners do about every quarter,
Create a Product Goal.
I want to talk about your quarterly items on here.
And you've got a couple, let me just kind of read some of these here, so you got establish a product goal.
That's a relatively new thing in Scrum.
I mean, I still think of 2020 as relatively knew, but as a old timer with Scum, product goals is one of the newer enhancements.
You've got doing the story writing workshop, so you're supporting what you said there.
Talk to me about the product goal here.
Yeah.
So I feel silly talking to Mike Cohen about what a product is.
Product goals are just that, they're a milestone, right?
And that's typically the way I talk about this in class is to say, especially when you're starting something new, you may not know everything that you
are going to do, but you know the next big thing that need to accomplish.
You know, the big mile marker that your going hit in the life of your product.
And that's what we want to establish with a product goal.
Something's going to take longer than a sprint, multiple sprints to do.
I've got this in the quarterly section, and that kind of how we tend to talk about it a lot here at Mountain Goat.
But even in class, we'll even say quarterly-ish, you know?
It's the bigger than the sprint section.
Right.
Bigger than sprint.
And sometimes it'll be longer.
Sometimes it will be shorter.
That's okay.
You just want to have that big thing that the team can keep their eyes on and kind of know, you know.
Here's, You got a sprint goal that tells us why what we're doing in this sprint is important and how my small task feeds into that.
And you've got this product goal to say, how does the sprints work?
fit into this bigger picture of what we're trying to do.
So you're making those connections consciously for the developers so that they are not just, hey, here's a laundry list of stuff to,
but here is the objective we are trying accomplish.
Yep.
I think it's important to have something that's out there bigger than a sprint.
A sprint is just, it just kind of sub-optimizing, right?
I'm thinking about if you're climbing a mountain and a sprints is like, what's the highest thing I see?
And just always walk into the thing you see.
Meanwhile, those are all false summits.
The real summit is, you know, behind some valley, but you don't see it because you set out that bigger goal.
And I like how you talked about it quarterly because if the goal's too big, if it is too far out, there, we're not going to feel very motivated.
about it.
I had this, the wackest example of this.
Hope the guy's not listening.
Actually, I hope he is.
But he told me he was on a project with the large particle collider.
And he said his whole project won't be due for 40 years.
I mean, I don't get it, but it's like they've got to run like 40 years worth of data before it is like totally done.
And I just picture myself showing up for work on a 40-year project, right?
I know you, you're going to be reading Dallas Cowboys news for the first 35 years, sports news.
That's a forty- year project too.
You're not going to take it serious for 35 years.
Then you're going wake up and go, oh, the deadline's only five years away.
I better get to work on this.
And then what I would do is realize, wow, I'll be retired after 40. Right.
Exactly.
So anyway, I've been silly, but I mean, you're on a project with a 40-year deadline.
How do you say motivated, right?
And I think three months is a really good time where I can see a bigger impact than a sprint.
But it's not so far that that student syndrome kicks in, and I feel, oh, don't really have to worry about it.
Let's go to a long lunch.
We'll get to work on it tomorrow, so I do like the quarter-ish approach there.
We greatly exaggerated a project length to make a point, and I can never resist a dig at Brian's favorite Dallas Cowboys team.
But I do want you to notice that I said quarterish.
I call this level of planning milestone planning versus other terms like release or quarterly planning.
And I talk about all of that and more in my Agile Planning Layers video if you'd like to know more.
In the meantime, I'm curious, how do you handle product goals?
Do you set them?
do find them useful?
Are they something you do regularly?
Let me know in the comments.