Having been a software developer for the first 7 years of my career, the natural approach to work was to receive a task (a new feature, bug or performance issue) and asking “How do I make this happen?”. And, honestly, how was the fun part. It was applying all the algorithms and best practices I had learned throughout getting my Bachelor’s and Master’s in Computer Science, mixing it with the capabilities of the servers I had access to, and making something new that helped solve a problem.
However, as I grew more senior in my profession, had more exposure to the business problems at hand, and began interacting with the people that had to use my solutions, that approach evolved. Sure, I had made applications that were usable, but not always very intuitive. As I grew into a Developer/Quasi-Product Manager role, I did start interacting with a handful of key contacts with our customers, and the seed of thoughts around “What is the user trying to accomplish?” had been planted.
I then attempted a transition into Project Management for the next step of my career. I quickly transitioned from coding with occasional customer interaction to a role that was fully customer-facing. It was a bit of a shock to the system for a natural introvert like myself, but even more of a shock was no longer having accountability for the answers. Focused on software implementations, life as a project manager was about “How do we get new customers using our system?”. And when customers asked for functionality that our application didn’t have, my job wasn’t about addressing that, but figuring out “How can we work around that problem for now?”.
Admittedly, it was difficult, mostly because my job was more about solving our company’s problems than it was about solving our customer’s problems. That “What?” seed had been planted and continued to grow, and it was anguish to not have any control over addressing those problems. I knew that I needed to get back to Product Management.
Now back in a Product Management role, I’m back to that “What?”-first mindset, and continually refining it to identify the many levels of “What?” within our customers organization:
- What are users trying to accomplish?
- What do users need to do their jobs more effectively?
- What does management need from our software to see the big picture?
- What are the key values that purchasers see in our software?
- What can we do to improve the ROI for our customers?
After we can paint a clear picture of what our customers need, only then can we effectively begin asking “How do we help our customers?”, start putting those plans into action, and then completing UX testing to make sure we haven’t missed the mark.
And it’s not just a one-time exploration. We must continually repeat this process as our markets change, customers evolve, roles change, and new needs and capabilities arise. But even in that iteration, the order remains the same: We must first understand what our customers problems are before we can provide effective answers on how to address them.