link: the software maven

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

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)

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.

review: gfeller field notes cover

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

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.

self-editing: tyranny and transition

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

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"

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

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.