Tag Archives: product managers

Don’t Barf Your Message

Why do tech companies insist on barfing out their message. It’s like they have to spew out absolutely every competitive threat, differentiator, techo-wizardry, benefit, target customer in one single breath. No wonder nobody understands what they do and what value they provide. Just stop it!

I’ve run into so many tech companies that have great intentions, but eventually end up with something that’s barfed out. They start with a short, crisp, well-articulated message and then they start adding in the prepositions (by, with, including, etc.). Each crisp message, when delivered, should lead the listener to the next sentence. They should want to hear the next sentence. Each sentence should build on the next – eventually revealing the story. If fact the person you’re speaking to will guide what your next sentence needs to be; e.g. ” what do you mean by such-and-such”. I’ve been following the writings of Jill Konrath; especially her views on value propositions. Keep your messages short and crisp and your audience will understand what you’re about … remember that your audience needs to understand your message, if they don’t then you’ve wasted your breath.

Product Management and SaaS Security Issues

Earlier this week Scott Wright of Streetwise Security Zone and I got together and created a podcast exploring security issues that product managers wrestle with when they transition to a SaaS model to deliver their product. Scott in this podcast offers some great tips and advice on the following topics:

  1. Moving from isolated software products to offering them as a service
  2. Basic considerations for securing services, assurance for customers
  3. Separating data between clients who could be competing with each other
  4. User login security considerations
  5. Who administers users, and who administers the system?
  6. The big picture – communicating new kinds of risks to senior management

I highly recommend product managers visit Scott’s website and blog to expand their knowledge in security. Thanks Scott!

Ottawa Product Management Assoc. Meeting

#OPMA #ProdMgmt – The first meeting of the Ottawa Product Management Association will be a “meet ‘n greet” gathering at a pub (tentatively Tuesday October 6th, starting at 6:30pm). In order to attempt to make the location as convenient as possible (closer to work or closer to home or whatever suits), please complete the following poll.

[poll id=”5″]

Thank-you very much … look forward to seeing everyone in October!

Clearly Define your Product Manager Role!

As software product companies adopt agile principles, the role of the Product Manager is changing and therefore needs to be clearly defined and established. As more and more companies adopt agile principles, people aspiring to be Product Managers need to understand what’s in store for them over the next 5 – 10 years. Looking back over the past 5 – 10 years the greatest influencer on developing products is the increase in the amount of change. It used to be that Waterfall methodologies actually worked well. Why? The reason is that once all the up-front requirements gathering and design was completed the amount of change over the course of the implementation phase was negligible. Projects that lasted a year and delivered product that was still relevant, were quite common.

Times are different, we as consumers love choices; we love changing our minds; we love new and innovative products. Even users of B2B products see what’s happening with the technology in our private lives – for example, searching for information on the Web where variations in search terms are easily handled and returns the highest relevant item has become standard – so why can’t my B2B product have the same capabilities? This all ripples up to the developer of the product. Bottom-line is that the ability to embrace change is key to surviving … and with the amount of change increasing, this is becoming quite a challenge.

So the trend of switching from Waterfall methodologies to Agile methodologies as a way of embracing change continues. More and more software product companies (and hardware product companies with a software component to them) are adopting, to some degree, an Agile methodology (Scrum, XP, etc.) to help them gracefully embrace the change that will inevitably happen. How this happens is that the amount of up-front activity is reduced to the bare minimum (as compared to the Waterfall methodology) – essentially what’s required to support the first sprint/iteration is completed up-front. The consequence, however, is that the up-front work for each feature/enhancement takes place when needed during the project – more of a Kanban (pull) approach.

Agile methodologies (Scrum in particular) introduces the role of Product Owner. There is much debate as to whether this new role is in fact the Product Manager or what activities the Product Manager now performs. The Product Manager role is very broad – it encompasses strategic activities related to the current and future target markets, technical activities related to the actual product and communications/training/support activities related to launch and sales. The technical activities of the Product Manager role are very closely aligned with the activities of the Product Owner. In smaller companies these roles can be supported by a single person and as the company grows multiple people will be needed; split between Technical Product Manager and Product Owner where they work very closely together. Companies that already have an established Technical Product Manager role are in a good position to make this transition. The key is that this role must extend from the customer/users to the development team – user intimacy, feature prioritization, requirements definition and prioritization, customer validation, etc. are all part of the role. Technical Product Managers that are too deep into requirements and design need to “move” towards the users – i.e. they need to be more engaged with the users of the product.

Companies that do not have the role of Product Managers crisply defined, will struggle in their transition. Product Managers that do (or attempt to do) all of the activities encompassed by all segments of the role will not be able to properly embrace the cadence and needs of the Agile methodology. In other words, the ability to provide the up-front work at a just-in-time pace during the project will be severely hampered. Companies need to clearly define this “customer/user to development” role and staff it properly. Responding to change throughout the entire project is vital … customer feedback comes quickly, business objectives/situations change – all of which needs to be handled very quickly and in time so that development is always busy and working on the most important items.

So the bottom-line is that product companies need to staff a role – Technical Product Manager – that spans the length between the users and the development team. Whether this role is the same as the Product Owner, depends on the size of the company. Companies also need to staff a role – Marketing Product Manager – that looks for and understands the markets that are suitable for the company to embrace. For start-up companies that only have the resources to staff one position – staff the Technical Product Manager role (as defined above) first – understanding your users and building your product that delights them will pay huge dividends in the long run.

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!

Can you feel the business in your finger-tips?

A handful of companies ago the CEO asked me, the head of product management, if I could feel the business in my finger tips. He went on to say (while rubbing his thumb over his finger tips) that you need to be able to feel the business on the tips of your fingers. I’ve kept that phrase with me for all these years and have asked the many product managers I’ve mentored over the years the exact same question.

What it means is that you get to the point where you have so much information about the business you are in that making product decisions is easy and that you can make them with such a high degree of confidence, you just know it is the right decision. Connecting the dots, developing strategies and tactics all come easy and natural. It does not come over night; it does not come by reading reports; it does not come by learning how the product works. It comes by getting out of the office and talking to people that are connected to your business – customers, partners, prospects, analysts, subject matter experts, and anyone else who is associated with your business.

Right from day 1 as a product manager in your new company make it a habit to talk to these people. Schedule on a monthly basis to visit (face-to-face) at least 4 customers – find out about the day in the life of a user; find out their challenges before they started using your product; find out how your product has impacted their business. Arrange with the sales team to sit in on 3 sales calls a week – don’t dominate the call, don’t influence/derail the selling process … listen and learn; contribute when asked. Attend regional sales meetings and user group meetings. Seek out the subject matter experts in your business domain, and take them to lunch or dinner. Ask them anything you want about your business … including what they think of your company and your product. Sit in on all of the webinars from the analysts in your business domain. Some of it may be directly relevant, some may not – the point is to understand your business and the bounds of your business (how do you know the boundary if you don’t know what’s beyond).

How do you know when you’ve reached this state? Good question. A lot has to do with confidence. You all of a sudden wake up and realize you’re there. You can answer every question confidently without saying “I’ll have to get back to you” … maybe that’s it. Every individual is different, but if you work at it you will get there and at some point you will realize that you are there.

Is your Product Management process Agile?

I’ve read many articles on whether product managers need to become agile as the development team embraces an Agile development methodology. Saeed wrote a great article for the March ’09 pragmaticmarketing.com newsletter proving that, in accordance with the Agile Manifesto, product managers have been living the elements of the Manifesto for some time (but may not have known it). Having been with companies that decided to ditch non-Agile methods and embrace Agile development the biggest challenge for my PM team was not for the product managers to become agile (or more agile) but instead the timing of when they perform their activities. Long gone where the days of a 6-8 week planning cycle where product managers brought everything to the table and the horse-trading began. It now meant that the team had to on a regular, timely basis (synchronized with the iteration cycle) prioritize new requests for the backlog, analyze the current backlog, and describe the usage scenario and key requirements as quickly as possible … as well as meeting with customers, performing market research, liaising with the development team on the work items of the current iteration, etc.

It also meant that the team became engaged with the project throughout its lifecycle on a more consistent basis instead of cyclical as was the case with the non-Agile method – i.e. the PM resource loading for the project remained relatively constant. It also meant that they needed to iterate through the requirements gathering / analysis / documentation process. First was to understand the top 5 requirements that meet the request and convey that to the development team. Next was to drill a little deeper in areas where dev neede more understanding. And lastly was to stop, when dev understood what was needed (I recommend reading Lean Software Development by Poppendieck – it provides a great discipline for this type of an environment).

In order to become business-driven in an agile world, product management processes need to be tuned so that product managers can perform all the activities that are needed so that business objectives are met.

Conveying Requirements to Development

Quick survey, show of hands … How many reading this post use email? 1, 2, 3, 10, 100 – ok everyone! Question #2 … How many use email for sending documents? 1, 2, 3, 10, 100 – ok everyone! How often have we seen email used as a means of sending a document over the wall – far too often. I’m sure you are thinking the same thing. Your email goes bing; you read it and think where did this come from. Email is supposed to be a communication tool; but it sometimes just doesn’t work.

What happens when product managers send their requirements document over the wall to the development team? In some cases, the designer interprets the document properly and the resulting design document properly reflects those requirements. However, in more cases than we’d like to admit to, the design does not even come close to aligning with the requirements. What happened? The product manager wrote everything correctly, but the designer didn’t interpret it the way the product manager intended. Something was lost in the translation.

The goal of a requirements document is to convey what the feature or capability must do. When things go awry, it’s most likely caused by misinterpretations. In other words, the product manager and the designer (or developer or analyst) need to be on the same page. The product manager must convey his thoughts and knowledge to the designer. In many cases a document attached to an email does not do this.

Here’s what I suggest …

  1. After you understand what the key requirements are and who the key users are, arrange a meeting with the development group to present your findings. Don’t wait until you have everything and certainly don’t wait until everything is written down.
  2. Put together a 30 minute presentation (10 slides or so) that contains: your vision of the feature, what problems it solves,  and who it solves them for; the typical scenarios in which this feature will be used; and the top 5 functional requirements (expressed as use-case summaries) and top 5 non-functional requirements (expressed as declarative statements).
  3. During the presentation ask the audience to parrot back what you just presented, but in their language. This is the most critical part. They have to understand what your intentions are right from the get-go – it will set the tone for the design efforts that will begin as soon as everyone heads to their desks.
  4. After the meeting send your presentation to the development team and set a follow-up meeting to review additional requirements and the initial design. This is where the iteration process starts. Don’t wait for everything to be completed … iterate your way to completion. While you are waiting for the next meeting, write your requirements document based on the contents of the presentation.
  5. During the days leading up to the next meeting, walk over or phone the development lead to see where they are at. Make sure that they are moving down the right path; listen for hints that they are not following one of the key requirements or have made assumptions about what you presented (remember that people only retain 10% to 25% of what they hear during presentations).

Try it … I think it will help you to ensure that your development team truly understands what you want them to build. And please, don’t throw the document over the wall.