Thursday, October 29, 2009

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.

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.

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.

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.