The Cranky Product Manager is a little busy this week, seeing as she is now also doing the work of 4 people who were laid off.  

So, she's going to be a laze and reprint an old article from exactly 2 years ago: Scrum This!  (see original post with the comments here).

Request: Don't be an a-hole.  Last time the Cranky PM published this article, she got scary, threatening, sexist, and pornographic emails and comments from the Agilista Henchmen - they were all freaked out she dared to say anything bad about their pet methodology.  

----------------------------------

Hey You! Mr. Release Manager!

The Cranky Product Manager appreciates that you're trying to do this Agile Scrum thing by the book. And that it is hard for you. Because before this Agile tsunami came crashing down you mainly just tracked the progression of different release documents (Is the PRD done? Check. Is the Functional Spec done? Check. Is the Design Doc done? Check.)

Ok, that's not fair of the Cranky Product Manager. You did more than that. You also ran hurried release meetings once a week that tried to bury issues instead of surface them (OK everyone, here's the status of all the documents. Anyone have any issues? None? OK, let's adjourn.) You also organized two or three Fantasy Cricket leagues plus your wedding during working hours, and boy it all took a lot of time.

But now, in the Scrum era, things are different.  It' s not easy. You once had a private office, but you now spend the bulk of your day tethered to a communal table in a stifling hot "War Room," inhaling the body odor of The Veteran, trying to tune-out the grandstanding arguments between two nimrod Hotshots ("My idea is the most elegant...", "No it's not. It's trivial. You'd have to refactor it immediately."), and listening to the documentation writer bitch and moan that she can't write the doc by Friday if the product keeps changing every hour. It's really hard to organize fantasy leagues or surf the web with so little privacy. Plus the porn shui of the War Room is completely off.

So it sucks to be you, Mr. Release Manager, and the CPM is sorry for you.

But just because you are stuck in that War Room doesn't mean the Cranky Product Manager should have to join you. You argue that in Scrum the product manager is the same as the Product Owner, and therefore the Cranky Product Manager needs to be constantly available to the team in order to make on-the-spot decisions within minutes of the asking.  Ergo, you demand the Cranky Product Manager sit in that sticky-note-encrusted, windowless tomb with you all damn day.

Uh, no way.  Not gonna happen.

Why not? Because the Cranky Product Manager needs to be the Voice of the Customer and the Voice of the Market.  How is she to do that without actually VISITING some customers and prospects?  And VISITING means that she actually needs to leave the office, hop on airplanes, and fly far, far away.  She cannot answer questions from the dev team within 5 minutes if she's on a plane, or in a meeting, or on the phone with a customer.  Not that the CPM wouldn't LOVE to hear debates about Iron Man or whether that Star Wars cartoon is "canon" or not --  all day, every day, for hours on end. Who wouldn't?

And your response, Mr. Release Manager?  You argued that perhaps the Cranky Product Manager should not visit so many customers and should spend more time in the War Room.

Anyone else see the irony? The Voice of the Customer should have less interaction with customers?  All so she can make on-the-spot customer-facing decisions more quickly?

TRUST that the Cranky Product Manager will have more to say about this Fatal Flaw of Scrum in an upcoming post... She feels a HUGE rant coming on.

Related Posts: So You Think "Agile" Methodologies Exempt You From Product Management

As you might know from previous posts, the Cranky Product Manager is pretty neutral on Agile / Scrum.

Yes, Agile is trendy.  Everyone is doing it.  Some consultancies out there have tied their entire brand to the Agile concept (digression – how smart is this when the inevitable backlash against something so over-hyped will inevitably occur?).

And don’t get the Cranky PM wrong, Agile/Scrum can help greatly with many types of product development problems.  It’s good. It can be fun. But Agile/Scrum is not perfect.  It has its problems too.  Some of which have been elucidated more eloquently by others.

Well, the Cranky Product Manager is going out on a limb and declaring that:

The BIGGEST problem with Agile/Scrum is its crazy, insulting, demeaning, and threatening lunatic fringe.

Yep, these zealots — and YES, they are TRUE frakin’ Drink-the-Kool-Aid, Jihadist ZEALOTS — believe that Agile is The One True Way to build a product.  And that if you do anything else, well, you’re a frakin’ moron who must be silenced.  You “just don’t get it,” “you must be doing it wrong”, etc.

And if a non-believer DARES publish something with less than ridiculous adoration for the Agile concept, well they get freakin’ flogged in a over-reacting, vitriolic, personalized fashion.

At best, the non-believer gets publicly berated as stupid/really naive by the principal of a product management consultancy.

At worst, the non-believer gets called a c-word who should “shut the f#$# up” and “watch out,” topped off with a “I’ll get YOU into some very Agile positions, you effing  b@#$%,” for good measure.

Lovely.

Yep. Each of the Cranky Product Manager’s three posts on Agile/Scrum received an amazing amount of hyper-nasty emails and comments, some of which were downright threatening.  The Cranky Product Manager has learned to scan and promptly dump these abusive comments and emails directly into the garbage before she has time to properly comprehend them.  Because otherwise, the Cranky Product Manager might become too afraid to leave her house (remember Kathy Sierra, anyone?  Fortunately, the Cranky Product Manager writes anonymously).

The Cranky Product Manager has had this post in draft form for months because she’s afraid of unleashing the wrath of the Agile Jihadists once more.  But eff it.  She won’t be intimidated by those f@#%s any longer.  Seeing the attack on Adam Bullied (even though it was relatively minor) made her want to speak up.

Anyway, the Cranky Product Manager does not know how to wrap this post up, except to call upon the more moderate elements of the Agile community to

1. Stop getting so defensive with people who don’t think Agile is the second coming, and
2. Do something about your lunatics.

Please.  And thank you.

Related Posts:

• Heresy Against the Church of Agile Software Development
• Scrum This
• So You Think Agile Methodologies Exempt You From Product Management?

Today we have a glorious guest post from Scott Sehlhorst, product management consultant extraordinaire and author of the tasty-good Tyner Blain blog.

Scott may be genetically incapable of true crankiness.  One of his co-workers once accused him of having excess serotonin levels.  And he’s never had a headache.  Nor has his dad or his grandfather. Scott once parachuted in to help out late in an “agile” project.  It inspired the following exam.  After you take the quiz, you’ll understand why the Cranky Product Manager is publishing it.

The Cranky Test for Agile Product Managers

One of the challenges that comes from the growing popularity of agile development is that sometimes the people racing to adopt the methodology out-pace the clue-train of understanding. Some teams say “Agile” without knowing what that really means. Sometimes part of the organization knows how to be agile, and other parts don’t. That can be a source of frustration for everyone. If you’re a product manager, working with an Agile (or “agile”) team, you might just get cranky. Being sensitive and pragmatic and realistic, just how cranky can you justifiably be?

Here’s a quick multiple choice test, for product managers joining an Agile team mid-flight.

Take the test to see just how cranky you can (justifiably) be. Record all your answers without reading ahead.

1. In the first daily stand-up meeting you attend you heard (pick one):
   
   1. Each member of the implementation team say what he did yesterday, what he will do today, and what if any roadblocks he faces.
   2. A user-rep / proxy from the business says “I have a couple UATs I’d like to add to that ‘send a gift’ story you’re doing this sprint.
   3. The architect proclaims that all stories must be delivered two weeks prior to each sprint, after which point, the business is not allowed to change them — only development can change them.
2. You sit down with the key stakeholders to prioritize the target users / market(s) / market segments, and you’re told (pick one):
   1. Here’s the persona representing our most profitable customers, and the one representing the bulk of our customers.
   2. We are focused on mom and pop SMB retailers. We’ll define the other market segments later. Remember:  Mom. And. Pop.
   3. It’s the Internet — for all we know, our customers are dogs. We suspect most of them speak English. At least some.
3. You reviewed the stories to find (pick one):
   1. Each story is on a yellow post-it on the whiteboard in the war room, with a pink post-it nearby including some ‘verify’ statements.
   2. All the stories that were just estimated for this sprint are sorted into columns based on size in points (and the team uses fibonacci for the values).
   3. All ‘stories’ are managed in a requirements repository, from which MS-Word docs are generated, zipped up, and emailed to the development team, who modify the word documents, and store them in subversion in a directory structure reflecting if they were accepted or rejected (for lack of clarity).
4. When you asked about testing, you were told (pick one):
   1. We automate our unit tests and incorporate into the daily build process – we won’t promote to the trunk with bugs.
   2. Do you mean testing what we wrote, or testing by users to make sure we wrote the right stuff? We did both.
   3. The person who manually tested was working against a different version of the product than development.
5. When you asked what the user feedback so far has been like (pick one):
   1. Very positive from a couple people in our target demographic – and we uncovered some great new ideas.
   2. Rough. The stakeholders let us know that they met last week, and completely changed their strategic goals – but we’re adapting now.
   3. Users? Look at the time…
6. You corner the QA lead for the project to talk about performance testing and (pick one):
   1. She shows you the logs, and how they identify which stories get the most action, and how long they take. Then she circles “the bad one” and shares that it just got prioritized into the current sprint.
   2. She takes you to the break room, and shows you the trend charts on the wall, for average response-times for the top ten stories (in importance to the key persona) – pointing out which times are above “ok” and which ones are below “ok.” Then she starts to ask you about scalability.
   3. She suggests that if you sit down with a stopwatch in front of the test server, next week, after the next build, you can probably measure performance, if the build doesn’t crash all the time like the current build.
7. You hear a rumor that the cadence of releases is not working very well. When you investigate, you find (pick one):
   1. Weekly releases are too frequent for the users to review, and they are asking that we move to biweekly releases.
   2. Monthly releases are too far apart, and now that the automated build process is done, developers want to move to biweekly releases.
   3. Our first release is two months away. How can anyone be complaining about the frequency of releases? No one has seen it yet.
8. The management team is completely replaced when a new CEO cleans house. When you meet with the new CEO to review project status, you share (pick one):
   1. The burndown charts and expected “completion” of today’s version of “the project vision.”
   2. The sequence of deployment of tangible, valuable capabilities, combined with the number of users at each release.
   3. A hand-waving explanation of why nothing can be deployed after 6 months, and how “everything” is 80% complete.

CALCULATE YOUR SCORE

• For every (a) answer, give yourself 0 points.
• For every (b) answer, give yourself 0 points.
• For every (c) answer, give yourself 5 points.
• Give yourself 1 point for every time you’ve been hit with the recent Facebook reincarnation of the 25-things meme.

Add up the points. This will tell you, on a scale from 1 to 40, just how Cranky you can justifiably be.  If you hit 40, make sure you sign up to write a guest post.  The Cranky Product Manager needs your rantings and ravings to be put to good use!

Related Posts

• Heresy Against the Church of Agile Software Development
• Scrum This
• So You Think “Agile” Methodologies Exempt You From Product Management

If you’ve been reading this blog for a while, you know the Cranky Product Manager thinks technology analysts (also known as Forest Rangers and Gardeners on this here blog) are GENERALLY (note 1) coin-operated ho-bags.  (See here and here.)

So you can appreciate the Cranky Product Manager’s consternation when confronted with Forrester’s Agile survey.  It’s about the effect of Agile development on the structure and operations of tech companies.

The Cranky Product Manager is very interested in this topic.  Very.

So, as much as this request makes the Cranky Product Manager feel disgusting/dirty/loathsome/repugnant/appalled with herself, she’s gonna ask you all to head over and take Forrester’s Agile Survey.

‘Cuz maybe then the Forest Rangers will share the results with her, even though she has no access to their research.  And even though she constantly maligns their good name. (hah!  right!)

Because then, maybe, she’d have more fodder for more cranky posts on Agile.

—————————

Note 1:  Observe that the Cranky Product Manager said GENERALLY.  No doubt, there are analysts that are NOT coin-operated.  But they are probably still ho-bags.

Big thanks to the 119 of you who deigned to answer to the Cranky Product Manager’s lil’ Facebook poll on software development methodologies. The poll is now closed.

While this is hardly a scientific poll, the results show a HUGE change in software development methodologies between now (2008) and two years ago (2006).

Software Product Development Methdologies: 2008 vs 2006

• In 2006, you reported that a sizable majority of product development used a waterfall methodology (55%), with Scrum garnering a mere 7%.
• In 2008, the picture is very different. Scrum and its Agile cousins account for nearly 60%, where waterfall has dropped to a mere 28%.
• The percentage of products using waterfall dropped by 50% in just two years! (from 55% in 2006 to 28% in 2008.)
• Scrum increased by 410% (!), and is now definitely the most popular flavor of Agile.

Wow. What a difference in just two years.,

Poll Conclusions

The CPM sees the writing on the wall. She’s now on a mission to learn all she can about Agile/Scrum in order to stay employable. But geez, there’s got to be something better out there than that canonical (naive) Scrum book. Something that reflects the realities of developing software PRODUCTS for multiple customers, not doing custom one-off developing projects. Please, say there is.

Nonetheless, the CPM thinks we are approaching Agile’s “Peak of Inflated Expectations,” soon to be followed by the “Trough of Disillusionment” (to borrow phraseology from the much-despised Gardeners), as people realize Agile still has flaws and is no Silver Bullet. Plus, Agile’s flaws aside, waterfall is not going away completely as there are too many products that CANNOT be developed via Agile (hardware, medical, defense, heavily regulated industries, products with very spread-out or outsourced development teams, to name a few).

Detailed Results

119 people responded to this Facebook poll, run between September 12 and October 1. Bare in mind that the readers of this blog are hardly representative of the entire software industry, and that the ones that use Facebook might be even less representative. Nonetheless, the results are very telling.

Question 1: Is your product currently being developed with one of the following software methodologies?

Reported Software Product Development Methodologies in 2008

Question 2: Two years ago, what methodology was used for the product from Question 1?

Reported Software Product Development Methodologies two years ago, in 2006

The Cranky Product Manager is a big fan of anything that will get quality, innovative, market-killing products out the door more quickly.

Sincerely. This statement is a paragon of truthiness. Hell, the Cranky Product Manager would even trade in her extensive work wardrobe of Lucky Brand jeans for a pile of poofy skirts if it would improve product quality. She would even stop swearing and referring to her colleagues as “beeyotches” if it would speed up development and reduce the number of half-finished features. No lie.

But alas, the Cranky Product Manager’s cantankerous, tomboyish lifestyle is hardly threatened, despite DysfunctoSoft’s move to Agile (specifically Scrum) two years ago.  Things are slightly better now, but not that much.

Shocking, the Cranky Product Manager knows.  Because Agile and Scrum are SO FRAKIN’ FASHIONABLE right now, that speaking of them in anything but the MOST obsequious “Agile-is-the-absolute-shizz-it’s-even-better-than-sex” manner, well, it’s kinda heresy.

You see, Agile is a pseudo-religion. It has a Manifesto and a bunch of zealots and everything. (gack)  In fact, the Cranky PM fully expects a pile of comments and trackbacks along the lines of:

• “The CPM just doesn’t get it. Agile is indeed the shizz. Plus it’s better than sex. It’s new (well, kinda). It’s iterative. All the cool kids (claim) to do it.”
• “The CPM is a waterfall-worshiping Luddite, afraid of change, out of touch, and a control freak — so typical of a product manager. Doesn’t she realize that Scrum liberates us developer-artistes to at long last build for intelligent audiences, people just like us?”
• “The CPM must be doing Agile the wrong way. Not me — I know all the secrets. To learn how to do Agile right, visit my blog, read my book, hire my consulting firm, take my training class… With my help, you too can use Scrum to MAKE MONEY FAST, MELT AWAY THE POUNDS without diet or exercise, and become ABSOLUTELY IRRESISTIBLE to the opposite sex. Agile riches will exceed your wildest dreams!!!!!!!!!!”

Hmmmphhh. Such are the stones a heretic must endure.

Anyway, let the Cranky Product Manager continue and speak directly about the unspeakable:

Sure, Agile makes some things (ok, many things) better.  But it also makes some things — IMPORTANT things — worse.

Yes, Agile can speed up the development and improve the quality of small features.  But it’s too often at the expense of the Big Important Work — the heavy lifting, multi-month market analysis and architectural work that lead to REAL customer value and REAL competitive differentiation.

Yes, Agile can do wonders to improve product usability. But the results are often incremental in nature.  Opportunities to come up with innovative user interaction models that put the user experience on a different plane are not explored. Not enough time.

Yes, Scrum can improve the speed of decision making by requiring a “Product Owner” make on-the-spot decisions. But because it does not allow the Product Owner the customer face time to intimately understand the market, it too often results in products that addresses the verbatim enhancement requests of one or two specific customers (whoever spoke to the Product Owner last) while missing the real market opportunities. (See footnote 1.)

Yes, Agile can reduce the size of the development team. But instead of cutting costs, it moves the resource bottleneck to the product management and project management teams which are usually understaffed for the greater demands Agile places on them.

Yes, Agile is good at holding developers’ feet to the fire and jacking their lines-of-code-per-day rate through the roof.  It helps them fix bugs faster too. But because Agile keeps them in an always-on, semi-panicked state, it also leads to burn-out and prevents developers from doing the deep thinking required to solve the really thorny problems and to truly innovate.

Further, the War Room atmosphere and pair programming practices require a different, more outgoing personality than many developers naturally possess.  Granted, his research might be dated, but Tom DeMarco (author of Peopleware) found productivity was highest when developers had private offices with actual walls, windows, and doors that shut — the very antithesis of today’s War Room. In the War Room, the ideas of the more quiet, introverted, and thoughtful developers are too often drowned out by their louder, more obnoxious, and less gifted brethren.

So, despite the massive amount of hype currently surrounding Agile / Scrum, let the Cranky Product Manager remind you that — in the immortal words of Fred Brooks — There Is No Silver Bullet.

Agile is NOT the end-all-be-all for software product development. It is NOT the second coming. It is an improvement to be sure, but it has some big flaws – just like ALL software development methodologies.  And that is more than just “truthiness.”  It is the actual fraking TRUTH, beeyotches…

————-

1. The Cranky Product Manager knows that many Product Management bloggers believe that this problem is solved if you separate the market / customer-facing Product Manager role from the development-facing Product Owner. However, the Cranky Product Manager remains unconvinced.  How can the Product Owner gain the perspective to make the best product decisions without regular customer contact?  More on this later….

CORRECTION: In the Cranky Product Manager wrongly claimed that Rich Mironov of Enthiosys supported the idea of separating the product manager and product owner roles. Untrue. He says he supports this role split it in a world of infinite resources and perfect communication, but of course that ain’t reality. Read his article all the way through (and wait for part 2) for a more civil and scholarly discussion of the problems the Cranky Product Manager rants about. It is truly a WICKED AWESOME piece, so get over there and READ IT.

Related Posts:

• Scrum This!
• So You Think Agile Development Methodologies Exempt You From Product Management?
• POLL: Agile vs. Waterfall Software Development

Hey there, the Cranky Product Manager has a new poll over at Facebook.  Its purpose is to informally see how much software development methodologies have changed over the past 2 years, be they  Waterfall, Agile / Scrum, Agile / But Not Scrum,  or Cowboy Coding. 

Only 2 questions. Won't take too long, promise.  You'll get to view the results immediately after answering.

And, yes, the Cranky Product Manager realizes that some of you DESPISE Facebook and won't take the poll, thereby skewing the results.  But the Cranky PM likes Facebook and the way it keeps people from voting twice even from different IPs. Plus she thinks Facebook is fun.  She loves answering Cosmo quizes like "what kind of shoe are you?" And its the Cranky Product Manager's blog, and her rules (even says so in the sidebar over there –> ). 

Besides, this is hardly a scientific poll, given that the readers of this blog are much more bitchy than the norm.

After a few weeks, the CPM will post the poll results to this blog so you can see them even if you don't belong to Facebook.

Enjoy, thanks, and have a great weekend!

Hey You! Mr. Release Manager!

The Cranky Product Manager appreciates that you’re trying to do this Agile Scrum thing by the book. And that it is hard for you. Because before this Agile tsunami came crashing down you mainly just tracked the progression of different release documents (Is the PRD done? Check. Is the Functional Spec done? Check. Is the Design Doc done? Check.)

Ok, that’s not fair of the Cranky Product Manager. You did more than that. You also ran hurried release meetings once a week that tried to bury issues instead of surface them (OK everyone, here’s the status of all the documents. Anyone have any issues? None? OK, let’s adjourn.) You also organized two or three Fantasy Cricket leagues plus your wedding during working hours, and boy it all took a lot of time.

But now, in the Scrum era, things are different.  It’ s not easy. You once had a private office, but you now spend the bulk of your day tethered to a communal table in a stifling hot “War Room,” inhaling the body odor of The Veteran, trying to tune-out the grandstanding arguments between two nimrod Hotshots (“My idea is the most elegant…”, “No it’s not. It’s trivial. You’d have to refactor it immediately.”), and listening to the documentation writer bitch and moan that she can’t write the doc by Friday if the product keeps changing every hour. It’s really hard to organize fantasy leagues or surf the web with so little privacy. Plus the porn shui of the War Room is completely off.

So it sucks to be you, Mr. Release Manager, and the CPM is sorry for you.

But just because you are stuck in that War Room doesn’t mean the Cranky Product Manager should have to join you. You argue that in Scrum the product manager is the same as the Product Owner, and therefore the Cranky Product Manager needs to be constantly available to the team in order to make on-the-spot decisions within minutes of the asking.  Ergo, you demand the Cranky Product Manager sit in that sticky-note-encrusted, windowless tomb with you all damn day.

Uh, no way.  Not gonna happen.

Why not? Because the Cranky Product Manager needs to be the Voice of the Customer and the Voice of the Market.  How is she to do that without actually VISITING some customers and prospects?  And VISITING means that she actually needs to leave the office, hop on airplanes, and fly far, far away.  She cannot answer questions from the dev team within 5 minutes if she’s on a plane, or in a meeting, or on the phone with a customer.  Not that the CPM wouldn’t LOVE to hear debates about Iron Man or whether that Star Wars cartoon is “canon” or not —  all day, every day, for hours on end. Who wouldn’t?

And your response, Mr. Release Manager?  You argued that perhaps the Cranky Product Manager should not visit so many customers and should spend more time in the War Room.

Anyone else see the irony? The Voice of the Customer should have less interaction with customers?  All so she can make on-the-spot customer-facing decisions more quickly?

TRUST that the Cranky Product Manager will have more to say about this Fatal Flaw of Scrum in an upcoming post… She feels a HUGE rant coming on.

Related Posts: 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.