guest blogger product management

Work with the Product Facts

Guest Post by: Chirag Madnani (Mentee, Session 10, The Product Mentor) [Paired with Mentor, Shobhit Chugh]

I applied to The Product Mentor program to become a more well-rounded product manager. That can mean a lot of things: the primary goals I set for myself were (1) use data better and more frequently to make decisions, (2) better understand & improve the relationship between UX/Design and Product in my organization, and (3) to launch my own side project but with the mindset of launching fast, learning, and improving quickly. One by-product goal that I internally set for myself was to improve at stakeholder management and these 3 goals help me towards that.  

Turns out, so far, each of my goals has encountered certain challenges that aren’t unique to my organization: reluctance to procedural change, organizational red tape, other competing priorities, etc. None of these should have been breaking news to me as many product managers navigate through each of these on a day-to-day basis. Often times, stakeholder management includes the understanding and management of roadblocks like these. As a PM who is the “CEO of the product” and the “voice of the user”, my job is to anticipate needs from stakeholders, communicate effectively, and play a major part in providing viable solutions. I purposefully chose the goals that I did because they not only help me improve as a product manager, but also will improve the way in which our product team views our process. I believe that I could use data more effectively and that there are points of improvement between UX/Design and Product. With regards to my own project, I aim to approach its launch with a user-centric mind set that will only accelerate my own product management skill set.

One common theme that I try to keep with all my projects and my goals is to work with the facts. The facts are where a PM will make their mark and can be used as PMs put their stakes in the ground at different times. By facts, I mean quantitative data, qualitative data, paper trail of conversations, historical examples, etc. Using facts, can help drive stronger assumptions and more confidence can be put into decisions and how they’re made.

In my view, the most important time to have facts handy and at the helm, are when these roadblocks come into play. Whether they be at your level or at a level higher up, for one reason or another, can derail progress. In my case, our development team is fully separated from the Product team and has different goals for their year. Of course, both teams work together to deliver but the product managers that make a better case with their set of facts get prioritized higher. Many times, the product that I’m responsible for is the one that takes the backseat and I often came to the table without being prepared to showcase why my product needs to become a higher priority. Over the course of this program, I started to dig more into analytics, create a framework, and have this information handy at each sprint planning or backlog refinement session. When “having meat to the bone” in terms of why I’d like to enhance my product was there, I started to get more consideration when allocating development resources. The timing was also perfect because from a C-Suite level, the product I’m working on has higher visibility this fiscal year, and we’ve also implemented more analytics tools, where I can have strong data to drive some decisions I’m making. In the past, if I came with a feature request/enhancement and other PMs/Senior Directors would want my deductive reasoning as to what validation I have…often times, I wouldn’t have strong tangible answers. At first, my product was deemed “important” by Senior Leadership and that helped me get to an end result without needing to stay on top of the analytics. But after that initial “success”, I derailed from being more data-driven and relied less on facts. However, when I started to really dig into the analytics, use new tools we have, created a framework, I started to have more credibility in the room and eventually my product became a higher priority. Undergoing this exercise helped me obtain more confidence that I plan on using moving forward.

Facts are useful to drive decisions both for external purposes (e.g., deliver higher quality products for users) and internal purposes. One internal purpose that I used more facts for were to accomplish another goal of mine during TPM; to understand and improve the process between Product and UX/Design. In my 1.5 years in my current organization, the process between the  Product and UX/Design teams has improved, but I feel there is more room for improvement. Requests would be made, designers would create, important people would give feedback/approve, product managers would input in JIRA tickets, and Devs, Designers, and Product would just comment back and forth on tickets. No official tracking of asset requests, design requests, feedback loops, prioritization of requests would be happening.

Roughly 6 months ago, the UX/Design team started working in their own “Design Sprints”, where they have their own backlog, sprint planning sessions, and have more of a “process” where Product inputs requests in their backlog. In theory, this process would work great. However, in practice, it’s still proving to be challenging (even though there has been improvement). Now that this new process has been around for about 6 months, I wanted to work on improving it. Again, similar roadblocks arose, and working towards this goal has taken longer then expected. However, as the right time to work towards this goal approaches fast, I’ll work towards obtaining the facts I need to validate why and how the process can be improved further. I’d love to show how, overall, these improvements will benefit both teams.

All in all, the lessons I’ve learned all revolve around having the facts ready, even when you don’t need them. Whether on an organizational level or when aiming to accomplish something on a personal level, this mindset will help me better accomplish my goals.


About Chirag Madnani


Chirag Madnani is a product manager within the music industry for the last 2 years and is passionate about music in his daily life. Chirag is attended the University of Florida and has been living in New York City for 9 years.




More About The Product Mentor

TPM-Short3-Logo4The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

  • Conducting regular 1-on-1 mentor-mentee chats
  • Sharing experiences with the larger Product community
  • Participating in live-streamed product management lessons and Q&A
  • Mentors and Mentees sharing their product management knowledge with the broader community

Sign up to be a Mentor today & join an elite group of product management leaders!

Check out the Mentors & Enjoy!

Jeremy Horn
The Product Guy

%d bloggers like this: