Domain knowledge in Product Management

Esin Over
Esin Over
Aug 28, 2017 · 3 min read

One of the topics I have been wondering and reading about was on how important it is to have domain knowledge. The things I read mostly suggested product manager to keep working in the same domain. But my career development has been the opposite. I’d like to share my own thoughts based on my own experience. There is no right or wrong answer for this topic.

In the last 10 years of my experience, I have worked in telecommunications, media, loyalty, healthcare, finance (bank) and fintech. Every time I come across with an exciting role and a project, I had the question in my mind “Should I continue in the same domain to improve my domain knowledge or change and learn different domains as well?”.

I’d like to start with the most important thing I learned. Domain knowledge is important but if you don’t know how to solve a problem, how to approach conflicts, it does not really matter even if you have years of knowledge in the same domain. You need to focus on improving problem solving skills rather than domain itself.

If you know how to solve a problem and improve your soft skills as well as your approach to product development, domain knowledge would be something that you can learn quite quickly not easily(!). For example before I moved to finance, I never worked with compliance, information security, legal as I did not need that in the areas I worked in. However once I moved to finance, I realised how important it is to consider all these aspects when planning for the product. When I moved into my last role in fintech company, I was aware of these already and started planning ahead and questioning if necessary. So domain knowledge helps you to get up to speed and think of different risks/problems that might just be relevant to that domain.

On the other hand, working in different domains like media, telecommunications gave me the flexibility and the practices that worked to speed up the process and see the product in different perspective. For example I had to get sign off from legal, compliance and security when I was working at a bank and there were cases where the release was put on hold because of these sign offs not being made on time, which delayed the releases and sprints. However when I look back on the technology driven products I worked in telecommunication and media domains, I can clearly see that the risks and problems were handled before the development phase. So I started getting sign off in the design phase which reduced the development time/effort without blocking the release timelines. All your stakeholders were also aware what is going to be released in the next sprint. This not only helped me to plan my sprints ahead but also increased productivity of the team, gained trust from stakeholders.

On a different note coming from a totally different domain makes you question things from different perspective. Questioning in product management is quite valuable especially if you are touching end users. So take your time to enjoy that time till you get into the product and its domain if you are new to the domain.

I also think that it is a personal preference for taking product roles in different domains. I personally like trying different things, learning different domains, working in different products with different people. So I thoroughly enjoyed each domain I worked for. I have seen different aspects, met great people and learned how things work in different domains with pros/cons. Currently I am trying to blend my technology driven approach with the restrictions and variety finance has to offer.


Originally published at esinover.com on August 28, 2017.

)