I started this post the same way I do most others, with background research. I talked with current data product managers and asked them how they learned to do the job. I started with 8, and they all gave me a different story of their journey into the role.
I asked another 5 people and got another 5 origin stories that had some overlaps with the first sample. However, the overlapping elements didn’t make them good at their job. It was mainly what got them interested in the job.
Answering the question, “Where do you find Data Product Managers?” isn’t straightforward. This post defines the journey and the critical aspects of the role. In a previous post, I explain the job functions. This time, I’m going deeper into how people who do them get to that point.
The journey is typically self-directed and driven by a common motivation. We can find Data Product Managers at any stage in this progression. The biggest tell is when someone seeks out data product management training. They often self-identify.
Non-technical people will often start their journey by seeking out technical training. It’s worth working with people to clarify intent. They often abandon their learning journey when they realize they don’t want to be hands-on and build solutions. They want something else.
Technical and non-technical people often share a common driver.
A Sense Of Frustration
It’s a sense of frustration. Mine was familiar to everyone I spoke with. I began as an accidental product manager. The systems group didn’t have one, so I started doing the job because of the disconnect between what we built and what customers wanted. It’s a common theme when legacy companies try to develop innovative product lines.
No one feels it more than customers and people in customer-facing roles. In this case, I was leading the team and working with customers.
Field service technicians who worked for the company had difficulty installing the software and hardware. I worked with them to make it easier.
Regulators didn’t understand wide-area gaming systems, and I worked with them to get the system approved.
Customers had concerns about data gathering and security. I worked with them to deliver something they would buy.
At the end of the project, I realized that we should have done all this work upfront. There were better ways to manage a product and take it to market. I began learning about product management without understanding that’s what I was doing.
And A Loss Of Control
My journey into product management began in a meeting. It was time to release very 2 of the wide area gaming system. I had it all mapped out with a crude go-to-market strategy. I went into the kickoff meeting with the expectation that I would be running the project. No one wanted to listen to me. They were focused on this other person.
That person was non-technical. He hadn’t spent any time in the trenches with stakeholders. He didn’t have the customer and regulator relationships I did or any of the credibility. Yet, when he spoke, C-level leaders listened. When I spoke, they nodded and asked him more questions.
This was my next frustration. Why wasn’t I taking the lead for this project!? I realized I was missing something that day, and it launched my journey into product management and strategy.
Frustration creates many product managers. They feel like their work is outside their control. For technical people, it’s what I thought in the meeting. It can also come from fire-drill-driven development. Their work is constantly highjacked by new features and ad hoc requests that weren’t part of the original scope but should have been.
For non-technical people, it’s the experience of working with the products. They feel like developers and engineers control their world. Products get dropped in their laps. They were never consulted about how the product should work and why it was being built in the first place.