Day 1 as a PM: Top 6 Questions to Ask

What questions would you ask when you start working on an evolving product?

About us: Andrew (AM) and Chandrika (CM) met during their MBA program at MIT Sloan and connected over their passion for product, growth and paying forward the help they got transitioning into product management. AM currently works as a Product Manager at Moveworks and CM works as a Product Manager at DocuSign.

What questions would you ask when you start working on an evolving product?

Being a PM for an evolving product is very different from a new one that hasn’t been built. It requires patience, perseverance and partnerships. Here are 3 things you can do to set yourself up for success before you start working on a project for a evolving product:

1. Educate yourself 📚- Spend time upfront educating yourself about the product - the users, segments, key user flows - and the right stakeholders

2. Get buy in into the problem statement and KPIs 🤝- Before you set out to drive a project, make sure that you have socialized your project, the problem statement and the measures of success with the right stakeholders

3. Manage expectations 💪 - On an evolving product, you’re typically going in as an agent of change. And change is often met with resistance. So the project is not so much about product or policy as it is about people

As new PMs on evolving products, what we have found most helpful is to quickly identify what’s broken so you can “fix it”. In order to get to what’s broken, here are the most important questions you can ask:

Q1. What problem are we solving for our users? - This will help you understand the larger mission of the organization and in that context, the value proposition of the product.

Q2. What do we know about our users? - This will help you understand who you are solving the problem (that you identified in the previous question) for and hence understand their context better. Basic information like demographics (Age, Gender, Education, Income group - more commonly used for consumer products;Industry, Company Size, Role- more commonly used for Enterprise products).

Q3. What are the key flows that users go through in the journey? - This will start the process of identifying what’s broken that we mentioned earlier. A fresh perspective is usually very helpful in identifying the gaps between what the product experience looks like today and what it should look like if you were a new user (belonging to the group defined in Q2) trying to solve a specific problem (defined in Q1).  

Q4. What are the different channels that we use to understand the voice of our customers? - This will help you understand the signals that you would need to be not just a product manager that is successful in a specific organization but a product manager who can help build and scale truly world class products.

Q5. Who are the various stakeholders involved in making this product successful? - As a new PM, a large part of your success is determined by and dependent on how well you can get various stakeholders to align, to get approvals and continued support for your projects and roadmap. This question will help you understand who these stakeholders are.

Q6. What are some quick wins that I can get to establish my credibility in the organization? - Now that you have identified what’s broken, who you would need to get support from to fix it, this question will help you understand how you would fix it. Putting together a brief plan to understand the level of effort, dependencies and impact would help you identify your first few projects and will establish you as a self-starter already.

If you found this valuable and want to support us, consider buying us a coffee!

---

If you’re interested in reading how we went about answering these questions in our first few days, read on.

Q1. What problem are we solving for our users?

CM: At DocuSign we’re saving our customers time and money while helping them save the environment. Legacy, paper-based agreement processes are manual, slow, expensive, and error-prone. We eliminate the paper, automate the process, and connect it to all the other systems that businesses are already using.

AM: At Moveworks we’re automatically resolving employee IT issues, which means we are improving productivity for employees and reducing service costs for IT Support, all while enhancing the IT support experience. 

Q2. What do we know about our users? 

CM: At DocuSign, we classify our eSignature customers into two broad categories - Enterprise & commercial and Web & mobile customers. The needs of both customer categories are different and the product is designed to serve their unique needs. 

Looking at industries, DocuSign offers special subscription plans for Real Estate customers. Beyond real estate, some of the dominant industries our customers come from include pharmaceutical, financial services, technology among others.

AM: At Moveworks, we classify our customers into medium, large, and enterprise accounts; however, we treat them equally since we are still a growing start-up and still understanding our user behaviors. Also, it takes the same amount of effort to deploy our product regardless of the company size - it’s just the nature of a machine learning product.

There are some behaviors of employees that we are interested in:

• On average, an employee files one IT issue per month

• Managers and executive assistants receive more notifications about IT ticket status updates than other employees

• Majority of enterprise employees are not active on chat but on email daily

• Employees find a self-service portal quite cumbersome to search for a specific form or troubleshooting article

These behaviors are both observed and measured within our product analytics. We also measure the traditional metrics, e.g. activation, resurrection, retention, DAU, MAU, etc Combining both types of metrics, we have unique metrics that help infer user behavior about our product. 

Q3. What are the key flows that users go through in the journey?

CM: In my first month as a PM, I spent 2-3 hours everyday in the product and documented key flows like the one below to understand the journey our users were going through:

AM: A user flow that demonstrates the value of Moveworks is the software request approval flow. In this situation, the flow looks like this

An employee who doesn’t even know about Moveworks would email a software request to a support alias → Moveworks would understand the request → acquire approval from the manager in the messaging platform → message the employee that they received access to the software. 

In the end, we would activate two new users in the employee base and resolve more issues in the future.

Q4. What are the different channels that we use to understand the voice of our customers?

CM: Keeping a check on the pulse of customers is a highly underrated skill as a PM. In my time as a PM, I have used a few different channels to understand the voice of customers. Most of these are commonly used at and would be applicable for general software companies:

• NPS survey and feedback

• CSAT (Customer Satisfaction) scores

• Feedback emails received

• Product research and studies

• Social media channels

• Comments from users during webinars

• Support cases received by customer success team

AM: At Moveworks, we have a playbook that engages various stakeholders of existing customers. In this approach, we ensure the following:

• Our product roadmap is aligned with the vision of the CIO

• Our current product capabilities are resolving the issues, usually handled by the IT Service Desk agents  

• Our product is creating a delightful experience for the employees for our customers

We execute this approach in a few ways. Our executives and account managers align on product vision. Our Customer Success team leverages our analytical dashboards to quantify our impact and hold ourselves accountable. They also work to increase the product capabilities over time by engaging in pilots. Finally, our UX team conducts user research to get a sense of the actual product experience for users. Collectively, we are able to get a steady stream of feedback for our product.  

Q5. Who are various stakeholders involved in making this product successful?

CM: Typically in an enterprise SaaS company, the product team needs to work very closely with sales & marketing and customer success, outside of the product development group. The day to day work involves close collaboration with the engineering (developers, QA) and design (UX, IX) teams. Data science and product research are some other teams that most tech companies have to support the PMs.

A pro tip I received from a mentor was to create a Power/Interest matrix for various stakeholders and decide the frequency of interactions like 1:1s, weekly reviews etc with each stakeholder/group based on that.

AM: At Moveworks, our Customer Success team strategically engages with our customers, highlighting areas in which our product can expand and resolve more IT issues. They have weekly meetings with ServiceDesk leads and ITSM admins who can reconfigure their environment to make it adaptable for machine learning. In addition, they engage with the CIO to ensure that our product aligns with their IT Service mandate. 

The Product Managers work closely with the Customer Success team to roll out new features, identify customers for product pilots, and expand existing feature capabilities. Collectively, we work together to ensure that all aforementioned stakeholders are successful and delighted with the Moveworks product. Our UX team even runs CSAT on employees to get a pulse for user satisfaction and report back to stakeholders. 

Q6. What are some quick wins that I can get to establish my credibility in the organization?

CM: My first project as a PM had very little to do with the product itself. Well, it kinda sorta did but it was a lot more about proving that I could get stuff done. The project was about getting a survey to show up on a specific page, at a specific point in the user journey. I had to essentially rally the troops - I had to find the right team that “owned” the page, get the project on their roadmap, make a case for why we needed to have it implemented soon and relentlessly follow up with the team till it was done. Months later I found out that this first project established my reputation in the firm as the person you needed on your project if you wanted to get things done. In my feedback reviews, folks I had been working with had mentioned things like “reliable”, “does not just hand-wave but actually gets work done”, “feels a high sense of ownership”. The key takeaway I want you to have is no matter how big or small your initial projects seem, do them well. This will set the tone for the rest of your time working with the team.

AM: When I started as a Product Manager intern, I had coffee chats with coworkers from various teams, from Marketing to Sales to DevOps to Machine Learning, with the guise of “I am an intern and would like to learn more about your role and experience.” Through these conversations, I asked many questions to identify their pain points within the organization and the product itself. The problems I had identified were categorized into two buckets:

• High-impact and complex issues - These tend to be product-related issues that require deeper analysis

• Simple, operational issues - These tend to be inefficient workflows for mundane tasks that few folks have time to address given the pace of the company

In my plan, I had focused on several operational tasks while creating a series of milestones to address the bigger problem. I had created a few small projects -  migrate graphs into Tableau for better visuals in the pre-sales deck, research a new analytics workflow to identify product gaps, and test a new chat platform integration. My actual intern project was to deliver a pilot product to a specific customer related to Sales and SFDC. 

Strategically, I had created these smaller projects for myself because:

• Engaging with pre-sales allowed me to understand our product positioning very well. 

• Engaging with the integration team allowed me to understand the underlying platform that powers our NLU platform

• Engaging with Analytics allowed me to understand how our data pipeline, e.g. ETL flows are structured. Also I gained access to our structured data to perform fast analysis. 

By tackling these smaller projects, I was able to get a full understanding of designing a conversational AI product, which needed to integrate into a new platform, SFDC. This helped me to deliver the pilot 7 weeks into my internship.