How Human Centered Design made me a better product manager

The joy of developing a commodity trading and risk management system (CTRM) is that every damn number has to tie out to the nano-penny. There are hundreds of thousands of numbers throughout the CTRM from prices, trade values, quantities, quality measurements, invoice amounts, payment amounts, credit exposures...I could go on for awhile. Amazingly, if there is an incorrect number in your system, it will be found. I am religious in our automated testing that we check and then check the check that checked every number generated by the system.

So you can imagine my excitement when a friend of mine told me I should focus on Human Centered Design. In my head, I was like...no, I should continue focusing on Quantitative Centered Design. She told me that I should focus not only on needs but also on context, emotions and behaviors. Clearly, she had never seen the emotions and behaviors in the context of a trading floor when a number is wrong! I am not developing a bath soap. Nobody freaks out if the bath bomb weighs 3.8 oz. vs. the 4 oz. advertised on the package.

I love learning new things and I had seen the term Human Centered Design in my Medium feed a couple of times. It seemed like it was trending and worth investigating further.

We were implementing our NGL module at a client site for the first time. It was a transactional masterpiece: if you wanted numbers, it would produce PERFECT numbers. In order to capture those numbers....it took a bit of practice but after 10,000 reps you would be flying.

In other words, while I thought I knew what customers wanted based on years of implementation experience, I unfortunately had always been focused on the transactional results. My job had been to generate perfect numbers while minimizing the effort required by the user to complete a task.

You would think this would be enough to make users fall in love with your product like with their iPhones.

Understanding people’s behaviors, thoughts and emotions

This missing element is empathy. Its the ability to watch someone use your software in the context of their job and admit "Yup, that would drive me crazy too.". Sometimes we don't have the entire context of what a particular user is going through on a daily basis. The process might work great for handling 1,000,000 transactions but overly complicated for managing 10 transactions.

Then there is the notion of emphatic accuracy. How accurately one person can infer the thoughts and feelings of another person. How well am I able to connect with how the person is feeling? Are they mildly irritated but I am perceiving that they are thinking: Where the hell is the Taze button on this Zoom app!

Empathic accuracy is the hardest for me. I have had to learn that some people have meltdowns over everything and others are ok with anything even though the process changes are burying them under a mountain of work. Personally, I need to back empathetic accuracy with quantifiable measurements. How many transactions do you have to enter manually? What is the value of the transactions? How long does it take you to execute the process? If the quantitative and emotional accuracy add up then I am going to sit down and think really hard.

To make good design decisions, we must first create possibilities to choose from.

This is a tough one. Most of the systems we design today handle complex calculations and transactions. Trying to create multiple possibilities to choose from when just creating one is an effort seems non-feasible. However, I have never once created a program from a spec that did not go through massive revisions once it went to production. I have become an Visual Studio, Axure (not Azure), PowerPoint and Excel expert in creating interactive mockups to try and give customers a sense of what would be delivered before actual delivery.

Great design comes from a desire to create real outcomes.

I once spent a year developing a power trading data warehouse. It became the largest database in my company. It had EVERYTHING. Well it was missing one thing. An actual purpose. I was so excited to be part of the project that I assumed the business stakeholders knew what they were going to do with it. They didn't. We all started with the idea that if we collected enough data that ideas on how to use the data would come to us. They didn't. Eventually the business stakeholders moved onto other jobs and companies and I was left supporting a big stack of sh....data.

Start with the questions that determines when the solution is a success. Otherwise it is just a long road to nowhere. No matter how cool, the project seems...start with the hard questions. Why are we doing this? Who will own it? What will it be used for? How will it be used? Who will use it?

Otherwise, you will either finish your product and it will sit on the shelf and die. Or the project will keeping going hoping that someone will find a reason for its existence.

Figure out how you will measure and monitor success.

Great Design is Iterative

A coworker once told me that it takes 6 months to settle a program into production. She was dead set on the month. 6. I scoffed at her. My stuff was close to perfect. 3 weeks. Tops! Over the next 12 years, I realized how right she was. It always seems to take 6 months after you introduce a big change for it to get settled into production where it is not at the top of the weekly Things our customers hate list.

I have learned to accept this. You put something big into production and first they smell it. Then they touch it with their toes. Then they pick it up. And then hell breaks loose. You have to fix it and break it, and break it and fix it. You make dramatic pivots and eliminate huge sections of code that you slaved on for many nights and weekends. Then all of a sudden: Silence. Your production/solution is now a part of their everyday processes and someone would have to rip your product out of their cold dead hands. But for 6 months, life is hell.

My perspective is that your job is to build the product. The users job is to make sure the product improves their business. You can't build a perfect product without intimate knowledge of every customer's process. This is impossible. You will get 80% of it right. The last 20% is blood, sweat and iteration.

If things didn't iterate then we would all still be a bunch of single-celled organisms.