Category Archives: product management team building

The Changing Role of the Product Manager

#ProdMgmt This is where I reveal my age! Ok, sort of. I remember the challenges of Product Managers 10 years or so ago. The major challenge back then for me was the activity of gathering information. Yes you would hear from your customers, but mostly when they wanted something or when something was not working – it was up to you to pick up the phone and call them. Another avenue for information was from analysts; an expensive option that returned slightly skewed information which was not really worth the money. Tradeshows were a great source of information – competition, customers, thought leaders, etc.; but incredibly expensive. Bottom-line – it was just plain tough and especially time-consuming to get solid, reliable information with which you made product decisions. The act of getting the information occupied a large percentage of the Product Manager’s time. Add to that, requirements writing and teaching / helping sales and well, there was no time left for anything strategic, let alone to try and stay ahead. Even after your release went GA and you distributed it to your customers, it took some time to get feedback … Beta programs occasionally worked, but not always.

Putting this into a Lean context, taking the time to gather information does not add direct value to the customer and therefore should be eliminated. In other words it is Muda.

Many Product Managers still operate this way today, but I’m seeing a growing trend of companies where Product Managers are spending their time responding to information rather than gathering it. In other words, instead of spending the time gathering information, they are doing something with it to add value to the product. Communication and the ease with which we can get information has the ability to significantly reduce the need to spend the time gathering information. Tools such as Twitter provide almost instant feedback from users. SF.com’s Ideas portal allows customers to post and vote on enhancement requests. The ability to intertwine your product and web-oriented feedback mechanisms makes it easy for customers to send you their feedback. From a Product Manager’s perspective the information freely flows in through these new mechanisms and they can now focus on what to add to the product to give the greatest value. The one new addition to the PM role is to monitor these new feedback mechanisms.

Two companies I know of push  a new release up to their site on a Friday and start monitoring the uptake and users behavior on Saturday. By Monday morning the Product Manager can assess and prioritize what needs to be done during the week. Another company uses their blog page for feedback. The link to the blog page is right there in the product to make it easy for customers to give feedback. Trends like these will continue far into the future.

Why is this happening? I see two reasons – and they are linked. First is that the rate and amount of change has increased. It is very difficult to maintain a steady course for more than 3 – 4 months. I remember not having to deal with change for a year. The other is the speed and breadth of communication. The web and the tools to mine data or the tools to send you data automatically has dramatically increased. They are linked because the more information available the more need to change what was decided.

It is very clear that our world has become and will continue to be agile – the roles of Product Manager, Product Owner, Business Analyst are in for a very exciting change. I look forward to this evolution!

Is your Org Chart Broken?

Is your Organization Chart getting in the way of creating great products that delight your customers? Is it getting in the way of capturing more marketshare?  Let’s face it, the basic structure of org charts has not changed. There’s the President along with Vice Presidents heading up the Finance, Marketing, R&D and Sales departments. But why are many companies so dysfunctional when it comes to defining, building and delivering products? Maybe it’s the structure of the organization. We’ve seen it / lived it over and over – marketing and R&D sometimes just do not play nicely together. Fiefdoms, egos, mistrust – whatever the reason, it can be a real toxic atmosphere. And when times are tough (as they are now) the departments hunker down protecting their turf. And Product Managers who straddle both sides bear the brunt of all this as they try to get products and releases out the door. It’s no wonder that defining, building and delivering products and releases can be sometimes so hard. But it doesn’t have to be.

If you are in a product-driven company – i.e. the business model for generating revenue is by defining, building and selling products – or transitioning into a product-driven company, then this blog post is for you. If you are a services-driven company and have no intentions of becoming a product-driven company, then maybe this post is not for you.

Generally speaking there are 3 major buckets of activities within a product-driven company. Finance and Corporate Services look after the internal workings of the company – making sure that everything is in place and operating properly (including adhering to GAAP so that the president stays out of jail, but I digress).  Next is Sales and Services (if Services is a component of your product offering) who are responsible for extracting as much money out of new and existing customers as possible; whether it is direct, indirect, online, telesales, etc. And last (but not least) are the activities around finding markets, defining and building solutions to address market needs and supporting customers. The latter certainly sounds like Product Management. So why do we split this between Marketing and R&D? Why do we have separate fiefdoms to support this essential set of activities? Isn’t managing the product portfolio one of the most important activities in a product-driven company?

So we need to view the org chart from that perspective. I propose an org chart that views the activities of defining, building and delivering products as paramount.

New Org Chart

As you can see I propose keeping the VP Finance and Corporate Services and VP Sales and Services roles intact. However the  Marketing and R&D roles become the VP Product Management role. This group is chartered with finding markets and their problems, defining solutions to address those problems, building the product, launching the product, communicating its goodness and supporting the customer base. As you can see everything related to the product is in one group. You’ll notice that product development reports into Product Management and that the Technical Product Manager role is absent – it’s part of Product Development. Lastly we have the CTO role. This role is about future technology – embracing new technologies, searching for / inventing technology that will improve the product in the future.

The biggest benefit? The management of the product portfolio, which is the lifeline of a product-driven company, is now the priority … not marketing it, not building it.

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.

Transitioning from Waterfall to Agile

Is your transition plan in place? Are you thinking ahead to that inevitable moment? Summer holidays are starting to happen. I can, with almost 100% certainty, state that a product manager in some company will return from holidays to hear that familiar refrain – ” we have switched to agile … oh by the way where’s the backlog”.

So before that happens when you, Mr. Product Manager, return from your fabulously relaxing holiday and you get even further behind, here are some important ideas to ponder and some key items to have at the ready before you head out on your holidays.

  1. Make sure that you have a system and process in place to easily and quickly manage your list of enhancements (the requests from customers and what you need to do to your product to help increase sales in current and potential markets). In the old methodology you were able to assemble and debate the features on the list early in the project and that’s what development agreed to build over an agreed upon timeframe. Now however the cadence of your development team (e.g. the sprint or iteration length) is short and so you need to be able to re-prioritize your list very quickly; you need to add and prioritize new items easily and quickly; and you need to be able to handle changes in business priorities very quickly. Before every sprint your list needs to be up-to-date.
  2. Make sure you reset the expectations of your executive team. In the old methodology the executive either fully participated in creating the list of features or they were peripheral to the process but kept their finger on the status of the meetings. In any event, the result was a list of features that development agreed to build within the agreed timeframe. Now with an agile methodology your executive has visibility at the sprint level. In other words, the horizon of agreement is far shorter with this new methodology; they do not have the full list of features that will be in the release – it is revealed sprint by sprint. The upside for your executive team is that the ability to embrace and react to change is far easier than with the old methodology.
  3. Make sure that you have a system in place that gives as much visibility of the project status as possible to as many stakeholders as possible. Your system should be easy to update from one sprint to the next. Executives like the high level picture – what enhancements are done, which ones are underway and which ones are ‘on deck’. Make this information available to them in real-time and make sure that the status is updated as soon as the state changes.
  4. Make sure that you have the ability and a process to assess when you have developed enough value for the release. Early in the project define the objectives of the release. Then later in the project, evaluate what has been completed against the objectives at the end of every sprint. At some point you will need to decide that you have enough value to go to market with. Everyone needs to be in agreement as to how this will be evaluated.
  5. Make sure that you gain an understanding with development on the product manager vs. product owner roles. Understand the product owner role and the differences / similarities with your role as a product manager. If you take on the product owner role then make sure that development understands that you still need to leave the office and visit customers – maybe at the most inopportune time.

If you think through these points and come up with an action plan, your transition will be relatively smooth.

Are you now a Product Manager or a Product Owner?

Agile has certainly changed the way Product Managers are perceived. In fact it raises the question within organizations that are moving to an Agile environment about what Product Management does. It raises the role of the product manager and the need for product management to the executive ranks – if it was not there already. But even though product managers have that title, are they really performing this role in an Agile environment. There are many blogs and tweets about this topic; my goal is to determine how many product managers in companies that use an Agile methodology actually perform the tasks of a product manager or do they in fact perform the tasks of a product owner.

Before we get too far ahead of ourselves, let’s look at some of the key activities for a product manager and for a product owner.

Product Managers own the product roadmap and the release strategy – they worry about the big picture. They work with all the stakeholders to maintain the roadmap and thus each of the releases and the vision for those releases are part of their responsibility. To do this effectively they need to get out and visit customers and be “plugged-in” to their target markets and the problems these markets have. They define the priority of the enhancements needed for the product based on meeting business objectives. To them the success of the product is paramount. They look for new markets for the product or ways to expand the reach of the product in existing markets.

Product Owners are responsible for delivering to the release plan – they are heavily involved in the day-to-day operations. Their focus is iteration by iteration. They write/elaborate user stories and prioritize them for each iteration so that iteration deadlines can be met. They virtually “live” with the development team(s), attending all stand-up meetings through each of the iterations. They understand the user stories extremely well and deep.

So now onto the poll.

[poll id=”3″]

If you picked that you are a Product Manager and primarily perform product owner activities, please answer the following.

[poll id=”4″]

Both roles are key to delivering products. Smaller companies in most cases cannot staff both positions. But it’s imperative that all companies understand the difference in the roles and make sure that both are adequately covered and that clear lines of delineation are drawn between the roles.

Thanks for participating.

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!

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!

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.

Building Successful Product Management Teams

I just had an interesting conversation with a friend of mine about the various activities product management performs within companies. He was fairly new to product management and was only ever exposed to the technical side of product management. Product Managers go about their daily, weekly, monthly activities – which are primarily in the tactical space … requirements gathering & documentation; working with the dev and sales teams; creating collateral; etc.; etc. Occasionally Product Managers get the opportunity to lift their heads into the strategical space and perform activities such market analysis; competitive analysis; etc. But by and large their focus is on the tactical activities.

But how do product managers determine what it is they need to do and when? How do they know when to go deep and when to pull back? People in charge of product management – typically directors – see product management from a different lens. They define what their product management team does, when they do it and why they do it. In other words one of the main responsibilities they have is the definition, implementation and training of the process within which the team operates. This typically takes anywhere from 30% to 35% of their time. The other responsibilities that they have is people and team management (typically 10% to 15%) and product strategy (typically 50% to 60%). Team management includes such tasks as mentoring / coaching; objective setting; performance reviews and product strategy is about the long term health of the product (i.e. strategy, roadmapping, prioritization, etc.).

As a director or someone in charge of a product management team are you slicing your time like this? Is something differently working for you?