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 my customers’ lives. One year into my job, I met my newly hired product manager. He used to talk to building operators and site managers who were actually using the software I was writing, and pass on real, human feedback from them back to my team. His job seemed exciting and meaningful.
I resolved to become a product manager — I wanted that guy’s job.
Six years later, I was a product manager intern 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?
After a few years of product management experience and 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.
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.
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
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
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 also helped me work with global teams better.
Keep a To-do List
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. I like that it has a Chrome extension and is easily accessible during backlog grooming or other meetings.
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
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:
- 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.
You know what?
You are an idiot, and that’s okay. :) It is actually liberating to think of yourself as an idiot. As a product manager, you are the least specialized person in the room.
Know it. Own it.
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.
- 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
- Keep a to-do list to keep track of your tasks — especially tasks that other people ask you to do.
- Keep a logbook. Write in it at the end of the day. Log how you spend your time.
- Get used to saying “I don’t know”.
Are you a product manager? What are some resources, tools or techniques that have helped you become a better product manager? Leave a comment.