The purpose of a Product Manager

Discovery is one of the key components of Product Management. ‘Discovery’ can mean a lot of different things to a lot of different PM’s in a lot of different settings. One of my most memorable ‘duh’ moments around discovery happened during an interview loop. Although I had been a PM for a few years in a different setting, things just ‘clicked’ during this interview process in a way that they hadn’t previously. I enjoy telling this story because the feeling of the ‘duh moment’ still excites me and it’s illustrative of what I believe is the purpose of a Product Manager.


The first few stages of the interview process had gone well with the Company, and the next stage entailed a take-home project: I was to propose an issue tracker for the purpose of ingesting and assigning questions from users of the Company’s platform to subject matter experts (SME’s) contracted by the Company. The Company wanted a solution that could be built by the growing Engineering team. My proposal was to include 1) a feature set for the MVP, 2) a few ‘fast follow’ features, and 3) a list of pros and cons for building my proposed solution.

I asked a few clarifying questions over email, got a bit more background on the problem to be solved… and promptly hit a wall. I recall sitting on the couch, computer in lap, feeling frustrated that I was stuck for reasons unknown. While I could understand academically what I was supposed to do, I was not making any real progress. Hours went by and, though I had a few days until the in-person presentation at the Company, I couldn’t shake the feeling that I was going to massively mess this all up somehow — then the ‘Duh Moment’ hit:

The Company operates in Industry XYZ — why in the world would they spend time building their own in-house issue tracker, a significant task and one that’s completely unrelated to their industry?

After the ‘Duh Moment’, my goal was clear: enable the Engineering team to focus on supporting the platform that customers already loved instead of chasing issue-tracker-rabbit-holes. I revisited the platform with new questions in mind: How did users connect with SME’s currently? Was there anything that could be optimized? What sorts of questions did users ask? How were these questions tracked internally? After reaching out to the Company with a few more clarifying questions, a picture started to form:

  • Users could complete their tasks without hearing back from SME’s 👍
  • Expectations around reply times were never set with users, but SME’s were under contract to respond in 7 days or less 😮
  • The number of users on the platform per day was over 400, while the average number of questions submitted by users per day was 2 🤔
  • Around 70% of the questions were ones SME’s could address, while 30% were unrelated to SME knowledge (e.g. technical support issues) 🎯
  • The Company had an existing subscription to Zendesk 💡

Though the overall incidence rate was low (0.5%), the volume of inquiries from users not relevant to SME knowledge (30%) was significant — that could cause noise for any workflow and would need to be addressed in my proposal.

My first priority was to re-think the UX around how questions were submitted and categorized. I audited Zendesk’s capabilities at the Company’s current subscription level. It turned out that many of the features available in Zendesk simply weren’t being used. From there, I put together an outline of how end users could 1) self-service the bulk of their questions, and 2) query an SME if an answer could not be found, or 3) submit an issue to the Company’s support team if their question was not relevant to SME knowledge.

I then honed in on implementation: a map of the current UX and the best ways to minimize risk around any UI changes through user testing, along with a proactive deep-dive into historical question/answer combinations. Finally, to track performance over time, I suggested a few KPI’s to start with such as overall incidence rate, time elapsed from asked-to-answered, and type-specific metrics.


As I put the finishing touches on my proposal, the thought did occur to me that I was explicitly not doing what the company asked of me. This felt odd, especially in the context of an interview project where my approach to these types of asks would be judged. It felt strange to ignore the specific instructions, but I did believe that my solution was a better answer to the problem at hand.

Fast-forward to the in-person interview: I gave my presentation, got great feedback, and had a job offer in my inbox a few hours later. It wasn’t until after I received the job offer that the lesson from my ‘Duh Moment’ became clear to me:

As a Product Manager, your job isn’t to build what you’re told to build: your job is to build what should be built.