The Clever PM

Tips, tricks, and hacks that help you to be a better, more clever, Product Manager.

Managing Technical Debt

by

It’s one of the more frustrating parts of being a software Product Manager – you inherit a product that’s been around for awhile, and every time you want to start a new project to change and improve what’s already there, some nasty little issue crops up and takes the spotlight.  Maybe the platform was never really designed to scale, maybe some customer is doing something outside the original intent of the product, or maybe the technology is just old and starting to crumble around the edges.

Regardless of the specifics, inevitably the primary cause of these issues is a mountain of technical debt that’s been built up by the teams working on the product over the course of its lifecycle — the shortcuts taken in the name of getting product shipped, the design corners skimmed because it was seen as an “edge case” three years ago, or even the architectural limits imposed by budget or resource constraints.

Regardless, once you realize what’s causing these issues, you need a plan to attack and mitigate the harm that these limitations are causing you — and that’s where you good old friend, The Clever PM, has a few tricks up his sleeve…

[Read more…]

Breaking Down the Agile Manifesto — Collaboration & Responding to Change

by

Earlier this week, I discussed the common misunderstandings related to the first two statements made in the Agile Manifesto — Individuals and Interactions over Processes and Tools, and Working Software over Comprehensive Documentation.  In that discussion, I focused on how important it is to remember that the Agile Manifesto itself was written largely in response to traditional “Waterfall” methods of product design and development.  There was never any intent on the part of those who created the Manifesto to shift the focus entirely to the “left side” of the spectrum — but rather to propose a spectrum that was more responsive to change and that could accelerate the delivery of value to interested stakeholders.  While these original concepts have brought forth many different specific approaches, the fundamental purpose of the Manifesto remains important in understanding when, where, and how to implement such practices, and why you should do so.

[Read more…]

“Agile” Does Not Mean “Without a Plan”

by

A very common, and very dangerous misconception about Agile development — whether you’re using Kanban, Scrum, XP, DevOps, or any other flavor of the week — is that it “requires” or “expects” that you can operate quickly, efficiently, and effectively without necessarily having an overall strategic plan.

Bullshit.

There certainly are teams and companies who waste their valuable time and energy moving forward through iteration after iteration without following a long-term plan.  And some of these teams can be successful in delivering in-the-moment, valuable solutions to customer problems.  And these teams can sometimes continue to be successful at this for a short time, until they realize that an entire organization has grown up around the product, and there are impacts to this lack of planning that span multiple groups.

Agile does not mean you don’t have a plan.  It means that you have a plan that’s flexible enough to accommodate valuable and important shifts in the plan’s underlying assumptions. [Read more…]

Be careful what you put on your backlog…

by

We’ve all had the conversation…you’re working at your desk, just finished a call with a customer or prospect, and that random person comes around and taps you on the shoulder…

“Where’s my feature?”

“Huh?  What feature?”

“You know — the feature you talked about last week.”

“Oh, that one!  It’s on the backlog.”

“I know, so when is it coming out?”

“Well, it’s…on the backlog.”

“Yes, I know.  So I told our biggest customer they’d have it next month, that’s cool, right? It’s on the backlog, after all!”

“YOU DID WHAT!?!?”

…and so it goes, and you wind up randomizing the teams to deliver what’s been promised, tossing out a good chunk of strategic work that you’d planned on doing.

[Read more…]

Five Ways to Make Your Meetings Not Suck

by

We’ve all been there – sitting in our chairs around a table while various people opine about some topic that may or may not be related at all to the original reason you all got together, staring at the clock, hoping and wishing and praying that the pain will end soon so that you can get back to work and back to doing something productive with your time.

Sound like a meeting to you?  It doesn’t need to.  In fact, there are a few very small things that you can do that can help ensure that your meetings don’t wind up being a death march that nobody in the room cares about.

[Read more…]

Accept Ambiguity — Then Drive it Out

by

I’ve worked in a lot of companies where the direction or vision that we were shooting for was in question or even in transition.  And, when that happens, the natural result is a lot of chaos and uncertainty.  I recall in one very contentious meeting regarding a new direction one company was taking, a very smart man in the room spoke up and said these words:

“We have to embrace ambiguity and drive it out where we can.”

This has, in many ways, become a bit of a mantra for me, as the whole concept of Agile development has built in to it this very concept.  You define what you know is important, when you know that it’s important, and you move forward.  This really is simply another way of rephrasing the common aphorism of “Fail Fast, Fail Early, and Fail Often.”

[Read more…]