Wednesday, February 4, 2009

About Soul

Ain't No Mountain



A couple of times a year, I manage to set aside some uninterrupted time to write a requirements specification. There are times when my fingers and my brain are in synch, and I am able to organize my thoughts. It can happen during a flight. It can happen during a surprise 2-hour break when a conference call is cancelled. It can happen over the weekend as I sit in the middle of the living room with the radio on and a pot of soup slowly cooking on the stove. Those are the times I am able to think back over things I have learned, read, heard, seen, sensed, or worried about, and use all these points of data to create something along a familiar pattern


  • What is our target market?
  • What trends are important to companies in this market?
  • How can our product help companies address these trends?
  • How does that benefit them?
  • Exactly what will our product do?
  • What is a concise list of features?
  • Who uses what features, and what is most important to those users?
  • Will it always be used in the same settings or are there multiple ways to use it?
  • How much does it cost?


It doesn’t take long to get down the basics. I have templates that help me organize my thoughts, and I enjoy writing. But after the initial draft has been distributed, and I have made a couple of updates based on feedback I receive, I tend to spend the next couple of weeks, or even months resolving an avalanche of issues.


  • There are constraints in the technology
  • Partners or suppliers change their roadmap
  • Key customers are acquired
  • Persistent bugs take so long to resolve that working around them becomes a project in its own right.


At some point, I go back review the requirements document and conclude that just about everything I wrote at the outset of the project has changed. And yet, the core statements I made, about the product’s goal, the way it should be positioned in the market, and the criteria for success are still as true as ever.


As long as the first few sections of the requirements document remain true, all the details that follow can change. What hasn’t changed is some deep-down quality of the product. It’s the same kind of quality that helps me recognize a childhood friend I haven’t seen for 20 years: Every single feature of my friend’s face, hair, shape, and posture has changed; and yet I recognize him immediately. What hasn’t changed is his soul. Software products are much the same. If their soul is strong, their features can change many times over.


I have often heard that all atoms in the human body are replaced or regenerated over a period of 7 years. I may still have some atoms inside of me that were with me when I plunged into the Atlantic Ocean for the 2004 Polar Bear Swim. But in a few years every atom that experienced that sudden rush of cold water will be gone. So it is with software products. Pieces of code stay intact for a long time, but after several releases and upgrades, eventually every piece of code is touched or modified. And yet the product’s soul remains.


As a product manager, I am always looking for the product’s soul. I suppose I could call it spirit, core, foundation, or value proposition. But I like the word SOUL, it rolls of the tongue easily, and it gives me an excuse to set my experiences as product manager to the tune of my favorite Motown Songs.


I have had the opportunity to work with fantastic engineers and sales people and experts in the fields of law, finance, and management. Whether they mean to or not, they often find ways to remind me that I will never be as technically astute as the engineers, never be as adept at relationship building as the sales people, and certainly never have the ability to catch potential mishaps the way lawyers or accountants can. This makes me wonder how it is that I contribute to the success of the product. It makes me feel lacking or lonely or both. But in those moments of self-doubt, I can turn to the product’s soul. I can nourish and allow it to dream. And that is a very fulfilling occupation.


This blog lacks tools and technical advice. If I come across good tools, I will try include links for all to follow. What I would like to share with you are ways you can find and nourish the product’s soul. Let’s have fun together, as we share our experiences about demo-ing the Soul, raising money for the Soul, doing Soulful Due Diligence, and testing the Soul.


The other day Marvin Gaye and Tammi Terrell were working late to try and get their product released in time for a major tradeshow. Here is what they were singing:


Listen, product

Ain't no mountain high

Ain't no valley low

Ain't no river wide enough


If you need me, call me

No matter where you are

No matter how far

Just call my name

I'll be there in a hurry

You don't have to worry

‘Cause product,


There ain't no bug severe enough

Ain't no backlog large enough

Ain't no load test slow enough

To keep me from releasing you


Remember the day

Of your launch

I told you

You could always count on me product

From that day on I made a vow

I'll be there when you want me

Some way, some how

'Cause product,


There ain't price list vague enough

Ain't no demo unstable enough

Ain't no help file small enough

To keep me from releasing you