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.

tools_for_product_managers

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.

Saeed

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.

Reverse Engineering & Product Management? Really?

by John Mansour

reverse engineerReverse engineering usually conjures thoughts of knock-off artists creating their own versions of popular consumer products.

Or in the B2B world, reverse engineering is often required after a company acquires products or technologies from a defunct company and there’s no documentation of the underpinnings.

But over the past couple of years, a significant number of our customers have found a much more creative application for reverse engineering – strategies and product plans that are already in flight! i.e. start with the end in mind and then work backwards, decomposing it as needed to define user scenarios, messaging etc.

Don’t raise your eyebrows yet! It’s become one of the most valuable and fun exercises I’ve seen in a while.

Here are a few examples you can probably relate to.

Example 1

Current Roadmap Item: Updates to Sales Quoting Tool

The supporting information is a list of features that comprise the update.

Reverse Engineered Item: A self-service quoting tool that will make our customers easier to do business with and showcase their unique abilities by allowing their prospective customers to quote configurations none of their competitors can offer.

The supporting information is a list of user scenarios that describe the various ways customers build unique quotes and the supporting features for each.

Example 2

Current Roadmap Item: Project Acme – a new platform.

The supporting information is a list of capabilities that comprise the new platform.

Reverse Engineered Item: Deliver a superior customer experience that will improve retention by reducing the effort and complexity required for customers to do X, Y and Z.

The supporting information describes before and after customer scenarios and highlights critical areas where the customer experience will change significantly for the better.

The Value? 

The value in both of the above examples and virtually every other situation I’ve witnessed is the creation of a simple and powerful business dialog that articulates what it is and why it’s valuable, instead of how it will be built!

Helping customers create the business dialogue around their strategic initiatives and product plans is a lot of fun for them and me. Watching the reaction from executives, sales, engineering or marketing when product management presents the new and improved versions is even more rewarding because everyone just “gets it.”

For product teams, it makes the downstream execution easier because the target is clear and expectations are in line accordingly. For executives, sales, marketing, account managers, etc., it gives them a compelling story for the outside world.

John

Tweet thisReverse Engineering & Product Management? Really? http://wp.me/pXBON-4dJ #prodmgmt 

About the author

John Mansour is a 20-year veteran in high technology product management, marketing and sales, and the Founder of Proficientz, a services company focusing on product portfolio management.

 

He Said, She Said: Part 3- How PM and UX can work together

By Saeed Khan and Heather Searl

pmuxParts 1 and 2 of this series covered a number of topics including working with other teams, organizational structures, personas and common documents. This part delves into:

Agile and Documentation

Heather: Agile presents a lot of problems when working with development. I worked for a company that moved to an agile development methodology, but sold into a very regulated market. As part of the move to agile a lot of formal documentation was reduced and omitted.

That didn’t work for the customers who needed to see a clear process and documentation on changes from release to release for their own regulations.

So we ended up developing the product using an agile methodology but on the side  we’d sit through long meetings creating requirements and arguing over whether the wording for each requirement was “should,” “shall,” “must” or “may” on things that were half built already

Saeed: That’s just bizarre. You mentioned Agile. I’ve had a lot of trouble with Agile and Product Management, but we don’t need to get into all of that here.

There is definitely good in the Agile process but people don’t pay attention to the basics. One of the principles of the Agile Manifesto is “working software over comprehensive documentation”.

People think “Hey, I don’t have to create documentation. I can just build stuff.”,  and they run with that idea because it is what they want to do.

If they just read and understood the basics, they’d realize the principles are structured as X over Y not X instead of Y. i.e. focus on the first, but don’t ignore the second.

Heather: I then went to a start-up environment where I asked to see specs and documentation on an existing product so I could understand everything it did to start working on the next iteration. There was no documentation.

I was told to just try using the product and figure it out that way.  As you can imagine that created a ton of issues for next generation products. Developers would agree to something and then discover the existing code didn’t work the way they thought and timelines would have to change.

I was told that I should create the spec documentation based on trying to use the released product. We actually tried to do that a few times and we tried to create a site map for a complex web app but gave up because there were so many different paths that we kept missing things.

All projects at that company had to have multiple long term employees on the team or all hell would break loose. New developers, a new product manager and new UX person on a team and a project would be defined, scoped and agreed upon that was totally impossible because of legacy code, designs etc.

Saeed:  Any process where people think a written record of the product can be done away with to save time and money, is doomed to fail. It’s truly penny-wise and pound-foolish.

As you said, new teams couldn’t succeed because all the required knowledge. How well could a mechanic repair an engine of a new car without any manuals or diagnostics?

I always find that documents helps. I write a lot of documents. I will write a Word document instead of using PowerPoint because sometimes the detail is really necessary. It also helps me get my thoughts organized and can be a reference document later as our collective memories eventually fail.

Also, it is easy to distill a Word doc down to PowerPoint, but not the other way around.

But unfortunately, many people don’t know how to create good reusable documents, so it creates a huge gap very early in the design and development process.

Ownership and Decision-Making

Saeed: One interview question that I ask product managers is how would you describe product management in one word. There is no right answer but there are bad and good answers. One of the answers I would give if asked is “balance”.

In the end product management is about balance. Sometimes I need to focus on the technical, other times  on the financial but over time this has to balance.

Heather: The word that was coming to mind is compromise. Thinking along the lines of what you said for balance. But balance is a better word. Compromise has too many negative connotations of giving in or creating mediocrity.

I like to think of myself as a product management’s right hand person – or one of them. There are a lot of other groups providing product management with key input.  I want to be listened to, but I get to dump the hard decisions on the product management who has to decide between the best user experience the scheduled the budget, competitive pressures etc.

I don’t have to be balanced. I get to stay focused on a single idea – what is best for the user. I get to argue for that and someone else makes the hard calls.

I like that I get to dump that on you. In the end I can argue my position and someone else has to balance it all.

Saeed: I don’t like the word compromise because of the negative connotations. Compromise sounds weak.

It is very clear when you see a failed product that there was no balance. There may have been a lot of compromise but no balance.

For example, the marketing may be great, the visuals fantastic but the technology platform is weak and makes the product weak overall. Or vice versa.

I prefer to get a good product out there and worry about the marketing later. But other people come at it from the opposite point of view. Go out with a bang.

Heather and Saeed

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

The UX responsibilities of a Product Manager – Part 2

by Gary Schroeder

In part 1, we discussed the importance of Product/Market Fit and concepts of Problem Validation and Solution Validation. This part covers 5 key UX responsibilities of Product Managers.

To architect great solutions to market problems, always start with the user and work backwards. Work backwards from their problems and how you want them to feel when those problems are solved.

#1 Responsibility: Prioritize Along User Needs

This is the end game and responsibilities #2 and #3 explain how you will be equipped to do this, but it is important to keep the end in mind.

Users have a hierarchy of needs that must be met in order to elicit delight.  I encourage using Dan Olson’s hierarchy of user needs as your framework to follow:

olsen-hierarchy

Much of the framework speaks for itself, but I will add two comments:

  • You haven’t yet earned the right to work on the “Increasing Satisfaction” areas (Feature Set and Usability/Design) until you have satisfactorily delivered on Uptime, Page Load Time, and Absence of bugs
  • The entire hierarchy (not just the top category labeled Usability and Design) adds up to the user’s experience with your product.

To effectively deliver a great solution to your users, you need to effectively prioritize work that aligns with the above user hierarchy.

#2 Responsibility: Know Your Users

You are your customers advocate and in order to do that you need to know your users. You need to be able to answer questions like:

  • What market are they in?
  • What are the trends in that market?
  • What are your user’s business goals?
  • What does a day in their life look like?
  • What problems do they encounter throughout their day and why do they need your product to solve those problems?
  • How often do they encounter these problems?
  • Do they work mainly from an office, or are they travelling 40 weeks a year?

Knowing the answers to these questions and more is the only way you can grade your product according to the user hierarchy of needs. What do I mean?

  • Does your product need to have a 99.999% uptime all year long? Or will your target user base only be using it during the first 3-4 months of the calendar year?
  • Do your users use the product 8 hours a day and need it to be lightning fast? Or do they use it only sporadically throughout the week and thus are not that concerned about page load times?
  • Is there really demand for the seven new features your executive team says your product needs? Or will that simply clutter the product with unnecessary and thus unused features?
  • If 87% of your users work at an office all day on three monitors, do you really need to invest in a mobile application or take great pains to incorporate responsive design?

Knowing your users makes these questions easy to answer. Getting the right answers to these questions helps facilitate a better user experience.

#3 Responsibility: Feel Your Users

The above questions require a certain level of understanding. But this kind of understanding only requires us to know. Truly great products however are not born from the brain, they find their source 18 inches south–the heart.  This type of understanding requires us to feel.  Building great products not only require us to know what our customers know, it requires us to feel what our customers feel. This means that customers are no longer customers; users are no longer users, prospects are no longer prospects; they are human beings–people just like you and me.

Making the human connection is step one. Developing deep empathy is step two. Empathy comes from answering–with the head and the heart–questions such as:

  • What do your users fear?
  • What are the frustrations in their lives?
  • What do your users want to gain from his job?
  • Less work and more money you say?
  • Why does a user want more money? Knowing that it is not to get a nicer car and rather it is because his son has a rare health condition and the medical bills are piling up changes your perspective entirely. He wants to take care of his son. This means this user needs to do well at his job so he can get a promotion, but this also means he can’t work 70+ hours a week to achieve that because he wants to spend every moment possible at his son’s side.  He needs a tool that will work with and for him.

Questions to gauge empathy?

  • Have you ever not been able to sleep because you were concerned about one of your users not spending enough time with her kids and how your product can help, even if in a small way, steal back some of that precious time?
  • Have you ever obsessed over two clicks vs. three?

#4 Responsibility: Interest Does Not Equal Aptitude – So Master the Basic Skills

Your goal is not to become a UI/UX Designer but you have to master the fundamentals of User Experience so that you can ensure your solution is compelling. Fortunately it’s fairly painless to pick up the necessary UX skills you’ll need as a product manager*.

Skill #1: User Research and Usability Testing

While you will likely partner with a UX Designer for these activities, you need to be involved and, if necessary, lead these initiatives.

To validate desirability–which is validating problems and solutions–you need to be in front of real users.

  • Learn how to conduct discovery interviews to help (in)validate your problem hypotheses.
  • Use design reviews and usability testing with actual or prospective users to (in)validate your solutions.

Skill #2: Prototyping – To the user, the interface is the product.

That doesn’t mean you need to know Photoshop, Illustrator, or Fireworks. But you do need to learn how to take a screens first, quick and dirty prototyping, approach to designing your product.  Again, start with the user–what do they actually see? How will they interact with the product? Get comfortable using tools like:

  • Pencil (or a pen if you’re daring) & Paper
  • Balsamiq

Skill #3: Reviewing Designs

You own the use cases and so you need to vet every single design against your market and user understanding.

Designs can be innovative and elegant, but if they don’t meet your user’s needs, they fail. And while your UI/UX designers should be taking great pains to understand your users as well as you do, don’t count on it.  It’s your responsibility to review their work and vet them against your user knowledge.

Responsibility #5:  Own Your Own UX Education

There is no shortage of UX resources for free online which means you don’ have any excuses to be ignorant.  Below are my recommendations on where to start:

  1. Documentary – Objectified
  2. Book – Design for Hackers
  3. Course (free) – Human Computer Interaction
  4. Bonus (free) – Hack Design

Summary

As a Product Manager, your job is to achieve product/market fit. A key component of product/market fit is validating if there is a prevailing problem in the market and that you have a compelling solution to that problem (e.g. Desirable).

To ensure your solution is compelling, you need to prioritize work according to your user’s hierarchy of needs which requires you to have deep knowledge and empathy of and for your users. Beyond knowledge and empathy, however, you need to be actively involved in creating solutions yourself via prototyping, testing the solutions in design and usability studies, and finally reviewing all designs that go into your product.

Gary

Tweet this:  The UX responsibilities of a Product Manager – Part 2 by @gjschroeder http://wp.me/pXBON-4ds #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.