UX and product managers


On the Mind the Product blog, Martin Eriksson writes,

I’ve always defined product management as the intersection between business, technology and user experience. A good product manager must be experienced in at least one, passionate about all three, and conversant with practitioners in all.

To Martin’s list I would add expertise on the market (or persona) and a passion for the domain. I’ve written about expertise in product management in my free ebook. (Download it here).


User experience (UX) is an area that befuddles many product managers. Ideally, product managers should be focused on the customer problem while development designs the company’s solution. A strong dev team will propose one or more solutions to the articulated problem, allowing the product manager to accept the best option by leveraging his or her business, technical, marketing, and domain knowledge. A UX designer is a critical element of a successful product team.

If you’re interested in UX design (and all product managers should be), take a look at The User Experience Guidebook for Product Managers from the helpful folks at UXPin.

The difference between good and great is often in the user experience. Let’s all become passionate about brilliant UX design.

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.

Stop saying “No” and start asking “Why”

by Saeed Khan


Every day, it seems, I see another blog post or article on product development that tells people to say “No” to feature requests.

Don’t believe me? Just do a web search on Say No to feature requests, or something similar, and you’ll see what I mean.

This advice to say “No” started, I’m certain, with this quote from who else but Steve Jobs.

“Innovation is not about saying yes to everything. It’s about saying NO to all but the most crucial features.”

Jobs said this to a group of people from the music industry, who, when showed a preview of the iTunes Music Store, started asking about potential feature enhancements. “Will it do [this]?”, “Will it do [that]?” etc.

This line, like the famous Ford faster horses line that Jobs also spoke about, is definitely a truism, but doesn’t constitute a hard and fast rule, dictating to people that they must say “No” to feature requests.

In the Jobs’ quote, he was simply explaining what he (rightly) believed about the innovation process.

“Why” is better than “No”

Instead of simply saying “No”,  people need to ask “Why?” and try to truly understand the reasons behind the request.

The people making the request should have a clear reason (in their mind) of why they’re making the request, and it is incumbent on you to find out.

Feature requests are pre-conceived solutions to problems. Asking “Why?” (as many times as needed and in as many different ways as needed) will get to the heart of the problem.

And only then should a Yes/No decision be made.

And even with a “No” decision, it can be “No, right now we have other priorities, but we’ll definitely consider it in the near future.” response. i.e. “No” is not always an absolute “No”

The more you understand “Why”, the more context you gain over time at underlying patterns. Different feature requests may simply be different perceived solutions to the same problem.

You’ll never realize this without asking “Why?”

So while I agree that we should say No to non-crucial items, you’ll never know what is and isn’t crucial unless you understand why.


Tweet this: Stop saying “No” and Start asking “Why” http://wp.me/pXBON-4cJ #prodmgmt #innovation

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.

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