It’s PdM!!!

Does this sound familiar?

“What do you do?”

“I’m a Product Manager.”

“Oh, cool. My neighbor is a Project Manager too.”

“No, not a Project Manager – I’m a Prah-DUCT Manager.”

“Oh… Is that, like, the same thing as a Program Manager too?”

“THUD! THUD! THUD!” <– The sound of your head pounding against a brick wall.

What’s worse is that Product Managers have traditionally used the PM abbreviation. And that almost always gets confused with Project and Program Managers who also use that same abbreviation (and outnumber Product Managers by at least 100-fold).

So here’s what I’ve started to use instead:

PdM

I’ve been using that for a little while and when I used PdM in my presentation at ProductCamp MN recently, a lot of people said they really liked that abbreviation and they’re going to start using it too. Why? Because everyone was nodding when I explained how annoying it is to constantly have people mix up job titles.

This post is my blatant attempt to brainwash, errr, convince more people to use it too.

PdM, PdM, PdM, PdM, PdM, PdM, PdM, PdM, PdM, PdM, PdM, PdM, PdM, PdM, PdM, PdM… just keep repeating it until you attain enlightenment.

July 14, 2014September 12, 2014

Agile Marketing and the Beauty of Failing Fast

Now we’ve all heard the mantra “fail fast, learn fast” and it sounds quite logical – the more you try, the more you learn, and people can certainly learn from both success and failure. In fact, if you learn from failure such that you don’t repeat it, it doesn’t really feel like a “failure” anymore. At least not in the embarrassing gut-punched way we’ve been conditioned to traditionally feel about failure. Still, to many people, that mantra seems like a simple platitude that they can never put into practice. If they fail, they’re sure someone is going to punish them for it.

Most Agile teams start out using the Scrum process. And Scrum gets teams working on fixed-length sprints, typically set between 2 and 4 weeks. Usually, when people learn about sprints, they have a problem believing that can break down their work into meaningful deliverables that can be delivered in such a short time. So we’ll do some exercises to show you how it can be done, and people will start to believe it’s possible. In one of my recent Agile coaching engagements, we went beyond simply breaking work down into chunks and got to the incredible “ah-ha” moment people have when they realize that “fail fast, learn fast” can become reality.

I don’t get to follow-up and coach everyone who attends my training classes. It’s unfortunate because when I get to spend time coaching teams, and they’re confronted with jumping in and really trying this, there’s often a moment of hesitation. It’s one thing to be bold in a training class. It’s another thing to put your professional reputation on the line back at the office when you’re trying something radically different. And in that moment, people are able to truly understand the value of the following:

“It’s only 2 weeks. And then you can try again.”

Boom. You can try anything. And if it doesn’t work as expected, we’ll look at what happened, discuss it, and we’ll do better the next 2 weeks. Sure, not everyone uses 2 week sprints – I’m just using that as an example. But whatever your sprint length, this is something we’ll do every sprint. There are non-Agile teams that will easily burn 2 weeks just planning to try something new. And then they won’t do it because they couldn’t get to 99.99999% confidence that it will work. An Agile team will just do it. In 2 weeks they’ll know more and have more experience no matter the outcome. Isn’t that cool?

Another nice thing about getting to coach teams: I get to spend some time with the managers above the Agile team. And it’s not hard to have a short and meaningful conversation that will set their expectations appropriately for what’s about to happen. In short, they’re going to see some people try something new, and things will get messy for a while and then start getting better at a rapid rate. Why is this so important? Well, obviously, it’s nice if upper-management doesn’t overreact to “failure” and wind up demoralizing or paralyzing the team. What’s less obvious is that it’s also very important that management lets failure happen early-on in Agile adoption.

Why? Because failing early-on will give a team opportunities to self-identify problems, figure out how to solve them and improve without relying on outside help such as management intervention. And the sooner teams get comfortable making mistakes, acknowledging them, and analyzing them, then the sooner they can start making rapid improvements.

Conversely, I would be really worried about any Agile team that doesn’t experience any problems or “failure” early-on. Such a team won’t develop the try-inspect-adapt skills necessary to truly become a high-performing team. So when teams truly adopt Agile, failing fast and learning fast isn’t just possible, it becomes essential.

Does that sound like the environment you work in? Or does it sound like some far-off dream? Take my Agile Marketing Boot Camp class and learn how to make it a reality.

July 7, 2014September 12, 2014

Agile Marketing and the Five Dysfunctions of a Team – Inattention to Results

In my last post, I discussed how the framework from “The Five Dysfunctions of a Team: A Leadership Fable” by Patrick Lencioni can illustrate how and why adopting Agile Marketing and the scrum process leads to success. And I drilled-down on the fourth dysfunction: avoidance of accountability.

Picking up from that point, let’s look at the fifth and final dysfunction: inattention to results. This stems directly from the avoidance of accountability. The connection may not be obvious to many, so I’ll paint a more detailed picture.

Imagine a team that only half-heartedly agrees to vague and ambiguous goals. We noted last time that people will find ways to avoid being accountable to those vague goals. So if you ask them what the team has accomplished, what do they focus on? They focus on their own accomplishments and ignore the team’s lack of results.

“Hey, look at all the new product graphics I produced. Yeah, the campaign is way behind schedule, but I’m knocking my stuff out of the park!”

When team members operate in that mode, they only see their participation as a means to achieve personal recognition. After all, they don’t believe the team will succeed, so they figure they need to at least accomplish some valuable “CYA work” so they don’t get blamed for the inevitable crash and burn.

In high-performing teams, everyone on the team is focused first and foremost on helping the team accomplish its goals. And just to emphasize, we’re talking about the team’s goals, not the goals of individual team members – those are secondary. Like a baseball player who agrees to bunt even though he’s close to setting a new personal HR record. Or like a basketball player who agrees to foul-out on defense even though she’s one assist away from a triple-double.

So how does Agile Marketing and Scrum deal with this dysfunction?

Agile Marketers value customer-focused collaboration over silos and hierarchy

The Agile Marketing Manifesto hits this nail on the head. We care first and foremost about working together to deliver something for customers, not to puff-up our own accomplishments and job titles. With truly customer-focused collaboration, members of high-performing teams don’t care about each others’ job titles – they care about how everyone can work together for the customer. You may be a Director of Social Media Marketing, but if you’re the only person with time to review and edit a brochure that has to go out to the printers ASAP and you have the skills to do it, then you go ahead and do it.

Scrum only credits the team’s work, not individual efforts

This is related to what I mentioned in my previous post, where I mentioned that Scrum only lets the team get credit for work that’s “done”. That time I was focusing on the word “done”, and this time I’m focusing on the word “team”. In fact, the one occasion when the team is truly trying to show-off its work to everyone, the Sprint Review meeting, only highlights what the team delivered. There’s no need to mention what individuals contributed, who was busiest, who worked on the “hardest” stuff, etc. In short, there’s no focus on individuals at all.

If that sounds kind of bleak, don’t worry. People receive recognition for doing good work, it’s just usually from their fellow teammates. Also, if the team feels it’s appropriate, they can call-out individual members to the rest of the organization for recognition, but it’s the exception, not the rule.

Once again, I could probably go on and on about this dysfunction and how Agile Marketing philosophy and scrum do a great job of beating it to death. Hopefully you get the idea. And if you recognize this dysfunction, you see how adopting Agile Marketing and the scrum process will lead to success. Which brings us to the end of this particular topic – we’ve covered the fifth of the five dysfunctions. And if you haven’t already done so, if you enjoyed this topic at all, I highly recommend that you read “The Five Dysfunctions of a Team: A Leadership Fable” by Patrick Lencioni. It’s short, engaging, and will give you a wealth of insights beyond what was covered here.