Frittering away the time with an experiment All experiments involving donuts are worth doing, so here's one you might try. Tomorrow, bring a box of donuts to work, and leave them in the kitchen. At the end of the day, go back to the kitchen and count the number of donuts that people have taken.
Next week, pick a meeting-filled day, and bring a new box of donuts to all of them. Don't leave the donuts in the kitchen--the point is to keep it visible at all times. At the end of the day, count the number of donuts consumed.
Chances are that the number of donuts consumed in Week One is greater than the number consumed in Week Two, for an obvious reason. People behave differently when they are observed. We like the donuts, but we don't like being seen taking a donut (Homer Simpson excluded).
2009 might be, in the Chinese calendar, the Year of the Ox, but January feels like the Month of PowerPoint. I've been doing a lot of speaking lately, including last week's great session about Lean and Agile in San Diego. (And thanks again to Rober Pryor of the San Diego Software Industry Council for the invitation.)
A small presentation to some Forrester clients about the state of the technology market, including where the opportunities lie, from a geographic, vertical, and solution perspective. Plus a few tips on how to emerge from the downturn a stronger company.
Most product management aficianados opine, at some point, about the importance of product passion. You need to love your product. You need to embrace it, nurture it, defend it, extol its virtues to other people. If your product fails, maybe you didn't believe in it enough. (You probably killed Tinkerbell, too, you unfeeling bastard.) If the product succeeds, you can bask in the afterglow, and then maybe have a cigarette.
If that sounds a little creepy, maybe it's worth re-evaluating your relationship with your product. I'm exaggerating for effect, but that's only because the word "passion" is vague, and exhortations to have product passion often sound pretty overheated.
Many product managers who work with or within Agile teams have told me how they've felt left in the dust during the early phases of the Agile implementation. "We've sighted our target persona!"the development team exclaims. "Champagne for everyone!"
Unfortunately, they forget to invite to these festivities the very person who will, beyond this sighting, provide ongoing intelligence about that role--and the use cases, and whether that's the right role for the product, and what the competition is doing to serve that person, and whether there's a market for all this technology in the first place. A good product manager also has mad skillz in collecting and analyzing this information, something that even the most wunderbar of Wunderkinder doesn't necessarily have right out of the womb.
Shane Hastie at InfoIQ describes the same problem facing business analysts, the cousins of product managers in IT organizations.
I'm growing fond of Twitter, particularly since it's a great tool for overhearing what's on the minds of people involved in a particular line of work--including, oh, say, product management. This morning, I followed a Twitter-posted link to Brian Lawley's "Product Management Manifesto." If future historians wanted to learn about the product management profession, both the good and the bad, the Manifesto might be a key piece of evidence.
That's not a good thing. The "Manifesto" may reflect the current state of product management, but it's a bad manifesto.
What Is And Isn't A Manifesto
For people reading this blog, the word manifesto probably conjures up two main examples, Agile and Communist. In both cases, the manifesto is intended to be a plan for collective action. Today, we follow a long-term development plan. Tomorrow, we start using a more adaptive process. Today, we work on the assembly and hope our lives will improve will get better. Tomorrow, we march on the factory owner's office, or the tsar's Winter Palace.
The "Product Management Manifesto" is really a personal oath. Statements like, "I refuse to settle for mediocrity," or, "I believe that Product Management is one of the toughest, yet most rewarding jobs in the world," sound more like personal statements of dedication, bordering on professions of belief.
Here's some text excerpted from some other oaths, just to drive home the point further:
The Cranky Product Manager has been posting up a storm lately, with several excellent ones in the last month. For personal self-interest alone, it's worth digesting what she has to say in her post about being the CEO of your own career. Plus, there are the results of her poll on PM certification. Go read.
As I said in my last post, different types of product management books serve different needs. Rich Mironov's The Art Of Product Management doesn't aspire to be a detailed reference manual. Instead, it provides quick, vivid snapshots of the challenges that product managers face on a day-to-day basis.
At least, it's one version of product management. To continue the Band Of Brothers analogy from my last post, you might not be a paratrooper, but if you're in the Army, you may learn quite a lot about the job of being another type of infantryman from the story of the 101st Airborne in
Sadly, if you were to line up the books about product management in the technology industry that are worth reading, you wouldn't fill up a bookshelf. Not only are there too few books on the topic, but some of the ones you'll find from a quick search on Amazon aren't that good.
Therefore, when two good books on product management appear at roughly the same time, it's time to celebrate an unexpected bumper crop. The first, The Product Manager's Desk Reference by Steven Haines, does exactly what its title suggests: provide reference information that covers a gamut of PM tasks. The other, The Art Of Product Management by Rich Mironov, also covers a wide swath of the product management world--but in a somewhat different way.