This morning I woke up to this tweet from Jeff Patton:

I found this interesting on a number levels. First, it was a gimme punchline at a product conference. Well played! I’ve heard plenty of gimme PM jokes at other conferences, so it sort of comes with the conference territory. Not a big deal.

Second, I found it laced with some juicy (likely unintentional) irony. I’m pretty up on the product community, and I’ve polled people during my talks, so I feel fairly confident to point out some likely patterns and quotes from a good chunk of the 1,400 people in attendance during their day to day work:

• “We need to ship more quickly”
• “How many resources do I have at my disposal to build this stuff?”
• “We have to move on to the next feature so [insert reason here]”
• “We can’t afford to work down that technical debt! You’re guessing it will keep us from slowing down. I need data”
• “I need an estimate, please, so I can [ insert reason here ]”
• “We really need to get an MVP out there now! And then we’ll, um, come back to it at some point in the future after we’ve done [other things]”
• How infrequently product managers actually focus on customer outcomes vs. feature delivery
• How often PMs shoot for 100% utilization (aka team Tetris), which sets up teams for catastrophic collapse when something doesn’t go right, which in turn impacts the customer
• The conference is called Mind The Product, not Mind The Customer. Sure, we still purchase products. But in the software world we are increasingly renting services (delivered through various, evolving products / touch-points) that yield outcomes. In my experience, PMs often have primary allegiance to this nebulous “product”, not customers, users, or outcomes No wonder people use points and velocity! No wonder some forward thinkers in the Agile community are arguing that estimates shouldn’t be necessary (see #noestimates). No wonder UX is injecting some life into product management!

I’m pretty sure this wasn’t what the speaker was thinking. Maybe they were selling something else. So I’ll just let it blow over as a good joke.

Anyway, what I was struck most by was Jeff’s term Agile Brand Problem (#agilebrandproblem). The branding of Agile, and all the various ways people are trying to capitalize on that brand … yeah, there’s your problem.

I’ve attended big Agile conferences. And yes, the busy tracks are filled with people buying into the Agile solution. Let’s DO AGILE™ THE BRAND. It makes it it an easy target for conference jokes. The UX and Product tracks can be pretty sparse, and PO focused talks tend to bring out the Agile Coaches trying desperately to help their POs do their job.

Heck, even Agilists crack jokes about Agile (see Joshua Kerievsky and his wonderful Modern Agile work, and read up on his great jokes at Agile 2016). I like Josh’s approach because he’s not being dogmatic, and evolving like Agile suggests you evolve.

Agile has become an umbrella term for so many practices, methodologies, frames, principles, stuff to buy, people to hire, etc. that it’s bewildering to the user (forget branding for a moment). But I think this is natural as things like Agile evolve. They start focused and principle based. Then welcome all sorts of experimentation and exploitation and grow a chest of offshoots and interpretations. And then sort of fold in on themselves under the weight. Layer that with two (and now coming on three) generations of consultants looking for their Agile Angle, and you’ll develop a self-inflicted branding problem.

At this point Lean is sort of past that. It is sufficiently “old” that you can use it at will, anywhere, without too much of the baggage. Once people got over the six-sigma associations and connecting it primarily with manufacturing, it became a good nondescript gimme that could be tacked on to anything for good effect. Are people trying to brand Lean as just Lean™? Let me know.

Anyway. Being a punchline is nothing new for Agile, Product Managers, Engineers, UX, Project Managers, etc. It’s easy to have a laugh. But it doesn’t really move forward the craft of product development. Rah rah conferences for the functional skillsets are good for keeping the hope alive, sharing information, and having some beers with likeminded individuals. Real work is required to figure out how we can work together.