Showing posts with label product management. Show all posts
Showing posts with label product management. Show all posts

Thursday, August 8, 2013

Best Practices from a Tomato Gardener

It's August and every day I pick a few red, ripe tomatoes from our vegetable garden.  As I admire the tall tomato plants, I am reminded of a dinner I had years ago, at a one of those upscale steakhouses with large booths, wood panelling, thick steaks, and plenty of hard liquor.

Around the table were the CEO, VP of Sales, and COO of the company I was working for.

The VP of Sales said how she much she valued working with people who were athletes, who were great team players and were driven to win.

The CEO said how much he valued working with people who had a military background - to him, business was a battle field and he was building a team to go to war.

The COO, who had just brought me in to run product management, asked me if either analogy resonated with me.  Were we in a sports competition, or were we at war?

I took a sip of bourbon and said that product management was a lot like tending a vegetable garden.  After some chuckles from the VP of Sales (who ended up being a great coach to me) and from the CEO (who ended up sending me out to many battles with engineering teams or customers), I shared some vegetable gardening best practices with them.  The bourbon kept flowing and the food was plentiful, and what may have started as a folksy analogy ended up being a great way to exchange ideas about product management.


Here are my best practices for growing tomatoes

1. Diversify. When selectings seeds, buy proven winners for your climate and soil, but also try some unusual varieties that might be resistent to unexpected drought, frost, or pests. 

2. Start Early. Germinate your seeds early. When there is still snow on the ground and the days are short, you can already give your plants a head start by providing them with rich soil, a warm space, and plenty of light.

3. Thin Out. Once the seedlings appear, thin them out vigorously.  Keep only the healthy seedlings. If you have space in your garden for 16 plants, you should have 48-64 seedlings at this point.


4. Harden Off. A couple of weeks before transplanting your seedlings, move them outside during the day to harden them off, and bring them back inside at night.  While the seedlings are hardening off, prepare the garden soil. Loosen the soil, add fertilizer

5. Leave Room for Support Structures. Layout the garden so that you can plant the seedlings far enough apart to allow space for cages, stakes, and trellises.

6. Select the Strongest. Select the strongest seedlings for transplanting.  Give the others away to friends or neighbors.  Since they have not made all the same preparations that you have, their tomatoes will never be the same size and quality as yours.  Keep a few seedlings for experiments such as upside down growing, or container gardening.  Or sneak across the street into a public space and plant a seedling, just to see if it will thrive.


7. Encourage Root Development.  When planting the seedlings in the garden soil, plant them deep.  Very deep.  Deep enough so that only the top two leaves peak out from above the ground.  This allows the plants to develop deep roots and will help them grow big and strong in the weeks ahead.

8. Guide Upwards. As your plants grow, guide them upwards, using stakes, cages, trellises or wires.  Even a small garden can yield a great crop if you use vertical space.

9. Watch the Surroundings. Watch the plants and the soil and the surroundings carefully, so you can apply water, nutrients, and pest control when it's needed and where it's needed. The larger and tastier your tomatoes become, the more attractive they are to all kinds of pests.  If you don't want to use chemicals, consider other creative methods such as plants that repel pests, netting, or noisemakers.

10. Use Creative Ways to Make the Harvest Last. The best way to enjoy a freshly harvested tomato is to simply slice it and eat it.  However, if you end up with more tomatoes than you can consume this way, make sure you have recipes and supplies on hand to make your harvest last longer: spaghetti sauce, salsa, soup, and ketchup can be preserved frozen or canned.  You can dry your tomatoes in the sun, or in an oven. 

11. Create Opportunities at the End of the Season. When the end of the season is near, harvest the green tomatoes, and make green tomato pickle, relish, fried green tomatoes, or salsa verde.

I could go on and on, but I think you get the picture.  Any of the principles that help create a successful pest-resistant, high yielding tomato patch can be applied to product management. 

Here is a picture of some of my early crop - one of which tips the scales at 638 grams (1.4 pounds)



So you can stop reading right now, slice a tomato, and eat it while you listen to another great Soul Classic: Sliced Tomatoes, by the Just Brothers


But if you're still here, let's look at product management best practices, brought to you by a tomato gardener.

1. Diversify. When looking at your product portfolio and deciding where to invest, invest in proven winners for your marketplace and your company's domain expertise, but also invest in some projects that can take your company into new markets or new problem domains, so you will be able to withstand a change in regulation, threats from competitors, or fluctuations in demand. 

2. Start Early. Start your innovations early. When others are launching a new product or a new release it is not too soon to look for disruptive ideas and incubate them in an environment that fosters creativity and risk taking. 

3. Thin Out. Once your new ideas have taken shape, in the form of prototypes or plans, evaluate them and keep only the viable ones.

4. Harden Off. Before launching the product, take the product through regular user testing to harden it off, and bring it back to the development team for iterative improvement.  While the products are going through their iterative improvements, prepare the market with promotions and education.

5. Leave Room for Support Structures.  Plan your go to market and take into consideration different sales channels. Does your pricing take into consideration revenue sharing, cost of services, and other costs? 


6. Select the Strongest. Select the strongest products for launch to market.  Spin off other ideas to partners or clients.  Keep a few immature products for further experimentation, such as open-source delivery.

7. Encourage Root Development. When releasing the product to early adopters, provide plenty of support and hand-holding.  Plenty of support.  This helps the early adopters be successful with the product and gives you reference clients and invaluable product feedback. 

8. Guide Upwards. As your products get adopted in the market, work with sales teams and clients to discover opportunities for services and new products and new benefits you can deliver to the market.  Even a small client base can yield great profits if you can deliver services.

9. Watch the Surroundings. Watch the products, the clients, and the delivery teams carefully, so you can adjust pricing, issue patches, offer services when they are needed and where they are needed.. The more adoption and marketshare your products gain, the more you have to think about support resources, product scalability, performance, and reliability.  Consider creative methods to address these issues such as partnerships, or the use of cloud-based solutions.

10. Use Creative Ways to Make the Harvest Last. You can see a lot of profit from selling your product directly to a customer.  But if you have more opportunities than you can cover through direct sales, make sure you consider partnerships or product extensions to get your product to a larger market: find ways to get to international markets, open up APIs to allow other parties to integrate with you, find ways to release the product on new platforms, or become part of larger solutions.

11. Create Opportunities at the End of the Season. If the product is near its end of life, look at how you can create solutions with components of the product.  Have you considered IP Licensing, spinning off a services business, or reusing newly developed business processes to create new solutions?

This just in:  Ned Johnson of Fidelity is having some problems with his tomato crop.
Read it in the Boston Globe



Just look at the diversified portfolio:  Cherries, Oxhearts, Swiss Heirlooms, with sprigs of Holy Basil, which has protected them from pests.



Sunday, March 28, 2010

Prodholm Syndrome: The Product Manager’s battle with Stockholm Syndrome

The legendary James Brown helps Patty the Product Manager reach new heights

Has something like this ever happened to you?

For the past 8 months Patty has been working with the same customer, a very important customer who has agreed to be the first one to implement a brand new product. Those 8 months have been full of ups and downs; requirements that surfaced way too late, product defects that proved to be very time consuming, change orders that no one wanted to approve, and new project team members that wanted to cancel the project.

But Patty was able to maintain a good relationship with the customer, she did her best to keep people focused on solving problems and putting things in perspective, and she is finally seeing her way clear to launching the product the next quarter. And just when she starts looking forward again to weekly status meetings and her issues list is showing more resolved issues than newly opened ones, Patty’s manager orders her to stop devoting so much time to the customer, to move on to new initiatives, and to tell the customer that if they don’t approve all those change orders immediately, the project will be put on hold.

Patty is shocked. She remembers clearly how on the flight back from that winning presentation a year ago her manager told her that she was the only one who could make this happen, that this was the most important customer for the future of the company and she was to do everything she could to make the project successful. And now, a year later, her efforts don’t seem to be appreciated at all, the customer’s name has gone from a magic word to a four-letter word, and no one wants to be associated with this once glamorous project anymore.

Here she is: She gave the customer her word that she would be there to make them successful. She missed her company’s holiday party because she was with the customer, she cancelled her vacation plans twice because she did not want put the project at risk… Patty wonders what she should try and rescue first: the project, her career, or her sanity.

She realizes she feels betrayed by her own manager and feels a deep loyalty towards the customer. She is worried that she is suffering from the Product Manager’s version of Stockholm Syndrome, also known as Prodholm Syndrome.

Conditions that Can Lead to Stockholm Syndrome

In 1973 criminologist and psychiatrist Nils Bejerot coined the term Stockholm Syndrome to describe a phenomenon wherein hostages have positive feelings towards their captors. Bejerot worked with bank employees in Stockholm who were held hostage by a team of bank robbers for six days. He observed that the bank employees had become emotionally attached to their captors and defended them.

Bejerot and others have identified the following conditions that can lead to Stockholm Syndrome
  • Hostages view the captor as giving life by simply not taking it. The captor becomes the person in control of the hostage’s needs for survival.
  • The hostage endures isolation from other people and has only the captor’s perspective available.
  • The hostage sees the captor as showing kindness. Hostages often misinterpret a lack of abuse as kindness and may develop feelings of appreciation for this treatment.

Stockholm Syndrome is a very serious condition. It is considered a common survival strategy for victims of abuse, and has been observed in battered spouses, abused children, prisoners of war, and concentration camp survivors. The stresses Patty experienced as a product manager by no means compare to the stresses suffered by hostages, abuse victims, or prisoners. And yet, it is easy to see the parallels to her situation:
  • She perceives the customer as giving life to the product.
  • She has become isolated from her own company and had become deeply enmeshed in the customer’s organization.
  • She has become a very strong advocate for the customer, explaining their requirements and defending their actions time and again.

Statistics from the FBI show that roughly 27% of hostages show evidence of Stockholm Syndrome. Possibly, Prodholm Syndrome is just as common, in Project Managers, Consultants, and Product Managers.

Is there a Treatment?

The literature warns us that treatment of Stockholm Syndrome takes time and patience and generally involves therapies that help the victim avoid isolation, develop support networks, and re-develop their view of nurturance and caring.

Recovering from Prodholm Syndrome also takes time. Here are some tips to help you recover:

Avoid isolation and develop support networks: Make time to participate in your own company’s events. Is it your turn to go to a tradeshow? Are there training opportunities you can take advantage of? Attend local meetings of professional associations. Use Facebook, LinkedIn, Meetup or Barcamp to connect with colleagues. Develop support networks in your family, your neighborhood, or any other community of which you are part.

Recalibrate your view of accomplishment and success. Perhaps your customer’s successful product launch is not the best indicator of success. It is possible that by cancelling the project and relaunching the product in another market segment, your company will derive more profit from the product in the long term. Think back to how you and your colleagues first presented the product to the customer. What problem were you trying to solve for the customer? Is the problem still relevant? Are there other ways you can solve the problem?

Chances are that you will not only recover from Prodholm Syndrome but come out of the experience with a better ability to manage complex projects, set direction for your products, manage conflict, and act as a mentor or source of support for others.

Prodholm Syndrome Risk Factors


An important question for those of us who are about to embark on complex projects is how to prevent Prodholm Syndrome. The three factors that put you at risk for Prodholm Syndrome are your organization, your role, and your own nature.

Some organizations are infamous for leading their employees into Prodholm Purgatory. Consulting firms may send their consultants on long-term assignments, keeping them away from any support structures. Those who get stuck on unprofitable projects may end up stuck in Prodholm Purgatory so long they decide to leave the company. Those who make it through Prodholm Purgatory can count on a promotion.

Other organizations have strong support structures ranging from mentoring programs, performance reviews, reward and recognition programs, and a clear communication of corporate and individual goals.

Some functional roles are more inherent to Prodholm Syndrome than others. Product Managers who are able to develop a holistic view of the product and market are not as susceptible to Prodholm Syndrome as implementation specialists or project managers. Some would argue that a Product Manager should never have been in Patty’s situation. A Program Manager should be responsible for the customer success, while a Product Manager looks out for the overall success of the product in the market. This is a great way to define roles and responsibilities, but there are not always enough resources to organize this way.

Finally, some individuals are more likely develop Prodholm Syndrome than others. Perfectionists,worriers, or those of us who over-empathize can develop Prodholm Syndrome quite easily.

Prodholm Syndrome Prevention


So what if you’re a perfectionist working in an organization that offers no support structures, and you have just kicked off a project that has Prodholm Syndrome written all over it?

A way to prevent Prodholm Syndrome is to get a clear understanding from all stakeholders as to what constitutes success, and to have an understanding of how the project fits into your own career path. This will help you re-calibrate your understanding of success and accomplishment over time.

It is also very important to maintain your support networks, no matter how much time the project demands of you. Tell your customer and your manager you will be attending a Product Camp on Saturday. They may be dismayed that you are not spending your Saturday catching up on issues lists and bug reports, but hopefully they will realize that the tips and techniques you will encounter at Product Camp will benefit them in the long run.

What if it’s Terminal?


So what happened to Patty? She analyzed her situation, she spoke with colleagues and mentors. She decided that her company did not offer the support she needed to be successful and she left. She setup her own consulting practice with a mission to help customers with product selection, vendor selection, and product implementation.

Patty likes to sing along with her idol James Brown to the tune of I FEEL GOOD:

Whoa-oa-oa! I feel good, I knew that I would, now
I feel good, I knew that I would, now
So good, so good, Prodholm-Free

Whoa! I feel nice, like sugar and spice
I feel nice, like sugar and spice
So nice, so nice, Prodholm-Free

When I focus on my project
I know that my decisions are sound
and when I reach out to my network
I gain perspective all around

and I feel nice, like sugar and spice
I feel nice, like sugar and spice
So nice, so nice, Prodholm-Free

When I focus on my project
I know that my decisions are sound
and when I reach out to my network
I gain perspective all around

and I feel nice, like sugar and spice
I feel nice, like sugar and spice
So nice, so nice, Prodholm-Free

Whoa! I feel good, I knew that I would, now
I feel good, I knew that I would
So good, so good, Prodholm-Free
So good, so good, Prodholm-Free
So good, so good, Prodholm-Free

Thursday, April 9, 2009

Putting Soul into a Demo

Let Proud Tina Show you How

When I joined a small startup as product manager, the head of development came to me and said "Great, now that you’re here, I never have to do a demo again." And the exciting job of doing demos of a product that was still under development fell to me.

Back then, doing a demo required flying out to see a prospect, crawling under the table in a conference room to find a phone jack, dialing out and connecting to the same server on which my new best friend in development was doing his coding, and hoping the line would stay live and the code would stay stable. I always enjoyed that moment of surprise, when I would emerge out from underneath a conference table and start matching the faces to the shoes I had been able to study as I tried to find a phone jack.

These days I can do demos via the web and have no idea who in the audience has mismatched shoelaces or is wearing loafers without socks. But at least I can count on the line staying live.

As the technology becomes more reliable and everyone in the audience is used to seeing data move from one machine to another and one state to another in real time … it becomes more important for a demo to tell a real story and illustrate the benefits that the customer will gain from using the product.

How Disappointing

It is disappointing to me how many demo’s, screenshots, or pages of documentation I see in which testuser1 logs in using password1, and retrieves a report that shows 14 records that almost identical, were it not for the clever way of reusing words like foo, bar, and asdf. Unfortunately testuser1 is not a decision maker, and foo, bar, and asdf never signed a license agreement. They may be of great help to you if you need to create a batch of test data, but they do not belong in a demo.

Create a Story

I enjoy creating stories that form the basis for a demo. When I show financial applications, the user is often Carmen Greene, whose password is sop1cam2. Carmen manages the family finances via the web. She has setup automatic transfers to the college savings accounts for Sophie and Cameron. She receives and pays utility and insurance bills. She also makes a contribution to a local sports team, and pays a vet bill for Fluffy the dog. Her husband Richard uses his mobile phone to receive financial alerts, and refinances the mortgage.

The Greenes probably look like one of those mythical families you see in minivan commercials or on brochures for life insurance. They look a little more glamorous and well dressed than ordinary people with the same income and lifestyle. They mysteriously combine features of various ethnic groups. Even their name implies that they are heading for a greener future where green dollar bills abound. It’s no wonder that every Bank or Brokerage or Insurance VP I have ever demo’d to would love to have them for a customer.

Every field has its mythical users. In healthcare demos the glamorous and supremely efficient Dr Sinha saves lives and complies with privacy regulations. In accounting applications Katherine Wong effortlessly prepares the firm’s records for an audit while setting up an overseas division in Shanghai.

The mythical users represent an idealized picture of how effective the application is. But in a way, they are just like you and me and the customer. The Greenes’ dog has fleas. Dr Sinha frequently runs down the battery on his blackberry and misses text messages. And Katherine Wong’s has lost her luggage in Singapore.

How Long is the Story?

The length of your actual demo depends on the setting

5 minutes is the limit for a tradeshow. Your demo should quickly work up to a punch line which clearly states the key benefits of the product. "Carmen can access her accounts anytime, from anywhere, and never ever pay a late fee. The savings monitor helps her plan for the future, making her a long-term profitable and loyal customer." If the prospect stays around after the punch line, you can always show reports, customizable alerts, or other capabilities, but you’ve made your main point.

30 minutes is the limit for an executive briefing. Plan the sequence of what you show very carefully and use clear transitions. "We’ve just seen how the back office staff can search for any record and give the medical staff permission to share a record. Now let’s see how Dr Sinha can quickly access information from multiple shared records as he researches a case." Hopefully you have the flexibility to adapt the story just a little bit to bring in some details that appeal to the customer, or point out features that competitors don’t have.

Anything longer than 30 minutes becomes a detailed technical discussion or use case analysis. In this setting it’s OK to do the Julia Child trick where she puts a raw chicken in one oven and produces a roasted chicken from under the counter: "Some of you mentioned you wanted to see how to customize the monthly reports. So let’s save the current order, and load the rest of the month’s data from a file…. OK, we have processed 200 more orders. Now let’s look at the reports." Oh, and by the way, if you frequently have to open files, put those files in a folder on the desktop. I once attended a presentation in which the presenter wanted to open a file and the first folder we all saw was called "Job Search" I hope he managed to find a job in which he didn’t have to do too many demos.

Delivering the Story

When you’re using a projector, test the Control F7 (or F5 or F4) feature, so that you can easily switch off the projector and search for a file.

When you’re doing web-delivered demo’s, make sure your desktop is not cluttered, and turn off your email. You don’t want emails about lost deals or high severity bugs popping up while you do your demo. And please remember that others can see your screen. If have certain keyboard and mouse tics (such as jiggling your mouse or Alt Tabbing between windows) please keep your hands away from the mouse and keyboard as you tell your story.

More Tips

And remember – it’s the story that will stick with the audience. Here are some other ways to make the story you tell in your demo relevant

Use dates in the recent past or near future. Don’t show 3 year old data when you are demoing a brand new release of your application.

Keep the data concise. Try and come up with just enough data so you can show key features and illustrate the main benefits – but don’t overwhelm the audience with reports that go on for pages, or screens that require so much scrolling everyone gets seasick.

Avoid using real names or copyrighted graphics. Demonstrate to the prospect that you respect data privacy, information security, and intellectual property.

Check your numbers. If your demo shows Carmen paying an $8,000 cable bill, the prospect may never ask you for a proposal for fear your fees will be equally wild.

This may not be everyone’s style, but I make an effort to be politically correct. I will make the female user the supervisor, and make the male user the support user. I try to show a diverse user base of an application; I believe it encourages the prospect to think about wide markets for their products or services. The first time I ever used email, I learned to use the features of the email program by reading a tutorial in which Jonathan and his grandmother exchange emails. Grandmother uses the cc feature to copy the ladies in her church. A big footnote appeared at the bottom of the page stating that "Grandmothers don’t actually use email." Whoever wrote the tutorial knew a lot about POP and sendmail and SMTP, but lacked vision when it came to the benefits of email.

What Tina can Teach Us

The fabulous Tina Turner can teach all of us a thing or two when it comes to demos. She can do her demo slowly, with lots of details. And she can do it lightning fast without losing a beat.

Listen to Tina, as she tells her story:

I left a good job in engineering
Working for the man every night and day
And I never lost one minute of sleeping
Worrying bout the way things might have been

Big deal in the pipeline
Demo better work right this time
Because my demo, demo
Demo tells the story

Worked a lot of booths in Vegas
Hours with my laptop down in New Orleans
But I never saw the good side of the city
Always kept my eyes on the big flat screen

Big deal in the pipeline
Demo better work right this time
Because my demo, demo
Demo tells a story

If you come and see my demo
I bet you gonna like the story you hear
You don’t have to worry about the competition
The story of my demo speaks loud and clear

Big deal in the pipeline
Demo better work right this time
Because my demo, demo
Demo tells the story

Tuesday, March 17, 2009

Expand Your Comfort Zone

Like a Rolling Stone

OK, I will write it down for all to see right here: I am a product manager. Sometimes I cry at work. There are restrooms on both coasts and in Europe into which I have retreated and cried, looked at myself in the mirror, and somehow convinced myself to step out that door and keep on going.It’s not that unusual really. I have come close to crying at work when I worked as a teacher, as an artist, a temporary file clerk, and as a waitress. So why shouldn’t product managers cry?

I guess what seems odd to me is that after all these years I am in an occupation for which I possess experience and qualifications (unlike the days when I tried my hand at construction, astrophysics, phone sales, or fortune telling) and I believe I have reached have some level of maturity and ability to put things in perspective, and yet I occasionally just lose it.Maybe it has something to do with being in a role in which I have very little control, and yet I feel responsible for everything. It’s a role in which I have to get involved in the detail of everything, yet I cannot claim to have expertise in anything. It’s a role in which I have to try and work well with everyone, and be prepared to deliver bad news to everyone as well.

Three constituencies

The three key constituencies I work with every single day are Sales, Engineering, and Executives. Their goals are in conflict with one another. Their working styles are very dissimilar. They often don’t trust each other. I have the privilege of working with all of them, listening to them, and trying to give meaning and direction to their work.

It is easy to imagine that if the engineers ran the company, we would have the most perfect product ever, but it would be several years late to market. If the sales force ran the company, we would give every customer exactly what they asked for, and end up with 1,000 different products. But since the executives do run the company, they give the product manager the impossible directive to “just get it done, get it done right, get it done faster, have the foresight to change direction in midstream and still get it done on time.”

In order to have a rewarding job amidst these kinds of challenges, it is important to develop effective relationships with all three constituencies, and to balance the needs of each group. We all have skills and ways of working that come natural to us.

Some of us are naturally drawn to the sales team. It’s where the energy is, where the highs are high and the lows are truly way down low. Some of us prefer to hang out with the techies, grapple with the tough problems, find elegant solutions, and revel in that great sense of accomplishment that comes with breaking new ground. Others are very skilled at inspiring executives and investors, at painting a vision for the future and distilling vast amounts of confusing information into nuggets of great wisdom, which can create unique opportunities. Yet, no matter how masterful we are at working with one area of the company – it is inevitable that another area will feel shortchanged.

Product Management Type Quiz

To help all of you assess how effective you are in working with each constituency… I have developed an inventory of Product Management types. It’s a bit like the Myers-Briggs Test, but just for Product Managers. If you are one of these people who immediately reaches for a pen - the moment you see a 10 question quiz in a magazine, no matter how crazy the topic – you will enjoy taking my quiz. If you are a product manager torn in many different directions.. give it a go and see how your score compares to the types I’ve come up with:

For each question, choose the ONE answer that best describes how you work as a product manager.


1. A nearby elementary school is having Career Day. Your job is to take 7 10-year olds on a tour of your company’s offices. Where do you take them first?

a. The R&D Area where they can see the equipment and the whiteboards full of drawings and writing
b. The large conference room where they can sit in swivel chairs and play with PowerPoint
c. The sales area, where they can see the awards and the map with a colored pushpin for every customer location.

2. Your company is in the process of acquiring a firm in Oregon. You will be going there for a one day Due Diligence visit, together with one of your colleagues. The schedule calls for a red-eye flight home. This means that you and your colleague will be spending 7 hours together at the airport. Who would you prefer to travel with?

a. The head of Technology
b. The head of Finance
c. The head of Sales

3. You just had a great phone interview with the CEO of a newly funded startup. She is looking for someone to start a Product Management team. She asks you to send her a sample of your work immediately – she wants to show it to the investor who has urged her to bring on a Product Manager. A sample that you have readily available, and that illustrates your work is.

a. A Product Requirements Document
b. A Business Case showing revenue and profitability projections
c. A PowerPoint showing a Product’s features, benefits, and competitive position

4. You have spent 3 days at a trade-show. You’ve been in non-stop meetings, demos, and press briefings. It is the last day of the show and you have 3 hours free time before you need to leave for the airport. What do you do?

a. Visit a bunch of booths and collect neat giveways so you can hand them out to the engineers back home
b. Swap badges with a colleague so you can attend the closing keynote. Corner the speaker and convince him to co-author an article with your CEO.
c. Crash a competitor’s sponsored breakfast. You are sure to meet customers who are open to switching vendors, given the competitor’s dismal financial results last quarter.

5. You and your boss are waiting for a plane. She pulls out today’s newspaper and offers you a section. Which section do you ask for?

a. Science and Technology
b. Financial News
c. Sports

6. You are expecting a call from an industry analyst who wants to interview you for a study he is doing about your product and products like it. You take a few minutes to review the analyst’s firm’s website where you notice that they have recently written a brief on a brand new company that has released a product that sounds a lot like the product your company is developing. You go to the company's website to find out more about them. There are 3 links on the company's front page. Which one do you click first?

a. Technology and White Papers
b. Investor Relations
c. Customers and Case Studies

7. It’s the Wednesday before Thanksgiving. You’ve enjoyed a nice lunch and you are about to craft your Out of Office message, when the head of sales stops by to show you an RFP she’s received. There are two other people available to help complete over 300 questions over the holiday. You glance over the questions and are quite positive about your company’s ability to win this business. You volunteer to answer the section on

a. Product Architecture
b. Corporate Information
c. Pricing

8. It’s hard to believe in these difficult times, but you find yourself with two job offers. Both jobs offer similar base pay and benefits, and both jobs provide a very good fit for your career goals. Your gut is already telling you which one to go for. Clearly, you are drawn to the job that offers

a. A chance to work with really cool technology
b. Preferred stock options that could be worth a lot when the company goes public or is acquired
c. A great big bonus if your product meets is revenue goals

9. Your favorite nephew has borrowed money from his roommates and started a business. You are very eager to see him succeed, and you agree to spend an evening here or there helping him out. As a first step, you offer to

a. Create a website for him
b. Setup Quickbooks for him
c. Listen to his sales pitch and help him fine-tune it

Let’s look at the score

OK, that’s it for the quiz. Now let’s count number of times you answered a, b, or c and plot your answers along the three axes shown below.












If you have a clear preference for working with just one area, your graph my look like this:


If you have skills in two areas, here is what your graph my look like:



And if you have the rare ability to work with all three, your graph will look like this:









Please note that the quiz results are not a reflection on your skills or experience, nor do they reflect where you spend most of your efforts. Your results show your natural tendency to work with one area of a company vs. another. They may also show where you are most comfortable in times of pressure.

Expanding your comfort zone

So now that you know where you are most comfortable, it is worth your while to consider how you can become more adept at working in areas where your natural talents and style are not as effective. A great way is to try and get just one step in front of people and ask them simple questions… When everyone seems to be flinging their questions and quandaries at you – just step aside for one minute and ask them something in return.

If you find yourself completely overwhelmed by a CEO who constantly forwards you press releases and articles – just ask the CEO what she thinks about these articles, how she has learned to sift through so many different viewpoints and distill out of it what is important today, and what to track with an eye toward the future. You may find that this endless stream of information wasn’t meant to overwhelm or discourage or distract you … It could be that all she expects you to do is organize it, and pick out one or two ideas or trends each week that simply capture your imagination.

If you find that the engineers’ endless requests for more detail and more precision create an insurmountable amount of work for you, take a step back and think of ways to provide the engineering team with new insights and inspiration. Sit down with them and provide them vivid examples of how the product is used by real people. Tell them users’ names, tell them about their interests, their ambitions, their frustrations. Before long, you will find that the engineers are able to make better decisions and require less detailed specifications – because they have a better idea of how the product is going to be used.

If you are having a hard time responding to requests from sales, first remember how fortunate you are that there are people out there selling the product. Even if they ask for things that are nowhere on your roadmap, acknowledge their input. Schedule regular feedback sessions with sales and let them know about the direction of the product. Provide them with talking points they can use at customer meetings, and questions they can ask. And make the time to go on calls with them, when you can. This allows you to talk to customers without being in selling mode, discover opportunities, and gain feedback. By working together you can align the customer’s plans with the product plans, and avoid those difficult situations where you have to commit to developing one-off solutions.

If you work in a team of product managers, you have a great chance to learn from each other and shamelessly copy the other team members’ techniques. If you are a manager and have a chance to put together a team, look for product managers with different backgrounds. Put a hot-shot MBA side by side with an experienced engineer-turned-product manager. You will end up with two very well-versed product managers.

And most importantly – look deep inside your SOUL

Back in 1972, the legendary Temptations struggled with their product management careers. Dennis and Melvin both worked for a company that was acquired, and found their products being discontinued in favor of the acquiring company’s offering. Richard’s product was months behind schedule, and everytime he tried to get consensus on a new release date, the engineers presented him with more bugs and requests for clarifications to the spec he had written. Damon spent many sleepless nights trying to come up with ways to tell customers that he would not be able to deliver all the features they had been promised. And Otis found himself just short of getting his product to profitability and dreaded the day he would have to tell his team that the company had chosen to stop all further investment.

The Temptations turned to a great source for product management advice. They turned to their mothers.

Here is the advice they received

It was the third of September.
That day I'll always remember, yes I will.
'Cause that was the day that my product was cancelled
I never got a chance to launch it
Never heard nothing but bad things about it.
Mama, I'm depending on you, tell me the truth.

And Mama looked at me and said,
"Go work it like a rolling stone.
Keep moving all around, expand your comfort zone
(Cause when you do) you’ll never be alone
"Go work it like a rolling stone, my son.
Keep moving all around, expand your comfort zone
(Cause when you do) you’ll never be alone

Well, well.
Hey Mama, is it true what they say,

that sales folks never work a day in their life?
And Mama, bad talk going around town
saying that sales folks slash our profit with a carving knife
And that ain't right.

Heard some talk about engineers endlessly coding
Talkin about refactoring while our margins are eroding
Finding more bugs, regressing in the name of the Lord

Mama looked at me and said,
"Go work it like a rolling stone
Prioritize the work and don’t postpone
(Cause when you do) your product team will hold its own."
"Go work it like a rolling stone
Prioritize the work and don’t postpone
(Cause when you do). your product team will hold its own "

Uh!

Hey Mama, I heard investors are seeking a buyer on the street
Tell me is that why I had to sign that non-compete?
Folk say accounting is doing due diligence and not paying the bills.
Hey Mama, folk say our CEO does not care about the product
Would rather outsource work or find some other construct
Mama, I'm depending on you to tell me the truth.

Mama looked up with a tear in her eye and said,
"Go work it like a rolling stone. (Well, well, well, well)
Ask questions anytime, to eliminate unknowns.
(Cause when you do) all roadblocks will be overthrown."
"Go work it like a rolling stone. (Well, well, well, well)
Ask questions anytime, to eliminate unknowns.
(Cause when you do) all roadblocks will be overthrown

This material was first presented at Product Camp Boston, Feb 28 2009. I am thankful for the participants who provided feedback.

Wednesday, March 11, 2009

Product R-O-A-D-M-A-P

Just you stick with it!

A product roadmap can be a very useful tool. A product roadmap has its limitations. A product roadmap can be as vague as the two sentences I just wrote.

What is a product roadmap?

Most product roadmaps I have worked with are diagrams that show a product or a group of products over a period of 2-4 years. There is a timeline across the bottom, and product releases are shown as blocks. Each block has a release number. Each block may list key features or capabilities of the release.





Product roadmaps use can use colors, symbols, or overlays, to indicate releases that are available on certain platforms or for certain market segments.

This roadmap for a CRM system uses one color to show releases available to customers who use the hosted version of the product, and other to show releases available for installation inhouse.








This roadmap for a mobile news service shows a timeline with major events such as the Olympics and Elections.


Regardless of how much detail the roadmap shows, or what time period it covers, having a roadmap demonstrates that the company plans is looking at future market trends and is using the insights it has gained about the future to plan development of the product. This is an important point to make to customers, investors, and partners: When they make a commitment to using the product, they do so because of what they can do with the product today, and because they believe the product will be able to support them in the future, however uncertain that future is.

Go visit an open house some Sunday. Chances are that the selling agent will tell you how well this house will suit you in the months and years to come: You can improve the yard and hold outdoor parties on those long summer nights; you can add on and accommodate a growing family. Together, you explore the roadmap for the house.

Go shopping for gift for a newborn baby. In many countries, the nursery is decorated with items that lay out a roadmap for the child’s future. A measuring stick gives the child an idea of how tall they will be; pictures of athletes or artists open up views of activities the child can explore.

A shared vision for the future

A product roadmap presents a vision for the future of the product, in the context of the market

You may have a product allows HR managers of midsize companies to manage recruiting, benefits administration, and training. Your roadmap can show that in the future you plan to create a version that is geared to HR managers of small companies, or to HR Service providers who work for companies that are too small to have their own HR professional. Your roadmap shows you have looked at your target market and made decisions on where you think the market will grow. A very different roadmap can show that in the future you plan to add modules to your product that will support other corporate functions such as facilities management, corporate travel, and leasing. This roadmap shows that you have a different vision for the problems your product will solve.

Customers can use the roadmap to plan their business: “Next year we will be able to use automated reporting and alerts. That will make our customer service staff more efficient and we will be able to offer faster turnaround on subscription renewals and exceptions. “

Developers can use the roadmap to make design decisions: “We are building screens for deployment on mobile devices. Later this year these screens are supposed to be available in English, Spanish, and Chinese. So we are designing the labels and messages in such a way that they can be quickly translated.”

Benefits of having a roadmap

The roadmap shows the order in which you plan to work on things. It shows a prioritization of work. You can use the roadmap to show that you have plans to make a new feature available, even it’s not in the immediate future. If a customer needs the feature right now, you can give them the choice between getting the feature now for a customization fee and a maintenance fee, or getting the feature at a later date, at which point it may be covered under an existing maintenance agreement.

The roadmap shows the frequency with which you plan to make releases available. Establishing regular releases helps make the rollout process more efficient and allows other stakeholders to plan activities around the release cycle. Marketing can announce the availability of new features at an industry event or in a quarterly newsletter. Customers can plan upgrades before their year-end freeze period. Somewhere underneath all the complexity of software development and deployment lies seasonality which reminds us that we have not evolved that far beyond hunting, gathering or farming. If it was up to me, I would gather requirements in the spring, develop in the summer, release in the fall and fix bugs during the winter. But I try to be agile, and I work with hosted systems so we can avoid having to ship and install new releases. Even so, I have found that the overhead of testing and releasing is too high if we try to do more than quarterly releases.

The roadmap shows what you won’t do. This is also important. If you have no plans to support certain market segments or technical environments, you can make that clear in the roadmap. Your roadmap can also show the time at which you plan to stop support for certain features or releases. And it can show what replacement or migration options are available. It is important to communicate these decisions clearly and in a timely manner. Planning for the end of life of a product is not a glamorous job. But it may be a good opportunity to connect with customers who are still using the product, and finding a solution for them that creates new opportunities.

Limitations of a roadmap

A product roadmap show more than just a dream. You can name your product “Protégé” or “Achilles” and hope it will grow up to be extremely successful. A roadmap shows the path the product will follow. But it does not show all the hard work along the way. It does not show the resources required to get you there, or the tools you will use. There are other deliverables or activities required before your development team can scope, design, or develop a release.

The roadmap is subject to change, especially the items that are planned more than 12 months in the future. I generally put a standard disclaimer on any roadmap presentation, to inform the audience that the roadmap is considered confidential and subject to non-disclosure agreements that are in place, and to inform them that dates and features are subject to change based on market conditions and customer requirements. Because we try to have regular releases, customers know that they will receive release notes a certain timeframe before a release is scheduled, and that these release notes contain a definitive list of features.

The roadmap is not the product architecture. Don’t try to redraw the roadmap so you can more accurately depict which modules integrate with what widgets. The roadmap shows bundles of value that customers can buy.

Tips for working with roadmaps

There are many charting tools out there, but just about everyone I’ve worked with uses PowerPoint to create their roadmap. PowerPoint is easy to present, and keeps you from trying to get into too much detail. If you use a box for each release or module, you can make the box clickable and take the user to a slide that lists the major features.

You may have an internal and external version of the roadmap. The internal version shows a more complete timeline and shows supporting releases or platform releases. The external version shows a shorter timeline and omits platform releases. That dreaded bugfix and code merge release does not need to appear on a roadmap you share with customers. If you are going to maintain both versions, it works best to derive the external version from the internal one.

You can create a multi-tier roadmap. One tier shows your product. A tier below it can show major market trends or technology trends. You can use the multi-tier roadmap to show how your product is in synch with the world.

And now for the Soul

No on can sell a product roadmap better than the fabulous Aretha Franklin. Listen to her roadmap presentation to a major customer who has been demanding enhancements and customizations for an old release.

(oo) What you want
(oo) Baby, I got
(oo) What you need
(oo) Do you know I got it?
(oo) All I'm askin'
(oo) Is we follow the roadmap (just you stick with it)
Hey baby (just you stick with it) follow the roadmap
(just you stick with it) oh yeah (just you stick with it)

I ain't gonna do you wrong when you buy my product
Ain't gonna do you wrong (oo) 'cause I don't wanna (oo)
All I'm askin' (oo)
Is we stick with the roadmap (just you stick with it)
Baby (just you stick with it) follow the roadmap (just you stick with it)
Yeah (just you stick with it)

I'm about to give you the very best pricing
And all I'm askin' in return, honey
Is to give me my profits
And to stick with the roadmap (just you, just you, just you, just you,)
Yeah baby (just you, just you, just you, just you,)
follow the roadmap (just you stick with it)
Yeah (just you stick with it)

------ instrumental break ------

Ooo, these new features (oo)
Sweeter than honey (oo)
And guess what? (oo)
So is your money (oo)
All I want you to do (oo) for me
Is give it to me when you upgrade (ro, ro, ro ,ro)
Yeah baby (ro, ro, ro ,ro)
Whip it to me (roadmap, just you stick with it)
When you upgrade, now (just you stick with it)

R-O-A-D-M-A-P
Find out what it means to me
R-O-A-D-M-A-P
Take care, TCB

Oh (sock it to me, sock it to me,
sock it to me, sock it to me)
A release at a time (sock it to me, sock it to me,
sock it to me, sock it to me)
Whoa, babe (just you stick with it)
A release at a time (just you stick with it)
I get tired (just you stick with it)
Keep on tryin' (just you stick with it)
You're runnin' out of enhancements' (just you stick with it)
And I ain't lyin' (just you stick with it)
(ro, ro, ro, ro) 'oadmap
When you buy the upgrade (ro, ro, ro ,ro)
Or you might stay behind (roadmap, just you stick with it)
And have no support (just you stick with it)
I got to have (just you stick with it)
A commitment to the roadmap (just you stick with it)

But watch out. Aretha can sell the roadmap just as effectively to the development teams. Every release that she ever planned was completed on time.

When you prepare for your next roadmap presentation, why not listen to Aretha on the way over to the meeting. I promise you, you will feel inspired!

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