Adoption of Product Management Software

The 280 Group recently conducted a Product Management Survey.  One of the survey questions was how many product managers (or companies) have purchased or subscribed to product management software.  What they found was that, “83% of respondents have NOT purchased product management software. Of the 17% or so that have, only 22% are very pleased with their purchase (i.e., love it). Widespread adoption and success appears to elude product management software vendors.”
I have considered product management software in the past, but as anyone who has ever written requirements knows, it just is not a “must have” or “P1″ requirement.  There are other ways to write and manage requirements, and I am among the the majority of product managers that depend on tools such as MS Word, MS Excel, Wikis, etc. for my managing product requirements.  Of course, these tools have their disadvantages, but it is a difficult hurdle to make the case for product management software, especially in this business climate.

Check out my article in the Pragmatic Marketing Newsletter

My article, Time Management for Product Managers was published in the September issue of the Pragmatic Marketing Newsletter.   This article addresses the struggle all Product Managers have to manage their time effectively.   The article describe how I have extended the prioritization matrix first developed by Stephen Covey to ensure I focus my attention on those activities that contribute towards my strategic goals.   Check it out!

Product naming and version number conventions

The Pragmatic Marketer, Volume 7, Issue 4 was published today and there is an excellent article in the Ask the Expert section that product managers can learn from when structuring their product naming conventions.  This is always a source of great debate, especially in startups where no standards exist.  This article presents some excellent conventions and backs it up with sound reasoning for it.

What Sales People Can Learn from Product Managers

I’ve been involved in enterprise software throughout my career as a system engineer, consultant, engineer and product manager.  Selling software into large organizations is a tough business, and I have seen the good, the bad and the ugly.  Before continuing, let me submit a full disclaimer that I have never sold software.  Doing so requires a necessary trait that I am simply not good at – asking people for money.  However, through thousand of hours of observation and working with sales in my capacity as a product manager, I have come to the conclusion that there are some traits that all high tech sales people could learn from Product Managers and in doing so become more successful.

The article Top 10 Reasons High-Tech Salespeople Fail… and What to do About was very enlightening, I encourage all to read the article in its entirety.  I found myself shaking my head in agreement throughout.  In particular, two of the top ten reasons stand out:

Reason #3—Sales people talk too much.
Oh, gee, do you think?  Of course not all do, but some just purely love the sound of the own voice so much they should audition for American Idol.  Sales people need to listen more and ask the right questions to uncover the business problems of the prospect.   See The Requirements Funnel for more on this topic, albeit with a product management slant to it.

Reason #5—Product training is over emphasized, product knowledge miss-used, and selling becomes presenting.
Before presenting to a customer, doesn’t it make sense that you need to understand what their business problem is first?  Some sales reps and their system engineers drone on and on with slides and demo features that prospects do not care about.  They need to focus on finding out what the problem is first and presenting a solution for it – sell a solution, not features.

And, there is another of the top ten that I just have to mention as one of my biggest pet peeves…

Reason #2—Spending too much time with prospects who will never buy.
To one who is not familiar with enterprise sales, this may seem foolish.  Why on earth would a account manager spend too much time with prospects who will never buy, but it happens all the time, and the authors have pinned it down perfectly.  Sales reps won’t ask the hard questions for fear of losing the prospect.  This is why as a product manager I always like to see the forecast before I get involved.  I’ll give my heart and soul to a viable prospect that has been qualified, but don’t waste my time if the customer is not the decision maker or has no budget.  If the account needs some more nurturing, then that is what system engineers are for – not product managers.

Five Simple Rules for a Bug Review Board

Bug Scrub, Bug Review Board, Triage,…, these are a few of the formal names and there are many more informal ones that I cannot print here.  Some other Product Managers have written on this topic.  Ivan Chalif (aka “The Productologist”) wrote the blog How I Learned to Stop Worrying and Love Bug Scrub which is bound to catch the attention of all Product Managers.  The The Cranky Product Manager also wrote a very humorous blog The Joy of the Bug Scrub.  Bug Scrubs (I prefer Bug Review Board or BRB) do not have to be so bad if properly managed.  Here are my five simple rules for a BRB:

1. Make it a recurring meeting so it is always on the radar of the BRB members.  It is too difficult to get all the key stakeholders together for “one-off” meetings.  How frequent?  It depends on how many customers you have, where in the release lifecycle the product is, and how big the product is.  Weekly should be fine in most cases, although the closer to a release, you may have to go to bi-weekly or daily for a period of time.
2. Invite just the key stakeholders only, making sure you have representation from the cross functional groups – Engineering, QA, Support, and Pre-sales (System Engineering).  Having too many people in the room can lead to disaster.  Too much democracy in a BRB is sometimes not a good thing.
3. Do not let the meetings run over. If there is ever a meeting where people get punchy and make bad decisions, it is the BRB.  Schedule a follow-on if you have to.
4. Always send a reminder (via Outlook for example), reiterating the agenda, reminding people to come prepared, and a high-level summary or status.  The summary might include some particular bugs that BRB members should review beforehand, a note indicating a sharp increase in the number of high-priority bugs, some specific customer-related issues, etc.
5. Have a specific owner for the BRB meetings.  It doesn’t necessarily have to be the Product Manager, although I believe it should be.  Keep in mind that controlling the keyboard has its advantages in keeping the meeting moving and casting the final decision after discussion has waned.

Ignore your customers?

I recently read a editorial in Fortune magazine by Justin Fox titled, Ignore Your Investors! The them of the article is on the premise of shareholder value, which came into vogue in the 1980s. It had CEO’s enamored with pleasing the stock market (aka the “shareholders”) with an obsession over meeting quarterly earnings or other means to immediately boost the stock price. With the rise in stock prices came incentive bonuses, awarding of stock options and more. What suffered was the long term strategic thinking, thus, by focusing on the short term, their companies inevitably became less valuable in the long run.

So how does this relate to Product Management? Very easily. Customers will always be at the ready with new features they want to see added to the product. Most will make sense, but others will not necessarily be tied to any strategic direction of the product (the roadmap). Too many bells and whistles will start to create feature bloat or cause performance problems. Product Managers need to balance customer requests with long-term innovation to keep the product fresh and poised for the future growth. Funding product innovation will partly come from slowing down the rate of customer requests in the product until the new release or architecture can come to fruition – and most likely satisfy the customer better in the long run.

So am I really proposing to ignore your customers? No, of course not. What I am saying is that it is necessary to balance short-term requests from customers with the longer term roadmap or vision. Too much focus on the color or arrangement of the chairs on the deck of the ship means you might not be watching where the boat is headed. This is not too different than the principal of “shareholder value” vs. a focus on the long term.

Product Review: Get organized with Evernote

Product Managers are prolific writers; product requirements, use cases, market research, competitive dossiers, sales collateral and the list goes on.  This involves collecting, collating, and summarizing information from Internet sites and various file formats such as PDF, MS Word, Excel, etc. If you are looking for a great tool to help organize and search through your notes and information sources, then Evernote is the application for you…oh, and by the way, it is also free (there is a premium option available).

Time Management for Product Managers

Product Managers are faced with a constant struggle to manage their time effectively.  I have relied on a prioritization matrix developed by Stephen Covey to ensure that I focus my attention on those activities that contribute towards my strategic goals.  Without doing so, I have found that it is too easy to get consumed by non-important tasks.  Covey first introduced his time management matrix in his book, The Seven Habits of Highly Effective People.  It involves a matrix composed of four quadrants that define how we spend our time:

I.      Important and Urgent
II.     Important but Not Urgent
III.    Not Important but Urgent
IV.    Not Important and Not Urgent

When the wind blows, some people build walls, others build windmills

The title of this blog entry is an ancient Chinese proverb, and very applicable to the days we live in.  I read recently where a CIO was saying that recessions provide the opportunity for IT organizations to reinvent themselves.  Uncertainty, fear, and even crisis can present opportunities if people are willing to think out-of-the-box.

Some software companies are doing this now.  My friend John Newton, co-founder of Documentum and currently the CTO and Chairmain of Alfresco, speaks about this in his blog entry, New Alfresco 3.2 was designed for the Great Recession.  John writes that last fall they saw the recession as an opportunity to highlight the value-add that an open source Enterprise Content Management solution can offer an organization that is looking to cut costs and “do more with less”.  Thus, Alfresco Community Edition 3.2 was recently released which is designed for the “Credit Crunch”.

It’s not just customers that Product Management needs to listen to, but the overall mood in the marketplace – a recession is the right time to look for opportunity when others are burrowing their heads in the sand.

The Requirments Funnel

When talking to customers a Product Manager needs to follow two simple rules; a) listen much more than you talk and b) ask the right questions and in the right order. The first rule is self-explanatory and should be easy – let the customer have the floor, however I know some Product Managers who seem to have a tough time with this. The second rule requires some explanation. To understand what a customer truly needs, the Product Manager needs to drill-down on their business problem in three levels:

1. Discover the pain points
2. Find the reason for the problem
3. What is the impact of the problem

The concept of a funnel is a practical way to show how the business problems of a customer can be reduced down to a concise set of workable requirements.

[click to enlarge]

The Product Manager needs to discover the pain points by asking general questions to understand the scope and nature of the problem. Once the pain is exposed, understand the reasons for it…what caused the problem. Finally, the customer needs to articulate why this is a problem. Is this impacting productivity or slowing down user adoption?

The Product Manager should conduct customer visits as a interview session, so be a good reporter, listen, and ask plenty of questions. Keep the Requirement Funnel in mind as you flush out the pain, the reason for it, and what the impact is.