Know when to call it quits

by Liraz Axelrad

keepcalmWhen asked about the future of “Home” ­– Facebook-not­-really-­mobile­OS-­but-­kind-­of” Mark Zuckerberg said: “It’s a tough thing determining when something doesn’t work, and when something hasn’t worked yet”.

Indeed it is. And sometimes it’s up to us PMs to make that decision. Sometimes it’s our job to make the hard call; to call it quits.

An object lesson

A few years ago I worked on the launch of an outdoor portal. One of the features was advanced search. I was in love with it. It had so many fields! So many options! Using it, one could find exactly the right activity for oneself, or so I thought.

And then we launched it, and no one used it. Was it because the feature was simply not needed, or did we screw up the experience? Could we make it work? Was it worth our time? And mostly, how could I know?

The easy option was to keep the feature as is. Let it be. Do nothing, make no decision. As a PM, I’m short on time and resources and, well, it’s already there, right? Working and all. No harm no foul.

Only it ain’t so. Dead spaces in our apps are harmful. We should not let our apps become graveyards for failed ideas. Apps get inflated over time because we keep adding stuff to them, so it’s doubly important to trim them down whenever we can. And it’s also important not to be afraid to make the call.

The problem is, we tend to fall in love with what we do. It’s a good thing when we start. Our enthusiasm fuels our advance and the whole industry, for that matter. But it can become an obstacle later on, when things don’t work as we expected. At that point we should be able to make an informed decision.


Should we kill the feature, or iterate on it? That’s the question we need to answer. Those are our options. Now let’s make a decision. A few question to consider:

  • What are the feature’s metrics and how do they sum up in comparison to what we promised at the beginning? How big is the gap?
  • Do we have practical ideas on how to close that gap?
  • What were our goals for the feature, what did we try to achieve strategically and is it still valid?

If the answers to any of those questions is “No”, then it’s a no-brainer, kill it. But If the answer is yes, then it’s time to plan the next feature iteration. A good iteration plan includes:

  • Time frame: how much work, how many hours or sprints, when will we release the upgraded feature and when do we have the next decision milestone. Put a date on it.
  • Numbers: What metrics are we trying to affect, what are our dream numbers. Be clear and be bold. Put down the numbers that will keep the feature alive.
  • Changes, user stories: what are we actually changing and how, full description.

And now to the hard part: try to get everyone, all stakeholders, to agree with your plan.

I know it’s not always possible, but when it is, it’ll make your life easier. And what if we do all that and the feature, alas, still doesn’t do what is should? Then it might be good to remember the wise words of Stephen King from his book “On Writing”, part autobiographical, part advice to young writers: “Kill your darlings, kill your darlings, kill your darlings”.

Your product will benefit from it. Your users will benefit. You will benefit.


Tweet this: Know when to call it quits #prodmgmt #eol

About the Author

Liraz-bwLiraz was born and raised on a Kibbutz in Israel,and currently lives in Berlin. Liraz is an experienced Mobile PM, writer and baker. She loves doing stuff that are used, or eaten, by others. 



The 3 biggest problems in Product Management today – Part 2 – Process

by Saeed Khan

innovation funnelIn part 1- I listed the following problems as the biggest ones I see facing high-tech product management.

  • poor definition of roles and responsibilities
  • significant gaps in repeatable product processes
  • problems in intra- and extra-company communication and alignment

I discussed the first one – Roles – in my previous post.

This time I’ll look at problems in repeatable processes.

Gaps in repeatable product processes

I’ve worked in several startups as well as a couple of public companies. Regardless of size, most of them had pretty good engineering processes. i.e. once they decided what to build, the engineering teams could usually build, test and release pretty good quality code. But what most did not have was a clear set of repeatable processes to identify new market opportunities and products, and then once built, release them with a clear and effective go-to-market strategy.

What should we build (next)?

On the front end, companies have problems answering the question, “What should we build next?”  This is not the same as “What can we build next?” It’s easy to simply build something. It’s difficult to build something that will be successful in the market. Many companies don’t understand what made their first product successful and thus have no idea how to repeat that success. Or, what they did (or the market conditions that existed) to make their first product successful cannot be repeated.

I once interviewed a product manager who was working at a company known for a VERY successful first product and several also ran products. He’d worked there for many years, and we discussed the new product process (if it could be called that) at his company. During the conversation, he mentioned that during his time there, the company had launched over 50 products that subsequently failed. The reasons varied, but mostly the failures were due to a CEO who “decided” what would be built next, with little real understanding of what people actually needed.

Some help is available

The Lean Startup movement aims to address the front-end problem with their constant learning, MVP (Minimum Viable Product)  and Pivot concepts. But in reality, they are far from a panacea. MVP is probably one of most misunderstood (and poorly named) concepts in any new product development methodology.

First, let’s cover the poor naming issue. There is no “product” necessary when dealing with Minimum Viable Product. The MVP could be anything that helps you learn more about the needs of users and customers: a demo, a prototype, a teaser page etc. While MVP does push the idea of learning and making decisions to the forefront of new product development, there is no set way to know what you need to find out, or how to find it out. You don’t know what you don’t know.

And in terms of misunderstanding,  I’ve heard people talk about a shipping product as “not yet MVP”. i.e. they were saying that the shipping product still does not provide enough value to compete successfully in the market.  This is hugely problematic. First, they clearly don’t understand what MVP means, but more importantly, they’ve decided to release a product to market that doesn’t meet minimum user needs.  Who benefits from that? Not the company and definitely not their users.

Although Lean Startup has a lot of notoriety these days, the principles it espouses are nothing new. Small experiments and making decisions as you learn what you need to move forward have been a successful innovation process for many years. Ever see the original Dyson vacuum commercial – the key line “…and a few thousand prototypes later…” is a telling statement.  How much did James Dyson learn from each of those prototypes.

How to go-to-market

But, let’s assume the product does meet minimum user needs. i.e. it sufficiently addresses specific use cases.  It still doesn’t guarantee success. Does the company know how to communicate the value externally? Can they position it and differentiate it from competitive offerings? Can the company identify initial prospects and customers. In short, can the company execute a successful go-to-market (GTM) strategy. In many cases, sadly, the answer to this question is “No”.

A go-to-market plan for a new product needs to be laser focused on a specific target market and one or two specific use cases. It should be clearly differentiated against existing competitors or alternative solutions. I’ve seen far too many companies come to market and position their new, unproven product as a head-to-head competitor against an established incumbent.

An example of a good GTM strategy is that of VMware. One of the first use cases for VMware’s virtualization technology was for Lab Management — the ability to easily configure, patch and manage server environments for development and QA. This was a very popular use case and addressed customer needs years before server virtualization in production environments — the most common use case today — was ready to adopt the technology.

On the flip side — remember the search engine Cuil? Probably not. Back in 2008, a bunch of ex-Googlers decided they were going to create a search engine to displace Google. As for the launch? I wrote about it here.  In short, significant problems that could have been avoided. The end result? 2 years and $33 million dollars later the site was shutdown in 2010. There are MANY examples of companies and products that were epic failures:

  • Coors Spring Water
  • Colgate Kitchen Entrees
  • New Coke
  • Bic Underwear
  • WebVan
  • Wii U
  • Microsoft Zune
  • Segway
  • Neflix Kwikster
  • Iridium phones
  • etc. etc. etc.

The list goes on and on, in every single product category you can think of. A philosopher might say that without failed products, there can be no successful ones.  But as a Product Manager, I say, that the sheer number of failed products shows companies have yet to learn the basics of repeatable product success.

So, what can be done to change this situation? What do you do in your company to address these problems?


Tweet this: The 3 biggest problems in Product Management today part 2 — Process — #prodmgmt #innovation 

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.

The 3 biggest problems in Product Management today – Part 1 – Roles

by Saeed Khan

RolesResponsibilitiesAs Product Managers, part of our job is to observe, understand and correlate information about our customers, prospects, markets, competitors and organizations. We then take the insight and apply it as needed.

Over the last several years, I’ve had the opportunity to talk to a lot people working in technology companies, either via the blog, in various online discussion forums, at various ProductCamps (Toronto, New York, Boston, Austin, Silicon Valley) or other events I’ve attended.

And as part of my observe, understand, correlate process, I’ve concluded there are still some major Product Management issues that seem endemic in companies, both small and large.  The problems I’ve seen are:

  • poor definition of roles and responsibilities
  • significant gaps in repeatable product processes
  • problems in intra- and extra-company communication and alignment

These are big problems. Not every company has all of these problems, and certainly some companies do some of these better than others. But many companies seem to be unable or unwilling  to think through and solve these problems, or are simply oblivious to the fact that these problems exist.

I’ll cover the first item in this post and the others in subsequent posts.

Poor definition of roles and responsibilities

This is by far the biggest and most fundamental problem I see. When you can’t get the roles and responsibilities right, how can the the activities and deliverables be done effectively.

With titles like Product Manager, Product Marketing Manager, Program Manager, Technical Product Manager, Associate Product Manager, and Solution Marketing Manager to name a few, confusion reigns. One of the core problems here is that Product Management is a true cross-functional role and most management teams don’t understand how to structure that.

Companies are very good at organizing and operating in silos. This lends itself to a traditional command and control, top down management model.  Cross-functional product management throws a wrench into this mindset by being completely orthogonal to this model. Yes, Product Management “belongs” somewhere, but where? There is a  correct answer, though I won’t go into it here.

Additionally, once the “where” question is answered, the harder “what”, “how” and “who” questions need answering. i.e. What are their responsibilities? How should they be organized to effective? Who do we hire for these roles? It’s not difficult to answer these questions if they are thought through, but most companies don’t and thus try to force fit a role into their existing, far from optimal, org structure.

In came Agile

And then the Agilists come marching in with Product Owner and several variants thereof and really messed things up. Suddenly development groups were going “agile” and demanded that the Product Manager become embedded with the Development team, attend standup meetings and be on-hand at all times to help make decisions.  As if somehow the Development teams suddenly had no responsibility in making development related decisions.

I’m absolutely convinced that the whole Agile movement has done a lot more harm than good for the role of Product Management in companies. I’m not an Agile-hater, and there are benefits to “being Agile” (or agile) but there is also growing dissension in Agile ranks. Some sanity is returning to the mix, and Product Managers are slowly extricating themselves from the mess created by Agile.

Product Manager vs. Product Marketer

But even without the Agilists and their misnamed, improperly defined role of Product Owner (see some of my thoughts on that topic here), simply defining and delineating Product Manager and Product Marketer caused confusion for many companies.

What part of the company do they report into? Are they both reporting into the same org or different orgs? When should we hire these roles? Who takes care of what and when?  I wrote this pair of articles for OpenView Labs to help delineate Product Management and Product Marketing.

User Experience rises

Now add UX to the mix — Experience Designer, Interaction/Interface Engineer etc. — and the role confusion increases. Where is the overlap between the two? Some people wonder whether Product Managers are needed now that UX is present. Clearly those people don’t understand what Product Management is if they are asking that question. Heather Searl’s first post on this site helps clarify some of these issues.

To a certain extent, some of these problems look eerily similar to what happened with Agile, but there are some differences. UX is a new area of expertise that didn’t exist previously in  most companies. Development and Engineering were long established and influential groups in every company. Additionally, I have found UX teams more reasonable than many Engineering teams. A generalization of course, but true in reality.

Jeff Lash of Serious Decisions wrote a good post on UX and Product Management, and makes valid, logical points.

The organizational problem is not that difficult. Really. Why do so many companies have so much trouble sorting this out? It’s pretty clear to me. :-)

What are your thoughts?


Tweet this: The 3 biggest problems in Product Management today (part 1) - #prodmgmt #ux #agile

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.

User Experience: A Primer

By Heather Searl

Every time I log into LinkedIn I’m asked to endorse someone else for user experience knowledge. I’d like to think this proves user experience has grown from a buzz word to taking its rightful place as a core business skill that people are investing in. Unfortunately many people I talk to go on and on about how important user experience is but don’t know how to create the experience their customers are looking for.

User Experience may be on their LinkedIn profile, but it isn’t in their everyday tool kit.

What is User Experience?

3 Pillars of User Experience: User Insight, Design, Concept & Usability TestingUser experience, or UX, means different things to different people. In some circles it’s used interchangeably with customer experience to refer to a customer’s interaction with a product or brand from initial research through purchase, use and disposal.

In the product development world user experience usually refers to designing and building a product that works the way people expect and that people will enjoy using. When you want to create a positive user experience in this world, you need to build it on the 3 pillars of:

  • User insight
  • Design
  • Concept and usability testing

User Insight

First, you have to get out and really listen to your end users. Going out and demo’ing the latest version of your product and asking what people think won’t cut it. You’ve got to listen and observe objectively to understand where people’s pain points are, how they expect your product to work and where it fits into their lives. You need to understand their goals, frustrations, domain knowledge and tasks.

This is different than traditional market research which focuses on the “Who” and the “What” of market segments and product interest. User insight that shapes the best user experiences focuses on the “How.”

  • How do people currently complete the task at hand?
  • How do they deal with current obstacles and pain points?
  • How knowledgeable are they in the domain and what related skills do they have or not have? For example, are users more likely to spend time web surfing and posting a status in Facebook, or do they spend time creating complex spreadsheets.)

Ideally this information is gathered by observing and interviewing potential users in their own environment.


All the customer insight in the world isn’t going to help if you can’t turn it into a design that reflects the goals, workflows and attitudes of your prospective customers.

To do this you must recognize which of the following skills you need on your project.

  • Interaction Design: Designing the behavior of a product
  • Industrial Design: Designing the form and function of physical products
  • Information Architect: Categorizing and organizing information and labeling it
  • Information Design: Designing clear communication of concepts or data
  • Graphic/Visual Design: Color, typography, and layout etc.

High Fidelity WireframeThese skills are frequently used interchangeably in job descriptions and titles, so it’s no wonder that organizations often assume the skills are interchangeable and that one designer will have them all.

But, designers who have mastered all of these skill sets are rare. (If you have one of these mythical creatures on staff, hold on to him or her.) Designers aren’t one size fits all. Make sure you understand the skills your team has and fill any shortfalls with freelancers, help from other teams etc.

Concept and Usability Testing

Too many companies either don’t test their product with their target market, or they wait too long to do it.

There often seems to be a desire to put the product’s best foot forward by getting customer feedback on a nearly complete product.  But what happens if it has some serious issues at this point?

You’ve probably heard the phrase, “fail early, fail often, and fail cheap.” This is especially true when concept and usability testing your product.

Getting feedback as you develop the product shouldn’t be optional. Just because the workflows, widgets and language make perfect sense to YOUR team, doesn’t mean they’ll work for end users.

Prototype of IR signal repeaters for consumer electronics made from odds and ends

Prototype of IR signal repeaters for consumer electronics made from odds and ends

For software and web sites, test your structure, workflows and key interaction points early with paper prototypes or low fidelity mock ups. Do the same for hardware by building low fidelity prototypes out of cheap materials.

Follow up by testing with more refined prototypes like wireframes, 3D printed models etc. And repeat as often as the budget allows.

It’s more important to test frequently that to test with large numbers of people. When resources are tight,opt to test earlier rather than later.

Creating an outstanding user experience isn’t a dark and mysterious process. It looks a lot like any other product development process – do the research, do the work, test the work. But it is one that is still often overlooked by many organizations.

Tweet this: New post – User Experience: A Primer #prodmgmt #ux

heathersearl-newHeather is a user experience consultant and writer who believes in doing everything from a user-centric point of view. She has more than 20 years working in high tech and is well-versed in helping product management and development teams get to know their customers, understand usability issues and turn these insights into design innovations.

Heather can be reached at or on Twitter as HeatherSearl.

Happy Star Wars Day — Rules of the Product Management Jedi


In honour of Star Wars Day — May 4th — I thought it was appropriate to reprint this oldie, but goodie. :-)


Balance many opposing forces to achieve harmony you must

Without question, being successful at Product Management can be viewed as a balancing act. This is true for any business function, but given the number of cross-team dependencies for Product Management, it’s incredibly important for Product Managers to be aware of this. Over time, balancing the needs of sales, marketing, development, support etc. are all critical to success.

A plan is only as good as those who see it through

It’s actually very easy to make plans. All it takes is a set of objectives and some optimism. But as everyone knows, creating a plan and executing a plan are very different things. Every company has limit on it’s ability to execute a plan. The size, background, existing workload, dedication, difficulty of the task and many other factors play parts in the company’s ability to execute. When defining plans, make sure your goals are feasible and within the limits of the teams that will have to carry out those plans.

Say “No”, for only then does “Yes” have meaning

Saying “Yes” to a customer or Executive request is easy. It’s the expected answer, but it’s meaningless if it is the only answer you give. Product Managers cannot be bobbleheads, nodding yes to every request.  Saying “No” to a customer or executive is also easy, IF you can clearly articulate why it is the right answer. Saying No the first time is the most difficult, but it is also very empowering. After all, part of what everyone expects of Product Managers is their judgment in making good decisions.

Earned over time credibility is, but in a moment lost it can be

Building strong cross-team relationships is critical for success….take time and effort to understand what other teams need from you, and what you need from them. Information and power will flow in both directions easily if you gain credibility with others. Without that credibility, and the associated trust that comes with it,  your path to success will be difficult regardless of how much effort you put into the job.

Inspire greatness in others, all great leaders do

There is a lot of talk about Product Management and leadership. But what does it mean to be a leader of product or of a cross-functional team? Leaders are only leaders as long as they have followers. But the best leaders gain followers by setting an example for them and, in fact,  helping the followers achieve their goals. To be a great leader, show your team members you can help them be successful, in whatever definition of “success” is meaningful to them.

Ignore you instincts at your own peril you do

Logic and reason are incredibly valuable tools, that unfortunately can be in short supply in many companies. But, logic works best when you know all the facts for any given situation. Remove some key facts and where will logic lead you? While we don’t understand how it works, instinct is a critical tool for decision-making, for leadership and for success. Don’t ignore your instincts if you are troubled about a decision. In the end, after all the data is crunched and the insight gleaned, decisions are made in our brain before we even consciously know that we’ve decided something. Sounds a bit like instinct don’t you think?

And finally, a bonus rule, surprisingly omitted from the original list.

Do. Or do not. There is no try.

One of the most famous quotes from Yoda, this is also one of the most applicable to product managers.  As product leaders we need to be decisive in our actions and focus on the key tasks that lead to product success. “Trying” is simply a statement showing lack of confidence.  This doesn’t mean that all decisions or actions will be the right ones, but it does indicate that when we take those actions or make those decisions, we have a firm grasp of the situation and commitment to our goals.


Tweet this: Happy Star Wars Day — Rules of the Product Management Jedi  #prodmgmt #starwarsday

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.

Passion and product teams

We act as though comfort and luxury were the chief requirements of life, when all that we need to make us really happy is something to be enthusiastic about.—Charles Kingsley, professor, historian and novelist


One of the corporate competencies that no one seems to discuss is passion. We talk about systems and expertise and different departments but passion and purpose rarely make the list.

Yet it is passion that makes people go the extra mile. It’s what makes them stay late and come in on the weekend.

I once developed a scheduling system for services personnel. It was multi-user in a time when most people were doing everything on a standalone computer. I worked hard on it and I was proud of it. To put a new upgrade in place, I waited til everyone had gone home for the day, did a full backup, installed the new system, and had it all back online by the time work started the following day. I worked through the night—and was glad to do it.

Your developers have this same sort of passion for what they build. What they need from product management is a sense of purpose—a passion.

How can product management inspire the team? Vision.

The insights product managers and product owners can provide to the team helps developers understand the people and their problems. That’s why persona profiles are so important. It’s also important to show your team the business side of things: explain how releases align with industry events, and how delivering on schedule results in revenue.

In my first development meeting I was surprised how much the team wanted to know the business of the product: revenue, installations, marketing plans, and business goals.

Sure, product managers need to provide requirements and stories in a prioritized list (see my post on prioritization). This to-do list is the work that needs to be done. Product leaders must also put this list in context to instill purpose in the team.

You’ve presented your business plan to the leadership team. Now present it to your development team. Trust me: they’ll appreciate it.

About the author

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

Product Management – It’s All About the Execution

By Josh Duncan

doneI recently was asked, what are the most important skills for a product manager?

I answered that there are range of skills that a PM is required to use from the standard technical and business side and to the important soft skills like communication and persuasion. I have been thinking  more about the answer and think you can call execution the most important skill when it comes to Product Management.

Getting product out the door is one of the many metrics a product organization tracks and the product management team plays an essential leadership role here (see point #5 on Hiring a great product leader). In order to make this happen, a product manager has many responsibilities and tasks that need to be addressed. However, execution is not just about getting things done. Product managers usually have an endless list of action items that they need to address.

A few of the factors that product management must balance when prioritizing this list:

  • What are the company goals for this year?
  • What about next?
  • What are the development capabilities and backlog?
  • Where does sales need help?
  • Where is the services team experiencing the most pain?
  • What is the customer feedback saying?
  • What is the customer data saying?
  • Where is the competition at and where are they heading?
  • Are there market dynamics that need be taken into account?

Execution is about understanding what needs to be done and how to get it done given the current set of constraints. It’s about figuring out what is important, what’s not, and then making sure it all happens.

An effective product manager must be able to see all parts of the equation while prioritizing everything that needs to be done. It may be a meeting with marketing to align on outgoing messaging. It may be working with sales to finalize pricing changes. It may be design sessions with the development and UX team on the next big feature release. The key being that not everything that is important is most important right now. 

Execution is about getting the right things done at the right time resulting in the right product shipping on time. 

What do you think?


Tweet this: Product Management – It’s all about the execution #prodmgmt

Want insights? Go outside and observe!

By Saeed Khan

I returned recently from a business trip to Germany. Whenever I travel, whether for business or pleasure, I find it difficult to take my “product manager”  hat off. Little things catch my eye, and often seemingly mundane things such as efficient parking lots draw my attention.

Here are few observations and lessons from my trip that I’d like to share.

If at first you don’t succeed…

Back in January after a business trip, I wrote about an ad I saw in the airport promoting Accenture. The image is below.


The misspelling of word “Billions”, simply to fit the concept was what really irked me. As I was walking through Frankfurt airport last week, I saw another ad from the same campaign.


The German text at the top (“Wir haben uns…”)  is similar to the text in the English ad:

After studying the critical elements of Dow. The result: savings of 2.5 billion U.S. dollars

[Feel free to give me a better translation if possible. This is a modified version from what Google translate provided.]

I’m assuming “Woo Hoo” translates into German as it does in English. This ad is a bit better (IMHO) than the English version above.The “Woo Hoo” catches the eye (much more so than “BiLiONS”, and there is a hard fact — 2.5 billion in savings — embedded in the message.  Perhaps the German market is more discriminating or their agency learned from their misstep in North America. Not a great ad, but certainly better than the English language one.

BTW, if you want to see other Accenture (English) print ads,  you can see them here.

Tailor your messaging to your audience


While waiting for the subway in Frankfurt, I started reading a poster for movies playing in town. “The Return of the First Avenger” caught my eye. In North America, this movie is called “Captain America: The Winter Soldier”.  Not a great name in my opinion unless you read the comics and know the story already. “The Winter Soldier” sounds like a description of Captain America himself. But I digress.

Apparently, the title didn’t test well in Germany, so they went with the alternative title. It’s interesting though that they didn’t call it “The Return of Captain America”.  The first film used “Captain America” in it’s title in Germany. i.e. “Captain America: The First Avenger”.  Regardless, it’s one of the very few countries in where the name “Captain America” doesn’t exist in the title in some form.

Keep the messaging simple

I’m a big fan of clear and easy to understand messaging. It sounds like a no brainer that everyone should follow, but somehow, in the bowels of marketing meetings, often very simple concepts turn into nebulous concepts that mean little to the target audience. So it’s nice to see examples where that didn’t happen.

In Heathrow Airport, whose waiting areas are often hard to distinguish from shopping malls, I had to take note of this establishment. No fancy name or confusing signage. Just a clear statement written from the customer’s point of view. And with throngs of multilingual customers passing by, there is little room for confusion, even if you don’t speak English. I ended up buying some food there: soup, sandwich, drink – what more could a hungry traveler need?

eat store

Measure and manage where possible

heathrow security

And lastly, after I had passed through the security check point in Heathrow, I came across this device.  I guess Heathrow Airport wants to know how they are doing with their security checks. The simple interface – 4 buttons – Very Happy, Somewhat Happy, Somewhat Sad, and Very Sad — is easy to understand and doesn’t provide a middle button – i.e. ambivalent or no preference.

There is also a paper form that asks for more detail — Tell us how we can make your journey better. I regret not taking a copy of one of those forms just to see what they were asking inside.

I did see one person walk up to the device and press a button so people do use it, but few people overall were pressing the button. This device was sitting near the exit of the security area and no mention of it was made via signs or security staff previously. If the security officers simply asked people to give them feedback as they via the device, there might be a higher response rate.

Still, it’s a start. I’ve not seen similar devices in any other security checkpoints in any other airports.

So there you have it. There are lessons we can learn everywhere. All that’s needed is a trip out of the office.


Tweet this: Want insights? Go outside and observe! #prodmgmt #insight

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.

Dear Product Manager: 4 Things Your UX Expert Wants You to Know

By Heather Searl

Dear Product Manager,

Here we are at the start of another project and, while I love working with you, there are a few things I’d like you to see from my point of view.

First off (and this is a biggie), you are NOT the target user.

Postcard representing a letter to Product Managers from UX

I know you know our domain inside out, and the presentations you give about the technology are impressive. I know you are passionate about our product and that you live and breathe everything related to our domain.

The problem is you know, and care, too much. Most of our users are not as passionate about our products as you are. Yes, I know there are some and I know they sought you out at the last user forum to share their ideas with you.

But most of our users aren’t like that. They use our product to accomplish a goal so they can move on to the next thing. They don’t understand all the industry jargon that rolls off your tongue with ease, and they don’t care about all the flash and wiz-bang of the latest and greatest technology advances.

My point is that we can’t design a product that is perfect for you.  We need to design a product for the typical user.

Secondly, you can’t do it all.

Yes, you are ultimately responsible for the success of this project and that’s a lot of pressure. I understand why you want to talk to all of the customers, document all of those discussions, analyse the results, and decide what tasks to use in usability testing. I get that you want to make sure everything is done right, but you can’t do it all.

You have too many budget meetings to sit through, sales projections to compile, stakeholder suck-up lunches to attend, and a million other things that have to be done as part of your day.

Let me help.  I know that it takes as long to write up the summary of a customer interview as it does to do the interview. I’ve done it many times. I also know that if it isn’t done that information will be lost.

I’m not suggesting you hand over all of the customer insight activities to me. Oh no. You HAVE to be part of that. It’s crucial that you understand our users inside and out. Which kinda’ brings me to my next point.

Third, you and I shouldn’t be the only user experts on the team.

I know it’s in your job description and mine that we talk to end users and understand their needs. But the developers, QA testers, tech writers and everyone else will make better decisions if they fully understand the user’s needs as well. Let’s take some of them along with us on our next customer visits, and after that, let’s put together some lunch and learn sessions to share what we learned with everyone else.

Yah, I know we’ll have to drag some of them (especially the developers) with us kicking and screaming. But I promise they’ll come up with some great ideas when they are working with firsthand knowledge of our end users instead of making decisions by guessing at what end users do and don’t do with our product.

And lastly, please, oh please, focus on the WHAT and not the HOW.

For example, don’t create full wireframes for your concept and requirements documents. These documents should tell us what to build, not how to build it. When you put too much detail about how things should look and work into these documents you lock us into a design direction when the project has barely started.

Put together some high-level sketches so everyone can visualize the product – but don’t go too far.  Some of our teammates are pretty literal, and they are going to fight against every change to your original idea no matter how much sense those changes make.

If you are worried that I or the rest of the team will go off on a tangent with the design, don’t be. We WANT you involved in our brainstorming sessions and we WILL get your approval on all designs.

Speaking for myself, if I don’t do detailed design reviews with you or I don’t give you time to think about the workflows and interactions that I’ve put together, call me on it. This is a collaborative project after all.

Please understand that I’m not pointing these things out just to make my job easier (although that is part of it). It’s more about working as a team. The more in-sync we are about what our users need, and the more we understand where each of us is coming from, the stronger the end product will be.

Let’s talk. In fact let’s make sure we are talking a lot more than we are now.


Your UX Expert

Tweet this:  Dear Product Manager – 4 things your UX expert wants you to know #prodmgmt #ux


Heather is a user experience consultant and writer who believes in doing everything from a user-centric point of view. She has more than 20 years working in high tech and is well-versed in helping product management and development teams get to know their customers, understand usability issues and turn these insights into design ideas and innovations. Heather can be reached at or on Twitter as HeatherSearl.


Photo courtesy of  Jeanne Menj via Flickr

Product management in the Cloud

by Paddy Barrett

How the shift to SaaS product offerings changes the role and activities of the product manager.

paddycloudA product manager who has learned the craft with on-premises products will have to adapt to the cloud by becoming more flexible and responsive – flexible in adapting to the speed of change with cloud products (think continuous delivery) and responsive to the greater interaction with customers that the cloud allows.

These were among the main findings of my dissertation for an MSc in Software Product Management in which I set out to determine the impact of the shift to the cloud on product managers. The existing academic literature revealed that little or no research into the subject had taken place, even while cloud computing was gaining more acceptance from business users, and as more enterprise software vendors were entering the cloud space.

Such a seismic shift in the industry was bound, I believed, to have a significant impact on the role and activities of the product manager, so I set out to research the subject by interviewing practising product managers who had experience with on-premises and cloud products.

To find suitable candidates for interview, I reached out to Scott Sehlhorst and Rich Mironov, who were guest lecturers during my first year of the Master’s program. Both were kind enough to introduce me to their contacts, and in the end I had to decline several offers to participate! The interviews covered the following core subjects:

  • cross-functional teamwork
  • decision-making processes
  • customer relationships
  • pricing
  • product life cycle management
  • continuous release
  • new product development
  • and key personal qualities and skills.

Over the course of ten in-depth interviews, my research confirmed that the aim of the study was valid – the shift to the cloud has a concrete impact on the product manager, and this impact is seen most clearly in the areas of cross-functional collaboration, customer relationships, and innovation.

My findings also met other research objectives, such as identifying the different product management activities required for cloud products compared to on-premises products, and an appreciation of why cloud products require a different product management approach.

The management of cloud products differs markedly from on-premises products in terms of the responsiveness and flexibility required of the product manager – the adaptability of the product manager becomes a critical factor in the success of cloud products. The shift to the cloud affects several activities of the product manager, who must anticipate new demands on both the role itself and on related functions within the organisation. From this conclusion, some key recommendations for practice are possible, including:

  • Understand how the cloud model works, with special regard to legal requirements for data protection.
  • Foster customer loyalty and interaction by managing customer expectations.
  • Master the use of metrics to analyse how customers use the product and also to develop product requirements.
  • Introduce design thinking practices to improve innovation, engage with users, and test prototypes.
  • To prevent the customer disruption that can be caused by continuous release, give customers some control over receiving upgrades to the product.
  • Help your cross-functional teams to adopt better collaboration processes, such as social networking tools, for faster communication and decision-making.
  • Stay focused on your long-term product strategy to safeguard against the tendency to focus on short-term customer requirements.

Some of these practices probably require further study, particularly the management of the continuous release process, the new opportunities for innovation – especially design thinking – that are made possible by the cloud. Other areas that could benefit from new research include lifecycle management of cloud products, the use of social networking tools for cross-functional collaboration, customer relationship management within the cloud paradigm, and the migration of on-premises products to the cloud. Given that the interviewees were all operating in B2B environments, it would also be interesting for other researchers to compare the experiences of B2B and B2C product managers.

In conclusion, this research offered a new understanding about the impact of the shift to the cloud on product management. Specifically, it found that traditional product management activities become more dynamic in the cloud context and that the product manager must adapt by becoming more flexible and responsive. It also found that managing customer expectations becomes a critical concern for the product manager.


Tweet this: Product Management in the Cloud - #prodmgmt #cloud

About the Author
Paddy Barrett is a technical writer for IBM Connections and a budding product manager. He received his MSc (First Class Honors) in Product Management from the Dublin Institute of Technology last November.