caution: lessons of reorganizations past

An Impending (Potential) Reorganization at a Large Software Company We All Know and the inevitable RIF-related misery it will cause among the rank and file has drawn my thoughts back, back to a simpler time and another reorganization I remember.  Perhaps you will let me tell you a story about it.

"I hope you had this sitting in draft for a while, mister, because you've got better things to do than tell stories."

What's with the cynicism?

Ahem.

Once upon a time. . .

A new CEO set out to reorganize a company to make it easier for it to deliver products that users would react to with the word "wow".

In a blog post (which I am impressed to see is still a live page), this new CEO described a management manifesto using folksy language like "People here have impressed the hell out of me" and "Look for this company's brand to kick ass again."

I! thought! that! was! great!

But I was a bit disappointed by the following:

We're also leaning on this team to make sure we're all hearing the voice of our customers (consumers and advertisers). I'm singularly focused on providing you with awesome products. Period. The kind that get you so excited, you have to tell someone about them. Whether on your desktop, your mobile device, or even your TV.

Umm. What were they doing before?

Then I read this. . .

And that takes a real understanding of what you want/need/love/hate, how you’re using our products, and what you find simple, intuitive, easy and fun. Who wants innovation for innovation’s sake if it doesn’t make your life easier, more efficient, more productive? So expect us to hear you better and take better care of you.

And was even more disappointed. Because really, what were they doing before?

I knew they must have been listening to customers prior to her arrival because they had product managers there. These were good (and some even great) product managers I had worked with In The Distant Past, and I was 100% convinced they understood how to build good (and even great) products that solved current, real-world problems in a delightful, wow-y way.

So, I was confused.  And so we arrive at the moral of the story.

Was it just that the product managers weren't able, prior to this reorganization, to blaze past the crufty institutional barriers that had accreted over the years, barriers that made it difficult to actually take action on transformational market feedback through transformational products?

Or…

Was it that their superiors, being fearful of risk or short-sighted or unable to get their voices heard or perhaps fearful, either suppressed or ignored market-focused innovation?

Or…

Were they unable to abandon dead-end products and services in their current portfolio so they could refocus their assets on Something Wonderful that would blaze a trail of profit and delight into the future?

I'm guessing some of all three.  And so we change leaders, who change the players, who try to make sense of what is possible and what is no longer possible.

Ultimately, change is hard, because it hurts like hell, and it goes on hurting long before it starts making things better.  Great leaders can bring organizations through this pain but it's not easy, it's not guaranteed, and it's certainly not without cost.  But sometimes, it's the only game in town.

Mutantur omnia nos et mutamur in illis. 

(PS - This post is definitely my opinion and does not in any way reflect the policies of my wonderful employer.  Just thinking out loud here, folks.)

considering: my office window

Readers of ack/nak will know by now that I have, for almost five years by cracky, been on staff here at your nation's natural history museum in historic (and might I say seasonally swampy) Washington DC.

It is a privilege to work here.  A transformational, wonderful, heart-stoppingly challenging yet still always wonderful privilege.  I invite all of you to visit.  We have world-class exhibits, staff and dare I say quite a lovely cafeteria and some enticing gift shoppes.  But I digress.

Last summer I "left" product management for the greenish pastures of operations and "general management", which, as is often the case, came with a few choice perks, one of which was freedom from having to write requirements (thank G_d) and another was a new office.

What this office has that my previous one did not is a window.  A rather large, long one, covered by blinds, that faces north towards Constitution Avenue, which I can definitely see past a stand of mature trees between me and the road.  Cars whiz by, pedestrians meander, life burbles on as is its wont.

Now before you start wheedling me with statements like "wow you must be some special kind of guy" (which we both know has always been true, so let's just not bring it up again, thanks), it's worth mentioning that I had inhabited a window-less bunker-like office for many months up to the time I moved, which, dear reader, makes the sudden arrival of sunlight in my daily work live all the sweeter.

"Shouldn't you have been, you know, out-and-about visiting customers as a product manager?  Weren't you the guy who said if you're spending time in your office you're failing?"

Enough, you.

When I moved into this office I did what all self-respecting new office inhabitants do - I cleaned it up, moved furniture around, put away my crap and settled in to work.

Then I started to experience what makes this window different from other office windows I've had in my long, long, very long career.

Through this window, I experience motorcades, tour busses, taxis, delivery trucks, and yesterday, storms of such force and violence that I expected to look up over the IRS building and see Noah himself waving at me, sad doomed sinner that I am, on his way to delivering a bolus of biodiversity to some mountain in Turkey.  It's a busy window.  The busiest of my career.

I don't face my window, but there it is, tempting me with life's rich and ever-changing tableau.  The light grows, and fades, throughout the day, and as I leave my fluorescent lights off, the changing-of-the-light is something I experience every day I am here in my office (which, Mr. Smarty Pants, is not every day, thank you).

The busy window is a quiet reminder of change directly over my left shoulder.  There it is now, hey, a tour bus, some lady pushing a big stroller, ok back to the post.

Too much of my time in product management and software development was spent trying to lock down requirements, lock down schedules, lock down releases.  Now, I spend the majority of my time adapting to change, balancing priorities, managing conflicts, encouraging, discouraging, negotiating, digging and generally plate-spinning.  I could not have handled having this much chaos this close to my workspace.

But today, well. . .today, it's perfect.  Because despite all the change and variety outside the window, everyone there is heading somewhere.  And that's exactly what I'm doing too.  Like the bus driver, my job is to bring a lot of people with me and make sure they all get to a destination happy and ready for what's next.

Here's to your windows.

PM in a Can (a.k.a. Is this the best part of being a PM?)

Hello again.

I'm now 39 days into my new operations role and may I say, I am loving it.  Most of the time.  But that's pretty much life, right?

One of the 'challenges' of taking on a new role is making sure you stay far, far away from the comfort zone of your previous role.  For me, that comfort zone is Being a Product Manager.  It's something I know How to Do.  Kind of like falling off a bike or setting fire to an abandoned car, it comes easily to me.  Also like juggling and hobo tracking.

I hear the voice of my board chairman echoing, echoing, you can't be the product manager anymore, Bob, you're an operator now, but you've still got to find a way to get that work done, have a nice day, oooooo (rattles chains).

Sigh.  Yes indeed.

And so, faced on day one with the operator's challenge to "assess a new opportunity to determine whether it can contribute to the sustainability of the enterprise", I considered my assets and liabilities.

Assets: Some reasonable amount of cash and freedom to spend that cash
Liabilities: The clock, no in-house staff capable of doing the work, no time to do it myself, no Holocaust Cloak

OK, I can work with those, I said.  And so I set forth to establish the PM in a Can.

"What is a PM in a Can? It sounds like Prince Albert in a Can."

Shh.

I sat down and asked 'what is the absolutely smallest set of information I need to make the best possible decision?' and came up with the following:

1. I needed to develop a product concept and its value proposition
2. I needed to test that product concept with some people who could conceivably buy it
3. I needed a minimally viable product spec (my favorite new acronym: MVP)
4. I needed a business model that challenged all of the assumptions of #1-3

I figured, OK, I really shouldn't ask one organization to do both of these because that's a fox in the henhouse problem - of *course* an organization that heard happiness from the market on the product concept would conclude that there's a business model that could support that concept.

So I hired two sets of people to do the work, serially.

And in doing so, I realized something entirely terrifying about product management.

This part - the PM in a Can - is the MOST INTERESTING PART OF THE ENTIRE PM JOB.

Everything else is. . .how to put it . . . .just 'work'.

Maintaining the story backlog = Just Work
Going on sales calls = Just Work
Negotiating with development around product delivery = Just Work
Evaluating win/loss assessments = Just Work

I could go on.  I won't, because it's too depressing.

The very best part of being a product manager is finding brand new problems to fix, and figuring out whether or not an investment in fixing them will advance the cause of the enterprise.  At least it was to me.  But now I've got a sinking feeling that those opportunities are, practically speaking:

1. Few and far between and
2. Often co-opted by clever operators who understand product development

And so I arrive at the point in this post where I ask you, my dear friends and readers, if you agree, disagree, care, wonder if Green Bay beat the spread, etc.

Because I'm thinking I may have just figured out something that has vexed me for years - why all the talk of "strategic product management" never seemed to translate into actual work, because all of the most strategic work gets directed & evaluated by others.

finally: launch day arrives

In January of last year I began work as the product manager for something called the Encyclopedia of Life.  A version of the product was already online at www.eol.org.

Today, the new version went live at that same URL.

And I'm having all of the standard product management emotions.

Emotion #1 - Loss.  The work we were doing was secret, and now it is not.  The team was galvanized by a common objective, and that objective has been reached.  There are a number of other dimensions of this most unwelcome of emotions that I won't bother you with.  But they're all a flavor of "it's over", even though in reality "it's just beginning".  Don't expect it to make sense, it's a feeling.  A Bad Feeling.  The Worst Feeling.  Like someone died.

Emotion #2 - Fear.  What if no one likes it?  What if it breaks?  What if the press doesn't think it's super-fine?  What if we misinterpreted some of those requirements?  What if the beta testers were all "just being nice"?  What if someone else does it better and launches next week?  The never-ending cascade of "what ifs" feels like someone throwing rocks at you from waaay up on a building.  The hits just keep coming.  You want to cover your head with a metal garbage can lid and move quickly through your day, because you don't know when the next rock is going. . to . . land.

Emotion #3 - Defensiveness.  I'm sorry, such-and-such a feature wasn't in the release plan.  I'm sorry, we weren't able to ship with that capability.  I'm sorry, that's on the known issues list.  I'm sorry, we'll be sure to get that into the next release.  I'm sorry, I'm sorry, I'm sorry.  There's never enough time to do it all, and inevitably there are people who are sad.  And I'm sorry about that.

Emotion #4 - Detachment.  OK, what's on the list for the next release?  Yes, I know, the new version still has that clean baby / new car / spring morning smell, but, you see, product managers are Tomorrow People and I've been working on the next release for, gosh, a month now, and let's start talking timetables.  Thank you, we're all very proud.  It's wonderful.  Now, about that Next Version.

We're wired differently.  We don't take victory laps.  We don't linger on current successes any more than we pore over current failures.  We move on.  If we're lucky, and we've got a) the support of people who love us, and b) a team we respect, admire and enjoy, we can c) move on without feeling like the one guy at a party who doesn't seem to get the fact that HE'S AT A PARTY and the point of the party is to BE HAPPY.

So with all that said, I am actually happy.  At least when I'm not parsing emotions one through four.

(PS - Gosh, the new Blogger editor sure is swell.)

(PSS - Travis Jensen (@softwaremaven) believes I am suffering from "Post-shipping stress syndrome" or PSSS.  I prefer to think of it as "Corrigan's Disorder".  But it might explain why people think I am PSSSed lately.)

wondering: when to let go of your "product focus"

I thought I had lost it forever, but there it was, in the bottom of a plastic bag full of crib mattress pads I discovered while cleaning out my basement.

My Newton MessagePad 120, nestled in its leather case with business cards from the (long defunct) Newton Source store in NYC tucked inside it.  Four AA batteries and one backup battery later, it booted up fine, looking as tidy as it did in 1995 when it went missing.

Alas, its handwriting recognition is still awful.  And it won't let me set its date to April 2011.

It's still as beautiful a piece of hardware as it was when it was new.  It's still delightful, even all these years later, for what it is.  But I've moved on.

I wonder if the #prodmgmt responsible for this device still think about it, or if they've moved on too.  They're all (obviously) doing something else today with their professional lives.  I doubt any of them still use a Newton.

But they still have users.  Some of them are very, very devoted. And I bet there are many more who would be ready to have their devotion restored, under the right circumstances.  Still, most have moved on.  It's the way of things.

I don't think about my old products very often, but I think about my old users, customers I used to care about deeply back when I was very, very devoted to delighting them.  I wonder if any of them are still delighted, or if, like me, they've moved on to other products, other problems.

It's why, as Boss Strouse once said, you don't meet many product managers over 50 - because by the time you hit that age, you've figured out that it is organizations that last, not products.  If you care deeply about people and you're trained as a product manager, eventually you need to let go of your product-focus and become organization-focused and brand-centric if you want to keep on delighting people over time.

Because those are the only two things that can last - products never do.  They're not supposed to.

So when is it time to let go of your product focus?

You'll know.  It's one of those forest and trees problems.

"That is. . .so frustrating.  I made it all the way to the end of the piece and you spring some zen mumbo-jumbo on me?  Damn.  This is why Cauvin and the other PM bloggers kick your butt these days.  They answer questions.  Forest and trees. . .you're losing it."

"What can I say.  There are some things you can't teach, you have to find them out for yourself.  All I can do is let people know that the question is looming out there so they're not surprised when it hits them."

"You used to be a lot more fun."

"Ha."

wondering: is everybody in product management?

There was an old joke that used to circulate every time the nice people in marketing would circulate a brochure or a press release or a sell sheet or an ad or whatever that "everyone is in marketing" because every one who touched the piece - regardless of whether or not they were qualified to do so - felt it was their job to monkey around with it.

"Change the font."

"Can you move these paragraphs around?"

"This message isn't strong enough."

"We need a quote from such-and-such."

"More cowbell."

And so on.

This used to frustrate the nice people in marketing who actually knew how to do their jobs, but who were tradition-bound to invite other people outside of marketing to get involved in the business of marketing.  Too often the head of marketing wouldn't stand up for his or her people, and so the adventure continued, to the detriment of the marketing department which was increasingly seen as "indecisive".  Really.  I can't make this stuff up.

Theseadays, as I read various and sundry product management blogs and twitterings and rumblings from the underground I'm starting to see the same awful malignant practice that used to plague marketing departments start to afflict the product management craft.  The challenge here is that the meddling is constant instead of seasonal, and it's coming from higher up in the org.  We've created this problem by writing about product management, and now non-PM people are using what little they know about it to show how smart they are.

"Our customers want such-and-such.  Go do it."

"That's too late to deliver that product.  Make it sooner."

"These guys over here are the new shiznit.  Partner with them."

"I'm the chief such-and-such officer and I know this market and here's what you need to do."

"I want these guys in the beta."

"You don't have enough market research to make that call."

"More cowbell."

And so on.

Here's how I avoid these problems, because I do.  I'll even boil it down to two sentences you can say with your mouth full of food.

"Everybody has a stake in the success of this venture, and everybody has a special unique contribution they can make to that success that no one else can.  If we all play together and work hard to delight our users, we can be successful together."

Smile when you say it.

Getting the people who think they are product managers out of product management is a matter of attitude - it is possible to be collegial in the effort to create the best possible outcome without creating an environment in which decision-making becomes diffused, or worse, capricious and inconsistent.

You, dear product manager, must create a process environment that involves the team appropriately and you must ride that process like a world-class cowboy as the surest way to get stuff done.  Because if people don't understand your process and the role they play in it, they are free to play any role they want at any time and expect that their inputs will be acted on (if they are senior enough to get away with it).

So good luck with that.  We've got no one else to blame for it but ourselves.

best: product management manual

What is the best instruction manual for product managers?

Yee, Wong Herbert. Hamburger Heaven. New York: Scholastic, 2001.

(Amazon link)

In a review of this fine book, C. Posey wrote:

My son was delighted while we read this book. Tickled by fantastic illustrations and disgusting delicacies, he enjoyed the book from front to back. I used it as an opportunity to teach him about entrepreneurship, a not-so-obvious theme underlying the story.

While others' reviews have pointed out that the moral is about helping others, I believe it goes deeper than that. It is about Pinky Pig taking charge, and doing what is required to not only save her job, but to help grow the business she works for.

She performs market research (asking others what they'd like), planning and advertising (distributing the new menus in places her customers were most likely to frequent), and even delivering the desired product to the masses, which nets the business (and her personally) financial success, and loyal customers galore.

A great book with a moral? Yes. And a fantastic one about self-reliance at that.

This book is full of PM goodness that will stick in your head forever. Which is why it is the best product management manual ever. Recommended for readers of all ages.

PS: When I read this to my kids years ago they both said "that's what you do Daddy!" My son then asked when I was going to start a hamburger stand. He was not satisfied with my answer.

PPS: My reason for writing about this today was I found myself saying "it's the product our users want that is important, not the one that you or I want", and I was reminded of the line "Aardvark's burger has termites inside" from this book. Everything is Connected.

embracing: crossroads

IF you've been brought into an organization as its first product manager, most likely you've spent your first 100 days figuring out the lay of the land.

AND you've probably figured out that there are changes that need to be made in order for the product and perhaps the organization to succeed. Otherwise they wouldn't have hired you.

THEN you realize you're at a crossroads. You can either continue along the previous path, or introduce the disruptions required to get the product to the destination the organization has set for itself.

This is a very lonely moment in time. It's also the most important moment you'll face in your time with that organization.

How you lead your team through this crossroads will challenge you in every way. It's a make-or-break time for you, Mr. Product Manager. Embrace it.

choices: an exercise

Consider the following.

You live in a neighborhood in a city. Your neighborhood may have three (3) restaurants. No more, no less.

When you are tired / hung-over / lazy / inspired / hungry you may visit one (1) of these three (3) restaurants.

This is not to say that there aren't other restaurants you *could* go to. But they're *far away* and it's too early / too late / you're busy. You want to go someplace familiar / close by / convenient.

And so. You must choose.

For your neighborhood, you must choose three (3) restaurants that are within stumbling distance from your abode.

They may serve any of the three traditional daily meals.

They can belong to any ethnic group.

They may be as cheap or expensive as you wish. Money is no object in this gedanken experiment.

And they can have any menu which would be typical of the sort of restaurant you select. Please note that a "serve everything" restaurant is patently not fair.

The most significant requirement is that they must suit *you* - day in, day out - on those occasions when you decide to eat out.

For purposes of illustration, here are my three choices:

1. A traditional American breakfast joint. Eggs, toast, corned beef hash, and gallons of excellent coffee served in chipped porcelain mugs. And orange juice of impeccable provenance. Oh, and more coffee: black, like my heart. Waitresses who have seen too much and yet still find time to smile and remember your name. You must over-tip them religiously.

2. A French bistro. Steak frites, onion soup, blanquette de veau, choucroute garnie, cheese, cheap wine that is still pretty good. Baguette sandwiches with good butter and ham. Diffident waiters. Black and white tile floors. The occasional confit du canard and cassoulet. Zinc bar. A blue haze of Gitanes smoke. Mismatched cutlery and checkerboard-style tablecloths.

3. A ramen-ya. Tall stools wrapped around a workman-like counter behind a flappy set of frayed black half-curtains. Enough said. Here's a wonderful post about the sort of experience I'm describing.

Why is this an exercise? Because it forces you to think about what it will take to delight you *consistently*. It connects you to a part of your psyche that you don't connect with often - the part that appreciates unsophisticated, everyday pleasure. Because you don't go out to eat unless you need to - and if you need to, you want to eat something you can't make yourself. You want to be wrapped in an experience that speaks to you intimately.

Now consider that you have the opportunity to create this sort of experience for your customers.

It's a heady responsibility.

BONUS EXTRA CREDIT OPPORTUNITY: Share your three restaurants in the comments or send them to me on twitter @bobcorrigan

definition: what is a product?

I had the opportunity to "define" what a product is to my steering committee last week. I thought I'd share my definition with you.

"Brands make promises to people - products keep those promises by delivering value in consistent, meaningful and delightful ways over time."

You'll note there are a few keywords missing there, such as profitable. It's missing because it's built in to the concept of delivering value over time - products that can't be sustained (by whatever means matters to you) can't be delivered, QED.

This definition works for me, because it aligns the mind around the customer, and it puts products into the higher-order perspective of the brand.

It also works for me because I can say it with my mouth full of food.

I hope all of you are well. I'm a week or so (I think) from being able to talk about my new adventure in greater detail.

considering: what's first UPDATED

I'm waiting.

"What are you waiting for? Godot? Mr. Goodbar?"

I'm waiting for my new job to begin. And by the way, you look for Mr. Goodbar, you don't wait for him.

"Woo hoo! Terrific! What are you going to be doing?"

"Product management."

"Where?"

Can't say. Yet.

"Why?"

Can't say that either. But I can say that I'm looking forward to starting, and I'm considering what to do first.

"What you do first is easy. You sign a lot of papers, you get your picture taken, you shake a lot of hands."

That stuff doesn't count. I'm talking about what's first.

"You've already written about that. You take a document inventory."

Well, yes. . . but. . .

"Come on, don't tell us that you're not going to take your own advice?"

The real world is complicated. Blog postings about product management make everything seem so cut-and-dry and black-and-white. Life is much more dynamic than that.

"OK, so what's first?"

I think job number one is to keep my mouth shut and listen.

"Really."

Really. When I was just starting out as a product manager I remember spending time selling the concept of product management to the new people I was working with, which was more of a telling thing than a listening thing.

"And you don't have to do that?"

I don't need to convince anyone that I know my craft. What I have to do is just do it. And that's going to take a lot of listening. And an absolute mountain of reading.

"But you like to read."

That's true.

UPDATE: Reader Matt, regretting the lack of a decent search facility on ack/nak, asked in a comment for me to cite the article in which I discuss taking a document inventory. That article can be found here.

idea: the LRD (life requirements document)

In one of my first posts here I wrote about the importance of writing the MRD first. It's amazing to think that was almost four years ago. Gosh I'm long-winded.

Recently I've come to appreciate that there's a document that must be written prior to the MRD.

It has nothing to do with your market, your products, or your company. It has everything to do with you.

I can't take credit for this - my wife made it clear to me that I needed to write down "what I wanted" if I was going to conduct a successful search, whether it was for consulting clients or a full-time gig.

"If you're such a hot-shot product manager, Bob, where are your requirements? Have you written down what you want, what's important to you, and what you will and won't accept? I think I recall someone saying 'if it's not written down it's not real' so get busy."

And so was born the LRD, or "life requirements document".

My headings are values, work (vocation), work (avocation), family, location, priorities, outcomes and challenges. Your headings will be your headings. Like the MRD, it is a living document.

I'm sure there are folks out there who are very adept at the "writing down of goals" part of this thing. But what I think is illuminating was the idea of treating it like a PM document, and as a private precursor to the MRD.

So where the MRD helps you understand:

Who are we selling this product to?
How are we going to sell this product?
What is the competitive landscape we're selling into?
What are the sizes of our buyer segments?

The LRD helps you understand:

What sorts of problems are you interested in solving?
What sort of customers are you interested in helping?
What markets are interesting to you?
What sort of people do you want to work with?
What motivates you?
What will make you feel like you've "won"?
What constraints do you need to work around?
What other activities do you need to pursue to make you feel "complete"?
What gaps exist in your capabilities that you must address or can safely ignore?

I could go on like this for a while, but you get the idea.

I've written a lot of MRDs for products and customers that frankly I wasn't all that interested in. Maybe it's a function of age, experience and scar tissue, but I am very focused today on making meaning, not just money.

If you're staring down the barrel of another development adventure and wondering what your life has come to, perhaps a little time spent writing your own requirements would help you understand whether or not you're doing work that is going to meet those requirements.

nice: persona-driven demo

If you're one of those folks on the prowl for news about the alleged Apple tablet, you probably saw reports of an equally alleged Microsoft device surface in recent days.

Well kids, MSFT beat APPL to the punch today by leaking (releasing?) a concept video that shows the Microsoft "Courier" device in action. OK, it's not the real thing - it's all animation and shadow-hands and a soothing hipster voice over.

But it does do something very, very well - it demonstrates a typical use case, and shows how the product supports that use case. It doesn't focus first on features - it focuses on value.

I was impressed.

Since I can't embed the Gizmodo video of the demo here, you will just have to go there to see it.

Sometimes product managers leave the "marketing stuff" up to the "marketing people". When it comes to how your products are demonstrated, don't let this happen. Make sure you connect capabilities to value by grounding them in problems people have, and how you help them solve those problems.

in the beginning: take inventory

I tweeted about this yesterday and immediately got a bunch of mail asking what I meant by "what's unwritten is dangerous".

In any software development or marketing organization, there is certain information that gets written down. We write down requirements, we write down schedules. We have written evidence of market research (if you've accepted that your opinion, while interesting, is irrelevant) and written examples of personas. We have piles of collateral, press releases, sales prompters and call notes. Lots of words.

The first part of my tweet related to the importance of making "taking inventory" the first "real" thing you do on the job. What you're looking to do is document what has been written down in the organization with regards to the product management process. These "artifacts" point to evidence of processes you haven't experienced and whose existence you can't prove.

From an attitude perspective, it is essential you do this without judgment. Just ask where things are, find them, and move on. No "ohmygawdIcan'tbelieveyouguysdon'thavearoadmap" comments. Really. In the words of the immortal Patrick Swayze in Roadhouse, "I want you to be nice until it's time to not be nice".

In this day and age it seems counter-intuitive to print out copies of the stuff you find that is relevant to product management, but I recommend you do. Put it in a binder with appropriate labels. This becomes your definitive record of "knowns". For knowns that are huge, print out the summary page. For knowns that have lots of history, just document the depth of that history.

Note that I'm not asking you to identify "how things are done" - just "what is written down". This is an important distinction I'll explain in a bit. And don't worry about consistency among the documents - all you care about is whether they exist or not and where they exist.

An easy way to ask for the stuff you need is to run down a list of items. By means of an analogy, you've been in a shop that's taking inventory. Workers go shelf to shelf and count things, then write down those counts on slips of paper attached to the shelf. Your job is to go shelf by shelf - business process by business process - and make sure that you can see what's on that shelf.

Once you've got that binder put together, take a look and see where the holes are. For example, and in no specific order:

1. Is there documented evidence of the vision, mission and values of the organization?
2. Is there a strategy document for each product?
3. Are there documented goals for the year? Previous years?
4. Is there evidence of whether those goals were met?
5. Is there a roadmap for every product?
6. Do you see market sizing data?
7. Do you have evidence of why a product was built?
8. Do you see market share data? Sales history?
9. Is there a record of development and launch history? (I'll eat my hat if you don't find this. It's the single-most common artifact in the software development world.)
10. Can you find support metrics? Defect tracking?
11. Can you find sales data: volumes, dollars and related funnel metrics with associated math?
12. Is there documented competitive intelligence, including how they package and price?
13. Are there documented requirements, whether that's in a RDD or as an agile backlog, with associated sources?
14. Are there user and buyer persona definitions?

Give this process a week at most. You can do it while you're meeting people, learning about products and completing your healthcare enrollment forms. Keep track of who you talk to.

When you are complete, you've accomplished three things:

1. You have demonstrated respect for and an interest in the history of the product and the company

You are the new guy or gal on the block. Prior to your arrival, the organization built, released, marketed and sold products. There are most likely customers. The exercise of looking back demonstrates that you want to understand the world you are now living in through the lens of past. . .as documented by evidence. Plus you've got fresh eyes, and that's the ideal time to "look back"; allow too much time to elapse and you'll have consumed the KoolAid and believe whatever version of history is official (e.g., Oceania Has Always Been at War With Eurasia).

2. You have established a reputation for being thoughtful about process

The reason you are there as a product manager is build products people will want to buy, and to do so in a way that is consistent, efficient, and effective. By taking an inventory of specific product artifacts, you demonstrate your expertise in your craft because you know the importance of taking a whole-picture view of what it takes to build, release, market and sell software.

3. You have not explicitly threatened anyone

Your job is not to walk around and ask "why don't you have such and such", your job is simply to walk around and find out if they exist or not, and to take a look at them to confirm they do.

In the process you will get lots of stories about why such-and-such a document doesn't exist, or why it used to but doesn't anymore - please resist the urge to do anything other than nod and move on to the next item. By taking an evidence-based approach to this inventory, you will figure out which departments and people are playing things fast and loose when it comes to process, but that's not important now.

So you've got your inventory of process artifacts. What's next? And what does this have to do with what's not written down being dangerous?

What's not written down exerts pressure on what is written down and diminishes its value. Here's an example:

A competitor releases a new version of their website that highlights a range of functional capabilities that the company's product doesn't have and which the company didn't see coming. The klaxons go off up in the executive suite, the previous product manager falls through the trapdoor in the floor down the chute to the pit of alligators, development scrambles to build the three or four features sales says are "critical", and a new version goes to market.

Then you get hired.

If your inventory revealed a gap in requirements and persona definition documentation, you could conclude the incumbent PM was the weak link, but. . .

If your inventory revealed a gap in roadmap documentation, you could conclude that the product manager's manager was the weak link, but. . .

If your inventory revealed a gap in strategy documentation, accompanied by a lack of sales process metrics, then you could conclude that senior management was the weak link, but. . .

If your inventory revealed a gap in market intelligence (e.g., analyst data, research, customer surveys, sales loss reports, etc) then no matter how well the other pieces worked or didn't work, the organization was flying blind and building things they wanted to build, unless. . .

If your inventory revealed a gap in concept testing (perhaps due to the presence of an internal thought-leader/savant from whom brilliance and insight flowed like water and whose ideas directed development), then you could conclude that development management was the weak link. . .and so forth and so on.

None of this is to say that the organization didn't think they had requirements, roadmaps, market intelligence, validated concepts or a coherent strategy. Every company will claim to have these.

And now we get to the danger. Whatever is not written down can change without warning, can't survive a change in personnel, can't stand up to objective analysis, and can't be shared or integrated into other processes in a repeatable way.

If you find substantial holes in documentation, you may find that the trail leads back to an individual who just "knows" what the customer wants, or who the customer is, or how many customers there are, or who the competition is, or how best to communicate with the marketplace, or the right price point.

How that individual comes to know isn't documented - all you can tell is that one of the elements of the product management process is based on a subjective, unwritten "known". Efforts to obtain evidence that contributes to the known can be met with "why are you looking at that, we already know it to be true". You may find that you can't challenge this individual to document the knowns they own; there are many reasons for this, some good (they're a savant who makes product magic) and some bad (they are a C-player who feels threatened by you, or someone who believes control of information equals power).

When taking an inventory of the evidence an organization uses to manage processes and make decisions, the danger of undocumented elements is that they introduce wild-cards that introduce delays, at best, or can steer you in the wrong direction, at worst.

So by making one of your first tasks on the job a comprehensive inventory of process artifacts, you're gaining immediate insight into how the organization functions. . .and does not function. Armed with that, you can lay out a plan for how you will get things done in the context of what the organization is immediately capable of doing - and set your sights on which of the processes you will work on next.

It also makes for a killer presentation.

thoughts: duplicating the "Apple Effect"

You've read about the "Apple Effect" before. It's the ability to turn your customers into a frothy horde of fans who obsess over "what's next", who consider your competition to be morally and intellectually laughable, and who will whip their wallets out to prove it.

You've wondered "How can I do that?"

You've read blogs and magazines that purport to answer that very question. Most of them are variations of the old joke "How do you become a millionaire? First, get a million dollars."

You've read Insanely Great. Twice.

You've thought about wearing a black mock turtleneck and becoming an obsessive ego pirate.

Then you've sighed and gone back to scrubbing that product backlog. Because you've come to realize, as all product managers ultimately do, that you do not have the organizational power to transform your company to that extent. The best you're likely to achieve is to transform your product, which is actually a bad thing - your company's image will become fractured as some customers get a dramatically different product experience than others.

At worst, you'll be laughed at as a half-baked doppelgänger of Someone We All Recognize.

Want to duplicate the Apple Effect?

Here's your cookbook:

1. Make sure you have power. Lots of it. Power to make people do exactly what you want, if necessary, but most importantly enough power to make people do things the way you want.

And here's that way. Simplified for Short Attention Spans, of course.

2. Find a "Path to Value" (P2V) in your target marketplace. With all the power you've got, you could get your Evil Minions(TM) to build practically anything. But you'd be best to focus on something the buyer will both love and value over time. So find that, whatever it is. Don't settle for "wow that'd be nice to have". You're not interested in building shiny pennies that people will love one day and drop the next. And you're not entirely interested in solving problems. You're interested in capturing their love, their passion, their imagination, their ambitions.

3. Find a "Path to Revenue" (P2R) for each potential P2V. It doesn't matter if the customer loves it if you can't make money giving it to them. Think about how the P2R will change over time. You're not interested in short-term cash that ends. You want a long-term relationship that works for the customer - and you.

4. Start down the "Path to Execution" (P2E) and be prepared to walk away - but refuse to give up. You may not be able to deliver on a given P2V today with the tools or technologies or people you have. But if that P2V is associated with a highly desirable P2R, damn it, you can't not deliver on it if that buyer is in your target market. So re-tool, re-think, re-engage.

5. Never Be Satisfied With The Status Quo. As the leader your primary job is to make sure each part this three-part engine stays in constant motion. Never assume you know what your customers will love - or that you are satisfied with just the the customers you always have. Never assume that you fully understand how you'll make money by making them love you. And never assume that what you create will satisfy them.

6. It's been said the first rule of Italian driving is what is behind you doesn't matter. In the pursuit of becoming a company worthy of desire, you must believe that everyone is behind you because you must know that you are more attentive to the market than anyone else. This knowing must be grounded in evidence of the process of knowing. Anything else is just empty ego making you feel good.

So go find out. Go figure out. Go build it. Be hungry. And always, always be at the front.

billy mays: lessons for product managers

Have you heard people don't read anymore?

"Ain't that the truth."

Which makes it all the more remarkable that you're reading this.

"I'm not reading - we're having a conversation. It's different."

So, Person Who Doesn't Read, have you read the article from Copyblogger on The Billy Mays 5-Step Guide to Easy Selling?

"No. I don't read blogs. They're shabby shadows of what I remember newspapers being, you know, back in the day."

If I promised you it was short and easy on the brain would you go read it?

"Does it have pictures?"

It has one picture.

"Is it of a girl?"

It's of Billy Mays.

"Hmm. I suppose you'll want me to read the comments too."

No, just the article.

"Why are you asking me to read an article about a recently-deceased pitchman's approach to selling that doesn't even have any nice pictures?"

Because it's a very crisp distillation of what product managers should build if they want their software to sell like hotcakes.

"I'm a software product manager. I'm not going to build a C++ version of the ShamWow."

But that's the rub - you could. And you don't have to be Vince Schlomi either.

"Who is he?"

The ShamWow guy.

"How do you know these things?"

Don't distract me. You need to read the article because product managers get too hung up on big brand ideas, about building segments and impressing analysts and whatnot and often forget that building products that people want to buy means you have to really think about the buyer, and what it's going to take to energize him or her to take action, and feel good about it.

"And. . .Billy Mays can tell me how to do that."

Yes.

"For a software product."

Yes.

"Do I need to double my customer's orders if they call in the next ten minutes?"

No.

response: der produktmanager

Der Producktmanager has an interesting article today on one of my favorite topics: the agile product manager.

PM's challenges with Agile go beyond how to interact with development in "real time" - they now have to translate what comes out of development to the rest of the organization. Odds are the rest of the organization isn't operating at the same speed that development is.

What does this mean?

Exampli gratia: development has decided it wants to use an Agile methodology and throws all its old waterfall chops out the window. The PM translates market requirements so development can make use of them, writes stories, owns the backlog, sets the priorities, these are pretty well known PM activities.

But now you've got "stuff" flowing out of development much faster than in the past. Marketing and sales need to be able to make use of this "stuff" - marketing needs to understand it so it can position it, sales needs to understand it so it can sell it.

Odds are strong that no one told sales and marketing that they need to be agile. They're in their own balkanized silos, they dance to their own tunes, they have their own bosses. They probably look at development with the sort of fixed smiles you save for "special people". They're not built to do sales training every few weeks to spin sales up on new capabilities. Marketing is not built to refresh the website, collateral, partners, press, analysts every few weeks.

And don't forget all the "stuff" zooming out of development needs to be rationalized to a pre-determined strategy, fit in to a pre-determined roadmap, and be able to demonstrate value through whatever success metrics have been (wait for it. . .) pre-determined to be important.

That's a lot of documentation to update. But you need to update it all because documents matter - if you're not writing all of this down, it's not real.

Agile puts the PM into the role of a "transformer", stepping down 220 volt output from the development plug to the 110 volt sales and marketing engine. Without a transformer, whatever you've plugged in will burn hot and bright for a while. . .then burn out.

In summary: just because development can create it, test it and ship it fast doesn't mean the people who need to consume it are ready for it. Ever have a waiter bring your main dish before you're done with your appetizer? Remember that feeling.

Unless your organization is totally harmonized around the idea of fast product turns, the product manager needs to "act agile" with development but "act waterfall" with sales and marketing. PMs who create "product harmony" in this way allow each silo to operate the way it wants/needs to operate to produce optimal results. That's a formula for success.

I'm curious what your real-world experiences are in this area.

call for input: the cost of knowing

Hey team - I'm writing an article on a topic of Great Importance to the #prodmgmt community.

No, it's not "Bars with Free Food during Happy Hour" or "Sure-Fire Pick Up Lines for the SDCC Cosplay Show".

I'm writing about the cost of knowing.

"What the &$^$ does that mean? It sounds vaguely 'biblical' and that's unlike you to be so crass."

That's nice of you, thanks. Let me explain.

Product managers rely on all kinds of information to do their jobs. Some of that information comes easily - unit volume, sales reports, support call volume, number of downloads. All of you SaaS cats have it especially easy. You know who you are.

Some is a bit less easy to get your hands on - sales funnel metrics, operating margins, cost of goods.

And some doesn't come easily at all - focus groups, market segment research, competitive sales data.

What I'm exploring are the challenges associated with trying to justify laying your hands on hard-to-get data, and what the follow-on challenges are once you get it.

Because if you have to justify a spend to get data, you're going to have to show that you managed to get value from it.

One of my arguments is that #prodmgmt lives without data it really shouldn't do without. It justifies "not having" this data because it's "too expensive" or "we wouldn't know how to use it".

"That's swell, Bob. Sounds like an interesting article. I've got some toast I'm working on, so unless you've got something you need. . ."

Here's my ask - if you could reduce the cost of acquiring it, what sorts of data would you, my dear reader, wish you could get your trembly mitts on?

Dream big. I want to know what you don't have that you wish you did have. It's that simple.

Thanks for the input.

palm pre: use-case analysis vs iphone

Like many of you I've been tracking the development and release of the Palm Pre as an example of how to go after a market leader.

And like many of you I've been wondering how the Palm Pre stacks up against the iPhone where it truly counts - the day-to-day user experience. Because the Pre certainly looks nice and seems to stack up well on paper, with a few key advantages that you'd think would really resonate with the buying public.

So when I find detailed user experience comparisons between the two devices, I pay close attention.

Here's one I discovered this morning on a comment chain in response to an article describing a Palm Pre tear-down over at AppleInsider.

Reader MacShack (not his real name, in case you were wondering) offered the following:

You want to go to a website on the Pre? You go to the browser. Shift open de (sic) keyboard. Type in the web address. Slide it in again to read the website. Now imagine that you are reading a web page sideways (which I do a lot). You then want to go to a different web site. You first have to turn the phone, shift open the keyboard, type in the address, shift the keyboard back in and turn the phone sideways again. What an obvious design error. At least they should have, just like the G1, have the keyboard come out from the side. This way they would have had more space for the keys, which I read are very hard to type with, and wouldn't have to turn the phone back and forth to type things on a webpage or other stuff.

I'd like to hear from someone at Palm why the aforementioned design for this use-case was chosen and implemented, and I'd like to know if they measured how often users manually navigate to webpages from other webpages while using the phone in landscape mode as part of the decision process.  Because it seems broken.

How often do the minute details of a product's design spell the difference between success and failure? Obsessing over these sorts of details may not show up in marketing materials or websites, but it is critical to the success of products you expect to be used by "real people" who get frustrated by inconsistencies in the user experience.  It's the equivalent of sand in your shoe - you can live with it for a while, but sooner or later it drives you mad.

deck: why most presentations suck

Thanks to Jon Gatrell at Spatially Relevant for turning me on to this.

And may I suggest that step one to making your presentations suck less (if not lose their suckiness entirely) is to start thinking of yourself as a storyteller who needs to entertain first and inform a close second.  It unleashes a flood of karmic goodness when you put the well-being of your audience first.

Why most presentations suck

View more Microsoft Word documents from Slideware Manager.