Category Archives: Process

The Importance of Perspective

Steve Johnson has a video on his site that shows a wonderful optical illusion. I’ve embedded it here for your viewing convenience.

This video is a great example of how important a role perspective plays in how we interpret our environment.

Perspective is also incredibly important for people when researching, designing or building products.

Specifically for Product Managers, it’s important to be conscious of how your perspective (your background knowledge, assumptions and existing viewpoints) on a situation influences how you interpret it.

To maximize your perspective, and avoid false assumptions and conclusions, try to get as many inputs as you can when researching requirements. This does not simply mean talk to more people, but make a conscious effort to to improve your domain knowledge, document and validate your assumptions clearly, and talk to different types of people in different roles, in different types of companies and with different needs.

It’s actually quite amazing how much insight you can gain by consciously broadening your perspectives on a given situation.

Saeed

Product Management Metrics (part 2a)

My  conference call on PM Metrics with Tom Grant went quite well yesterday. It was a round table discussion with good points made by several participants.

While we did talk about a number of topics, the metrics discussion dominated the first 1/2 of the call.

One of the questions  — What metrics should be used to measure the effectiveness of Product Managers? — got me thinking a bit.

My answer on the call was that first the focus should be on metrics for the Product Management organization, and then a breakdown from there on metrics for individuals based on objectives and tasks that support the goals of the organization.

To me that seems like a logical approach, because all other organizations in a company, includes sales, marketing, technical support etc. have metrics defined and measured that way.

So what’s the problem?

So why is it so hard to come up with metrics for the Product Management organization? Well,  it goes to the heart of the major issue with hi-tech Product Management today.

And that is that most companies don’t look at Product Management as a holistic function within the company, but rather as a set of individuals or small teams working on a variety of product related tasks.

Look around and see how the focus of Product Management is different in different companies.

Look at how widely the reporting and organizational structures are for Product Management. It is part of Marketing in some companies, part of Engineering in others, a standalone department in others.

Look at the ongoing debates related to when Product Management roles should be defined and introduced in a company.

If you’ve worked in or have been exposed to Product Management in different companies, compare and contrast the tool sets (or lack of them) used by Product Management organizations versus the tools used by other departments to do their jobs.

And if people don’t look at Product Management and it’s objectives in any holistic and standard way, how can they set about defining and measuring key metrics for the Product Management organization?

Metrics should focus on measuring intended outcomes

For Sales organizations, the key metrics  (product sales/bookings etc.) are directly tied to the intended outcome of the function: generating sales and revenue.  There are numerous secondary metrics that are tracked such as  sales breakdown by product/product family, by deal size, by geography, by new vs. existing customer etc.

And don’t forget all the sales funnel metrics that are used to track progress and success, such as average time to close, win/loss ratio etc. The important metrics are clearly tied to the intended outcomes of the activity of the sales organization.

For marketers it’s a bit more complicated because there are different roles in marketing and different intended outcomes. The two primary outcomes that can be applied to marketing are related to lead generation and market/industry awareness.

And from there numerous metrics can be identified related to number of leads, cost per lead, lead quality, lead to prospect conversion ratio etc.

Metrics for awareness are numerous, but basic metrics focus on “mentions” by press, analysts and other influencers in publications, reports, blogs, and via social media such as Facebook and Twitter.

And what of Product Management?

What is the primary objective of Product Management? In a previous article on this blog entitled Product Management Metrics (part 1), I defined the mandate of Product Management as:

To optimize the business at a product, product line or product portfolio level over the product lifecycle.

Don Vendetti of Product Arts, wrote a series of guest posts, entitled Measuring Product Management. In part 3 of his series, he provided his definition of the Product Management mandate:

To deliver measurable business results through product solutions that meet both market needs and company goals.

I like Don’s definition.  Both definitions share the same spirit about business focus,  but Don’s phrasing is clearer and more explicit than mine. But I do think that mention of the product lifecycle is needed because that has a huge impact on the objectives and the required focus of Product Management.

Don’s use of the words “measurable business results” is crucial to this discussion.

So what are those business results? Well it depends on the business and the company goals. 🙂

Those goals depend on the many things. Some companies care about revenue. Others care about market share. Others care about profitability. Others only care about getting acquired. And those goals can change with time.

Some choose to be technology focused, while others are sales, marketing or market focused. Some companies have a single product, while others have portfolios of products.

Depending on the company’s goals, size and level of maturity, the market conditions, it’s financial status and it’s overall strategy, Product Management’s objectives will change and so the metrics to measure Product Management will also change.

I’ll stop here, but I’ll pick up this discussion in an upcoming, and long overdue post that will be entitled Product Management Metrics (part 3).

Make sure you read Part 1 and Part 2. 🙂

Saeed

Questions for Product Managers

It started with an interview on Red Canary, talking to Product Management leaders in Toronto, including Alan Armstrong, Stephen Pollack, Lee Garrison and Roy Pereira.

Interestingly enough, I know all of these people personally. I have worked with  Lee & Alan, worked for Stephen, and know Roy through very close common contacts.

In the interview, they each answered the following six questions:

  1. Tell us about the best product you’ve ever encountered? Why do you like it?
  2. How do you know a great product manager when you meet one?
  3. What’s your favorite interview question?
  4. When is the best time for a start-up to hire a product manager?
  5. What has been the defining moment in your career?
  6. Mistakes. What was your biggest?

Steve Johnson took up the challenge and posted his answers to those questions on his blog, and most recently Scott Sehlhorst did the same.

I thought it was time to join the discussion myself.  So here are my answers to those same six questions.

Tell us about the best product you’ve ever encountered? Why do you like it?

I’m a big fan of any product that “just works” or surprises/delights me in some way. I don’t have a “best” product, but here are a few that I really like and use regularly.

  • The Blackberry – It does what it promises,efficiently and in a very compact form factor. It’s not perfect, but it’s really good, and it can take a beating like no other device I’ve seen. I’ve dropped my Blackberry many times and it is no worse for wear. To quote an old advertising phrase — “it takes a licking and keeps on ticking”.
  • Dyson vacuum cleaner — I’ve blogged about Dyson previously, but after 3 years, the thing still sucks more than any other vacuum and leaves it’s competition in the dust. Sorry couldn’t resist. 🙂 What really amazes me about it is that their customer service is also really great. A small part broke on the bottom of the machine. I called the toll-free number clearly visible on the cleaner itself. The person on the phone quickly confirmed which part was broken and they shipped me a replacement free of charge a couple of days later. The cleaner was clearly designed for this kind of diagnosis and service. Awesome.
  • The Honda Civic — We’re a Honda family so I don’t have experience with other brands of cars, but then why would I need to? I love the Civic because it just works. I’m terrible when it comes to maintenance and oil changes etc. but even with minimal attention it gets me where I need to go.  It’s both totally reliable and easily affordable. That’s what I want in a car.

How do you know a great product manager when you meet one?

If a product manager adheres to all of these rules, then they must be great! 🙂  Certainly product managers need to be smart, analytic, understand technology and markets, and be great communicators and leaders.

But if there is one thing that I think really defines a great product manager, it’s the ability to “connect the dots” in seemingly unrelated or conflicting contexts.  Perhaps another way to say this is product managers need a strong mixture of creativity, curiosity and intuition.

Steve Johnson answered this question with the line:

A great product manager sees patterns.

Scott wrote:

Great product managers are polymaths, with several areas of deep expertise and skill.

While written differently, these are similar answers and tie in well with the ability to connect dots.

A lot of times product managers need to find solutions to problems that are highly constrained — usually WRT budgets, resources or time. Finding solutions that satisfy business, technical and market requirements, and being able to sell those solutions to executives or other doubting Thomases are hallmarks of a great product manager.

What’s your favorite interview question?

The one I like to ask potential product managers is:

What one word best describes Product Management?

I’ve asked that question on the blog. Here are the results.

It’s always interesting to observe interviewees struggle with the question as it usually catches them off guard. And of course, once they come with an answer, the obvious follow up question is “Why?”

When is the best time for a start-up to hire a product manager?

This is a great question and core to how our industry understands and values Product Management.  I’m clearly biased here, but I have to agree with Stephen Pollack’s response:

Thirty days before you start the company.

This answer also lines up perfectly with what Bill Campbell of Intuit said about Product Management.

Too many people don’t actually realize the full scope of the Product Management role. It’s not just about product requirements, even at the very earliest stages of a company. I’ve seen too many founders of companies create offerings (I won’t call them products), that didn’t completely address market problems, that weren’t differentiated from competitors, or  that didn’t target specific market segments and problem domains.

And what happened then? They brought in “a product manager” to help address the issues. Sorry, way too late. Why spend another year and potentially millions of dollars to fix problems that you could have addressed right at the start?

What has been the defining moment in your career?

I’d say it was leading the Product Management efforts of the flagship product of a public company in Silicon Valley. The release was described by the CTO as “the biggest, most ambitious release in company history.”

That effort consumed my focus  for almost 2 years, and I learned so much during that period. I’ve shared some of it publicly.

I ran a large beta program during that release and used that experience to write this article on betas.

I gained a greater understanding of how to optimize cross-team communication.

I also gained some insights into leadership, particularly when dealing with people across departments, geographies and areas of focus.

Mistakes. What was your biggest?

I’ve certainly made my share.  My biggest was probably not understanding (for far too long) the impact personal motivations and politics played in Product Management. I’ve written that for product managers,  “Every activity is part of a sale.

Virtually everything we do in Product Management relates to influencing others to support our goals. In most companies, Engineering won’t simply do what the PM asks.  Darn. 🙂  And certainly in larger organizations, with significant constraints, misaligned objectives and even compensation conflicts, people will focus on what is of benefit to them. They will optimize locally (i.e. what’s best for them or their team).

A lot of what Product Management is about to get teams to optimize globally (i.e. what’s best for the product or the business), sometimes at the cost of local optimization. This is where selling becomes important. The sale is in getting other teams to agree to do what you need, and to get that, you have to understand their motivations, drivers, goals and objectives. Once I understood that, life became much easier for me as a product manager.

Saeed

P.S. I’d love to see the Cranky PM’s answers to these questions.

Toronto Transit Commission – How not to handle bad PR

The Toronto Transit Commission (TTC) is dealing with a real PR problem right now. There have been a number of photos and videos taken by transit riders and posted on the Internet showing TTC workers sleeping on the job (such as in the photo below) or otherwise doing things that did not provide a positive image of the transit commission.

Newspapers, television and radio news programs have reprinted the images and run articles and news segments on this story.

Many employees of the transit commission aren’t pleased.

Background on the TTC

Here’s a bit of background for those who are not from Toronto. The TTC operates all of the public transit buses, street cars and subways in the city of Toronto and has the 3rd highest daily ridership of any transit system in North America. Only New York and Mexico City (both significantly larger than Toronto in population) have transit systems that carry more passengers. The TTC is an integral part of people’s lives here.

There have been a number of issues in the last few years such as transit worker strikes, fare increases, ticket and token shortages, and service issues that have led to growing negative attitudes towards the TTC and the services it provides. Most people would probably say that the TTC does a good job in general,  but there are certainly many areas for improvement, and the TTC hasn’t appeared to be the most responsive organization.

Now there are 3 parties with stakes in this situation. There is the TTC management, the TTC workers (drivers etc.) and the public.

The public have legitimate gripes with both the workers and the management. Now, it is only fair to state that the recent pictures such as the one above are not the key problem here, and it is clear that only a very small number of workers are behaving this way. But for an already frustrated public, these images — and they are powerful — are what is putting the frustration over the top.

The TTC has made a number of mistakes in handling this situation.

1. They have not come out and openly acknowledged the problems that their customers (the general public) faces regularly

This is the first step that any company should take when dealing with problems such as these. Acknowledging the problems does not mean accepting the blame, but it does begin a communication process about the grievances. It also starts to frame the key discussion points so that constructive dialogue can occur. Otherwise the result is increasing distrust and frustration from the customers who become further entrenched in their views. This can quickly lead to customer attrition.

2. The TTC itself is embroiled in it’s own (rather public) conflict between management and the workers

This is probably one of the biggest problems facing the TTC and it is the customers that are punished through drops in service, striking unions or other issues.  But management keeps their jobs and the unionized workers focus even more on their own grievances.

The net result is that not only do customers suffer, but their needs are basically ignored while the two groups fight it out.

Here’s part of a statement from TTC chief general manager Gary Webster to workers.  This is excerpted from this article in a local Toronto paper.

In a memo sent to all TTC employees on Saturday, Webster says, “I am becoming increasingly tired of defending the reputation of the TTC; tired of explaining what is acceptable and what is not; and tired of stating the obvious: that much of the behaviour being reported is, indeed, unacceptable.”

“Two weeks ago I said that the vast majority of TTC employees care about the organization and do a good job, but we can all do better. I asked everyone to respond well. Some of you did. Clearly, some of you did not.”

He is referring, of course, to the bus driver filmed taking an unscheduled coffee break in the middle of his route about a week ago, not long after a pair of ticket collectors were snapped sleeping in their booths.

The resulting video and photos have incited a maelstrom of discontent among riders already familiar with poor service from front line TTC workers.

“The culture of complacency and malaise that has seeped into our organization will end,” Webster warns.

“I hold all of management responsible to make this happen. Reviews and plans are under way to address systemic issues regarding customer service, but real change starts with you.”

Now the response from the union went something like this:

But (Bob) Kinnear (head of the union representing the TTC workers) blamed some of the issues frustrating both the public and TTC workers on transit managers and the commission board, which consists of politicians.

He also blasted chief general manager Gary Webster for his statement over the weekend that appeared to brand all TTC workers as deficient in their work ethic and attitudes.

“The worst thing for a good union is bad management,” Kinnear said. “If you have strong management and a strong union, you meet in the middle.”

Kinnear did ask for calm on all sides and to try to work together to solve the problems, but the finger pointing on all sides, particularly publicly just exacerbates the problem.

3. Some TTC workers started a very poorly thought through social media campaign

In a tit-for-tat move, some TTC workers created a Facebook group, called Toronto Transit Operators against public harassment.

The organizers of the group describe it’s purpose as follows:

This is a group where Operator’s [sic] can give suggestions on how to fight back to the recent photo and video harassment from passengers just looking to make trouble for us. And post photo’s [sic] of your own of passengers breaking the rules.

The “just looking to make trouble for us” line shows a complete inward mindset with no attempt to understand the real issues at hand. Also, the irony of the group name and that last sentence in the description seems to be lost on the group’s creators, although one group member, Mary Bruno Tidona, pointed it out quite plainly. See the image here for more info.

There were many people in the group who clearly supported the transit workers, but there were also a lot of  responses from people pointing fingers at politicians (local, provincial and federal), at the public, at their management, at “the system”, but rarely if ever at themselves. One comment that suggested that the few workers who do sleep on the job etc. get the boot was met with this response.

(click to enlarge)

If you’re going to use social media, at least understand that you’re engaging in a conversation with others and not an excuse making or brow beating exercise. That may work in broadcast media where the few control the message to the masses,  but in a Facebook group, for example, you’re only inviting ridicule.

4. TTC management have responded with old school thinking — repeat the obvious and add more features

On January 27, 2010, the TTC proudly proclaimed their commitment to customer service excellence. Is there anyone who would openly state they are NOT committed to customer service excellence? The web page on their site looks like a well crafted communication piece that announces a lot but doesn’t really indicate that they understand the core problems.

Front and center is the creation of a panel. The description is the following:

This panel will have representation from customers, the private sector, TTC employees and the public transit industry. The panel will review and approve a terms of reference then begin the work of assessing existing plans to improve customer service, advise on where the TTC should seek outside expertise to achieve its objective, conduct public consultations, and draft a customer charter or “bill of rights.” It is intended that the advisory panel will publicly report its recommendations by June 30.

Honestly, this is the best they can do in 2010? Create a panel and report back in 5 months? How about something more inclusive, using social media (effectively!), involving community groups in a series of TransitCamps starting at the end of February? Nope. Just old school thinking.

Beyond the panel, the web page also lists a number of new “features” they will add to the system. These include:

  • a beta of a new trip planning application
  • 50 new ticket vending machines across the system
  • improved plans to help customers and employees during subway delays
  • a new SMS messaging capability at all 800 streetcar stops
  • new video screens and better system status communication with ticket collectors and employees
  • a review of training programs for new employees and those going through re-certification

Now this is a nice list, but it’s simply a list of incremental features being added to the system. How will any of this – with the possible exception of better training — address the core issues of the public?

Incremental changes to the system, like incremental changes to a product, are not game changers. And while it is very difficult to make major changes to something as complex as a transit system in a short period of time, there is certainly a lot more that can be done to make the system more efficient and better address passenger needs.

I grew up in Toronto and used to love the transit system and it was only after I got married that I stopped using it regularly. And the few times I have used it since my marriage, I’ve found it excruciatingly painful and time-consuming.

I think the Toronto Transit Commission needs to understand there are alternatives for people and they will use them when the TTC fails to deliver appropriate value.  I’ve found an alternative to the TTC — same initials though — Take The Car. It does have it’s downsides, but it gets me where I’m going and I always know when it will depart and arrive.

Saeed

Tweet this article:  @onpm – Toronto Transit Commission – How not to handle bad PR – http://bit.ly/9swydU – #ttc #marketing

What Origami can teach us about Product Requirements

Tom Grant has started an interesting series of posts entitled Against a Grand Theory of Product Management. The articles are interesting reading, but make sure you have your thinking cap on when you start, because Tom is discussing an important but rather abstract topic.

He pulls in references ranging from Middle Range Theory (something I’d never heard of before) to Darwin’s theories (something I think we’ve all heard of but probably don’t adequately understand) to help convey his points. I had to read the posts a couple of times each to better grasp the specifics of his arguments.

In Part 2 of his series, Tom asks:

If someone can figure out why even the most meticulously written and reviewed requirements don’t stop some tech companies from making products that their users don’t like or can’t understand, that’s a big contribution to our little field of study. Best to have more middle-range theory before even thinking about the GToE [Grand Theory of Everything].

This is a great question. But before I answer it, I want you to watch the following video. It is from a TED Conference talk given in February 2008 by Robert Lang. Not only is this a fascinating video, but as you’re watching it, keep Tom’s question in mind. Don’t read on though until you watch the video. 🙂

[BTW, if you are impatient and read ahead, the important stuff starts at about 2:30 in the video.]

Lang talks about the evolution of origami, that took it from a traditional Japanese art form that most of us associate with creating things like this:

and turned it into an art (and science)  form that allows people to create things like this:

And what caused that evolution? In Lang’s words, the answer is “mathematics”, or more specifically, the creation and utilization of a set of rules that provide a language for defining what can and can’t be done in origami.

The rules define the crease patterns — the lines along which folds are made — in the paper. And there are 4 rules:

  • 2-colorability — any valid crease pattern can always be coloured with only 2 colours and will not have the same colour in two adjacent areas.
  • modulus (M-V) = +2 or -2 — at any interior vertex, the number of mountain folds and the number of valley folds will always differ by 2
  • For any vertex, the sum of alternate angles around that vertex will always be 180 degrees. e.g. a1+a3+a5 … = 180 degrees  & a2+a4+a6… = 180 degrees.
  • No self-intersection at overlaps – a sheet when folded cannot penetrate itself

[Note: if you don’t understand these rules, watch the video. 🙂 ]

Now these 4 rules define the properties of valid crease patterns, but there’s still something missing. How can those rules be applied to create sophisticated origami? In short, what goes in the box? (see 4:40 of the video)

Lang discusses that as well, and provides this diagram:

In short, the physical subject is reduced to a tree figure defining the key components (“flaps” in Lang’s terminology) of the subject. In this case, those are the legs, antennae, horns etc. of the beetle. That’s fairly easy.

Then some process must be used to take that tree-figure and create a base form for the final origami. He calls that the hard step.

And finally the base form can be refined to create the finished model. That’s fairly straight forward.

The “hard step” is accomplished using the rules defined above and the language for applying those rules. Given those rules are mathematical in nature, they can be written precisely and unambiguously and then executed to create the final model.

What does this have to do with product requirements and Tom’s question?

When looking at product requirements, there are analogies to Subject-Tree-Base-Model example given above.

  • Product Managers investigate  real world problems, needs, scenarios etc. (Subject).
  • They then take their learnings and create abstracted representations of them (requirements) using artifacts such as problem statements, personas, use cases and user stories (Tree)
  • These artifacts are then used by engineering teams to create prototypes and mockups etc. to ensure that the requirements were understood and addressed in the product. (Base)
  • The final product is built, tested, tweeked etc. with the appropriate “fit and finish” before being released. (Model).

Sounds pretty good so far right?

But herein lie the problems.

  • There currently is no language for requirements like the one defined for origami, that can precisely and unambiguously convey what is needed and define that in a way that ensures it can be built.
  • Requirements should be implementation neutral, but as we all know in technology, the ability to fulfill a requirement can often be limited by technology choices and decisions that were made well before the requirement existed.
  • Other constraints such as time, resources, knowledge, legalities, finances etc. all factor into how well a requirement can be met, or perhaps if it can be met or not.
  • In many cases requirements contain unknowns or ambiguities that are filled in by assumptions during the development process. This is a reality of developing products in a business environment.  In the origami situation, this is would never happen. A model (like the stag beetle) can only be built when the full crease pattern is defined.
  • There is no concept of people “liking” or “understanding” the origami in Robert Lang’s rules. i.e. Tom Grant asks about why companies build product their customers don’t like or understand.

This last point is key and deserves a little more discussion. What people like and understand is complex and is not static. In general, what people like is based on overall experience and emotion. It is not something that (currently) can be defined in a set of requirements.

i.e. users of this product must feel giddy with excitement the first time they use this software

So, can origami teach us something about product requirements?

Absolutely. The origami path from Subject->Tree->Base->Model forms series of transformations that is akin to the requirements gathering, communication and development process used when creating products.

Once a set of clear foundational rules for origami were defined and understood, not only did they open up new possibilities for forms never thought possible, but those rules formed the grammar for a language that makes precise and unambiguous communication also possible.

There is almost certainly a set of rules and language for precise definition and communication of requirements, but it has not yet been clearly formalized. That is likely a necessary stepping stone in the maturity cycle of product development.

But even with that requirements language, changing market landscapes, customer preferences and needs, technological, resource and time constraints will all work together to make product success a “grey box”, where those with great vision, insight and execution are likely to succeed but never guaranteed that success.

Saeed

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

Guest Post: Measuring Product Management (part 3)

This is part 3 of a series of guest posts by Don Vendetti. Don is the founder of Product Arts, a product management consulting company in Seattle.

NOTE: If you’d like to write a guest post, contact us and let us know about your idea.

——-

In part 1 and part 2 respectively, I discussed the answers I received from company executives on the following questions.

  1. What is the value that product management brings to your company?
  2. How would you measure success for the group and individuals? i.e. on what metrics would you reward them?

In this part, I’ll look at the following question.

Question #3:  Is Product Management Effective, in Your Experience?

The dominant answer here was a resounding SOMETIMES.    I’ll let some comments speak for themselves.

(VP Eng) “Never adequately. It’s a tall order and they are often placed in the organization where they cannot succeed or with unenlightened leadership. If they are in sales they become too deal / feature / near term focused. If they are in engineering they become too development / feature / development focused. If they are in marketing they become too abstract and disconnected. Ideally they are in line of business management reporting directly to an SBU Manager or GM. Where they have done best it was where the corporate imperatives were obvious, and they were well connected and led.”

(VP Ops) “Currently, our model defines product management in terms of marketing activities, so the value is less than optimal.”

(GM) “Yes, the good ones. As always, if their direction is good, and they have goals that make sense, and they are managed, they can usually meet or exceed their goals.”

(VP Eng) “Both successful & unsuccessful.   Needs to have an environment for success – expectations, aligned groups, business goals.  PM needs to stay outwardly focused.   Needs to bring customer into the company.”

(Program Mgmt/Former VP Mkt) “For Agile shops, the product owner role is critical and delivers great value to the business and to dev teams — the product cannot be built without one.  For more waterfall oriented shops, it can be tricky.  I find that product managers that seek to translate market requirements (from marketing/ customer facing teams) into product specs for engineering program managers will often deliver dubious value.  It is best if the product manager is closer to either the customer (e.g. product marketing manager), or to the developers (e.g. program manager) to avoid being an odd-man out. “

Summary

Let’s compare where we ended up as the primary value of Product Management with the Mandate previously posted on this site:

The Product Management Mandate These Results
To optimize the business at a product, product line or product portfolio level over the product lifecycle. To deliver measurable business results through product solutions that meet both market needs and company goals.

They are both in the same ballpark with regards to business and products, but there is definitely a divergence beyond that, with the Mandate missing the key element of MARKET NEEDS.

It is a primary expectation of company executives that product management is a bridge between the internal functions and understanding the market needs and this got lost in the Mandate.

Where we still don’t have clear guidelines are the actual measurements to use, but we do have a general direction in which we need to head.   It is imperative for product management to be able to tie their activities to measurable business results to be perceived as adding value for executives.

These do not have to be tied directly to revenue or profit, but there is ideally some way to tie to leading indicators of them – usage, penetration, retention, quality, cost, etc.

If the feature sets you’re prioritizing or the activities you’re doing do not somehow support an improvement in these indicators, it’s time to rethink what you’re doing… pronto.   It also important that you communicate where you’re impacting business level results so that the execs are aware of it.

I have also personally found that the “intangibles” carry a much higher weight than emerged from these exec comments.   Be assured that even if there is no formal process for measuring how you are perceived in the organization, you are constantly being assessed for leadership skills and ability to collaborate and facilitate internally and externally.   These will ultimately steer your career progression.

Lastly, it’s clear from the final comments that product management success is strongly correlated to a supportive organization with clearly defined roles, objectives and mission.   If you find yourself in a company without these, it’s time to exercise some leadership to help create them or to perhaps move on to greener pastures.    It’s really not that much fun to continue to struggle where personal success is unlikely.

Don

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

Related Posts

Measuring Product Management (part 1)
Measuring Product Management (part 2)
Measuring Product Management (part 3)

Guest Post: Measuring Product Management (part 2)

This is part 2 of a series of guest posts by Don Vendetti. Don is the founder of Product Arts, a product management consulting company in Seattle.

NOTE: If you’d like to write a guest post, contact us and let us know about your idea.

——

In part 1, I described my conversations with some industry executives on the question:

What is Product Management’s overall value to your company?

The answers were quite interesting. In this part, I’ll look at the following question:

Question #2:  How would you measure success for the group and individuals?

This question generated a few different discussions and in many instances I got the response “they SHOULD be measured on…”, which indicated their expectations and reality are different.

That being said, most respondents were strongly on the side of tying rewards to business results.    These included:

  • (#1 by a wide margin) Meeting product business plans and forecasts for revenue and profitability
  • Achieving key business objectives for the specific period, including meeting delivery milestones for releases and launches
  • Achieving key market metrics – adoption and usage, penetration and market share, customer satisfaction and retention

Only a few mentioned the difficulty of looking at current business results only, such as revenue, while needing the product manager to be focused on producing future business results.

One also recognized there may be multiple product managers on a large product, with revenue difficult to associate to each.

These advocated a more blended set of measurements that included specific assigned metrics or deliverables within a specific period.

Product quality was mentioned a few times, and included measurements such as returned product, trouble tickets submitted, major bugs found and SLA performance.

There were also some who raised the need to include some “intangibles”, specifically around how well the individuals were perceived in the organization.

This included satisfaction ratings of internal stakeholders based on timely and effective support of other functional groups, how well they performed at driving product delivery and resolution of issues, how well they collaborated with others, and in providing general leadership.

To capture the intangibles, a few companies performed peer reviews or 360 degree reviews on a regular basis.

A few highlighted that the metrics used for a B2B company versus a B2C were somewhat different.

In the B2B company, responsiveness and effectiveness in supporting a direct sales team for major accounts was a key need.

In a B2C company, there may be less on-demand support of the sales channel, and a higher emphasis on marketing and usage metrics.   (As with everything else, this is probably highly variable from company to company, but may be worth a whole separate article.)

Specific comments included:

(CEO) “I am sure every company is different, but revenue, customer retention, customer satisfaction, net promoter score, and market share (are the measures of success).”

(VP Biz Dev/PM) “We measure and reward based on a combination of product performance in market and other metrics related to on-time delivery for new products, quality metrics, and other qualitative measures based on the PM’s role in providing timely and effective support to marketing, sales, and other functions.”

(CEO) “The success metric has to be on net contribution.  Given the lifecycle stage of the product, it may even be managing losses during the formative stages, but ultimately, the only goal of any product is to make money.  The market is the best indicator of success. If quality is down, sales will be off or returns high. If the product doesn’t meet needs, there will be no sales.  If the product is a poor value against the competition… you get the idea.”

Take-Away

The key take-away from this section is the expectation level of the senior executives on product management being measured against business results.  These other executives are heavily dependent on product management for making the right product choices to ensure business success, and they believe product managers should be tied to company results, just as the execs are.

With business results emerging as the top priority, I would reorder and rework my previous value list to be:

  • Delivers measurable business results through product solutions that meet both market needs and company goals.
  • This is accomplished through:
    • Creating a shared awareness of the customer and market needs to the internal functions
    • Shaping the product solution and delivery plan
    • Facilitating and supporting cross-functional and external activities required to achieve the planned objectives

So how well does Product Management do at meeting expectations? I’ll get to that in part 3.

Don

Share:

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

Related Posts

Measuring Product Management (part 1)
Measuring Product Management (part 2)
Measuring Product Management (part 3)