What keeps Product Managers from being really effective?

by Saeed Khan

The-Most-Importat-ThingA couple of weeks ago, I asked you to tell me what important activities you aren’t able to do because you’re caught up doing other (less important) things?

In a rather unscientific survey, I asked the following questions:

1. What is the most important thing you SHOULD be doing in your job that you DON’T get done because of other tasks/priorities?

2. What activity (that you regularly have to do, but would rather not be doing) prevents you from doing the most important thing from Q1?

3. In an ideal world, who should really be doing the task you described in Q2?

4. How many people are there in your company?

And thank you to all who answered.  The following is a sample of the the responses. There were too many to report all of them here.

There were some clear patterns in the responses and it really points to a problem in how companies define and staff their product management teams.

1. What is the most important thing you SHOULD be doing in your job that you DON’T get done because of other tasks/priorities?

  • Talk to or observe customers using our products.
  • Research product ideas, features and user interface improvements.
  • Focusing on strategy, on what’s next and why.
  • Get out of the building – see customers, prospects, competitor offerings at industry meetings.
  • Interviewing and observing prospects and customers.
  • Talking with users, prototyping and iterating.
  • Long term thinking and conversation, asking existential/strategy questions to shape the roadmap.
  • Meeting customers to better understand their actual problems and get their input.
  • Meeting with customers.
  • Talking to customers. Seems obvious but can never crack through and make that regular.

2. What activity (that you regularly have to do, but would rather not be doing) prevents you from doing the most important thing from Q1?

  • Performing second level support for older products
  • Testing features, coordinating releases, planning deployments
  • Janitorial work – e.g. checking peoples’ work, managing their content etc.
  • Answering basic questions about product to internal teams. Mitigating “urgent” and “we will lose the client” escalations
  • Crafting marketing experiments to test value statements and determine effective marketing tactics
  • Managing engineering
  • Writing docs (release notes, marketing collateral, deployment guides etc.)
  • Answering questions from sales when answers are obvious or well known
  • Supporting pre-sales with demos, RFPs, POCs etc.

3. In an ideal world, who should really be doing the task you described in Q2?

  • Support
  • Engineering manager
  • Sales engineer
  • Marketing
  • Engineering
  • No idea!
  • Sales and Marketing
  • Marketing
  • Pre-sales Engineers
  • Project Manager

4. How many people are in your company?

I added this question after the first few responses came in because I thought I might see some pattern differences between smaller and larger companies. To be honest I saw few differences. A couple of people from larger companies (500+ people) cited process and approval issues but otherwise not much difference from smaller companies.

Take a look at these responses. Yes, it’s completely unscientific and a small sample size but it’s really a mess from my point of view.

As Steve Johnson wrote, other departments may be hiding some of their headcount in your budget. i.e. Product Management is performing tasks that should rightly be done by other groups. Based on these responses, it seems virtually every other department (except for Finance and HR) are doing this.

OR, maybe Product Management is doing these tasks because they are expected to do them because nobody else has the knowledge to do them.

How can we change this situation? How can we give other departments’ tasks back to them so we can focus on the really important work that’s not being done today?


Tweet this: What keeps Product Managers from being really effective?  http://wp.me/pXBON-4e6 #prodmgmt

About the Author

Saeed Khan is a founder and Managing Editor of On Product Management, and has worked for the last 20 years in high-technology companies building and managing market leading products. He also speaks regularly at events on the topic of product management and product leadership. You can contact him via Twitter @saeedwkhan or via the Contact Us page on this blog.

Your user interface defines a conversation – does it always make sense?

By Saeed Khan

man vs machineWhat is the difference between these two sentences?

  1. He eats, shoots and leaves.
  2. He eats shoots and leaves.

The first describes a gunman, most likely in a dining establishment. The second describes a vegetarian, most likely a panda bear. The comma in the first sentence makes a huge difference in the meaning, context etc.

Now think about user interfaces.  Do inconsistencies or other issues change the user experience?

Everyone knows what a user interface is, right? At least I hope everyone reading this blog knows. :-)

Wikipedia defines user interface as:

“The user interface, in the industrial design field of human–machine interaction, is the space where interactions between humans and machines occur. The goal of this interaction is effective operation and control of the machine on the user’s end, and feedback from the machine, which aids the operator in making operational decisions.”

To and fro with the machine

Note that the user interface enables a bi-directional interaction, controlling the machine AND getting feedback from it.

That interaction is, for all intents and purposes, a conversation, in a language that you’ve created for your application or product.

And just to be clear, I’m not using the word “conversation” to describe a conversational or voice interface like Siri. The conversation (bi-directional information exchange) exists in any user interface – character, graphical, gesture, voice, haptic etc.

Every dialog, every menu, every gesture, every action is part of the language that defines that conversation between user and machine. How well is it defined? Like the two sentences at the top of this article, do small issues in the interface change significantly change how users perceive the application?

The question to ask yourself is whether the language of that conversation — the vocabulary, the meanings, the constructs, the responses — is constructive or not. A constructive conversation is not just random talk. It’s communication with a specific intent or goal in mind.  Think about what is required to have a good conversation. The exchange between the parties needs to have some specific qualities. I call them the 4Cs of Conversation. They are:

  • consistency
  • completeness
  • conciseness
  • clarity

Think about those 4 Cs, and then think about any interface you’ve used or worked on.

Consistency - Do the words you use in your interface have consistent meanings?

e.g. does the word “Home” mean the same thing throughout, or are there different “Home” pages depending on the context?

Completeness – Can the user perform all the task they need within the interface, or are there steps that must be done external to the tool?

e.g. can the user email information from within the application or do they have to save the information and then switch to a mail client and send the email?

Does the system provide all the information needed for the user to complete their task.

e.g. do error messages/dialog give the user the information they need to address the problem or do they have to guess what to do?

Conciseness – Can the user perform each task with a minimum of effort (clicks, selects, checks, confirmations etc.)?

e.g. Can a drop-down menu of choices be replaced with a set of icons for direct selection? A menu selection takes at least two actions, while an icon click takes 1. A small difference until you multiply it by the number of times each user will select from the menu vs. the icons.

Clarity –  Is each possible action easily revealed and understood?

e.g. in a touch interface, can a user easily identify all the available gestures and their associated actions without a lot of guess work?

How do you evaluate the consistency, completeness etc. of your interfaces?

How do you analyze the conversation your users are having with your products and applications to ensure they are clear, concise etc?


Tweet this: Your user interface defines a conversation – does it always make sense? http://wp.me/pXBON-49Z  #prodmgmt #ux 

About the Author

Saeed Khan is a founder and Managing Editor of On Product Management, and has worked for the last 20 years in high-technology companies building and managing market leading products. He also speaks regularly at events on the topic of product management and product leadership. You can contact him via Twitter @saeedwkhan or via the Contact Us page on this blog.

He Said, She Said: Part 4 – Product Management and UX working together.

By Saeed Khan and Heather Searl

pmuxParts 12, and 3 of this series covered a number of topics including working with other teams, organizational structures, personas, Agile, and common documents. This 4th and final part covers a few more areas.

Company Orientation

Saeed: I was talking to a VC a while back about Product Management in startups. We discussed some of the issues he saw. First, he said, that people don’t have enough training for product management.  This is both the PMs themselves but also executives. It’s poorly understood and poorly implemented, so often fails.

The second issue he raised was company orientation. Companies can be product-centric or sales-centric and that changes the product management role quite a bit. That adds complexity and relates back to the first problem.

Let’s say a company is sales-centric.  How does that affect UX? Does UX care?

Heather: No, not as much as product management. It will affect the direction we are given. I may have to make design for  the 17 features that are in all of the blog and industry journal checklists but that no one actually uses, and I have to do it without compromising the workflows people do use. However that’s it – it isn’t as big of an impact.


Heather: On the other hand, I worked for a research-centric company where the research team was made up of industry experts who talked to other industry experts and defined the products they wanted.

However the end-users weren’t like them. They were college grads rather than PhD researchers who did a job by following explicit instructions. The researchers wanted the product to be able to do everything and to be incredibly flexible. The customers wanted easy repeatability.

We (the UX team) ended up creating anti-personas that were very similar to the research scientists so we could make it clear who we were not designing for.

Saeed: I’ve never heard that term “anti-persona” before. In fact, I’ve never had to deal with that situation where one group was advocating something that was totally wrong. Usually, I’ve had to deal with shades of grey, vs. diametric opposites.

Heather: It was clear that the anti-persona was a very well-educated and very well-known and respected individual in the industry – whereas  most of our users were just doing a 9 to 5 job.

A bizarre outcome of this was that the research scientists liked that the anti-personas resembled them and showed them as thought leaders and experts. They jokingly all wanted an anti-persona based on them.  They’d ask for little things to be added like the universities they attended, the awards they won.

Strangely anti-personas became a required deliverable for every project. They kept the research scientists happy. They felt special.  And the project team could politely turn down ideas or redirect them by referring to the anti-persona rather than scientists on the team.

There wasn’t any product management in that company. Agile required a customer or customer representative. The research scientist filled this role in the beginning. Then subject manner experts who had done the job were hired form customer companies. And eventually that evolved into a product management role.

Saeed: I have to say that I find that odd. Both that you had to create anti-personas for every project, but also that the researchers liked being depicted in them. You’ve worked with some interesting companies. :-)

What do you like most about UX and the work you do?

Best parts of our jobs

Heather: I like working with end users. I like seeing how people work and think and how they interact with each other. I like when I work on technology that improves someone’s life in some small way, though if it fails, it is also interesting to see why it fails.

How about you?

Saeed: I’ve done a lot of things in my career. Immediately before I was a product management I was responsible for documentation, training and support. I’ve done some marketing and some development before that.  What I’ve seen is that product management brings all of that together.

Also, product management is fundamentally about problem solving; people problems, process problems, product problems, market problems etc. You can’t have a successful product without a wide range of input and understanding. I like connecting dots so to speak.

So what do you hate about your job?

Worst part of our jobs

Heather: Politics.

Everyone has an opinion on what the design should be and everyone wants it their way and often the differences of opinion get solved through politics and that makes no sense to me. When things get political I’m lost.

When someone disagrees with me or has a different point of view that is based on what they truly believe is the best for the customer, I can work with that. I’m happy to talk to them and work out a solution.

But when it seems more that a person or department just wants it their way; they want a win; they need to get their way on this project to make up for something didn’t go their way somewhere else or whatever, I’m completely lost. I don’t know how to work with that. I don’t get the cross-project negotiation. If this happens on project X then I’ll help get Y implemented on project Z.

I decided to freelance because I can come in give my opinion and someone else can make the final decisions.

Saeed: So you don’t want to assert yourself? You said you prefer someone else to make final decisions?

Heather: I want to be heard. I want to put my ideas forward. But I am happy in more of a support role where someone else makes the trade-offs between schedule, budget and quality.

I fully understand that they need to be made, but I’m not great at that negotiation. I want everything.  And product managers who won’t do the negotiation and make the decisions and just say give me it all on time and under budget also frustrate me.

I don’t have to get my way to be happy. I just need my ideas to be heard and my input to be valued.

Saeed: I think people from the outside look at product management and have no idea the amount of backroom politics and intercompany struggles and trade-offs there are.

I worked with someone years ago who a sales engineer and  was always complaining about how long it took for product management to get things done.

“Why can’t you get functionality out faster? This has been a known issue with the product for years. Why don’t you get it fixed?”  and so on.

I used to tell him that if he knew all the BS that I had to with just to get releases out the door, he wouldn’t ask those questions.

A few years later he moved into a product management role and after a few months in that role,  I asked him if he remembered our conversation.  He looked at me and said “Oh my god,  you were so right! I understand why it takes forever to get something done.”

There is so much politics in the job, and by that I mean the assertion of power and assertion of influence. And people with power and influence are in different groups and have different views on what success is.

When I became a product manager I had no idea what was involved. Some of it was a pleasant surprise, and some of it was a complete shock.

In the end my focus as a product manager is what we need to do to succeed. No one wants to work on a failed product.

Some days though, it’s hard not to bang your head against the wall and wonder why you bother.

Heather: What is the main quality that you look for in your UX team?

Saeed: Same quality I look for in everyone is being a rational person. I assume you are qualified to do your role and that you were hired because you have the skills you need.

I worked with someone who said in the end, every problem is a people problem.  And that is true. It may look like a technical problem but if the people trying to resolve it are rational and open we can figure out what to do about it. If someone isn’t rational and insists on everything their way, then it’s much harder.

Currently I work with someone in UX who is easy to work with and he and I are very much aligned on our goals and that is important. We bring our combined knowledge to problems and constraints.

Heather, this has been a great conversation. Thank you very much.

Heather: Thank you. I agree it’s been great. We covered a lot more than I expected.

Heather and Saeed

Tweet this:  He Said, She Said: Part 4 – How can Product Management and UX work together http://wp.me/pXBON-4dz #prodmgmt #ux

Don’t discover; observe

It’s not that problems are invisible; it’s that no one is looking for them.—Steve Johnson, Under 10 Consulting.

I often chat with company leaders who ask me how to do customer discovery but I always find it a confusing conversation. They don’t seem to understand my questions. “Who did you build it for?” “What problems are you solving and for whom?”

At a conference I heard many people talking about technology and products and features, but very few talking about markets and segments and personas. Our industry continues to embrace the idea that “if you build it, they will come.”

There’s a belief that technology is difficult but finding customers is easy.

sprinklerThe funny thing is there are so many products begging to be re-invented. Look at the Nest thermostat and Nest Protect (their smoke detector). Beautiful! And when will they reinvent my sprinkler system controller?

One technique that product managers and product marketing managers need to embrace is customer observation. More than customer discovery and more than having domain knowledge, research through customer observation is critical. It means working alongside a customer (or potential customer) to truly understand their work. How long does each step take? And why do we have to perform each step?

Before you can re-imagine a workflow, you have to understand what customers do and why.

I’m using a new vendor management system that is totally bewildering. I’m sure it will save someone’s time eventually. But for now, none of us using the system seem to know how to use it. The documentation and on-screen clues are non-existent. But I’m motivated to learn it since I have to use it to get paid. I’d love to have the developer watch me use it, just to see how confusing it really is. Clearly none of the people who developed the system are the ones who have to use it.
“Listen to the customer” is just wrong.

You’ve heard marketing people say it for years and years: “Listen to the customer.” And they are just wrong. You don’t want to “listen;” you want to observe. People cannot describe what they do in words. Watch their actions instead.

Customer observation is a critical skill for product management. Is it part of your Product Playbook? For more on customer interviews and observation, get my free ebook on Customer Interviews.

About the author

Steve Johnson is a recognized thought leader and storyteller within the technology product management community. At Under10 Consulting, he helps product teams implement product management in an agile world. Sign up for his inspirational newsletter.

Are these really the tools Product Managers use?

by Saeed Khan

As a Product Manager, and with the exception of Excel, PowerPoint and Word, what software tools do you use on a regular basis to do your job?

It’s always an interesting conversation to have when PMs get together to share and compare what tools are worth checking out.

Product Hunt or Products Shunned?

I recently came across the following list on Product Hunt – Tools for Product Managers — and the items  and rankings surprised me. I don’t know how representative Product Hunt’s audience is of the broader (software) product management community, but based on the tool rankings, I’m certainly not like those PMs in the tools that I use. Trello as the dominant tool, well above all others?? Really?

There are note taking tools, task management tools, presentation tools (PowerPoint is noticeably absent), and no mention of Excel or Word. More importantly no mention of any PM specific tools such as requirements management or roadmapping tools, or any business or financial analysis tools.

Here’s a chart of the number of upvotes for each tool listed as of Sept 17, 2014.


Is this representative of your environment or company? Are there any tools you’d like to see that don’t exist today? Let us know.


Tweet this: Are these really the tools Product Managers use? http://wp.me/pXBON-4dT #prodmgmt #tools #ux

About the Author

Saeed Khan is a founder and Managing Editor of On Product Management, and has worked for the last 20 years in high-technology companies building and managing market leading products. He also speaks regularly at events on the topic of product management and product leadership. You can contact him via Twitter @saeedwkhan or via the Contact Us page on this blog.