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
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
No comments:
Post a Comment