Photo by Alexis Chloe on Unsplash

How Empathy Changed My Product Management Process

I was an operations manager long before I transitioned to designing and building software products for internal operations. No other experience has taught me more about empathy in the workplace than consuming the technology prior to building the technology.

What did I learn from this perspective shift?

One product management process does not fit all. Building products for internal operations requires enhancements to the Product Management tool set. I like to think of it as Product Management+. As a result of this perspective shift, my approach to Product Management became more nuanced in a few different ways:

1. Your customers are your colleagues and they know where you sit

As a Product Manager for internal products, you will be inundated with solutions before you have the chance to comprehensively identify the problem. Signs that the problem articulated may not be the problem:

1. Few Whys are asked. If Whys are asked, be cautious of workflow specific, circuitous, or qualitative answers.
2. The solution is discussed as obvious and the only one that makes sense.
3. Data is missing. The operational team does not measure the metrics you need to baseline your key performance metrics.
4. A voice in the room is saying something that sounds like “It’s not that complicated.” It often is, at the very least, more nuanced, more dimensional, and likely impacts more teams or processes than the collective voice has identified.

Suggestion:

1. Listen to everyone.
2. Decide alone.
3. Come up with your own counterarguments.

You are the CEO of the product. You have unique access to information that no one else on the team has because of your connection to business strategy, Engineering organization, and user research.

Once you make a decision, it is your responsibility to gather buy-in from stakeholders, Engineering, and company executives. Decisions without buy-in are just wishes.

2. Your customers are your colleagues and you know where they sit

Building products for the operation means user research is at your fingertips. You have the opportunity to shadow your users, understand their workflows, bottlenecks, and downstream/upstream processes. You also share a common company lexical set.

Be cautious of this access to your customer. You may find yourself dependent on them for problem and solution identification. As a result,

1. The potential solution landscape narrows. Operational users are masters at workarounds and these workarounds are missed opportunities for improvement. Second, operational users are focused on the operation in front of them. Their solution may not be department, workflow, or software agnostic.
2. You assume knowledge of process and language because you both work in the same company. However, familiarity is not understanding. This assumption can lead to costly product and technical debt down the road.
3. Your loudest stakeholder steers the ship, either in UI design or feature prioritization.

Suggestion:

See previous suggestion. Also, meet separately with each of your stakeholders before bringing them together. If you notice discrepancies in understanding between the stakeholder and the end-user, host a transactional meeting for both parties to review standard operating procedures.

3. Inter-departmental politics will find their way into the product development process

Interpersonal dynamics are unavoidable, regardless of the product type. However, Product Managers working on internal software may walk into a history of potentially broken promises, underfunded projects, and a string of Nos. There may be little trust between the stakeholders, operational leaders, and Engineering. Some signs that you might be walking into a low-trust relationship:

1. Stakeholders will push for 80% of the features in the MVP. This is not their first rodeo. They have experience with unfinished, half-baked internal tools that breed inefficiency in their operations.
2. Engineers working on the product have never met the end-users or seen the operation.
3. Department-built macros and function-heavy Excel spreadsheets have replaced internal software tools.

Suggestion:

Trust is built over time, by keeping your word and demonstrating empathy. Be realistic about what you can deliver and transparent about the expectations, objectives, and limitations.

Oh, and get your engineers to shadow the operation for a few hours. We’re all one team. Exemplify this idea with your actions.

4. A/B testing is (mostly) inapplicable for operational PMs

I will sing the praises of A/B testing all the livelong day. But, when I wear my Operations Manager hat and a PM tells me that she wants to test two versions of a feature in a piece of software used by the operation, one thing comes to mind — “You have no idea what it is like to run this operation while meeting service level.”

Remember that often an entire operation or process is built around the tool you have released. Dividing the user group to test feature version A and feature version B will give you invaluable insight, but it will also impact that operation’s throughput, work in progress queue, upstream and downstream processes, and the employees’ work day.

Suggestion:

Your test plan should be mindful and specific to the operational context that the product will live in.

1. Pilot test with a small number of users.
2. Screen captures reveal UI concerns without disturbing the operation’s workflow.
3. Test during off-peak hours. Run load tests to prepare for peak capacity.

5. Operational product debt cripples growth

We are all familiar with technical debt. We know that we will need to pay back this debt at some point in the future. But there is another type of debt that shows itself in a company’s operations. Operational product debt is born out of an Agile environment where product development is iterative. Iterative product development is valuable and preferred, but it has limitations when you are working with internal products.

Signs you might have operational product debt to deal with:

1. Proprietary software has been frankensteined to the point where the proprietor of that software can no longer service the software.
2. The operation is using proprietary software version 4. That software is now on version 10. Version 4 is no longer supported.
3. Entire operations are built around a technology that was only meant to be used as a pilot test (read stopgap).

Similar to technical debt, you can only take on so much operational product debt. There will come a time (and that time often comes at a critical inflection point when the company needs to scale to compete) when the debt has to be paid.

Conclusion

Poor execution for external products limits a company’s ability to enter the market; poor execution for internal products limits a company’s ability to acquire the market. I’ve seen this happen in two ways:

1. You will not be able to scale effectively. Poor tools work fine when you are small. As you scale your operations, those poor tools will limit your growth and become top priority fixes, taking precious resources from building revenue-generating products and services.
2. Trust will erode within your team. Operations will no longer trust Engineering, resulting in reduced empathy across teams.

It is valuable to explore the differences in product development process flow for internal versus external products because getting it right impacts company revenue and growth. Those differences in process were highlighted for me when I came at the problem from a source of empathy for both sides.