The Master Product Manager - Part 3
The Technical Product Manager Part 2
When were talking in the last article about the technical product manager, it sparked a story that happened to me few years back. I was at my early stages in product management in Egypt where I just started my role for washing machines line up coming out of Egypt Factory. I had a great manager at that time who taught me lots of new concepts on how to navigate the landmines of technical product managers. The idea was for me to really understand the RACI matrix in our company product development and what I was actually responsible and accountable for. The main obstacle that faced me at that time was the possibility to enforce that RACI Matrix and hold people accountable which was a bit tricky especially if you are a new joiner in the organization and don’t want to have many grudges from people around you.
Yet I tried to handle this smartly, so I use one of the kick off projects that we had as an opportunity to do this saying that I am new and I was fascinated by the way the RACI was arranged and asked the project manager to use it as main deliverable document during the regular weekly meeting “OfCourse I had to owe the guy one for backing me up". The Moral of the story is that even though that as a technical product manager, you may own the roadmap that doesn’t mean that you can let people responsible to delivery specific tasks push it to you or make you take the fall. RACI is one of your best friends especially in the product development technical space where things can get little bit tricky.
3. Owner of the Development Planning:
Here it gets a little bit more fun, because as a technical product manager, you have a responsibility to ensure that the right priorities are on track and that these priorities are aligned with the latest company direction and strategies. But in reality, what does that mean in terms of actions
1. Initiatives Requirements
As a technical product manager, you need to ensure that each initiative has a clear scope and requirements right from the start especially if you are working in the physical goods space such as the home appliances industry. In reality you need to collect the requirements from the commercial and innovation product manager and these requirements include but not limited to:
Target Markets where these initiates will be launched.
The Commercial Launch Window for each of these markets
The Innovation Readiness of the modules to be integrated.
The Financial pre-study done on these initiatives.
Now this can get bit tricky as you don’t own this study, the commercial product manager does.
But you have the right to hold the activities until you get the preliminary study as it may not make perfect sense financially, then it becomes more of a strategic decision of specific needs.
One aspect can be penetrating a market to pave the way for bigger launch.
Another aspect can be for bigger portfolio of products where the overall business case makes more sense.
The estimated demand plan for such initiative on yearly basis and with seasonality.
This becomes more critical especially if your factory is approaching saturation with the number of shifts it is handling and you may need to order an extra shift.
Another aspect is if there is specific component shortage that you need to handle across new and running initiatives so you may need to choose which is more priority.
Additional aspect is if the demand plan doesn’t really match the actual financial study, is a point where you will usually have to tackle it with sales teams. Educating the sales teams that using two different numbers is not OK. Demand planning have +/- tolerance level but that level should be within 10-15% and in extreme cases 20% to ensure you don’t have high extra inventory and affect the net operating working capital.
4. Center of Collaboration with Technical team:
If you have never worked with engineers and technical teams you will understand what I am about to say. Engineers and Technical teams are pretty much straight forward which means that as much clear as you are with them, as much great output you will get. Technical product manager will work with every technical function inside the organization and in SaaS it may appear to be mainly developers from both front and back end but in other industries the situation is a bit different. If I would tackle a company where you are building physical goods, here are the technical functions: -
1. Research and Development (R&D) Team.
R&D teams are the closest you will have as an ally in product innovation as a technical product manager. They are your close companions where you get majority of the support, and they are the main function of the product innovation team that supports you on the technical feasibility studies and where project managers usually come from for new product initiatives.
How to Work With R&D:
Involve Them Early and Continuously: Ensure that R&D team is involved from the conceptualization stage. Continually update them on market requirements and feedback. This part is very critical as I find lots of product managers not giving continuous update to the technical R&D team on market conditions. You need to understand that they are part of the innovation team, and their insights and cooperation is critical for your success. Sometime what you thought was an impossible task can have a simple work around from your R&D team. From a personal experience, I avoided lots of hassle unnecessary work thanks to the contribution of my R&D team.
Speak Their Language: Use technical jargon where appropriate. Understand their constraints and capabilities to set realistic product features and timelines. You need to ensure that when you are asking the R&D team for a study that you understand what their expectation from your request is and what is your expectation and ensure that both of them align. The last time one of our team members asked R&D for a feasibility study, what he wanted was high level estimation with 80% accuracy but he never said that and if we didn’t ask clearly the team what they perceived to be the request, we would have ended with 2 weeks’ worth of work for 2 full resources when what we needed in reality was 1 resource for 1 day.
Regular Sync-ups: Schedule weekly or bi-weekly meetings to monitor progress, adjust priorities, and resolve blockers. A Plan is as good as all its components working together in Sync. What makes a symphony a success is the synchronization between the different instruments in a seamless flow. Imagine if just one instrument went out of sync, you will hear noise. The same case is with your R&D team, if you are not in Sync with them you will get outputs that has no relevance and no meaning to what you are trying to achieve because either things are changing fast that they are not able to keep up or you are not updating them or keeping them in the loop for some political nonsense or hidden agenda or because simply you are lazy enough to forget something like this.
Top Things to Do with R&D:
Resource Allocation: Assist the R&D team in the allocation of resources and prioritizing projects that align closely with business objectives. This is very critical because as you might have heard when you first joined the product management track that you don’t have infinite resources and if you don’t use them wisely you will not just waste them, but you will miss on great opportunities as well to generate something meaningful for the consumers and for the company.
Technical Review: Participate in technical reviews to understand the feasibility of different approaches and to offer the business perspective. As Technical Product Manager you need to act as the steering wheel of the R&D team as you have the highest technical background in the product management team and the same time you understand the context of the business that allows you to take calculated risks decisions for which direction should your team proceed towards.
Prototyping: Facilitate quick prototyping sessions for high-risk or novel aspects of the product. At the end of the day, for physical goods industry specially when imagination is quite difficult or some business stakeholders, so you need to generate the guideline for what kind of prototype is needed and what is the context. Prototyping is one of the most expensive activities when you are generating something physical specially, so care has to be taken not to waste time, money and resources.
Top Things Not to Do:
Micromanagement: Avoid getting too deep into the technical weeds unless necessary, to avoid hampering productivity. From my experience coming from technical background, technical teams hate it when someone non-technical start telling them what to do. They even hate it more when you are trying to micromanage them and recommend technical solution because you saw something at the competition, and you believe you have understood it all. DON’T DO THIS. Try and be sensible in the requirements you are giving in terms of what you want to see as an outcome and the guidelines the team needs to work around and then leave the team to figure it out. Given them the space they need to operate.
Changing Goals Abruptly: Avoid sudden shifts in product requirements without sufficient notice and reasoned justification. When I was working in the technical R&D team, I always hated product managers when they suddenly change the requirement without even having the courtesy of saying why or what the driver is. One time they changed the requirements 3 times in less than 1 week. The R&D team is your backbone as a product manager, and they will provide you with the support if you are 100% clear with them. Market conditions can change, and situations can be updated. BUT, if you are constantly changing requirements or changing it at a critical phase, you need to have the proper process and clarity of WHY and what is your updated expected outcome. One famous story that every product manager knows is that when you NEVER EVER send requirements or request for technical team evaluation without first having alignment on what you will send and have them clarify to you what they have clearly understood from you as an expectation. The main reason here is that when you send a request or a change in the requirements, the other team will probably do a detailed study analysis when sometimes, you need a high-level rough estimation. This will help you avoid wasting resources.
Ignoring Technical Debt: Don’t push for features at the expense of accumulating technical debt. Product managers sometimes act as children in Candyland or as a Foodie in kitchen with the best 100 Michelin chefs, they want to try many things and everything. You have limited resources, never forget this. You can send a request for new feature or update or a request in 1 day, but it may take the R&D team 1 week just to break it down. You must have priorities and you must align your priorities with few things as:
Impact in the market from financial point of view
Consumer pain points importance
Resources that need to be utilized
Product roadmap alignment
And without that alignment, the team won’t have the right direction to guide them in their work.
……to be continued
In our next article we will discuss about the interaction of technical product managers with more departments Stay Tuned.