The UX Responsibilities of a Product Manager – Part 1

by Gary Schroeder

“Design is not just what it looks like and feels like. Design is how it works.” – Steve Jobs (1955-2011)

When defining new products, one of key objectives for a Product Manager is achieving product/market fit; without it, nothing else matters.

But what exactly is product/market fit (PMF)?

To help us understand more clearly, let’s consider the following framework–adopted from the premiere product design firm IDEO. For IDEO, this framework helped codify innovation; for us, it will codify product/market fit.

To achieve PMF, our products need to find the intersection of three meta-themes:innovation-desirable-viable-possible

  • Desirability – this theme is fundamentally answering the question: “Do people want it?”
  • Feasibility – this theme is fundamentally answering the question: “Can we build it?”
  • Viability – this theme is fundamentally answering the question: “Will it be financially worthwhile for us to build it?”

Achieving this intersection is a pass/fail test.

If you build something that nobody wants, you fail. If you build something that people want but you lose money doing so, you fail.  If you identify a potentially profitable product that people really want but you can’t build, you fail.  To pass, you need all three.

It All Starts with Desirability

For this article today however, we will be focusing exclusively on Desirability which can be broken down into two questions that need validating:

“The primary thing that any technology startup must do is build a product that’s at least 10 times better at doing something than the current prevailing way of doing that thing. Two or three times better will not be good enough to get people to switch to the new thing fast enough or in large enough volume to matter. – Ben Horowitz

  1. Problem Validation – Is There a Prevailing Problem?

Product as built to solve problems;  and when attempting to answer the question, “Do people want it?” we are fundamentally answering the question, “Do people have the problem my product solves?”

Effectively answering this question requires knowing:

  • Who these people are (e.g. age, gender, internet habits, buying patterns, etc)?
  • How many of them are there (e.g. Total Available Market, Serviceable Market, Target Market)?

If no one has the problem you’re solving, or too few people have the problem your product solves, your product doesn’t pass the desirable test and there is no reason to build a solution for a problem that doesn’t exist.

  1. Solution Validation– Not just a Solution, “Your” Solution.

With problem validation, you’re simply proving that there is a problem in the market. With solution validation, you’re proving that the market doesn’t just want any solution to that problem; they want your solution to that problem. This is where user experience comes in full force.

Validating whether your product is a compelling solution to users’ needs is where Product Management and User Experience converge. Product Managers are not UX Designers and UX Designers are not Product Managers. But there is significant overlap and critical UX responsibilities that Product Managers have.

In part 2, we’ll cover the 5 specific UX responsibilities a Product Manager has when creating new products.

Gary

Tweet this:  The UX responsibilities of a Product Manager – Part 1 by @gjschroeder http://wp.me/pXBON-4dn #prodmgmt #ux #innovation

About the Author

gary-schroeder-bwGary Schroeder (@gjschroeder) has been helping companies deliver world-class products for over 8 years.  Currently he is Associate Product Manager at Accruent and writes about Growth Hacking, Product Management, Innovation, and Design at GarySchroeder.me.

He Said, She Said: Part 2 – How can PM and UX work together

By Saeed Khan and Heather Searl

pmuxIn the first part of this discussion, Heather and Saeed covered a number of  topics related to both Product Management and User Experience, including working across teams, working with customer and organizational structures. In this part we will cover ….

Personas

Heather: Personas are critical tools when defining user interfaces, but they are not well understood and often poorly defined. Personas often become an exercise in creative writing for UX teams. Writing a persona can be fun, but you can get carried away. This kills them as a useful tool.

If the personas don’t accurately reflect the group of people being designed for, and if they don’t answer project related questions about the target customer’s goals, work, work-related challenges that could be influenced by the current project and so on, they aren’t useful.

Some UX personas are too general or they just create a character. A good persona has to be project specific and relate to features being worked on.

Saeed: I once worked on a new UI for IT administrators. The UX team had created personas for a “generic” administrator. It contained a lot of, “Fred gets up in the morning, goes for a jog, has his latte and goes to work,” info.

The engineering team wasn’t very receptive. When you present that type of persona to an engineering group, they just roll their eyes and walk away.

So we did a bunch of user research with the engineers alongside. In our findings, one big change I made was to remove the word “persona” and start using the word “role”.

We identified multiple different administrator roles such system administrator, infrastructure administrator, network administrator, database administrator et cetera.  Then we agreed that our focus was the infrastructure administrator. This made things very clear and tangible for the engineers.

We used one particular customer — Chris — who became, for us, the prototypical infrastructure administrator.

From that point forward, if there were any questions that needed decisions, we would ask ourselves, “What would Chris do?”

That worked very well for everyone. We had effectively created a persona, but it was really focused on relevant activities we needed to understand. It had a lot of credibility.

Heather: There are also buyer personas that cover how Joe makes buying decisions, what his income level is, how he does research before he buys et cetera.

I’ve been told to use them and we couldn’t create design personas because too many personas would be confusing.

But the marketing personas don’t help me do my job. They don’t answer my questions.  All a project team can do is put them in a drawer and move on.

Saeed: I think buyer personas are important, particularly in B2C scenarios where the Buyer and User are the same or very closely related.

In that scenario, why someone buys, how they evaluate and how they use can be intertwined and need to be understood.  e.g. a parent might buy a digital camera for their child, but clearly the two personas are quite different but interrelated. The parent (buyer) may also be an occasional user as well.

In B2B, buyers and users are often quite different, though in many SaaS/Cloud applications they can be the same or closely related. e.g. the marketing team will purchase and use Marketing Automation tools.

Also there are influencers, who are related to buyers, and may have product needs of their own.

e.g. for an audit compliance product, the users (and buyers) are the legal/finance teams, but IT would need to manage the software, so they are heavy influencers.

If, for example, software administration is part of IT’s qualification process, and your product is not easy to administer, that would be a strike against you, even though, technically, IT is neither the buyer nor user.

Documentation and Deliverables

Heather: What about other project documentation? I find that sometimes there is conflict between UX and Product Management about who owns what deliverable.

Saeed:  Project documentation can be a problem when there is overlap in the acquired knowledge or even authorship of documents.

Requirements is one area. Although it is generally agreed that Product Management owns requirements, there can be requirements that come out of the UX side. The solution in those cases is to work together and discuss areas of possible overlap. In theory, PM and UX are part of a TEAM. :-)

But there is a bigger problem. You go from company to company to company, or even across teams i the same company, and there isn’t a standard definition of those deliverables except at the highest level.  Artifacts are different, formats are different, information is different…it’s a mess.

I worked at a company where we had a product management offsite where we had to present the current state and future plans of each of our products.

You’d think that since we all worked in the same company there would be consistency in the presentations. There wasn’t.

Some people had a lot of technical information. Others had a lot of financials. We didn’t look at our own products the same way. Even the financials were presented in very different ways for different products. When you bring in other groups like UX it gets more confusing.

Heather: I’ve seen great differences in what a product concept document (PCD) coming from different product managers contains, but they give me direction I need.  I’ve also worked with other Product Managers who refuse to put a meaningful PCD together.

Then you get into something that is more of a combined ownership, like requirements where you have user requirements, technical requirement, marketing requirements that all  have to come together at some level.

It falls apart when there isn’t collaboration. I’ve had product managers dictate all of the user requirements and others expect me to do it all.  I’ve also seen requirements put together in isolation that don’t make any sense as a whole.

People are trying to define the product their way by what they put in the market requirements, user requirements and technical requirements. And then there are conflicts between requirements that cause problems and create delays.

I like to work collaboratively. You start the document, I’ll add some stuff, and we’ll talk and edit and revise and see where it ends up. I struggle with almost anything that is just put together and thrown over the fence.

Saeed: I think that as soon as you start the discussion about standardizing processes you get a lot of pushback. People see added bureaucracy and more work. If you think about it in the long run, good processes should reduce work.

A friend of mine told me this story. At a startup, there was value to ambiguity from management’s perspective because it was easier to hide behind. It was an accountability issue with the board of directors.

So some senior people worked to ensure process and deliverables weren’t defined. Obviously that startup failed miserably.

In other places people are fearful of change or what the impact on them will be.

The discussion has to be what works for all of us. How can we make it better for all of us? I think that is the important question, but a lot of people don’t want to think or act on that? And in most cases, that leads to failure.

Saeed & Heather

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

 

 

 

Rules for customer visits #3 – Observation is critical

by Saeed Khan

Most often, a customer visit means having a discussion in a meeting room at your customer’s site, with a small group of users or interested parties.

They usually expect you to present something and get their feedback. e.g. a new or upcoming product release. or product roadmap or whatever.

Once the meeting is over, a lot of good intentions are shared for future such meetings and you leave the premises.

While those meetings have definite value, you should really try to spend some time with one or more users in THEIR environment — i.e. not in a meeting room, but at their desk or in their work areas to see what they do in their jobs, and how they ACTUALLY use your product.

You’ll be surprised how much you will learn.

customer_visit_rule_3_observing

How much time do you spend actually observing your users?

Tweet this: Rules for customer visits #3 – Observation is critical http://wp.me/pXBON-4d6 #prodmgmt #ux

Also see: Rule #2 – Moderation is key

Image source: Kylephoto.com

When Did Apple Become a Market Laggard?

by Saeed Khan

apple logoIn case you were sleeping yesterday, let me fill you in on the big technology announcement from Apple. Live from Cupertino California, and streamed (rather problematically) on the web, Apple had a number of big splashy product announcements. These included:

  • Upgrades to the 7 year old IPhone
  • A new (expensive) Apple Watch that can tell the time (amongst other things)
  • A mobile payment service call Apple Pay
  • Some updates to iOS
  • A free U2 album on  iTunes

With the exception of Apple Pay, it was for the most part an unimpressive show, though I have to give Apple credit for generated buzz for what were essentially a number of “me-too” product announcements.

The star of the show?

Most of the focus was on the new iPhones. The iPhone improvements were mostly related to faster processors, better cameras and most obviously bigger screens. But all that did was invite the inevitable comparisons with phones from Samsung and HTC which already had faster processors, better cameras and bigger screens.

iphone-samsung-htc

Yet another smart watch?

The long awaited Apple Watch was also announced.

apple watch mosaic

Yes, it does look good, has a number of wrist-band styles, and measures your heartbeat with built-in sensors etc., but in the end, it’s a watch with a STARTING price of $349! Oh, yeah, and even though it is a new product, the inevitable comparisons are being made with existing watches from Samsung, Motorola and others that have similar capabilities and are less expensive.

apple-samsung-moto-watch

 

Apple Pay has potential

Apple Pay seems like a differentiator to me….Even though there are other mobile payment systems like Square and Paypal, Google Wallet etc. the fact is that the client UI looks great, and on the back end Apple has partnered with Visa and Amex, so they are not a direct competitor in the way Square would be.

I’m not a mobile payment expert, but if I have an iPhone and it’s DEAD EASY to use Apple Pay, then as a consumer, that may be the way I start paying. Alas, I don’t have an iPhone, but lots of other people do and Apple’s cut of the payments made on all those iPhones could add up to a LOT of recurring revenue.

U2 on stage again? WTF?

I was (and still am) a U2 fan. I remember going to see them during the Joshua Tree tour with Los Lobos and Little Steven as warm up acts. Bono, arm in a sling because he had injured it in a fall during a concert a week or so earlier, belted out songs with a then, still vibrant voice. It was a cold October evening and my friends and I all shivered endlessly in our nose-bleed seats in the open air Exhibition stadium by Lake Ontario, regretting not wearing warmer clothing, but still enjoying the music and the show on the stage.

There were lots of “kids” — 14 years old or thereabouts– with their parents, probably attending their first concert. Apparently my wife – a big U2 fan herself – was also at the concert with her friends, though in much better seats than me. We didn’t know each other then, and wouldn’t meet each other for another 6 years. It was October 3, 1987, I was in my early 20s and U2 was the biggest band in the world.apple-u2

But U2 today is NOT the U2 of the 80s or 90s. So when U2 came on stage at the Apple launch and announced that their latest album would be free for download from iTunes, it seemed a decade or two too late. It’s almost like announcing a new version of Angry Birds is now available free for  download on the Apple App Store. Yeah…so what. It seemed a bit like Apple grasping for some old glory.  Apple did release a U2 branded iPod back in 2004 with Steve Jobs on stage with U2.

I’ll definitely check out the album (hey it’s free)…maybe there’s some good music there. Maybe U2 has a whole lot of fans that still see them the way I did back in ’87.

I may be completely wrong — Apple’s stock is up today over yesterday — and if so, it wouldn’t be the first time I was mistaken. :-)

What do you think? Is Apple losing it’s shine and becoming a follower vs. a leader?

Saeed

Tweet this: When did #Apple become a laggard? http://wp.me/pXBON-4cO #prodmgmt #prodmktg #iphone #u2

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 customers are not lab rats!

by Saeed Khan

mazeEverywhere you turn these days, someone is talking about running experiments and tests to understand your customers or target market.

They say things like:

  • use experiments to validate your ideas
  • A/B test responses to interface designs
  • build minimal solutions that can be built and released quickly to get ongoing feedback.

It seems that many product people can no longer make a decision without first testing everything out on users.  Some would say:

 “Of course, why wouldn’t you do things that way?”

but I’m going to take a counter point.

Just because you can run lots of experiments or  A/B test almost everything, doesn’t mean you should or that it’s the right thing to do.

In a recent discussion about improving sales effectiveness, someone actually suggested running an A/B test with sales teams; training one group one way, the other, another way, and then seeing which group did better.

Clearly this person didn’t understand that A/B testing requires ALL other variables to be held constant which would be impossible for different sales teams, with different territories, customers, objectives etc.

Additionally, let’s be honest…with exceptions such as A/B testing specific web page designs/layout over MANY impressions, most experimentation and user validation is done empirically with small numbers of customers. And the results themselves may be skewed or contain significant margins of error.

  • Did you ask the right questions?
  • Did you ask the right people?
  • Did you use the right tests?

Is anyone measuring that when the feedback is incorporated into product decisions?

Don’t get me wrong; I completely support making INFORMED decisions, but the mantra of experimentation is getting out of control.  Just because you didn’t ask someone some specific questions(s) about some issue in the past week, it doesn’t mean you can’t make a decisions about that issue.

Between Wild Ass Guesses and Calculations

Take a look at the the diagram below.

decisionzone2

On the left, we have the (infamous) Wild Ass Guess. Sometimes called “gut feel” — though IMHO gut feel is a bit to the right of WAG —  this is a decision based on little or no data and has huge uncertainty.

On the right, we have what I call Solid Calculation. This is a decision made with a complete set of high confidence data and is clearly understood as fact.

In the middle is what I call the Decision Zone. It’s skewed to the right of center, and there is a reason for that.  Here, there is some or a  lot of data, but it’s never 100% of the data. Thus it’s a decision and not a calculation. It’s skewed to the right because you want to have a SOME level of information (explicit or implicit), to base your decision on, and as you get further to the right it starts turning more into a calculation.

We are paid to make good decisions

In his book Blink, Malcolm Gladwell writes:

“The key to good decision making is not knowledge. It is understanding. We are swimming in the former. We are desperately lacking in the latter.” 

Experiments and  particularly A/B testing give us data and some knowledge, but where do understanding and insights come from? You can’t A/B test your way to deep insights. These come from experience, hindsight, domain knowledge and the like. In life, we use these traits everyday to make both big and small decisions, so what about work?

In fact, one of the main jobs of good managers, including Product Managers, is to make good decisions.

VERY Successful products and businesses can and have been been built without excessive amounts of testing and constant experimentation. Apple is the obvious company that comes to mind, and you can read short post here about how Apple views customer experimentation and iterative feedback.

So, let’s continue to make informed decisions, but also, let’s decide that not every decision requires A/B testing or customer experimentation before it can be made. Let’s trust in ourselves and in our coworkers enough so that we don’t waste time (ours and our customers) in unneeded data collection activities, simply to tell us what we should already know.

Saeed

 Tweet this: Your customers are not lab rats! http://wp.me/pXBON-4aD #prodmgmt #prodmktg #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.