Ottawa Product Management Association

To all you product managers in the Ottawa area … I’m interested in determining who would participate in an Ottawa Product Management Association. I envision that the association meetings would be on a monthly basis somewhere in the city with guest presenters or a panel discussion related to product management. The goal is to help enrich each other in the practice of product management and to network. It does not matter whether you are employed, self-employed or unemployed. If there is enough interest we can start in the Fall.

If you are interested, please send me a note through the Contact Us page on this site … use OPMA as the subject … or leave a reply below.

Twitter: An Essential Product Management Tool

Twitter over the passed little while has become, IMHO, an essential tool for product managers and product marketing managers. Articles such as 7 Reasons Why Good Product Managers Must Be On Twitter by Thomas Fuchs Martin and 5 Not Obvious Reasons Product Marketers Should Twitter by April Dunford list reasons why twitter is an essential tool. Without duplicating these articles, some of the reasons they cite include:

• Connect with other PM’s
• Get in touch with (potential) clients
• Listen to customer feedback
• Grow your online reputation
• Get inside the heads of analysts and experts
• Competitive Analysis

The challenge for product managers and product marketing managers is that they are extremely busy and adding another place to go to and look for and disseminate information is a challenge. Having been a PM and PMM for nearly 20 years I have lived this challenge. But Twitter is such an easy mechanism for doing research, publishing material and connecting that I feel it’s worth adding to your list of locations. Blogs are good for details, but you need lots of time to devote to following bloggers. Tweets are short and therefore quicker to read and follow – some have links to blogs or articles, others are part of a conversation and others are live. Luckily I’ve come across a couple of tools that make it easier to focus in on what it’s important to your PM/PMM life.

1. Twinbox - This is a newly released Twitter add-in for Outlook. Let’s face it, most PM’s and PMM’s live in their email tool – and in most cases that tool is MS-Outlook. This add-in is great. I’ve been using it for a couple of weeks and find it very easy to setup, use and filter on what’s important to me. Once you have downloaded it and installed it, you simply set your Twitter userid and password and you’re good to go. What I really like is the ability to set up Outlook folders with search criteria for that folder and then all tweets that match your criteria are deposited in that folder. This way you can set up folders that will hold tweets related to topics that you are interested in. It also has the ability to Tweet, RT, etc. directly in an Outlook toolbar.
2. TweetDeck - This has been available for awhile now – many fellow ‘tweeters’ use it. I blogged on this in early May; so without repeating the entire blog … with Tweetdeck you can define panes and search criteria for that pane (similar concept as with Twinbox). Tweetdeck then channels tweets that match your criteria into the appropriate pane. A very easy tool to focus in on what’s important to you.
3. TwitterBerry, Blackbird, UberTwitter, etc. – Applications that you can use to tweet, search, etc. from your BlackBerry device. All have different strengths and weaknesses – I suggest reading some of the blogs that compare the various applications to determine what will work for you (e.g. CrackBerry.com).

OK – so now you have your tool of choice … what do you follow? Clearly you can’t follow everything; so here are the 3 categories that I believe PM’s and PMM’s should follow (check out my blog on using Twitter for business to learn about #hashtags):

1. #prodmgmt – set up a search criteria to channel all tweets with the #prodmgmt #hashtag into a folder or pane or a direct search. This is thee place where product management folks tweet. It alerts you to upcoming webinars, it holds live “tweet-inars” (ok, that was made up), people ask questions and answer questions, etc. etc. It’s a great source of information to get ideas on how to improve your PM/PMM practices and by contributing ideas it establishes yourself as a PM/PMM “expert”.
2. Business Interest – set up search criteria to channel all tweets about the business that your company is in into a folder or pane or a direct search. Using #hashtags such as #SCM, #FOI, #DRM, etc. you can read Tweets about the business/market and contribute to the community – making you a subject matter expert. Gain incite into what’s going on in the business that you’re in.
3. Your Company/Product – set up search criteria to channel all tweets about your company and/or product into a folder or pane or a direct search. This way you can easily catch what people are saying about your company and/or product and respond quickly.

The best thing to do now is to try it. Good luck … have fun!

Iterative Requirements Management

Your release plan is done (or as done as it’s going to be at this stage). Your best estimates indicate that the development team can probably implement the top 10 to 15 items to meet an acceptable window of opportunity. The team has committed to implementing the top 3 or 4 items in the backlog in the first iteration. So now what? Well, open Word with your trusty, well-used, highly refined requirements specification template and begin writing requirements. Right? WRONG! This template probably started with great lean-ness to it; but over time more sections were added to make it “complete” … until the next new section is added. I see this so often that I wonder why we do this. We essentially are asking our product management team to write full requirements specifications within a short period of time. If you have a small PM team, then it’s virtually an impossible request. The result is that requirements are late, incomplete, not at the right level of depth, maybe even all of the above. Which means that the development team will usually “wing” it, and the PM task turns into a retro-specing exercise. Whether using an Agile methodology or a Unified Process methodology, our development teams develop iteratively (at least they should). They focus in on the next iteration and “grow” the release as they move from iteration to iteration. They tackle the high risk items early in the project. Etc. Etc. So why are requirements managed differently? Maybe because the template was approved some time ago in response to some botched feature and no one took a step back and asked how this can be better performed.

The goal of documenting requirements is to record the needs of the users in terms that development can build from. In other words the spec translates what the user needs to solve one or more of their problems into a format that development can use to design and build from. The underlying goal is that the development team needs to understand what it is that needs to be built so that they can come up with a design and an estimate for effort and risk. Collaboration between product management (representatives of the customers) and product development is essential … throwing a fully-baked requirements spec over the wall does not constitute collaboration. Presenting the requirements in layers is a better approach to achieving the goal.

So let’s break this process down into three essential layers where we present information in ever increasing depth and amount until development understands what they need to do … and no further!

1. Key Requirements. The first layer is an identification of the essential requirements – those that drive / shape the feature or capability. These are the requirements that are non-negotiable, i.e. you can not go to market without these being met. The first step is to make sure that these key requirements are captured. I recommend no more than 5 requirements, expressed as user stories or high-level use cases or declarative statements – the point is that you capture them so that the development team understands them. Present them to the team (or a subset of the team) as soon as you have them, from which they should begin thinking of the design and effort and risk.
2. One-page Requirements Document. If step 1 is not sufficient enough, i.e. the development team does not have enough information to come up with estimates for effort and risk, then the next layer is to create a single page requirements specification. Add detail such as usage scenario, actor/persona, problem solved and more depth to the key requirements and possibly even more requirements. Remember that the goal does not change – development needs to get to a level of understanding where they can come up with a design and effort and risk estimates.
3. Requirements Specification. If the previous steps are not sufficient, then the full-blown requirements spec is the last layer. In these cases the feature / capability is possibly something brand new being added to the product. You should consider maybe dividing this into smaller chunks; in some cases that may not be possible.

By managing your requirements iteratively you can put the appropriate amount of effort into your requirements that’s needed to achieve the goal (i.e. develpoment understands what’s needed from them). Do not waste your time writing requirements that do not add value to achieving this goal. In other words, once you have reached your goal, stop and move on to the next item.

I finally figured out how to use Twitter for business!

Honestly – I’m probably the last person on earth to have figured out how to use Twitter. Ok, since I don’t know everybody there’s no guarantee that I’m the last. I’ve had a Twiter account for a year or so and it was not until a couple of days ago I figured out how to use it for business. I’ve tweeted on my half-marathon training, the weather, news and other personal topics, but never on business. So for those that have figured this out, no point continuing on. But for the others read on.

I wanted to get my early thoughts down while they are fresh – so here goes. I was stumped for months on figuring out who to follow, when I had no clue as to who was using Twitter. I managed to find some interesting people and began following them, but it was a stream of conversations that I couldn’t follow and frankly missed most of them as they scrolled by everyday. Over coffee with a local social media expert he put me on to Tweetdeck. So between Tweetdeck and the concept of #hashtags, my Twitter experience improved dramatically.  Honestly!

With Tweetdeck you can view tweets that fall into categories that you define. For example, I’m interested in product management. So I set up a Tweetdeck search on all tweets that contain the #prodmgmt hashtag. Every time a tweet occurs with the #prodmgmt embedded in it, the tweet appears in my #prodmgmt search pane. Employees of companies, especially those involved with the core business have interests in the subject matter of their business as well as the role they play in the company. For example, if you are a product manager with a company that sells to the supply chain management space, you could set up a search pane for product management (#prodmgmt) and one for supply chain management (#scm). If you deliver your software as a service, set up a search pane with #saas as the search keyword, or #agile if you develop software using agile methods … you get the picture. On the subject matter end, if you’re in the DRM space use #drm as your keyword or if you’re in the FOIA space use #foia and so on. The #hashtags site allows you to search for registered tags – make sure that you pick ones that are active (i.e. there are posts at least hourly) for you to get any value.

Good luck! See you on Twitter!

Product management by committee … how sustainable is it?

I recently talked to another early stage software company that is managing their product portfolio by committee. Oddly enough they too are using an agile development approach – I believe that the committee approach fits well into the notion of daily meetings, product backlogs on the whiteboard, etc. Regardless of the development methodology I wonder how sustainable this is. At what point does this method of managing products breaks down?

Early stage companies typically have a dozen employees or so. What I’ve seen so far is that the committee consists of a combination of the CEO, head of development, Chief Architect, and head of marketing. One or more members are usually the founders / visionaries. Now each have their own roles within the company and they devote a portion of their time (roughly 10%) on the product management activity. The committee primarily decides what goes into the product and when. All works well, but the challenge they face as the company grows is that the members of the committee become more consumed with their primary roles (as they should) and the product management activities fall by the wayside. The result is that a single person – usually the head of development or the chief architect – takes on the task of deciding what goes into the product. But as the development team grows, these product management decisions are made from an internal perspective and not from the outside in as they should be. I believe that as companies approach and move through the $1.5M to $3.0M annual revenue milestone and/or the 20-25 employee threshold, they will see the breakdown of the product management by committee methodology. Most notably, committee members find it a challenge to attend meetings and to focus on the details of what needs to go into the product.

Here are some of suggestions to help get through this phase … (1) hire a product manager with product management experience, (2) invest in building an infrastructure (processes, artifacts, etc.) that meets the needs of your development methodology, (3) document your core competency, market problems you solve and why you add value, and (4) setup regular status meetings with the stakeholders. The key is to setup your product management methodology to support the next stage of your companies growth.