ack/nak

thinking: about the blessing of mileage

2009-11-12T21:22:00.008-06:00

A friend of mine has just started a new business - a genuine wine and cigar "bar" in Brighton, Michigan. It's already getting some great press. You should go there. But that's not why I'm writing this.

I know the guy who owns it. He is, as one of my Irish ancestors would say, a mensch. Such a man as operates this genuine wine and cigar "bar" you will rarely find, even if you lift up rocks in the search for said brand of fellow.

I know him from Way Back When, and I know a little about the trip he's taken to get to where he is today.

I don't envy him that trip.

Looking at the Facebook page dedicated to his new venture there is a picture of this man, smoking a cigar, looking quite content. When I see that look of contentment on his face, I know it's something he's paid for, and paid dearly.

Whatever joys and sorrows have come his way have created a man of substance who occupies a still point in a moving world, as Eliot would describe it.

It's not the years, it's the mileage. Sorry, Indiana, I'm going to borrow that line.

He's earned that cigar. Now you need to go buy one from him so you can reflect on the benefits of the miles you've racked up.

link: the software maven

2009-10-29T08:51:00.003-05:00

If you're a developer or a product manager who has come up through the software development ranks, you probably already know about Travis Jensen's blog The Software Maven.

What I really enjoy and value about Travis' writing is his focus on how the product development and product management roles relate (or don't relate, as the case may be) to each other over time, which is to say at different points of the software development life cycle. Each season of the product development process brings different challenges; Travis' insights into these different seasons makes for terrific reading.

So how about you take a break from the same old product management bloggy bits and explore something new. For your Added Convenience he provides a regular run down of what's interesting out on the intrawebs too, which is very helpful for people like me who tend to read all the same bloggy bits most days.

PS: I'll be coming up for air soon with news of my Exciting New Adventure, so stay tuned.

hello: visitors from pragmatic marketing

2009-10-14T14:54:00.002-05:00

If you've just finished reading my article in October's Pragmatic Marketing newsletter and have decided to pay a visit, welcome. You may skip the next line.

If you have not read that article, please refer to the link above, then come back.

For your amusement and edification I have made it easy for you to find what you want here at ack/nak. Simply use the tags found on the upper right hand side of the page, relax with a delicious beverage and your choice of snacks, and enjoy.

idea: the LRD (life requirements document)

2009-10-06T11:53:00.004-05:00

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

2009-09-23T10:35:00.003-05:00

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.

review: gfeller field notes cover

2009-09-21T15:40:00.001-05:00

Readers of ack/nak know of my great regard for Steve Derricott's wonderful Moleskine covers. Since their debut back in 2007, they've become the must-have cover for serious note-takers who want to protect their moleskine notebooks (both large and small) in the field.

A few months ago Steve sent me a prototype of a new notebook cover he's been fooling around with, with the request to try it out and let him know what I thought of it.

The Gfeller Casemakers Field Notes cover is fashioned of the same natural kip leather Steve uses to make so many of his professional products.

It is a "soft cover" designed to hold two of the Field Notes notebooks, the first of which is secured by sliding its front cover into the cover's inner front flap, the second being secured by sliding its back cover into the cover's inner rear flap. It's simple, and it works.

Those of you who are familiar with the Gfeller Casemaker moleskine covers know that these covers start out light tan - and over time weather naturally to a rich dark brown. That's your reward for using them for a long time.

As Steve says, "details make the difference": I can tell that the sewn edges have been trimmed and the sharp edges hand-softened with an edging tool. I hope the photos can give you a sense of just how well-made these are.

It's important to mention that the Field Notes notebooks are not very thick, and they aren't particularly stiff. They benefit greatly from being wrapped in something more substantial and this case does the trick. Once loaded up with two notebooks, the ensemble has much more heft to it than if you stacked two notebooks up.

And you get the little plus of two secure little pockets you can sneak bits of paper into.

For my notebooks, I use a quad-lined notebook on the left for taking notes, and a plain notebook on the right for "bookmarks".

What can I say - Steve's got another hit on his hands. You could argue that putting cheap notebooks into a hand-made leather cover is overkill. I'll argue that if you're serious about keeping your notebooks in good condition until you can get them back to "home base", then you need some sort of cover, and there's nothing more effective and durable over the long term than one made with Old World attention to detail and quality.

Gfeller Casemakers

301 E. Bower St., Meridian, Idaho 83642

http://www.gfellercasemakers.com/

in the beginning: take inventory

2009-09-18T09:00:00.007-05:00

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:

Is there documented evidence of the vision, mission and values of the organization?
Is there a strategy document for each product?
Are there documented goals for the year? Previous years?
Is there evidence of whether those goals were met?
Is there a roadmap for every product?
Do you see market sizing data?
Do you have evidence of why a product was built?
Do you see market share data? Sales history?
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.)
Can you find support metrics? Defect tracking?
Can you find sales data: volumes, dollars and related funnel metrics with associated math?
Is there documented competitive intelligence, including how they package and price?
Are there documented requirements, whether that's in a RDD or as an agile backlog, with associated sources?
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.

self-editing: tyranny and transition

2009-09-18T08:58:00.000-05:00

If you're a blogger you're familiar with the problem of self-editing. It's the blogger's auto-immune disease - with the realization that more and more people are reading what you write, you find yourself less willing to say what you're Actually Thinking.

Is what you write "serious enough"? Is what you write "interesting enough"? The "dark, inaccessible part of our personality" that Freud describes throws rocks at you and makes every word you write suspect. What you did for fulfillment and pleasure becomes strewn with land-mines. It's all very interesting at a certain level.

Once the blogger starts this cycle, breaking out of it takes something dramatic. Becoming willing to hit the "publish post button" again (and again) requires a change of mind and a change of heart, and often a change of direction.

I am, of course, referring to someone else, not me. Ahem.

bug: edirol FA-101 crashes handbrake on 10.5.8

2009-08-28T11:35:00.003-05:00

Problem: With an Edirol FA-101 firewire interface turned on, attempts to convert a M4V movie (a software demo, if you must ask) to the AVI format using Handbrake 0.9.3 on an iMac running Mac OS X 10.5.8 results in a crash.

Solution: Turn off the FA-101 and retry.

Reason: Who the heck knows.

thoughts: duplicating the "Apple Effect"

2009-08-27T20:36:00.006-05:00

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.

recommended: washimatta

2009-08-07T19:04:00.003-05:00

Washimatta is Karen Satto's blog.

She lives in Japan.

Her writing style, her photography, and her love of Japanese culture are simply delightful.

And she happens to be the best resource on Etsy for MT Masking Tape.

Which is made of washi.

If you wanted more washi, you might say, "Washi mata!"

Which happens to be something like the name of a blog I like called Washimatta.

Washimatta is Karen Sato's blog.

billy mays: lessons for product managers

2009-08-06T13:15:00.002-05:00

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

2009-07-29T09:09:00.005-05:00

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

2009-07-28T20:34:00.002-05:00

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.

still: alive

2009-07-20T20:05:00.003-05:00

Hey folks - just a quick note to let ya'll know I'm a) still alive but b) traveling like crazy and c) still alive.

To stay abreast of my current whereabouts and state of mind, please refer to my Twitter feed.

I anticipate returning to a more-or-less normal cycle of posting come August. Thanks for your patience.

bob

palm pre: use-case analysis vs iphone

2009-06-08T09:08:00.003-05:00

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.

user testing: success

2009-06-07T15:09:00.001-05:00

I wonder what the disclaimer for this looked like. . . to say nothing of the requirements.

electric stimulus to face from toniwenwen on Vimeo.

surprise: gordon ramsay's scrambled eggs

2009-05-31T12:48:00.003-05:00

And surprise surprise, not a single F-bomb.

deck: why most presentations suck

2009-05-29T14:49:00.002-05:00

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.

transitions: onward and upward

2009-05-29T08:49:00.005-05:00

Thoughtful readers of ack/nak will have noticed I've been rather quiet this month.

Like many Americans I got caught up in the economic downturn, and found myself on May 1st to be, as the euphemism goes, "exploring new opportunities".

What I made were a lot of discoveries.

One of the biggest was in stress management, as I took to going to the gym on a near-daily basis, figuring if I exhausted myself I could purge some of the stress-toxins. It worked quite well. I'm sorry I didn't discover this a long time ago.

I discovered there were a lot of people who appreciate what I "do". Thank you to all of you who reached out to me with ideas and opportunities for collaboration. Thank you.

I discovered there is a world of difference between "manning the oars" and "holding the rudder" when it comes to approaching problems - it's hard to see where you're going when you have your back to the bow of the boat.

I discovered an ability to visualize that I hadn't fully exploited. As they say in "The Secret", thoughts become things - the Law of Attraction is a powerful force available to everyone to turn your dreams into reality. And as I started to dream, I felt the fear melt away.

And I discovered - again - how wonderful my wife and kids truly are.

The journey of the product manager is never easy, it is never straight, and it is never predictable. It is also never, ever boring. As I begin a new product management adventure, I'm proud to be part of a community of professionals who never lose sight of their humanity.

I'll keep you posted. Keep those cards and letters coming.

musashi-sensei: rules for product management

2009-05-16T10:30:00.004-05:00

Shinmen Musashi No Kami Fujiwara No Genshin, or as he is commonly known Miyamoto Musashi, was born in the village called Miyamoto in the province Mimasaka in 1584.

He was the author of A Book of Five Rings (Go Rin No Sho), a philosophical treatise on the way of the sword. To the Japanese he is Kensei (literally "sword saint"), and his teachings are an essential part of the Kendo bibliography.

In his 1974 translation of the book, Victor Harris remarked that "the book is not a thesis on strategy, it is in Musashi's word 'a guide for men who want to learn strategy' and, as a guide always leads, so the contents are always beyond the student's understanding. The more one reads the book the more one finds in its pages. It is Musashi's last will, the key to the path he trod."

Go Rin No Sho is definitely worthy of that warning. I've been reading it for 25 years and it reveals something new each time I visit it.

Musashi-sensei generously provided a list of nine guidelines for students who would follow his Way:

Do not think dishonestly.
The Way is in training.
Become acquainted with every art.
Know the Ways of all professions.
Distinguish between gain and loss in worldly matters.
Develop intuitive judgement and understanding for everything.
Perceive those things which cannot be seen.
Pay attention even to trifles.
Do nothing which is of no use.

For individuals interested in strategy these are powerful and quite intimate personal lessons. Victor Harris describes the book as ". . . unique among books of martial art in that it deals with both the strategy of warfare and the methods of single combat in exactly the same way." Put another way, Musashi-sensei teaches that you cannot master the grand strategy of armies without also mastering the self.

For product managers, this is the most powerful lesson of Go Rin No Sho. We operate in a world in which we are called on to assimilate information, formulate plans, execute on campaigns and adapt to changing conditions - all without direct control of or authority over the resources who will perform the work required to achieve the goal.

I believe the superior product manager is able to accomplish this work of grand strategy if he or she demonstrates a strong competency in personal strategy - in the individual disciplines that give evidence of an ability to direct and accomplish the larger works.

Musashi-sensei wrote "all of the five books (that make up Go Rin No Sho) are chiefly concerned with timing. You must train sufficiently to appreciate all this." When to strike, and how, and why, are at the core of his teaching. Is there anything more fundamental to our craft than timing? This is worthy of some discussion, I think.

I carry these nine guidelines with me wherever I go. Next time we meet, ask for a copy and I'll give you one. You'll probably be better at many of them than I am, and I'll look forward to learning from you.

____

A Book of Five Rings by Miyamoto Musashi, translated by Victor Harris (The Overlook Press, 1982)

transparency: your calendar

2009-05-05T06:20:00.002-05:00

If I were to magically gain access to your work calendar would it tell me anything about your priorities? Or would I just see "meetings"?

Product managers and product marketers live in an intensely networked world - our jobs require us to spend a disproportionate amount of time in meetings with others in order to accomplish our goals. Take a look at any of our calendars and you'll see a patchwork of weekly/monthly/quarterly/yearly recurring meetings. During release seasons, you may see that we're completely booked.

It will be immediately clear what's "urgent". But will it be equally clear what's "important"?

I ask because one of the quality-of-life problems for practitioners of our craft is - wait for it - not having enough time to dedicate to the long-cycle problems. And one reason we don't have enough time is that we're too free with it.

Have you ever heard the following statement: "I looked at your calendar and saw you were free, so I scheduled a meeting with you"?

Conversely, have you ever heard the following statement: "I looked at your calendar and decided what I needed you to do was more urgent than what you had scheduled at the time, so I scheduled a meeting with you"?

My bet is you've heard both - the former from peers and subordinates, and the latter from the folks you work for.

In both situations you ask yourself- do you want to be the one who DECLINES the meeting and upsets the cart? Or do you just accept, secretly resentful that you've been pulled away from a task that you need to accomplish? Are the first words out of your mouth at the meeting "where is the agenda" and "I have a hard stop at. . ."?

Or: do you schedule time to advance your non-urgent (or "long-cycle") agendas, and if you do, do you label them in a manner that would make sense to a third party? Beyond the title, do you include any details in the meeting notes that could help the viewer understand what you were doing and why?

I ask for two reasons - one external to you and one internal - with a bonus outcome you may not have anticipated.

Externally, booking your own time for activities that make sense to an external viewer raises the bar for someone looking to take that time away from you. It also forces you to "reschedule" those activities to remove the conflict from your calendar (if you accept the meeting), which means they'll still get done. Marking a time for "projects" is OK, but it's not going to stand up to much external scrutiny.

The bonus outcome is you become more transparent. Your process for advancing your personal agendas is visible to everyone, especially those whose contributions are required for you to accomplish them. For the members of your team, imagine seeing an item on your calendar that reads "update team MBO progress" every month.

And this helps to make time for the activities that can get "lost" - how many of you PMs wish you had more time to spend with telesales? Get it on your calendar. Tell them that you've got time dedicated to them each month, and that they can book you for time to sit at their desks with a pair of headphones on, listening to actual prospects.

It also serves as a helpful tool for justifying an investment in additional staff - when you run out of time to advance the agendas you've been assigned you have three choices: find more time, eliminate some existing agendas from your list, get more resources. Option number one is only an option if you're not managing your time well, and option number two is only an option if you're not managing your priorities well. Once those are both as tight as you can get them, you can make a good argument to add staff.

I'm sure there are other benefits that you, my dear reader, will remind me of. But I've run out of time today to write you and must move on to my next activity.

"7:00am: make coffee for Julie"

No way am I rescheduling that.

quiz: do marketers and programmers talk?

2009-04-22T22:32:00.002-05:00

Please respond in the comments.

Yes - our marketing guys and our developers talk all the time, and have a deep appreciation for each other's perspectives on creating and selling products. That's not to say that they're best friends, but they have an active dialog going on.

Maybe - I think they know that the other guys exist, and I think they've been known to say hello and share brownie recipes. Occasionally.

No - our marketing folks and our developers get along like turkeys and wood chippers. In fact, I don't think I've ever seen them talk to each other. I'm not sure they even speak the same language.

the tyranny: of twitter

2009-04-21T22:29:00.010-05:00

SET RANT_ALERT=ON

True story: Since I started "tweeting", my blog output has sunk to an all-time low. All Time Low, I tell you!

Yet during the same period my tweet-rate has increased. Increased!

Am I proud of this? Buh no.

Do I think that tweeting has the same nutritive value as blogging? Buh no.

And yet. It offers a poke to the pleasure center of the brain that blogging does not - specifically, it focuses the mind to be expressive in 140 characters. It's fast. Oh, so very fast. Hit the update button and shaZAMM, you've blurted 140 characters of erudition at all of your followers.

Instant gratification ho!

Why wait for your loyal readers to wander by your blog and tediously shamble their way through your latest article when you can submit them to an episode of id gavage.

When I'm writing here, 140 characters doesn't buy you much. I can't get out of bed in 140 characters.

And yet, I have been tweeting. Quite a lot, at least by my standards.

And in the course of doing so I've learned two simple lessons: you can't create and sustain a narrative thread in 140 characters. And it's really hard to establish a relationship with readers 140 characters at a time.

So here's the challenge. In a world in which the tyranny of Twitter is compressing attention spans in inverse proportion to the volume of messages assaulting those newly-compressed attention spans, what can one do to adapt?

Well, we can settle for reducing complex concepts and thoughts into fortune cookie-length declarative statements, like "product managers must lead" and "it's important to be nice".

Or, we can agree that Twitter has its uses. And like all good tools, it should be used for what it is good at. Not more.

The bottom line: I apologize for my drop in ack/nak posts. I've learned there are a lot of things I can't express 140 characters at a time. So I won't try.

I look forward to sharing them with you here, even if I end up reducing complex concepts and thoughts into fortune cookie-length declarative sentences. The difference is that over here, they're short by choice, not by design.

And I promise to use whatever "influence" I gain for good, not evil. You're not so much followers as fellow travelers, and I value being on the road with you.

best: excuse for not podcasting

2009-04-14T09:27:00.001-05:00

It's unfair how clever certain people are (exempli gratia).