Distinctive Competence

Steve Jobs was recently named the CEO of the Decade by Fortune magazine.  Could there be any other choice?  As the article notes, “in the past 10 years alone he has radically and lucratively reordered three markets – music, movies, and mobile telephones – and his impact on his original industry, computing, has only grown”.  Much is talked about a company having a distinctive competence – those critical assets that uniquely define and sustain a company’s being – in another words, what do they do better than anyone else.  With Apple it is very clear what their distinctive competence is; they create the most well-designed, user-friendly products that are like no other in the market.  Nancy F. Koehn writes in her article on Jobs, His Legacy:

People who work with Jobs talk about his maniacal attention to the smallest design detail. For Jobs, working in a world of engineers who are focused on the power of technology, this paradigm has never been enough. Yes, his products must be functional and fast. But they must also be beautiful.

Another example is Southwest Airlines.  Southwest has a customer-focused, low-cost operational efficiency that uniquely sets them apart from their competitors.  And now for the final question…can you quickly and succinctly describe the distinctive competence of your company?

Requirements Management Tools

I have written in the past on requirements management tools.  In Product Management Software, I refer to the work done by the 280 Group, which is a good starting point for a high-level comparison of some of the leading vendors.

For more complete and detailed information, check out the the INCOSE Requirements Management (RM) Tools Survey site (INCOSE stands for International Council on Systems Engineering).  Currently they have over 25 different tools or applications that they track in their database.  They have developed an extremely detailed list of vendor surveys for each of these products. Think of it as a Request for Information (RFI) for requirements management tools, with all of the vendors being rated for compliance for each feature/requirement.  However, be warned that the answers are provided by the vendors, but INCOSE does reserve the right to, “review and correct any informational injustices”, meaning exaggerated answers.

This site, while a bit overwhelming with all of its information, is a “must see” if you are looking to purchase requirements management software – if for nothing else than providing a detailed list of companies to start your search with.  Another site that has an even more comprehensive list of tools and vendors, including some free and open source products, is the requirements management tools list by the Ludwig Consulting Services, LLC.

Customer Visits the Intuit way

On-site customer visits are the best way to gather good requirements – no other way comes close.  The blog, Five reasons why customer visits “rock” does a great job of summarizing the benefits of customer visits over other techniques.

At a former company of mine, a User Designer who use to work for Intuit, introduced us to Intuit’s “Follow Me Home” program.  Intuit has always had a great reputation for well designed, user friendly products, and this program is a big reason why.  It started with the founder of Intuit, Scott Cook, who would go to a local Staples store, and would ask someone who purchased Quicken if they could follow them home to watch them install and use the product.  Laura Messerschmitt, who is a member of the Intuit Small Business Unit, writes about this program in the blog, What is a “Follow Me Home? She writes:

“During these customer visits, I spend about an hour observing our customer working in QuickBooks.  I [would] also check out their facility and get a good sense of how work gets done in the office.  I spent the second half of the visit asking questions and having a dialogue with the customer about how QuickBooks fits into their business.  Interestingly, I often find that the small business being interviewed gets as much out of the interview as we do: It forces them to think through why they do business in the way that they do and to come up with ideas for improvements.”

We had great success in implementing a variation of this for enterprise software, where we would “follow to the office”.  For the customer observation part, it is vital that you get direct access to the end user of your product.  This is not always as simple as one might think – particularly for large enterprise software.  In our case, our product would be managed by the IT department and it wasn’t always easy to get through them and to the actual user so you have to be persistent with your sponsor of the customer visit (which is typically IT).  At the end of the session, it is also a good gesture to present the product roadmap along with an open Q & A session; the customer will always be curious, they deserve it for being a true “partner”, and it represents a nice “present” for the host.

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).