In layman terms, describe your day to day activities as a Product Manager.

Here's a framework for addressing this behavioral interview question.

Since I work on multiple products and work with different stakeholders located in different time zone, the day spent differs, to cover how my day look like I will categorize things I do under Product Strategy, Product Execution and Product Leadership during pre-product building phase, Product building phase and post product building phase. The activities also depends on which day of the iteration/sprint we are in.

 

Pre-Product Building Phase:

 

Product Strategy:

• Meet (F2F or virtually) Stakeholders/Customer to understand the pain points on high level.
• Talk to different stakeholders/customers involved and also facing the same or similar pain points.
• Check for the availability of stakeholders/customers/dev team(atleast architects) to conduct customer journey or design thinking workshop to identify the problem statement.
• Plan for customer Journey mapping or Design Thinking workshop.
• Speak to IT Managers for available resources (people/infrastructure.. etc)

Product Execution:

• Monitor the product metrics (Product acquisition, Activation, Engagement Metrics) and Plan for the backlog items if any of the metrics is going down.
• Execute Design thinking or Customer Journey workshop (Workshop includes Stakeholders/Customers, Dev team, UX and Product Manager(s), Business Owner)
• Define the problem statement which needs to be solved (Problem will be defined in workshop) & have shared understanding of the problem.
• Prioritize pain points if there are multiple paint points to be addressed. Prioritization will be based on Business Impact Vs Technical Complexity.
• Brainstorm the solution(s) and do a quick whiteboard session or paper prototype (Rapid Prototyping)

Product Leadership:

• Negotiate with stakeholders on prioritized items and timeline.
• Negotiate and work with Management to get all the required resources.

 

Product Building Phase:

 

Product Strategy:

• Collaborate with UX designer to come up with Mockups for the solution defined.
• Create Product Backlog/Roadmap (User stories or PRD).
• Prioritize the Backlog items and groom it for the sprint/iterations.

 

Product Execution:

• Collaborate with dev team to and plan for the sprint/iteration.
• Walk them through the prioritized backlog for the iteration & estimate the work which can be accommodated for the sprint.
• Clarify the queries (if any) about the backlog to be on the same page & Keep getting the updates via daily standup meetings to understand about the progress.
• Work with dev team and other dept/team to clear the impediments which dev team encounters to keep the development smooth.

 

Product Leadership:

• Working with different dept and negotiate to get the required resources for dev team to keep the development smooth.
• Discuss and demo the developed product to customers/Stakeholders and gather feedback from them which may get prioritized in coming iterations.
• Keep motivating the dev team (by telling them the stories about their work is impacting the business).

 Post Product Building Phase:

Product Strategy:

• Prepare plan of how to promote the product developed or built.
• Plan for Road shows, Demos, Writing blogs about the product, Create newsletter.

Product Execution:

• Work on demoing the product to different departments across the company.
• Publish blogs in internal company portal and publish Newsletter article about the product.
• Publish the details about the products to different teams/dept via different channels like email(s), Mattermost (Similar to slack in our company).

 

Product Leadership:

• Negotiating with management to get a slot with executive(s) meetings to demo or showcase the product.

 

As the question talks about explaning the activities of a Product Manager to someone(a family member) who doesn't understand technology, I would explain the parallel using the example of Building Construction Contractor. So here is how it will go:

My work is similar to that of a Building Contractor except that I do not pay the bills of all the people who work with me. Just like a building contractor who builds houses based on people's asks or builds houses on the feeling that people might want to buy them and live in them, I design software products for the online crowd. My work can be segregated into 4 major stages:

Stage 1 - Research & Planning

In this stage, just like a building contractor I try to foresee what people might be looking for and try to capture that for future product growth ideas. I try to do this by conducting market research to understand user demand & pain points that they have. Sometimes, I also look at the suggestions/complaints our existing customers provide and try to capture those as well for future enhancements. Then I prioritize those points captured- in terms of impact they are going to bring for our customers, revenue they can bring for us and the ease with which we can build them and create a plan for multiple delivery cycles. Then I try to bring these ideas up in front of my higher management and secure their budgetary and resource approvals before the work can begin. 

Stage 2 - Design

This stage is similar to a building construction contractor explaining what the client wants in terms of number of rooms, amenities etc. and by when to his/her team and getting the designs ready and approved by clients. In this stage, I provide my design, engineering and quality teams a detailed walkthrough on the prioritized item that we plan to build and clarify any doubts that they might have. Based on the detailed information provided to the team, the team can suggest some modifications to the initial idea. Based on the final requirements, the design teams comes up with design ideas and I do work with them to finetune it before the team can build it. After the designs are are ready, I present it to stakeholders to get the requisite approvals before implementation can begin.

Stage 3 - Implement & Test

In this stage engineers build the product just like builders building the house. I do have a daily checkpoint with the engineers to understand what they have done the previous day, what their plan for the current day is and what is stopping them from completing their work. I do meet up with other team to remove any impediments in the engineers way so that they can complete their work on time. I also interact with our quality teams to finalize testing coverage so as to make sure we carry out internal testing as well as external testing, to iron out issues and make sure the product fits the initial plan that started off with.

Stage 4 - Release

This stage is similar to handing over a finished home to clients by the contractor and getting to know how satisfied they are with the end product. Prior to release, we create documents and educational videos to make sure the user understands what the changes are and how they can use them. In this stage, we release the product online and try to measure the satisfaction of our users. We also try to capture user feedbacks so as to use them for future enhancements to the product.

Usually while one product feature is in testing phase, we try to plan for the future enhancements and the research and planning stage begins for the next product feature. This is similar to the contractor looking for next projects and signing up for them so that he/she can begin work on that post the first product handover.

I believe explaining my work through the lens of a building constructor contractor would help them understand how PMs continue to work through multiple features one after another.

What is your day to day responsibilities as a Product Manager?

Being a product manager, I contribute to each activity that might impact the business, product or users. Still, I can majorly categorize my responsibilities into three phases -

• Product Planning
• Product Execution
• And, Post-Launch Phase. 

The first phase is Product Planning, and in this phase, I am involved in

• Requirement Gathering and meeting different Stakeholders to understand their requirements and pain points.
• Defining the product vision, strategy, and roadmap aligned with the business objective.
• Prioritize product and stakeholders requirements.
• Manage and Prioritize Backlog items. Groom them for the sprint.
• Writing PRDs and Documentation
• Negotiate with stakeholders on prioritized items and timelines

The second phase is the Execution Phase, in which I

• Work closely with cross-functional teams and collaborate with other stakeholders to ensure product and business goals are met.
• Collaborate with the Developers to discuss and plan the picked sprint items.
• Conduct Daily Standups meetings - To keep track of the progress and blockers.
• Collaborate with the QA team to test the product and feature before role out.

Last is Post Launch Phase, in which I 

• Track product analytics and post live metrics to measure product success or failure.
• Collaborate with the support team to check on issues post-launch.
• Conducting Product Demos to Senior Management and Stakeholders.
• Gather feedback and prioritize them in coming iterations.

So, I am a PM at ABC company.

Some people say a PM is the CEO of the product. While i dont subscibe to the same, i still think being a PM i feel responsible for the success or failure of the product.

My day starts at 10 AM. I read a few emails along with a cup of coffee for 30 mins.

Then i see what is the day's events as per the calendar.

Mostly there are meetings, reviews scheduled for the day.

Let me tell you how i go about the entire product launch process. This actually spans many days.

I take ownership of the product and the various stages the product goes thorugh, like Research about the problem and its solution, Ideation about the solution and its approach and coming to a consensus with various stakeholders. Then i prepare a master document which other team members like the engineers and management can refer to know what is the product we are building, what it will give and what not and by when will we launch it.

Then the designing team prepares the diagrams of how the product will look like in the App and website based upon my inputs. This is discussed with various stakeholders including me as well as my managers. We refine the diagram a few times.

Having shared the document and diagram with the engineering team, they start building the logics and appearence of the product.

We do daily small 10 minute meetings in the morning to understand what they did yesterday, what they will do today and what problems/challenges they are facing.

After the engineers have made the product, a different team of engineers do a quality check to know if the product is performing as expected or not. They suggest their changes and the previous engineers' team do them.

Once, we are done with building the product, we go about launching it.

The narketing team has already prepared a launch plan of what activities they are going to do for the same.

We launch the product and then i monitor how the product is doing on a few key parameters i had decided to focus on.

I keep reading customer/sales emails to see how i can improve products or launch newer ones.

I attend many meetings with engineers, designers, marketing, senior management etc. to give status updates, discuss new ideas/opportunities or take inputs.

So, this is the summary of what i do.

I wrap up my day at 6 PM and commute back to home.

At 10 PM, i see on my mobile if there is any urgent mail that needs to be answered quickly or not.

 

I start every day making sure I address any urgent issues. I start by checking my communication channels to see if anyone is in immediate need of help or attention. So around 9 am when I don’t have meeting or work starting, I start reading on PRD, which is product requirement document, concepts notes, some bugs that have come up, some feature request and complaint and questions, which my peers has mailed or mentioned me on slack. I also put my comments and answers on those documents, incidents, request or questions either using slack or email. Then I also schedule meeting based upon these with concerned stakeholder

I also check what all meetings I have to attend today, what all documents and preparation I need to do for those meetings

So 10 am where my work starts, where I usually have 1 on 1 with my manager, where we discuss project status that I am working on, what are the action items I need to take on and what are the blockers or challenges that I am facing or can face while resolving or performing these action items. Plan of action etc to resolve all of those issue

When I don’t have meeting at this point of time, I generally use it for writing concept note or PRD, or some research document or analytics. I also use this time to analyse data and make certain inferences out of it.

So 12:30 to 2:30 is the busiest time of my day, because we have daily standups, where product engineers, designers and Pms come for discussion, what are they suppose to do, what have they accomplished during the day, what is the next step forward, if there any blockers or dependency on others, those are resolved and discussed in this meeting as well. We also have some other tech related meeting usually in this time slot, what are the technical developments needs to be done, what is the scope, estimate for particular line item. So basically estimation, planning and issue resolution are three main thing which I work upon

Around 3 to 7 I am usually involved in cross functional meeting, with product marketing manager, designers, consultant, customer, key account manager, leaders. Because my product is fairly new, so I have to talk to multiple teams and take their opinion into consideration. And I also communicate what are the expectation and update are going to met with this product. I also need to make sure, whatever document I need to deliver, I deliver before 7 pm, so people or stakeholder who are involved can read the document for upcoming discussion and can have top of the head questions for the meeting. If I am hosting any meeting during this time, I make sure that everyone gets it before the time, with the agenda, and make sure they are available

I take a little bit break, and I do systhessis, categorising thing happened during the day

Writing – So if need to write any doc based upon discussion happened during the day ranging from PRD, concept note, customer research, prodtc specs, design specs, etc

Decision making – so for decision making if I am making any decision wrt metric, spec I make sure to have pros and cons. I also make sure to fall back upon on data for any decision making

Discussion seeting – deciding which discussion I need to setup for the next day. So I sent out meeting invite to block time of people for me, because everyone is busy

 

 

This is a really fun question. If it's okay with you, I'm going to answer as if I was explaining product management to my mom. She doesn't really understand technology, but she loves to bake so I'll use baking as an analogy.

Product management is work that sits across strategy and execution. First I'll explain strategy work, then I'll explain execution work. At my current job I manage multiple product areas, so my day to day will depend on the needs of each product area, and where my company is in its quarterly planning.

Product strategy is all about understanding the problems of the customer, and picking the right problem to solve so that you can get deliver the most value to your customer and to your business. So, lets say I was a baker and I'm opening up my first bakery in New York City. Even though I love baking chocolate croissants, if nobody wants to buy a chocolate croissant my bakery will not do well. So first, I need to understand what my customers want. I do this by conducting research. I can ask my potential customers, I can see what other bakeries are selling, and I can run experiments like taste tests to see what I should sell. I will also talk to people who are financing my bakery or my business partners to get their points of view.

I will then take all of my research and see which types of bakes will further my goal: sales (or revenue of the bakery).

After doing this, I might learn that customers in New York City really like almond croissants and that selling almond croissants will drive sales for my bakery more than any other pastry. Almond croissants are a complicated bake and have a lot of different variations. Before I start making almond croissants I'll need to meet with my pastry chef to decide how to make our almond croissants. In baking this is our recipe, in product management this is product execution.

Product execution is all about delivering your solution to a problem completely, while taking into account constraints. So to continue our almond croissant example, if our goal is to make almond croissant and sell a certain amount in a certain amount of time, I need to partner with my pastry chef to decide the best recipe. Together we will think of recipes that satisfy the following things:

        1. Taste: Customers must love it

        2. Appeal: Many customers must be willing to buy, not just a few

        3. Cost: It must be cheap to produce so we'll make money

        4. Time: It must be quick to produce so we can make these daily

There are a lot of types of almond croissant recipes, so we'll have to prioritize which satisfies taste and appeal while maintaining low cost and time. Together, we will agree with a recipe that we will use for opening day of our bakery. Once we have our recipe, we will work together to set up our kitchen. I will document the recipe and answer any open questions. My pastry chef will hire and manage cooks, and together we'll create our process for baking and selling almond croisants.

Finally, let's say it's opening week of our bakery. It will be by responsibility to monitor our sales and see if we are successful. If we are successful, great! It's my job to see how we can increase sales by adding additional baked goods. But let's say our sales are lower than expected, it would be my job to research what about our almond croissants wasn't resonating with customers, and to create a plan to improve.

This is how you can understand product management by understanding baking!

I work as a product manager where my job is to figure our what work we want to do over next 12-24 months, give direction to my co-workers and guide them to create products that improves our customer lives and generate revenue for the the company.

Everyday at work, I attend many meetings with my co-workers, customers. I receive and send many emails. I get to understand what problems customer are facing, I spend time to read and understand what would solve these problems, I talk to industry experts to gain/share knowledge.

I work with engineers, co-workers that are technical experts to create a plan that will help these co-worker to write a compute program to eventually create a product that our customers can purchase and use.

I also write documents that describe the work we do so that our sales/marketing team can go out and sell the products that we are building.

One a regular basis, I meet with the senior leaders who run the company, to explain them where we are headed, get their feedback whether we need to make any changes. I share the problems I am facing and make recommendations on how to resolve these.

Just to give a brief of the kind of product I am working on so that people can relate with the activities that I am doing.

Our product is finance product which manages receivables and payables data across multiple buying systems. The product can be plugged downstream into any buying system and then after some configurations and master data management - we are ready to start processing the receivables and payables and generate reports.

 

Day to day activities include following:

1. We work in a 2 week sprint cycle i.e. we release changes every two weeks -  and I own the outcome of 3 enginnering teams. So my highest priority is to keep enough requirements ready to be adopted for development in each sprint across teams. So that maximum capacity of the engineering teams is utilized for doing feature work (trust me this is eaier said than done)

2.  There are multiple buying systems upstreams which are integrated with out product - so a lot of my time is devoted interacting with PMs and engineering teams across buying products to understand the requirements.

3. My work also involves analyzing requirements coming from different integrating products and organic changes which we are making in our product to make it better across functional and non functional aspects.

4. Prioritizing backlogs negotiating with different stake holders whose priorities will get affected based on the decisions that I am making as a Product owner. Doing justice to the product roadmap(long terms plan for the product) and handling every day exigencies.

5. I also work with the User experience design teams in order to make sure that whatever feature we develop no just solves the problem it is meant to solve and fulfill the user requirements but is also user friendly and makes the life of user better.

6. As we build multiple features across different functionalities in the application - we need to manage the usage tracking. Usage tracking is done to understand how is the user using the system are there any concerns that the tracking data is flagging
e.g. if a user is spending a lot of time on a page we try to find out the different actions that the user can take and try to understand if there is any specific user action which is taking longer than it should - which is keeping the user longer than usual on that page. We also talk to the user to understand their problem (althoug that is not on our daily plan)

7. A lot of time also gets invested in the queries and concerns that the development and QA teams have on the features they are analyzing for a future sprint or any query on the work they are doing in the current sprint. A lot of decisions have to be made depending on the concerns raised by the teams everyday which affect the course of product development. Decisions regarding building minimum value solutions or more sophisticated ones. Analyzing and understanding whether a more sophisticated solution will add more value or sometimes a minimal solution is enough.

8. Running product demos for Client services teams for all the work engineering teams are doing every release - taking feedback from these teams and implementing it back in the form of requirements after validating the impact.

9. One of the most important stake holders I interact with regularly is the technical writing team. No matter how good the product is - if no one understand what it is doing it is of no use. The quality of the documentation that backs any product has to be very high and that's the reason we are constantly talking to the techincal writing teams to give them context of what we are doing - so that they can write exceptional release notes / release details.

10. Talking to the sales and marketing teams to give the what we typially refer to as "What's New" some impact fule features every release that they can portray in the market as potential winners.

A lot of information flows through me and every decision I make impacts a lot of people and the work they are doing. I have to be very cautios and thoughtful while analyzing the impact of every decision I make.

As a product person, I perform a lot of functions, and primarily, I do problem-solving by doing market research, talking with users, or understanding patterns and trying to come up with a solution.

 

We have a lot of tools to do that. Once we know how to fix something, we connect with our team, come up with a plan, and make sure everything is aligned. I’m  also someone who connects with everyone, keeping all teams in sync.

 

When we build or fix an issue, I  make plans on how to inform users about it. There are different ways to do that.

 

This pattern keeps going.