Yana Welinder looks at different areas where PMs need to make sure we don’t let process get in the way of good product sense in her post Product Over Process. On the importance of making sure specs aren’t “set in stone”:

Focusing on product over process during the execution stage means constantly evaluating whether the product does what it’s intended to do. This requires PMs to see the product through the users’ eyes and, more importantly, to figure out ways to do user testing even when it’s hard. It also means that the build process needs to be iterative. If you discover that the product doesn’t have the impact you’d expected, you should change it before it reaches the users — even if that means delaying launch.

Sometimes we can get overly reliant on our frameworks and methodologies to help us make sense of our products and our worlds. Melissa Perri shares some excellent advice about the dangers of this in The Science of Product Management:

These motions, these frameworks, they were made to teach you to think. They were a means to an end, not the end goal itself. They are training wheels. How can they help you understand your work better, so you can DO your work better?

The point of Product Management is not to put things in JIRA in a specific format, use a specific framework for writing out goals, or make sure your developers have full backlogs. The point of Product Management is to create valuable products that customers love.

That’s where the real science of Product Management comes in. The science is about understanding the patterns to building products that people love from a strategy perspective.

I shared some similar thoughts on Twitter in the context of this new-ish push for “product thinking”:

I’m in a spot where I feel we’re trying too hard to make “product thinking” a thing with fancy words and lofty concepts. Like we have some kind of inferiority complex with other disciplines we’re trying to make up for. Talk to customers, understand the market and the business, and experiment until you get it right. That’s pretty much it, right? How you do that looks different in every org, but that’s where the art comes in. You can’t codify product management.

Phil Johnson has some good advice for product managers in The Goldilocks of Process:

Blindly following process is a project-killer—not just in terms of efficiency. The real poison is the mentality: in these cases process became a crutch to lean on, with these individuals no longer thinking critically about their tasks. In many ways, the process became the job, where process really should be what enables the job. This rings doubly true in the software development world.

On any team, you want your process like you want your porridge: just right. If you have too little, the team may not know what the priorities are, or who is responsible for the next step. Too much, and your team will end up doing more process than actual work. The right strategy should be flexible enough to fill in the cracks of the team’s blind spots while enhancing their strengths. It’s up to the PM to find that sweet spot.

This also reminds me of Michael Lopp’s essay The Process Myth, and these words that will forever be etched in my brain:

Engineers don’t hate process. They hate process that can’t defend itself.

Emily Tate’s article on the best ways to prioritize bugs comes at the problem with a Scrum lens, but many of the points are more broadly applicable to product management. I particularly like her assertion that there’s nothing “special” about bugs, and as such they should be prioritized just like any other idea/feature:

As product managers, we should always manage our backlog so that the next most important thing is at the top of the list. Many times, the bug you would work on is less important than other things on your backlog. By working on the lower priority bug, you are deferring the more important work that can help you reach your strategic goals.

The flip side of this is also true: sometimes the next most important thing may be five or six bugs that really need to be fixed before adding yet another feature on top of a fragile platform. If you live in a world of separate queues or say you’ll always devote 20% of the team’s time to bugs, you actually lose the opportunity to say “this week, we are squashing these bugs that have been plaguing us before we do another thing.” In reality, you will likely have a mix of bugs and features in your backlog, but the most important thing is that you prioritize strategically and intentionally, not letting a false constraint determine what the ratio of your backlog looks like.

Product Management podcasts are a bit hit and miss, but this week there were two discussions that I found really interesting and useful.

First, on the Product Science Podcast, an interview with Teresa Torres on continuous product discovery:

Teresa Torres is a product discovery coach and the author of the Product Talk Blog. She spends most of her time coaching cross-functional product teams on how to adopt continuous discovery practices. On this episode of the Product Science Podcast, we get into how you can refine your product discovery practices.

And on the Product Experience Podcast, Tim Herbig discusses how to be an effective product leader when you don’t have “official” power:

Tim Herbig has made many mistakes (who hasn’t?). Fortunately for us, Tim not only owns up to his mistakes, he’s written a book to help the rest of us avoid making the same ones. We’ve all had issues with how to work best – not only within our individual teams, but with the rest of the organisation as well. In our conversation, he shares some simple and practical methods to diagnose when you have a problem and how to solve it.

Tim references Teresa’s work in his conversation, so the two episodes are really complementary as well, which is a nice bonus. Tim’s agile peer canvas to foster empathy within a team is also really interesting and worth looking into.

My favorite article of the week is one on change management, which, yes, I know how that sounds. Like you (probably), I hated the phrase “change management”. But in her article How to begin the invisible work of change management Cate Huston defines it as “taking teams that are struggling and helping them focus, align, and start delivering at their potential”, so now I finally understand what it is and I don’t hate the phrase any more.

Anyway, the entire article is excellent. If you’re interested in managing teams at all, you have to read this one. Here she is on diagnosing problems within teams:

Sometimes people look at teams and diagnose problems as an absence of process rather than an absence of values, or cohesion, or delivery.

And on the problem with trying to implement a process without understanding cultural context:

When teams struggle to do retrospectives, often the problem isn’t the lack of retrospective, but the lack of psychological safety that a productive retrospective requires. That might be due to lack of trust or cohesion on the team, or other problems that have not been addressed. You need to address those things first, otherwise the retrospectives will not be productive, and the process will be for naught.

Jeff Gothelf addresses a very common problem in his post on the perils of fixed time, fixed scope projects. This point on what it means when you “launch” a product is so important:

Deadlines imply that if we don’t get the product right on the day we launch, we’re doomed. This is an antiquated point of view. Launching publicly simply begins the process of learning how right (or wrong) our assumptions were. It is the start of a continuous conversation with your target audience and the fastest way to learn how to optimise your system. The sooner you can get something to market, the sooner you can make the system better. By the time you get to your deadline, your product should have been in market for multiple cycles.

This is a good summary of the “healthy pressure” we strive towards on our team as well:

While working without the pressure of explicit deadlines can feel liberating, it also increases the chance of distraction. Deadlines help us stay focused, aligned and driven – and can be used to keep project scope in check.

Here’s a pragmatic approach to roadmaps that I can get behind. Escape From the Feature Roadmap to Outcome-driven Development:

You’re exploring new lands. You know where you want to get to — that’s your outcome — but there’s no established route to get there. So you’ll probably set out, and if you’re measuring yourself correctly and you’ve got good feedback loops in place, you’ll be able to course correct and quickly iterate towards your outcome. But you could only draw the complete roadmap with hindsight.

So it’s time to take a new approach: forget the features and focus on the outcomes.

Roadmaps that include a bunch of features are doomed to fail. Instead, say “here’s the problem we want to solve in this iteration.” That allows you to be flexible on scope, and ship solutions to customers quickly.