All Things Product Management

Product Management for the High Tech Professional

Book Review: Writing Effective Use Cases

Posted by Mark Officer on March 16, 2010

Writing Effective Use Cases Front Cover Alistair Cockburn is a well-renowned expert on agile development and use cases; his book Writing Effective Use Cases is a “must read” for all product managers.  There are professional books that you read, then put aside and sometimes you might refer to them.  Other books become part of your core reference library, never far from your reach, dog-eared from frequent reading, and filled with highlights and underlines – this is one of those books. 

For someone who has never written a use case, this is an excellent starting point, covering all you need to know about use cases to be successful.  For those that have written use cases, I am confident that you will find many new valuable nuggets of information that will help you in your job.  The book is manageable in length (270 pages including appendices and index) and very practical with many examples of uses cases throughout (including examples of bad ones).  The most valuable aspect to the book is Cockburn’s professional advice and tidbits that he sprinkles throughout the book.  Anyone who is familiar with Alistair Cockburn’s work knows that he has a great deal of experience, and it shows in this book.  This book is short in theory and long in real-world examples.

Cockburn refers to use cases as “scaffolding” that connects various pieces of the project, which is very true.  Use cases are crossed linked to requirements, user interface designs and test plans, creating a traceability matrix throughout the lifecycle of the project.  Cockburn dedicates a chapter to how use cases fit in the overall process.  Managing the entire body of use cases is just as important as writing them.

A big part of any product manager’s job is time management, and Cockburn addresses this in the book.  It is not feasible to write detailed use cases right from the start, and it certainly cannot be done for all of the potential uses cases.  Cockburn stresses the importance of “warming up” with use case briefs or narratives, and then working towards more detailed, fully dressed use cases.

I like how Cockburn distinguishes between requirements and use cases – this is an important concept for product managers to understand.  In short, use cases really are requirements.  Properly written, use cases describe the behavioral requirements.  However, with that said, use cases do not deal with all requirements such as the non-functional ones (external interfaces, performance criteria, documentation standards, etc.).

For those product managers that already have their own format or preferred method for use cases, Cockburn provides many examples of different use case styles.  He is quite flexible in this regard, understanding that use cases are, “fundamentally an exercise in writing prose essays, with all the difficulties in articulating good that comes with prose writing in general”.  What Cockburn is very insistent about is that the use cases must be easy to read, short and clear for all stakeholders to understand.

There are other excellent books on use cases (Use Case Modeling by Bittner and Spence is one I would also recommend), however, at the end of the day, a product manager needs to adopt one standard and run with it.  Cockburn’s book fits this bill and more.  I would highly recommend this book for new or experienced product managers.   

Posted in Book Reviews, Product Management | Tagged: , | Leave a Comment »

Distinctive Competence

Posted by Mark Officer on December 14, 2009

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?

Posted in Planning, Product Management | Tagged: , , | Leave a Comment »

Requirements Management Tools

Posted by Mark Officer on December 10, 2009

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.

Posted in Product Management, Tools | Tagged: , , | Leave a Comment »

Customer Visits the Intuit way

Posted by Mark Officer on November 24, 2009

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.

Posted in Product Management | Leave a Comment »

Adoption of Product Management Software

Posted by Mark Officer on October 31, 2009

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.

Posted in Product Management, Tools | Tagged: , , | Leave a Comment »

Check out my Article in the Pragmatic Marketing Newsletter

Posted by Mark Officer on September 17, 2009

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!

Posted in Planning, Product Management | Tagged: , , , | Leave a Comment »

Product Naming and Version Number Conventions

Posted by Mark Officer on September 8, 2009

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.

Posted in Planning, Product Management | Tagged: , , | Leave a Comment »

What Sales People Can Learn from Product Managers

Posted by Mark Officer on September 4, 2009

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.

Posted in Marketing, Product Management | Tagged: , | Leave a Comment »

Five Simple Rules for a Bug Review Board

Posted by Mark Officer on August 31, 2009

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.

Posted in Product Management | Tagged: , , , , , | Leave a Comment »

Ignore Your Customers?

Posted by Mark Officer on August 27, 2009

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.

Posted in Product Management | Tagged: , | Leave a Comment »

 
Follow

Get every new post delivered to your Inbox.