How I Learned to Be a Better Product Manager

Ashwini Sriram
Ascent Publication
Published in
8 min readJul 30, 2020


Photo by airfocus on Unsplash

I was 21 when I wanted to become a product manager.

I was a software engineer in Chennai, India, working for a company that manufactured HVAC systems. As a fresh college graduate, I wanted to understand how what I was working on was making a difference to the world!

One year into my job, my team hired a product manager. He used to talk to building operators and site managers who were actually using my software, and pass on real, human feedback from them back to my team. He was the one telling us what to build and what our customers need. His job seemed exciting and meaningful.

I resolved to become a product manager — I wanted that guy’s job.

Six years later, I landed my first product manager internship at a large tech company in San Jose, California. My dream came true — several thousand dollars in student loans, and two years of graduate school later.

I read all the important books written on product management, and went to work equipped with a working knowledge of user stories, prioritization frameworks and other product management techniques.

Nothing could have prepared me for my actual experience of being a product manager. My engineering team didn’t trust me (I was an intern with no product management experience). My boss didn’t really trust me. It took me a while to understand the systems I was expected to redesign, and what my customers needed. People didn’t believe I deserved to be there. More importantly, the requirements I wrote had gaping holes that my engineering team was quick to point out.

“What do you mean the customer needs a dashboard? Why? That makes no sense.”

“I don’t understand these product requirements!”

“Should we scale this system horizontally or vertically?”

My boss dumped many things on me:

“Ashwini, could you please starting doing <task X> starting next week?”

“Could you please prepare a program report for product X, and do problem discovery for product Y?”

I used to go back home feeling disheartened and incapable.

I saw many of my commitments slip through the cracks. It was just hard to keep up with all my tasks. During requirements review meetings with my team, I felt tongue-tied. I embarrassed myself quite a bit by pretending like I knew what I was talking about. I felt like a fraud.

Why did I think I could be a product manager?

Photo by Zohre Nemati on Unsplash

After 4 years of product management experience and a few successful product ships under my belt, I am now a better product manager. I still get asked these questions, but I know how to answer them. I think every product manager goes this journey of self-doubt before they get the hang of it. You will feel like you are swimming against the tide for a few years. It is hard.

There are several blogs and articles dedicated to product management but here are some practices and books that I believe made me a better PM.

I Read These Books on Storytelling and Communication

While there are books that are widely read by product managers (which are great), these are the books that helped me write better stories, work with people from different cultures and create more confidently. These books taught me the skills I use every day in my work:

The Story Genius by Lisa Cron

image courtesy:

This book gave me these important insights:

Humans are hardwired to crave stories. The purpose of the story is to help us interpret, and anticipate the actions of others and of ourselves, and help us survive in this unpredictable, cruel and beautiful world.

We humans don’t care as much about the external events that happen to the central character (romantic relationship, poverty, crime)— we care about the character’s internal journey and how the character changes internally as they pursue a difficult goal.

I now spend a lot of time understanding and describing how customers feel/change as a result of a problem they face, that my product should solve.

For example: “It takes Jessie 6 hours to deploy a code change using our CI/CD pipelines. She dreads having to deploy code incrementally. Every time her team plans to deploy, she has to know at least a week ahead, so that she can pay for a sitter to look after her kid — she’d only be able to go back home at around 11 pm. Once she has started to deploy, she has to keep watching the monitors to ensure that deployments to each box has happened successfully since even one failure would require her to restart the entire deployment, considering that our product doesn’t detect/alert on deploy failures. This is usually the low point of her week — she feels frustrated and helpless.”.. you get the drift.

You really feel Jessie’s pain and are compelled to act. This book taught me that as a human, you are hardwired to actually experience Jessie’s pain if the internal journey of your customer is written/told well.

The Culture Map by Erin Meyer

image courtesy:

I grew up in India.

Although I went to an English medium school, like many Indians, I struggled to communicate effectively with my American peers. This book taught me that since Indians are from a “high-context culture”, we tend to put the burden of comprehension equally on the speaker and the listener when communicating an idea. The definition of “good communication” is just different for us.

Low-context: “Good communication is precise, simple and clear. Messages are expressed and understood at face value. Repetition is appreciated if it helps clarify the communication”

High-context: “Good communication is sophisticated, nuanced, and layered. Messages are both spoken and read between the lines. Messages are often implied but not plainly expressed.”

I used to “imply” many things, and used to get frustrated when my audience didn’t understand what I was implying.

In the U.S., the onus of comprehension is almost entirely on the speaker. As the speaker, it is on me to use the right words, set the right context, and state the facts slowly and clearly.

This was a revelation to me, and changed the way I communicate. It helped me write better requirements and work well with global teams.

I Keep a To-do List That Actually Works

Everyone tells you to make to-do lists. Here’s the problem: it is hard to sustain the habit. I have tried using notebooks, evernote, sticky notes and many other tools to keep track of my to-dos. I never went back to them after week 1.

As a product manager, you absolutely need to-do lists. You switch context a lot and may forget to fulfill your commitments. You do forget the little tasks, like following up with a team on a ticket or filing a ticket for a bug, or one of the dozen other things you are expected to do everyday.

I love Todoist. It is the only to-do list tool that has actually worked for me.

I like that it has a Chrome extension and is easily accessible during backlog grooming or other meetings. It doesn’t require you to close tabs or stop doing what you are doing (writing product specs!) to use it.

When someone says, “Hey Ashwini, could you check with this team on <something>”, I immediately note it down on Todoist.

At the end of the week, I check to make sure that my to-do list is empty.

Keep a Log Book: Track How You Spend Your Day

Photo by Hannah Olinger on Unsplash

Keeping track of your day is especially helpful for product managers, since we split our workday into multiple tasks and struggle with describing how we spent our time when it is time for performance reviews.

Maintain a log book.

Mine is literally just a Google doc with a table for each day with these columns:

Time spent | Task | What I learned


1 hr | All Hands | Company priorities are changing..<more detail>. 

We do a lot of different things and it is good to keep track of how we spend our day for two main reasons:

  1. Automate/hire for time-sinks

If you spend two hours each week gathering the same data for a report, automate it, or make a case for hiring an analyst. Keeping a logbook makes it easier for you to make a case to hire someone.

2. Say no to things you don’t have time for

Your boss comes to you with “Ashwini, can you spend time coaching our new intern?”,

I simply look at my log book and see what tasks will slip if I take on this new thing. I have fallen into the trap of saying yes to too many things because as a PM, I don’t have JIRA or other tools to help me keep track of my daily work.

Get Comfortable with Saying “I Don’t Know”

I used to hate saying “I don’t know”. It made me feel like an idiot. I used to nod along quite a lot.

You know what?

You are an idiot, and that’s okay. It is actually liberating to think of yourself as an idiot. A beginner’s mind is so important for a product manager. It allows you to approach things with curiosity, and challenge the status quo.

As a product manager, you are the least specialized person in the room. Own it. I now view this as a strength, because it lets me see the big picture and cut through the bullsh*t.

Your job is not to know everything, but to get the right information from the right people so that your team can gain clarity. You don’t need to know. You just need to be able to find out quickly, or ask the person who knows, for help.

Practice saying “I don’t know”.

Now, practice saying:

“I don’t know, but you can ask X — they’ll know”.

“I don’t know, but I can find out and get you the information by <state a date and time>”.

“I don’t know, and we will never actually know for sure. But, here’s a reasonable assumption — <state your assumption>”.

Be kinder on yourself and stop pretending to know something you don’t.


  1. Read books on storytelling and working with people across cultures. These are the books that helped me: The Story Genius by Lisa Cron and The Culture Map by Erin Meyer
  2. Keep a to-do list to keep track of your tasks — especially tasks that other people ask you to do.
  3. Keep a logbook. Write in it at the end of the day. Log how you spend your time.
  4. Get used to saying “I don’t know”.

This is by no means a comprehensive list of all the things you need to be a good product manager.

Setting clear expectations, always grounding solutions and decisions in a customer problem, working effectively with different types of personalities, staying calm, the ability to prioritize tasks/features, taking the time to gain the technical knowledge you need to do your job are all things you must learn.

I’ll talk about these core skills another day. :)

Are you a product manager? What are some resources, tools or techniques that have helped you become a better product manager? Leave a comment.



Ashwini Sriram
Ascent Publication

Technology leader from Chennai living and writing in San Francisco.