Blog Viewer

What is a Product Manager, and Why Should the User Community Care?

By Anon Anon posted 06-10-2015 03:05 PM

  

A casual observer of this community will notice that there are quite a few members that refer to themselves as “product managers.”  Sometimes the product managers refer to themselves as product owners.  From the perspective of the community, they are one in the same.

 

I would like to share some background on the position to help users in this community understand what they do on the development team and why interfacing with the product managers is very valuable to the members of the community.

 

The UIM software development organization is quite large.  The organization is broken into smaller teams, sometimes referred to as “scrums”.   The teams are led by a group of three managers; we call these managers collectively a “triad.”  A triad is made up of an engineering manager, an architect, and a product manager.  Each triad will lead one or more development teams, and they are usually embedded directly in the team, sitting with them in the same room.

 

The engineering manager is responsible for managing the software developers, and owns what we call the “When”.  The “When” is short for “When will the product requirements be delivered?”

 

The architect is responsible for the “How”.  The “How” is short for “How will the requirements be implemented in the product?”

 

Finally, the product managers are responsible for the “What”.  The “What” is short for “What are the requirements, and what are their priorities?”  The “What” is communicated to the development team primarily through use cases.  Use cases describe who is using the product, what that user needs to do, and why it is valuable to them.  Product managers are all about the use cases.  The use cases drive the design by the architects, and the implementation by the engineers.

 

Knowing all of the uses cases is one of the greatest challenges faced by product managers.  The best product managers admit this fact, and know they must interface with the users as often as practical to capture previously unrecognized uses cases.

 

Therefore, the community is vital to the product managers and helps them to capture use cases directly from the users themselves.  Community members, who are able to effectively communicate their use cases and influence the product managers to work those use cases into the development plan, are some of the most powerful members in the community.  Those influential members have successfully opened the most direct channel available, strait to the developers themselves.

4 comments
0 views

Comments

06-15-2015 03:58 PM

It's not clear to me how the Product Managers at CA develop their user stories or use case.  No one has ever reached out to me to ask how we use the product or elicit requirements.   I've never been invited to a sprint demo for Spectrum.  On those rare occasions when we do, as part of a trouble ticket, discuss the details of how we perform various network management tasks, that information is never captured by the support engineer to inform future product decisions.  As has been discussed, the 'ideation' process has many problems and certainly doesn't seem adequate to systematically discover user stories.  So, what is the mechanism by which product managers expect to get input from customers?

06-15-2015 09:21 AM

Thanks for sharing, Jim.Perkins! Great stuff!

06-11-2015 11:45 AM

Garin,

 

> From a customer standpoint, it really looks like a lot of activity with no well defined direction.

I am happy to hear you say that it looks like a lot of activity, even on the outside.  Despite how it may appear to one who is outside the organization looking in, there is a direction.  I believe the activity you see is the result of our continuous improvement.

 

As product managers, we need to bring many different perspectives together to form our final plans for each release, and our overall strategy.   That takes a lot of work, and diverse opinions are valuable.

06-11-2015 11:11 AM

I appreciate the insight into the organization.

 

This though begs me to ask the question with regards to what the structure is to reconcile or define overlaps of functionality between scrums.

 

Consider for instance the number of places in the product today where the list of hubs is generated? service_host does it, discovery_server does it, nas does it, hub does it, it is written to the database in a couple different places, and there are a handful of legacy probes that used to do it and there are rumored to be new probes coming that will also do it. It should all be the same information, why reinvent the wheel over and over?

 

Or consider the number of different places there are to get network interface statistics? Do you use SNMP, network_interface, CDM, snmpcollector, etc.

 

I acknowledge that denormalizing functionality has its benefits - Personally I'd much rather deploy CDM and get the statistics for interfaces than have to deal with snmpcollector and its overhead.

 

So, who's driving the ship? From a customer standpoint, it really looks like a lot of activity with no well defined direction.

 

-Garin