A Supply Chain Product Manager – is it the same as a regular Product Manager
“Are you a front end Product Manager or a backend Product Manager, read on to find out where you fall..”
One thing I have noticed across the product management blogging world is that most of these blogs are centred around products which are directly customer facing. Most blogs discuss on product management from a perspective of engaging your user. Or keeping them hooked on to your product. User engagement is a theme amongst most product management blogs. But, for a Supply chain product manager (read backend PM), user engagement is merely one of the objectives. It is surely not the most important objective that we have. Also, there are many differences in the way a PM functions while working on a product linking the SCM with technology vis a vis the conventional product manager who is interested in getting customers to use his product more and more. I believe, anyone who is working as a PM on the backend needs to remember the following points. Also, they must ensure they are different from a conventional PM along these lines:
Importance of user experience vis a vis importance of functionality
A supply chain product manager has to always be more bothered about the functionality that his product delivers. For a customer facing website product manager, the problem is more about getting the user successfully through his screen onto the next screen. A customer, if his functionality is not being met will drop out and this is immediately noticed in the funnel drop analysis.
But for a functionality based SCM product, the user will find a way around and still get this work done. Many a time, it will seem as if the process is happening perfectly and that no process improvements are needed. So, though functionality is important for a customer facing Product Manager, it is something that usually the SCM Product Managers builds and merely adds as one more service for a customer by the front end Product Manager.
Long term vis a vis Short term results
SCM Product managers more often than not get significant metric changes or improvements over a longer range of time. A change that we make today may expose to the customer at a much later time. Sometimes it will not involve any customer exposure and it will be more about the acceptance by the operations team.
One instance where I found this particularly important was during run-sheet scheduling automation. A run-sheet essentially is completely an operational process and hence any change in the process directly impacts every day operation. The acceptance to the change was initially very low, and hence if they check the metrics on Day 1 after deployment, everyone would have felt that the change had no impact. But, over time, with multiple demos, the users gradually started using it more and more, which eventually led to a higher acceptance. This eventually meant better metrics.
A/B testing does not always work
Unlike the front end, wherein A/B testing is easily measurable, on the supply chain it is not so easy to do A/B testing. Because asking the operations, to change their operations for a short period of time so that we can test out the efficiency doesn’t really work. An operational process change is something that requires months of planning and asking them to change something only to change it back to the previous status quo kills their trust in the technology team. Already, most operations staff feel that they hardly get any appreciation for their positive contributions. Thus, the minute they get an opportunity to criticise, prepare yourself, they will.
Your team is not just the engineering and UX team
When working in the front end, most inputs for the ideation is got from product managers themselves. But on the supply chain, most raw inputs are got from the operations managers. They do not really have a huge knowledge of tech. They form one of the biggest parts of your team. If you do not develop something that they require, then what you develop. May be the best product intervention ever. It will not be used in your organisation.
Hence, a product manager working in the supply chain must have the soft skills. It is required to understand every stakeholder and take them along.
What you build today you will use it after 3 months
Here is a very common observation. You build something new and get the business to setup processes around it. The business itself for it is very slow. Marketing would not even be aware of your initiative initially. Finally, someone from the front end will take it up and highlight it to customers. It will lead to higher business flow and suddenly everyone will forget the backend brain behind it. Remember, as a product manager, you will hardly get any appreciation. Even if there are product managers who do get any appreciation, the front end guys are the ones getting it.
Suppose you subscribe to these views, and user engagement alone does not appeal to you as the beginning. And end of your product management world. Then welcome to the world of supply chain product management. You may just be cut out for it.
Supply Chain Product Management Blog by Eashwar Rajan, Product Manager at Coviam Technologies, currently working in Jakarta for Blibli.com
You can read more at engineering.coviam.com
Here’s an article on React 16 Features
Blog Cover Photo by Fancycrave on Unsplash
