Internal Users Deserve Empathy Too

Brainstorm ideas. I am talking ALL ideas — the dumber the better. No idea is too small or too wild in brainstorming. You never know what best idea will come out of the ramblings of silly or terrible ideas. If someone cares enough to offer an idea, I can care enough to entertain it.

New Feature, who dis?

Well, they’ve done it again. An engineer had a great idea for a new feature and executed it without consulting anyone — not product, not leadership, not the UX team. He saw a need, and our company has empowered its engineers to show their grit with tenacity and confidence. He built a configuration tool that consolidates four separate internal tools. Great to get rid disparate tools and move the functionality into an existing application, but … the workflow was rough.

There were two responses from the demo attendees:

1. How dare he! Product needs to be involved in these rogue features because he is missing valuable steps in the design process! (which made me think of this LinkedIn post by Jared Spool re: “seat at the table”)
2. OR … Give him a bonus and a raise! He saw a problem, and he solved it! What initiative! And he didn’t need that bureaucratic Product nonsense!

I was in neither group. I asked if the engineer wanted a suggestion. He did. So I typed out:

I see there is no visible difference in the UI when a user adds a new configuration vs edits an existing configuration. When a user uses this tool, there are two different tasks s/he cares about:

User [story] number one:
“I want to edit an existing thing to fix something either broken, or sub-optimal, or experiment with getting a better result.”
Therefore: The entity already exists. User makes edits across all four tabs like you showed.

User [story] number two:
“I want to create a new entity, so I need to set the new name and its requirements.”
Therefore: Entity does not already exist.

How can we visualize they are adding a new entity with the gravitas of “You are creating a new entity | This is a big deal — make sure you know what you’re doing …”

What about a “create new” button beneath the entity search (like how [this other tool] works)?

That makes it VERY clear that “you are in new territory now, User!”

More questions:

What happens if the entity is a duplicate?

Are there required fields, or do we have default options if a user skips one?

The software engineer didn’t think about the new entity setup when he was throwing together a new UI real quick. And that’s not his job to think of those things! That’s why we exist in Product Management. We think about these things ahead of committing ideas to code. That’s why we exist.

Instead of ripping his head off about “why didn’t you involve me,” I chose to offer my value and expertise. Maybe next time he will want to brainstorm his ideas with me, and we can save some development rework time. No ego; I just want to help by any methods necessary to improve an internal user’s experience.

A Painful Pivot

This week, I had to make the call to abandon a new feature because I am not seeing desired results. We have been working on an algorithm that compares and ranks good results from bad results.

After almost two years of iterating and testing, I ran a sample size of 1335 data points and plotted where they were ranked compared to being a good or bad result. The results still show no sort of pattern. Due to the risk to negatively impact my application’s data, I presented my findings to engineering leadership and made the recommendation to either stop the project or commit new/more resources to the feature.

How did we determine whether the result was good or bad? It took a time commitment of 12 FTE hours to open each and every one of the 1335 data points. That was the most accurate way to determine success. Were the hours of click and check worth it? Yes. Was it worth it for a data-driven decision? Yes, and I’d do it again.

Customer Feature Request

I joined a client call alongside one of the engineering managers from another team. The client offered us six feature ideas to change the way the product works today. Their priority feature is to request additional quality control for 50 out of about a thousand data points they have with us. They offered us this question, “If we pay you extra for just those 50, could you provide guaranteed delivery for just those 50 data points?”

The problem statement: There are n variables that contribute to consistent quality. Customers accept our current margins of error are due to providing our current scope of work at scale. How can we demonstrate guaranteed consistency by limiting the scope to a smaller subset of data?

There are two parts to designing this new feature: 1) what are our success criteria to achieve “guaranteed consistency”? How would we define that internally? 2) Could we package it as an additionally priced feature? The stricter definitions for success will certainly require additional effort. I will need an estimate of the cost to perform the work before I can price what we could charge for this work.

My design decision? Write up a one-page product brief. Engineering said they want to keep the brainstorming conversations between themselves at first because they wanted to determine the level of effort without Product’s “processes slowing them down.” It cannot hurt to give them a starting point to define what we consider “guaranteed consistency.” I need it whipped up before the engineering team meets on Monday to scope potential requirements. They invited me to the Monday meeting — so I’m taking that as a compliment.