15 Lessons from A week in the Life of a Product Manager

15 Lessons from A week in the Life of a Product Manager

A reader just wrote to me about how my article One Week in the Life of a MBA Student inspired him. It made me realize how powerful it is to actually get a glimpse of what other people's professional lives are, so I decided to write this article about life as a Product Manager. I break down the meetings and work done in each day of the week and highlight 3 things I learned from each day.Who am I? I'm an engineer-turned-entrepreneur-turned Product Manager, I started my career designing airplanes so I am deeply enthusiastic about beautiful design and robust engineering. Right now, I'm a Senior PM at Twilio, a 3000 person cloud communications company, in hypergrowth mode. We build enterprise software to enable people to communicate with companies easily. Remember that text that told you that your Uber has arrived, Twilio powered that text, did you hit the call button to call up your Uber driver? Twilio powered that call too, in over 200 countries. The company is publicly valued at $40 Billion dollars but still feels like a fast moving startup. The wildest part of being at Twilio is that things move really fast and you're generally working on multiple big initiatives simultaneously, and as a PM you need to drive the things that are happening while keeping everyone aligned and looped in.

I personally manage three product suites at Twilio, so I work closely with 3 Engineering Managers, and set the roadmaps for 20+ Engineers and designers. Half the developers are in Tallinn, Estonia though, so I've set my Google calendar to show me SF time next to TLL time so I can schedule meetings mindfully for everyone's timezone.

Calendar Snapshot showing meetings and work blocks from Monday to Friday. Color coded by category of work.

The Legend on the left of the calendar screenshot above shows a few buckets to classify the time blocks; Customer meetings and interviews, Meetings (all kinds of work meetings), Hiring related interviews and recaps, 1:1s with my manager and the Design and Engineering Managers I work with, Providing and Getting Training, Sprint Ceremonies, a Gym Block so I can work out with my partner, and Work Blocks for planned work. I don't believe in filling every minute of the calendar so the empty spaces let me catch up on emails and the unstoppable Slack pings through the day. Product Managers rarely plan their personal sprints or do personal retrospectives, but looking back at this week, could offer insights into what is working and what I could optimize.

Let's get into it.

Monday

I start the week in a recap discussion of whether to hire a PM we interviewed last week (we said no). I attend only half the next meeting with the design team so I can ensure I have a personal dashboard setup for the upcoming product launch today.

No alt text provided for this image

The highlight of this week is that we're publicly launching Messaging Insights, an important product that the team has been developing for 11 months! We've scheduled a half hour on Monday morning to turn on the feature flag from "Private Beta" to "Generally Available". This is an exciting time and I've got a very spirited and serious team on Zoom, monitoring all our metrics as we release the blog post and enable the product for all our customers.

I then have a customer interview scheduled to discuss another upcoming product, which is in Discovery phase. Then there's a noon gym block - gotta exercise. I dedicated a block of time to track how the newly launched product is doing - how many customers have found it, which of my various different marketing tactics is leading new users to the product, how long they're staying, what they're rating the experience, etc. I concluded the analysis confirming that our launch has hit its mark, and adoption as well as satisfaction metrics are pretty high for launch day.

In the afternoon, I catch up with Engineering on a retrospective for the last sprint and planning for upcoming sprints. And have a meeting about whether there are any technology incidences or failures with the new launched product this morning.

The evening is free, and celebratory after the big launch.

3 Lessons:

  1. Don't launch anything new in the weekend in case something goes wrong over the weekend, but also don't launch anything on a Monday. Launch in the middle of the week so that everyone can be comfortably on-call and not dealing with Monday morning blues.
  2. The team loved the detailed launch sequence I had created to ensure all are parts were shipped simultaneously, so that will now become my template for every new launch. Launch days are busy- they're all about making sure things. go smoothly and tracking what is working and what we can learn from the numbers, have a plan for the day ready beforehand.
  3. Find reasons to celebrate with your team. Share lots of credit every time you get a chance. Make time for praise, humor, and levity. Especially when there's a pandemic going on.

Tuesday

The morning starts with a meeting to review a candidate designer's portfolio (it was really impressive, so we got excited to jump into the interview panels).

During my 1:1 with my amazing managers + mentors, Matan Gal & Amit Agarwal, we discussed thee success of the previous days launch and talked about how:

Product management is a thousand little things, interspersed with a big launch once in a while. Both are equally important.

The next meeting was about an incident that happened when one of our products malfunctioned for 0.16% of our customers for 11 minutes. We spend an hour deconstructing what went wrong, and what we can learn from the incident. We come away with betterments that will be implemented over the next few months to ensure such an incident never happens again.

At Twilio, things move fast, so we need to keep track of microeconomic trends and changes in customer needs that we should react to. For this, we have tactical bi-weekly Operational Reviews. Within these operational reviews, we discuss recent sales requests, new rules, and learnings from customers that might be relevant.

No alt text provided for this image

The main agenda on Tuesday is to handle a big change in regulations in India. While it is not in my usual portfolio of work, there was an Operational Review last week, where I volunteered to handle what can only be called a new "Fire": Indian regulators have announced a sudden change in Telco regulations that affects our ability to do business in the country. Twilio is built on the AWS cloud, and we need to work closely with AWS on how to manage these changes. During the course of Tuesday, I count 5 meetings across stakeholders from engineering, billing, Legal, and a company wide International product council that we've created to help manage the company's international expansion initiatives. I also spent time reassuring a customer who is worried about how the regulatory changes might affect them.

The daily workout needed to be moved to the evening to accommodate all these meetings.

After the workout, during those empty hours I write a 1-page summary and a detailed 5-phased plan on how we'll handle these regulatory changes. I name this project "Hot Potato" and release the draft plan to everyone who might be interested. Then, when it becomes morning in the Indian time-zone, I meet with the Twilio team located in India to walk them through the "Hot Potato" plan and get feedback.

3 Lessons:

  1. To handle Fires (or escalations) - create a single source of truth document and a temporary Slack channel that people can come to and get the latest info. Multiple email threads suck, keep all comments and action items in a doc. And send a daily or weekly email update about the project linking to the doc and channel. Giving the project a memorable name also makes it easy for people to reference it later.
  2. Handling changes in International regulations are a huge part of the work in Enterprise product management. Make friends with the lawyers. Your legal team should tell you about the latest rulings or court decisions but jumping in and understanding how it impacts your customers and what you need to do to be compliant is on the product team. Sidenote: if you're reading this and have customers in Europe- you should really read up on the new Schrems ruling. It won't just affect Facebook, it will require a lot of work for every software company to be compliant by the end of next year.
  3. When your system goes down it costs you customer trust, and Trust is the highest thing to aspire to. Therefore, Postmortem meetings are really important whenever you have software incidents that impact customers, even if the impact is small. We usually use the 5-Why's framework to conduct blameless postmortems and immediately create work items to track using an in-house tool so that we can track betterments.

Wednesday

Wednesday is centered around how different products are billed within Twilio and what limitations there are in the billing system. Business model innovation is part of every disruptive company's toolkit. Thus, Twilio's products are very diverse - we have Pay-as-you-go products which cost more as you use more, Subscription products which get billed once every month, Tiered pricing where different customers receive varying discounts, Cost-per-seat licenses that let customers pay per user and probably more business models that I don't know about. Further, all these bills need to be created in multiple currencies and follow various international taxation laws.

A picture of a random phone bill issued by Sprint. Sourced from Google.

If you have a post-paid phone plan, imagine your monthly cellphone bill where your carrier (like Sprint or Verizon) may be charging you different line items for your mobile handset, plus the calls and texts, plus the international roaming plus the shared family plan and then some complicated taxes and insurance charge. Now multiply that complexity by 1000 and that's Twilio's billing feels like.

I'm very interested in our billing infrastructure because one of the products I'm planning to launch in Q4 in the year requires a completely different way of charging the customer and I want to be sure that the billing infrastructure will support that functionality. So, I'm trying to work with them to ensure our roadmaps are aligned. Turns out they can't support my request this year.

Since I found out that the Billing will not be able to support my billing requirements for this year and next year's roadmap isn't certain, I have decided to rethink how we'll charge for the product and spend the evening rewriting the product spec.

As part of a normal weekday, I conducted one Product Manager interview (not hired) and attend one Designer interview recap (hired). I had two meetings with Engineering managers to catchup and work on plans for the products we're building together. Twilio is committed to incredible diversity goals, so I voluntarily attended the "Be Inclusive" training being offered to see how I can play my part. I also polished some slides for the next day's Sales training.

3 Lessons:

  1. Part of leading with Influence rather than Authority is about being flexible. You might have dependencies on dozens of stakeholders for your product ideas to be successful. And some of them might have higher priority work than meeting your dependencies and that is OK. Pick your battles on which teams you want to put pressure on or escalate issues to senior leadership. The more you act with goodwill & flexibility and be obliging when other teams need your help, the more you'll be able to navigate the company's dynamics.
  2. As companies scale, there are crucial parts of their technical infrastructure that need heavy investments just to keep the lights on. Billing, Taxation, Invoicing, and Compliance are a few of those crucial infrastructure layers. Keep them updated and ensure those teams are well-funded even though they are cost centers and their "customer impact" metrics are usually the lack of any fires, rather than increased revenue or usage. Another crucial team is your talent acquisition team - keep them resourced - because they're the ones who enable you to hire well!
  3. In-house training courses usually do a much better job engaging employees than purchased training tools to meet compliance requirements. Good training sessions are respectful of everyone's time, quite educational, and can be even fun. I enjoyed my diversity training and made new friends because I got to hear their stories rather than having to just watch a video and do an online quiz.


Thursday


No alt text provided for this image

On Thursday morning, I prep the AV in my home office for the best lighting and audio quality. I am providing training to the company's sales force for the product we launched on Monday. Since my product is free to customers, the Sales training starts with a fun gif about how EVERYBODY GETS A NEW PRODUCT. A total of 504 Sales people attended my training webinar from around the world (which I'm thrilled about). The result was a nice spike in usage of my product as the Sales reps reached out to current customers who might be interested in using it.

On Tuesday I got to focus on short-term urgent issues. On Thursday, I got to spend time on medium term issues. Our product team met up in the morning to clarify expectations from the Quarterly planning meeting scheduled for later in the afternoon. I blocked off an hour to update my Q3 planning documentation so that I'm prepared for the important Q3 planning meeting.

At Twilio, our Quarterly plans are hugely informed by our strategic annual plans. The annual plan is built off the company's Business Priority Metrics - BPMs. The Business Priorities are always evolving, and so we write "Long Range Plans" that are multi-year plans for every business unit and keep updating the Long Range Plans as the business environment changes. This helps us keep an eye on macroeconomic trends affecting our business.

3 Lessons:

  1. If you're the one training people - please make it fun. If you build a reputation that not-just your customer facing webinars, even your company facing presentation are fun and useful, people will turn up. It's worth the time it takes to practice. Make your presentations as short as possible, but not shorter.
  2. Planning meetings require advanced planning from the attendees. If you turn up without a write up for what you're proposing within a planning meeting, then it isn't easy to make informed trade-offs and it just becomes a discussion session that leads to YET-ANOTHER planning meeting...
  3. A business has So many types of Metrics. But a shared understanding of where we're trying to get each year, each quarter and each Sprint, makes it much easier to have the big picture in mind when making priority decisions. Never propose a new idea without indicating which metrics it will help and hurt.


No-Meeting-Friday

Friday almost succeeds in being Meeting-free! I only have one Engg standup to attend and a customer interview late in the evening to wrap up Discovery for an upcoming product design.

I try to spend Fridays on Longer term. thinking. I block off the morning to analyze my product portfolio metrics. These blocks take many hours of focus. The multiple product dashboards can only show top-level numbers like new users, retention, etc. I intend to dive deep and analyze what users are doing within the product, which screens they're going to, what comments they're leaving behind, etc. To do this effectively, I'll need to use Looker, Heap, and Qualaroo dashboards that I create, and Tableau, and Google Analytics dashboards that Marketing maintains. That's just the usage stats, if I wanted to look at API metrics, I would need to dive into DataDog, BigQuery, and Kibana dashboards that the Engg team maintains.

Fortunately, I love data, so after spending a few hours digging deep. I sent out updates to people so that we're all on the same page as WFH drags on and we can't yet see our wonderful teammates in person. I include a "nerdy stats" section at the bottom with the nerdy nuggets I found and how they will be informing future prioritization decisions on what Engineering builds. I also write up a summary for business leadership about how some of my products are doing as part of a monthly update email.

I got to spend the afternoon thinking much longer term and playing with ideas on my whiteboard.

3 Lessons:

  1. You need a clear calendar to focus, think, and do deep-dives. In Paul Graham's seminal essay about Maker's Schedule vs Manager's Schedule he talks about why developers hate meetings - cause it breaks their ability to focus. As a PM, or any business leader, clearing regular time in your calendar lets you do the Maker work too. Making investments based on Long term insights is what differentiates real leaders from regular middle-managers who are just tactical.
  2. No-meeting-days are really useful if people respect them. But still, the constant emails and Slack pings are distracting. Even better are No-Talk-Days where you don't feel obligated to reply to anything and just dive deep into the Maker work.
  3. Find the work in your schedule that gives you energy. I enjoy nerding out with data, you might not. I enjoy designing pixels on Figma, so I can free up my designers from easy tasks to let them focus on researching and designing beautiful and important flows. You have to make deliberate decisions on how you'll spend your time each week, and each year. That's how you get to enjoy your work.

Final thoughts:

Between hiring, training, planning, executing, talking to customers, and handling Fires, every week of work flies by. It seems like I spent about 60 hours working which is on the high-side if we want to stay healthy during this WFH phase.

Having personal and professional goals on what you're trying to learn, what you're trying to build, and who you're trying to become help you keep some perspective. My personal fitness goals made it obvious I needed to create a Gym-Block in the middle of each work day instead of taking a lazy lunch break.

I suspect we'll all be doing dramatically different things in 2030, 2040, 2050, etc. than we are doing today. Between the age of 20 to 70, we'll get to work for 50 years in our lifetime if we choose to work that long, and we'll get increasingly more effective at serving our customers no matter what industry or shape we find them in. So, I'm glad I took the time to look at one of my weeks in detail and spot the lessons in it.

At heart, I'm a builder and a problem solver. So, what I love about weeks like this is that we get to ship things that solve problems for real customers - humans who can have an easier day because of something we've built for them. And that I get to solve challenging problems in the short term, put tactical things in motion for medium term goals, and come up with stimulating ideas for the long term.

I hope you enjoyed reading this and will find it worth sharing with current / aspirational PMs and other managers. Please leave comments about what you found interesting, what your week is like as a PM or in any other field, and do feel free to share... what you'd have done differently :)


Rob Miller

Experienced Founder and Angel Investor

10mo

Incredibly insightful, thank you for this glimpse into how Product Management is done well.

Clifton Mhlanga

Helping orgs govern their quote-to-cash process.

3y

What tools do you use? Prateek Jain

Vinay Shetty

Senior Customer Success Manager at UiPath

3y

Greatly insightful . Thank You for sharing.

Chetan Kapoor

Growth Hacker | Product Storyteller | 10x Advisor

3y

Wow! Great articulation Prateek Jain. You described such a complex PM week with such simplicity and ease. Covering Lawyer conversations about regulations, to putting out daily fires, to penning down long-term innovative ideas! #TruePMLife

Kunal Vasudev

Sr. Project Management Analyst at Target

3y

This is soo well written. There are many takeaways for me in this, thanks for always inspiring.

Like
Reply

To view or add a comment, sign in

Insights from the community

Others also viewed

Explore topics