web counter

Posts tagged as:

product+development

Guest Post: The Cranky Test for Agile Product Managers

by The Cranky Product Manager on February 6, 2009

in Agile/Scrum

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

{ Comments on this entry are closed }

Guest Post: This is NOT a Democracy

by The Cranky Product Manager on January 27, 2009

in Guest Posts, The PM Profession

The Cranky Product Manager is still in her funk.  Such things happen when layoffs hit too close to home.  No, the Cranky Product Manager was not laid off, but this guy she knows was.  And apparently, he lives in her house, is father to her child, and pays a bunch of the bills.

As such, the CPM is not up for much writing this week. Thank Cheezus there are some marvelous, cranky guest posters out there who are stepping up — all to ensure you readers get your weekly dose of Crankitude.  You’re welcome.

Anyway, the following extra cranky article was contributed by Ivan Chalif.  Ivan is a Product Management and Product Marketing professional with over 10 years experience in technology Product Management and Marketing. He has built successful web-based products and services at companies like StrongMail Systems, ValueClick, The Gale Group and Acxiom Digital. For less cranky (but still witty) Product Management and Product Marketing articles, visit his WICKED AWESOME blog, The Productologist. 

(The Cranky Product Manager likes The Productologist blog very much, but thinks it is unfortunately named, since she constantly confuses it with The Proctologist.  Especially because Ivan’s guest post recommends Kevlar thongs — ouch!)

—————–

This is NOT a Democracy

You know what chaps my hide? When people mistake feedback for requirements. If you don’t know what I’m talking about, let me spell it out for you.

In almost every organization, Product Management is viewed as a collaborative role, responsible for connecting all of the disparate product stakeholders. We’re charged with communicating with everyone (and their mothers) in order to get the real picture on product strategy, feature and release prioritization, and execution. Go talk to Sales; they know what the market is asking for. Call your top 5/10/20/100 customers because they’re the most important. Find out who the biggest users of Technical Support are and why. Attend the next Professional Services staff meeting to hear what special sauce they’re whipping up and how they think it’s the next big thing. Everybody wants to have their say. Even Engineers have suggestions on what should be added or changed or updated, even if they’ve NEVER met with a customer or prospect in their lives.

The first thing that the Product Manager hears when the product is released is “Where’s MY ______? I told you we needed the ______ to get customer/keep customer/be cool/placate the board/appease the analysts/blah blah blah. For the love of Pete, weren’t you even listening?!”

To which the Product Manager responds, “That didn’t make it into this release. Didn’t you read the email I sent explaining the adjustments to this release?” This usually flusters the person accosting the Product Manager, and they storm off muttering something about how nobody ever listens to them. Wahhh.

Guess what? Just because the Product Manager asked you for your input about a bug, or a feature, or prioritization, or whether you think the UI should be red, blue or chartreuse, does not mean that everything you specify will actually happen. The whole point of soliciting folks for feedback is just that…to get feedback. Any Product Manager worth their salt is not asking you to tell them exactly what to do. They’re collecting information that will help THEM make a decision about what to do. NEWSFLASH: Making great products is not about democracy.

51% PRODUCTS

In fact, being a democratic Product Manager guarantees that you will deliver a crappy product. Building a product that meets the needs of a minimum of 51% of the market is not a very useful solution, since you leave upwards of 49% of the market unsatisfied.

Unfortunately, 51% products are what you get when you try to build what everyone wants.

Let me be clear. No release will have everything everyone wants. Over time, product democracy will insure that you build a bloated product that tries to meet the needs of every possible user, does none of it well, and is a bear to maintain.

Unless creating bloated, useless products is your market strategy, don’t be a vote counter. The role of the Product Manager is not to go around to all of the stakeholders and collect the relevant data points and then deliver a product that meets 100% of those requirements. Any monkey (code, sales, or otherwise) can do that using Cut/Copy/Paste. Product Management is bigger than that. The Product Manager has to distill all of that information, and discern what’s really important, not just regurgitate it so that everyone can feel good about their contribution and maintain their high level of self-esteem (that’s what all of those “certificates of participation” from grade school were for…well done, Ruprecht).

1 + 1 + 1  EQUALS 5, NOT 3

Great Product Managers take all of the data that they collect–insights from customer and prospect calls, competitive analysis, Tech Support research, UI feedback and more, and create a panoramic view of their product. With that view, they build a product strategy that balances the needs of current users while envisioning “what could be” in the future. What emerges is something more valuable than the sum of the original parts. It’s something revolutionary and rare.

Building a democratically determined product doesn’t get you revolutionary and rare. It gets you a big heaping bowl of ordinary. That’s not exactly ideal for being the leading whatever-you-want-to-be-the-leader-of or creating the kind of emotional response in customers and prospects that’s so big they’re all banging on your door to get it (think iPhone).

If adding features and defect fixes just because someone else said to is all you do, that’s not being a Product Manager. It’s being an administrator. Listen closely, because I’ll let you in on a secret: administrators don’t make great products. They make 51% products. You say you don’t want to create 51% products? Great, but it’s hard work and usually involves getting into fights with just about everyone, so make sure you’re wearing your Kevlar underpants (or thong, for those of you who like to go that route).

JUST SAY NO

If everyone is happy about what’s in the product, then you aren’t doing your job as Product Manager. Releasing great products is about sacrifice. It’s easy to say “Yes” to every Tom, Dick, and Mary; you’ll just have to wait 6 years for your product to actually make it to market. With all those features, I’m sure the market will wait for it.

The hard part of being a Product Manager is saying “No.” If you want to be successful and deliver great products, you have to say “No” to Sales. You have to say “No” to Tech Support. You have to say “No” to customers. You have to say “No” to the board. Sometimes, you even have to say “No” to yourself.

Ultimately, there has to be one person to make the tough calls about what goes in the product and what doesn’t. That one person is the Product Manager.

If it isn’t, the Product Manager should probably start looking for a new job.

{ Comments on this entry are closed }