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.
Thursday, October 29, 2009
link: the software maven
labels - reviews
Wednesday, October 14, 2009
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.
labels - news
Tuesday, October 06, 2009
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.
labels - koans, product management
Wednesday, September 23, 2009
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.
labels - product management
Monday, September 21, 2009
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.

labels - reviews
Friday, September 18, 2009
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".
- 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?
1. You have demonstrated respect for and an interest in the history of the product and the companyYou 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 processThe 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 anyoneYour 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.
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.
labels - product management
self-editing: tyranny and transition
labels - lint
Friday, August 28, 2009
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.
labels - lint
Thursday, August 27, 2009
thoughts: duplicating the "Apple Effect"
labels - product management
Friday, August 07, 2009
recommended: washimatta
Washimatta is Karen Satto's blog.
labels - lint

