It was a Wednesday and I found myself pulled into a meeting with a couple of our customer support folks and consultants representing one of our major accounts. The reason I remember it was a Wednesday was because this meeting fell smack dab in the middle of time I normally used to take care of some internal housekeeping — following up with engineers, talking through some of the workflows we were addressing, grooming the backlog a little bit, analyzing performance and user data. Things like that.

My Mondays were meeting hell that started with the team weekly sync, bizdev milestone update, ops milestone update, major deliveries and presales tech demo reviews, proposal reviews, cross-team coordination sync… basically everything but the kitchen sink.

Tuesdays were my team one-on-ones, which I very much enjoyed. These were generally spent providing lightweight business updates, real time feedback, and talking through workflows, which became a crucial part of our product strategy and roadmap.

Wednesdays were sacred days to get MY stuff done, but here I am. Sitting. Waiting. And I just found out that the customer service team blocked off FOUR HOURS to host a couple of customer success consultants representing a large account, who asked for an opportunity to provide user feedback to our team.

GREAT! I’m really into users and I’m REALLY into users that provide feedback we can use to improve the product, even if it takes up a bit of “me” time.

To set some context, our product is a data access solution for geospatial data, focused heavily on backend system performance, interoperable web services, and data management. Our secret sauce doesn’t demo well because it’s quite possibly the least sexy niche in the geospatial world — disk I/O, file management, data encoding, things like that… BUT, users LOVE how fast our servers are and we have some standard, out-of-the-box front end components we use to demo new features. That said, our CEO will be the first one to tell you — “We are not a viewer company.”

Within minutes I knew exactly what was about to happen…

Do not trust this human.

The Ephemeral User was about to make an appearance.

You know this exact situation. Sometimes, when you’re in meetings, people start talking about this ideal user who has certain preferences and pain points. In the past, I’ve heard people refer to rumblings as whispers from the “Good Idea Fairy”.

I reject the ”Good Idea Fairy” notion and understand this for what it is- an individual’s (often unverified) assumptions about HOW users interact with technology.

I call this phenomenon The Ephemeral User. The Ephemeral User is talked about in meetings, but is stateless, so no information about that user is retained after the meeting concludes. As I’m sure you can anticipate, at the next meeting a new version of The Ephemeral User pops up, with new tastes, preferences, and inclinations, often times completely contradicting previous versions of itself. The Ephemeral User is a phantom and a trickster that will send you down many nasty rabbit holes. I have spent a handful of years watching its tactics and learning how to make this phantom disappear.

And so Consultant One begins…

“So, uhhh… we were looking at some of the labels you have for the imagery layers. They are confusing to The User, so we need to change them to something The User will understand.”

“This dropdown menu is kinda in the way of other stuff The User likes, so we should move it to a new location. Or can we maybe get rid of it altogether?”

“Can we break this drawer into two separate boxes and make them pop out so The User can drag them off the map??

“The User would really like it if, when they hit submit on a job, the screen would morph into a desktop espresso maker and pour them a shot to get them through mid-afternoon. Also, Wednesdays are The User’s big meeting day, so the espresso maker would have to pour them a double shot. Only on Wednesdays though. That’s when The User needs it the most.”

Shouldn’t we just add a double or single shot option to the job submission?

“The User prefers when tiny unicorns prance around alongside the desk when the job is complete. Then maybe the unicorns could deliver handwritten thank you cards to The User that thank them for visiting your website.”

In pipes the Consultant 2 — “Man, The User really knows how to cut to the core of a remarkable, satisfying user experience, don’t they?”

“The User sure does, Consultant 2. They sure do.”

I’m pretty sure I did all the things a Product Owner is supposed to do in this situation. I listened. I empathized. I asked probing questions. I pointed out that it was clear these two consultants had absolutely no clue what the fu*k they were talking about.

J/k… I didn’t actually call them out. But I wanted to. I wasn’t frustrated by the time spent having the discussion. I was frustrated by people who came representing an account of tens of millions of $$$ and a large user base, but didn’t have the slightest inkling of what the actual users wanted.

OK, that last part I didn’t know for sure, but I had suspicions. Here is what triggered my bullshit radar.

1. No mention of a specific, single known workflow we had mapped out. 2. Additionally, no mention of a general use case in which to provide user context. Coincidentally, this is Phase One in User Centered Design Basics. 3. Absence of data.

So here I am, taking all this in. We took a break and our customer support team pulled me aside to talk about how I was going to prioritize changes in the current and next release.

“This is an important customer,” they said.

I simply replied- “We are not committing to changes yet.”

We sit down and I open up my bag of tricks to expose The Ephemeral User for what it is, without being combative to our guests, who were earnest in their efforts to make their customer happy (who coincidentally is the account manager and not the users).

Phase One: TALK SHOP

“Wow, you guys got some great user feedback. I know operational users are hard to pin down, so how did you get all this data?”

“Well, you know, we have easy access to the users because we sit at the customer site. It’s easy for us to swing by and check in with the entire team.”

“Awesome. Did you conduct surveys or sit with the user or what?”

“We sat with them and got real time feedback.”

They marginally passed Phase One.

Phase Two: DATA SHARING

“Great! Can you share the data with me? Is it somewhere online I can access? What format is it in? Just text reports, I’m assuming if they were drive by, real-time feedback sessions, right?”

Here’s where things begin to break down…

“Well, we don’t really have any data per se. This is just from the folks we talked to on site.”

Phase Three: BULLDOZE WITH METHODS AND DATA

“No worries. Which divisions are they in? Maybe I can follow up and share some of the insights we got from our most recent round of internal UX interviews and see if it jives with them.”

“Hmmmm, it was pretty much just people in the program office.” (a.k.a. not users)

“Oh, cool. Well since you’re here, let me show you what we’ve done.”

I had just conveniently completed a round internal testing with ~ 10 users in the Non-Technical, Non-Familiar user category, going through the eight basic tasks a user should be able to perform out of the box with virtually no assistance.

Then I shared all the data we collected. Since we were dealing with Non-Technical, Non-Familiar users, my focus was on how quickly can users orient themselves to a new interface and where do they “get stuck” along the process. I had my data points on what ACTUALLY confuses users and HOW they dealt with it. I additionally asked users to go back and complete random tasks they had completed earlier to see if it was intuitive the second or third time around.

The truth is, sometimes we need to give the users some credit for being able to quickly orient to something new and repeat it with no training. This was my response to the knee-jerk reaction making many cosmetic changes on the assumption of The Ephemeral User’s preferences at any given moment in time, without the added context of a user workflow. At the end of my presentation to Consultant One and Two, I asked — “Which of these are the most critical changes we need to make first to satisfy your users?”

“Maybe we jumped the gun. Let’s circle back after we do some more research.”

They never did.

What’s the lesson here? Just remember this. As product managers, we are in a constant tug of war on how to spend our team cycles. The Ephemeral User is just one of the many distractions that may pop up along the way, but a little bit of data goes a long in sending that specter back into the ether, freeing up time and energy to focus on what your users REALLY want.