When your past role haunts you and sabotage your work.

If you are a product manager, then most likely it wasn’t your first role in the industry. You probably transitioned to this role from a different, non-product title, you held before.

I’ve seen people transitioning to product management from all kinds of roles – R&D, QA, account management, sales and more…

That means that when you start your first days as a product manager, you’re likely to carry some remnant of your previous role. This can sometimes get in your way as a product manager and may result in suboptimal decisions if you are not careful.

What do I mean?

How Your Past Role May Fail You

Let’s take the case when an R&D veteran decides to become a product manager. For me, that was the case. I’m a software engineer by profession and I spent more than a decade writing code and leading R&D teams.

When I made my first days as an official product manager (I did some ‘unofficial’ product duties as part of managing my startup), it was very natural for me to dive deeper into the conversations with the R&D as for how they are going to implement the features I asked them to work on. At first it made me feel good about myself, and I was happy to ‘show off’ my knowledge in terms of engineering. The engineers thought highly of me and I became more involved in the technical conversations.

However, as time went by, I soon realized that this is wrong.

I found out that the more I delved in the ‘how’ (how features are going to be implemented) I’m forced to also participate with how the engineering challenges need to be addressed and solved. As a result – I had to shift focus from the product decisions towards engineering decisions.

There are other downsides which I had to learn the hard way. I want to spare you the pain, so here is a short list of hazards you may run into if you are getting too much involved with the implementation details:

1. Bending the product requirements to cater to the current implementation and favor easier implementations to customers and users needs. For example – if you know that an asynchronous approach will be trickier to implement you may settle on a synchronous solution even though the customers clearly asked for an asynchronous solution.
2. Missing out important product abstractions because you start using the R&D jargon and you adopt the R&D POV of the system. For example – the R&D named an entity a ‘user’ when it’s actually better to be named and treated as a ‘client’ from the product’s perspective.
3. Focusing your energy where you shouldn’t, and that comes on the expense of actual product work. Focusing your energy also includes your thoughts and ‘offline processing’ time even when you are outside of the working hours, so this is not negligible. For example – when you cook the evening meal to your kids and the CPU in your head is focused on how we can improve the performance of the cache, rather than how the roadmap for the next 6 months should look (you may argue that your thoughts should focus on none of those at that time – and you’re probably right :-)).

And here is a concrete example:

In one of my first roles as a product manager in a B2B2C company, I was working on a feature that empowered our customers to have full control on how their branding will look & feel on their own product when their customers visit their site.

The developers reached out to me more than once and asked me questions in that spirit:

“So, you are practically asking to introduce a configuration parameter Logo_x, which is affected by Logo_width and Logo_height, and we must make sure that Logo_automation is ‘false’”.

At first I started looking into it and tried to understand all the various existing configuration parameters and their possible values. But then, I suddenly shaked my head and said ‘No. This is not right.’. The different values of various configuration parameters are implementation details. As a product manager I must look at this from a higher level of abstraction. I should focus on what configuration options should exist and what is the general level of granularity of each.

So next time the engineers reached out to me and asked me a similar question I told them:

“Guys, I don’t know what Logi_x is, and how it affects Logo_width and Logo_height (though I can make an intelligent guess). On the higher level – there should be a configuration field where the user can change to position their logo on their screen in one of four options: top-right, top-left, bottom-right and bottom-left. Whether you decide to implement this with 1 or 5 configuration parameters – this is your call, but from the user’s perspective – this is one configuration option.”

Another scenario was when one of the senior engineers came to me and asked me whether we should use S3 for the long term storage and Postgres for the ongoing operations or not. I told him that I’d be happy to sit with him and share my advice based on my experience from my R&D days, however, as a product authority – I don’t care. As long as the performance requirements are met and as long as the data is aggregated as I asked for supporting efficient and trivial queries – then I’m happy. As far as I’m concerned – the database can reside on the moon.

You can claim that such an approach may cause some frustration to your colleagues. Well… at first – maybe. But you need to manage it properly and explain to your colleagues the long term damage of being actively involved in the implementation details. From my experience – if properly communicated – they all get it, understand it and eventually respect it.

This phenomena doesn’t apply only to R&D veterans by the way. I once knew a product manager who was a technical account manager before. We had the opportunity to work together on a feature that involved both of our groups. I just started thinking about what this feature means when he came to me and said:

“Oh, this feature is easy. You just need to modify the value of this parameter to 60 and check the extension to see that it’s ‘.jpg’ and you are done.”

At first I was amazed, and to be honest, even a little envy of how well this guy was in the details of the implementation.

But long story short – it turned out to be wrong. All of it. A lot of modifications were needed. We had to introduce new configuration options. We had to make the API more flexible and we had to tweak the flow a bit. For sure this feature wasn’t ‘easy’. Now, generally speaking, it’s fine to assume that something is gonna be delivered fast and eventually it’s not. It happens all the time. The thing to focus here (the lesson) is how quickly the guy got ‘locked in’ on a certain implementation and lost sight because of that of the real product challenges around it. Being in the details of the implementation was just harmful.

The examples above were focused on being over-technical and too much in the implementation details. However, your past roles can haunt you on non-technical aspects as well.

For example – if you were a UX designer and became a product manager – there is a very good chance that you’ll put too much focus on the UX and UI and the user flows rather than how the backend should behave. I’ve seen this happening and it’s not great. Product specifications written with this state of mind turns out to have a lot of overlooked logic or missing representation for flows which have no UX at all (for instance – server-2-server communication flow).

If you came from marketing or sales you may focus on what ‘sells’ better rather than where is the true value for your users. You may actually overlook or neglect all the internal & external stakeholders who are not the customers of the company. So be careful here if that’s your background.

How to Avoid This Pitfall

At the end of the day – your background may be a double-edged sword. You need to learn to take the benefits of your past experience while understanding that you are now wearing a different hat. A hat which forces you to take the ‘big picture’ approach and properly identify who are the stakeholders and where is the value for each. You will need to get out of your comfort zone and become a ‘product-first’ guy. 

Yes, if you have a technical background – leverage it – but not by getting into the implementation details. But rather – for understanding where the R&D are trying to buls@#t you with effort estimations, for evaluating the value in a tech-debt task, when your intuition yells at you that this engineering project is not going to converge and so forth.

Yes, if you have a sales/marketing background – leverage it – but not by narrowing your vision on what sells, but rather on how to interleave features that can close the deal together with value-adding features into one coherent product.

Yes, if you have a UX/UI background – leverage it – but not by focusing too on the UX/UI aspects, but rather by making sure the user flows are efficient and intuitive and also by making sure that your product looks awesome in addition to the end value it delivers.

That sums up our post for today. If you found it beneficial – feel free to ‘like’ it. If you think someone else can benefit from it – feel free to share it.

Thank you and until next time!