So You Think “Agile” Methodologies Exempt You From Product Management

Yo, yo, yo!  Listen up, Enterprise Software Developers.  Yeah, you!

The news: The Cranky Product Manager knows that there is a certain percentage of you that doesn’t really care for her or her PM brethren.

And why?  Because the Cranky Product Manager is a pain in your ass. Because, YES, she totally cramps your style.

For one thing, the Cranky PM always prioritizes the boring projects higher than creating super-cool new products, or rewriting existing products from scratch. In other words, she wants you to FIX (not completely rewrite) Joe Idiot’s effed-up code so it can handle multiple users.  Instead of doing that WICKED COOL feature — the one you pet-named “Extreme E” — that 64-bit, Web 2.0-ish, open source, DRM-defeating wet dream (based on an SOA architecture and Ruby on Rails, of course). You know, the idea that occurred to you in between that mega-bong hit at Softwarehaus’s annual Geekapalooza party and 4am, when you started drunk dialing all your ex-girlfriends.

The other thing the Cranky PM does that is TOTALLY annoying is always say things like “we’re not seeing market demand for Extreme E.”  And whenever you try to shoot down her proposed projects as being stupid or irrelevant, she always starts reciting a list of customers who want it or need it, explains the new markets her beloved project would help DysfunctoSoft attack, and then she starts explaining use cases. Ugh.  If that wasn’t bad enough, if you persist, she’ll bore you to death with a frakin’ slideshow containing revenue projections for her stupid, dumb-ass project.

Doesn’t she realize that her projects are frakin’ BORING?  No technical challenge. And who wants to sully his hands fixing some other engineer’s code?  Disgusting — like sharing his toothbrush.  None for you, thank you. You need excitement in your life. You need to create something cool, something from scratch, something you can brag about or at least put on your resume.  Her project does not qualify.

But the thing that REALLY pisses you off about the Cranky Product Manager is when you try to shoot down a project with the “it’s technically impossible” bullet. This jujitsu move is supposed to be a winner, that’s-it, end-of-discussion type of pronouncement.  It works all the time, especially with the Marketing weenies. They all run and hide under their desks, shivering with fear.

But it doesn’t work with her. The Cranky Product Manager always says something like “Can you explain why not in more detail?  Because I’m not sure I understand how <Competitor X>, <Competitor Y> and <Related Software Product Z> can do something that is VERY similar.  How were THEY able to do it?” And then when you spew some crap about multi-threading, messaging protocol design patterns as a confuse-the-enemy tactic, she starts talking about possible approaches to prove you wrong.

Bitch.  Doesn’t she understand that it is technically impossible because her project is so BORING it is not technically possible for you to stay awake to work on it?

If only you could get rid of product management, life would be so much easier.  What do you need them for, anyway?  You talk to 2 or 3 customers (out of 2500) a year, and you know at least two of them would totally LOVE Extreme E.  And you pretty much know what the customers and market need, anyway, at least if they are SANE. Because it’s not that complicated. It’s OBVIOUS what the product needs to a SANE person.  Fortunately, you are sane.

And THEN, you read about this thing called “Agile Product Development.”  And you learn about Scrum and Extreme Programming, etc… And you think, “AHA!  At last! This is the solution! Who needs the Cranky Product Manager and her ilk when I have this awesome methodology?!?  Instead of having that old school, waterfall-worshiping PM prioritize me to death, I’m going to code blissfully for two weeks and then get feedback directly from the customers!”

Well, nice fantasy, Code Boy.  But the Cranky Product Manager says, Not. So. Fast.

Realize why the purest form of Scrum and other agile methods do not provide for a Product Manager: because they were designed for CUSTOM SOFTWARE DEVELOPMENT.  As in, there is just ONE customer.  This is typical of IT projects in big companies, or even consulting engagements.  And guess what, if there is, in fact, just ONE customer, then Hell Yeah, the Cranky Product Manager agrees with you.  Product Management is not needed.  Get a PROJECT manager (aka ScrumMaster) and a customer project owners (aka Product Owner) and go to town.

But what if you are at a commercial software vendor, where your software has to meet the needs of MANY customers, maybe thousands?  And where your software has to not just meet the needs of those many CURRENT customers, but also attract new customers in the future?  New customers whom you haven’t met yet. New customers in different industries who are solving problems you never even knew about.

Are you, Code Boy, going to show ALL the customers the result of your latest sprint cycle, every 2-4 weeks?  And are you going to gather up a good representative panel of all future customers and get their direct feedback every 2 weeks as well??  And how are you going to decide which customer has the final word?  Oh wait, that sounds like a lot of work, doesn’t it?  Maybe it isn’t even “technically possible.”  If you had to get the feedback from all those customers and prospective customers every 2 weeks, well you wouldn’t have any time to code. And neither would any of the other developers.

In fact, getting all this customer feedback sounds like a full-time job, as does identifying who the  prospective customers are and what they are likely to require.  And sifting through the contradictory wants and needs of such a wide customer population, well, it will be time consuming. You can’t do everything that every customer wants or thinks is vitally important.  You need to prioritize. You need to come up with the feature set that would make the company the most money.  But that kind of analysis needs extensive research and familiarity with the current (and future) customer base. It will take time. A lot of time.  Time you don’t have.

Then a solution occurs to you.  Maybe you should hire someone to be the “Voice of the Customer” for your Scrum team.

And when you do, the Cranky Product Manager or one of her colleagues would be glad to help you out. Call the role “Voice of the Customer”, “Product Manager,”  “Product Owner”, “My Enemy” or whatever… Whatever title floats your boat. They all mean same thing.

And then, the Cranky Product Manager (or someone just like her) will be back to cramping your style once again.

17 comments

  1. Mark Curphey

    Dear “Cranky PM”, You totally missed the point of my post and mis-quoted what I said so I figured I would take 5 mins from being a “code boy” (your phrase) and try and “buff your gruff”. For instance take a look at our SourceClear Influencers program.
    a href=”http://securitybuddha.com/2007/04/02/sourceclear-influencers-program/” rel=”nofollow”http://securitybuddha.com/2007/04/02/sourceclear-influencers-program//a

    We are working with some of the biggest banks in the world to understand their requirements and exactly how their business works. I used to be responsible for security for over 3,500 developers and let me tell you PM girl that I know what a mess it would be if you let the masses build what they want! My point was there is a balance between old school PM’ing (the stick) and modern development (the carrot). Building software is not a science and if you can find a balance between creativity and business you have a killer blend that is better than anything. nathan Myrvold the old MSFT CTO used to say tha a good develoepr can create 10,000 more software than an average one. I think its spot on. Our jobs is to bring out the best in develoeprs. Its like the music industry. A good artist without a good manager will produce good music that may not sell, a good manager alone is just plain lonely but the combination of the two is killer.

    OK time to go, I see an old school PM throwing monkey nuts at me….I guess thats a queue to write more code. Ooops thats a bannana skin …OMG thats not a nice sight ;-)

  2. bob corrigan

    Wow. I was going to leave a funny note for Cranky, but then I read Mark’s comment.

    SET SOAPBOX_MODE=ON

    Mark writes: “Our jobs (sic) is to bring out the best in develoeprs (sic).”

    Our job – collectively – is to build shareholder value by creating products that sell, and sell well, in the face of competitors who want to take food out of our children’s mouths and out of our pockets. Our job isn’t to provide a comfy milieu for exploration and experimentation. Not even Google does that.

    We work to bring out the best in each other so that we can get stuff done – on time, on quality, and on spec.

    I’ll agree that a good product manager plus a good development team is desirable and optimal – but at the end of the day, development must build what the market-facing agents of the company (the product manager) specify must be built. We can differ on “how” it can be built, but there is no discussion when it comes to “what”.

    And on the topic of programmer as “artist”…

    Writing specifications, setting schedules, tracking milestones, testing. . .these are all science. Even how a programmer documents and unit tests are structured, scientific activities. The “art” required to create a mental model of a problem and code it into being is an important aspect of programming. . .but so are stealing/borrowing code to avoid having to write new code.

    Creating products that sell doesn’t happen by mistake – it happens through the consistent application of measurable, reliable processes, all of which are enhanced by thoughtful, well-researched marketing that captures the imagination of the buyer better than the competitor’s marketing, and the activities of crafty salespeople who know how to sell.

    If you are personally inspired in the exercise of your job so much so that a transcendent event occurs and you manage to invent something manifestly new or elegant or blisteringly effective, that’s swell. But it better not make you late for your next deadline. That goes for all of us.

    SET SOAPBOX_MODE=OFF

  3. Ivan Chalif

    Cranky PM:

    I know your post is in the voice of your “fictional, snarky alter-ego”, but I think it hits on (intentionally?) the dynamic between many Product Managers and their Engineering teams. The tone of Mark’s comment on your post appears to illustrate that, but maybe he was just being snarky and alter-egoish, too.

    I like to believe that Product Management and Engineering can have a cooperative, egalitarian relationship, like marriages on TV. But the reality is that PM and ENGR are more like real-life marriages (or life-partnerships for those of us on the coasts). Despite our high ideals, we can too easily fall back into our traditional roles.

    Just like in a real relationship, there is love, such as when ENGR goes into overdrive to get an important release out the door on schedule even though it was late to start with. Sometimes the relationship seems focused on the conflict, especially around scope and usability.

    But it’s always a negotiation. PM asks for more features/bugs than they need and ENGR overestimates the effort/time it takes to deliver. It’s a dysfunctional marriage, but one that works for many companies…or does it?

    Ivan

  4. Don MacLennan

    Respect. Trust. That’s all it comes down to. If an engineering team respects and trusts product management, they will agree to be led by them in support of the greater good (revenue). C’mon, few of us create true inventions in defiance of what’s requested. It’s a matter of who we choose to listen to and influence us. Marketers talk about “grok’ing” a persona. That applies to presenting plans and requirements to engineering that speak to their persona, needs, value system. Ignore it at your peril….

  5. Ex-PM

    Absolutely hilarious post and one that rang very true for me Cranky. The icing on the cake was the comment extolling the “programmer as artist” meme, which I had hoped for a moment was an attempt at irony. It wasn’t.

    Keep up the excellent work.

  6. Pingback: Agile and Product Management
  7. Snipe

    Wow. Treating your engineers as if they’re always lying to you because your project is boring is a perfect way to create distrust and disrespect between depts. I work with someone like you, and they are absolutely toxic to my dev team, and that mentality spreads like cancer. Sad.

Post a comment

You may use the following HTML:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>