First month as a Product Management Intern
I first started entertaining the possibility of making product management my profession when I was given charge as the release manager of the project in my previous firm. A lot of things have changed since then and it will be safe for me to assume that I have taken my first few steps towards realizing that dream. After a few months of foraging through various online resources, books and videos I felt prepared to get a bit more hands-on in my approach. I started applying to various early-stage start-ups, to maximize my chances of getting the most ownership at my job.
After a month of struggling with internship applications, I landed a product management internship role at an early stage ed-tech start-up InfyBytes AI
Labs Pvt. Ltd. At my time of joining, the company was just three months old and had ambitious plans to aggressively scale its business. I was assigned to take charge of the Homework App, a product that aimed to aide teachers in assigning homework to students. This was a perfectly poised opportunity for me to experience the rapidly changing start-up boom and the fast-paced design-develop-reiterate cycle that it brings along with it to accentuate my learnings as a product manager. As I finished my first month at the company my experience was blissfully different from my expectations, and I was enthralled by all that I was offered.
So here are the three things I learned on the way, that I hope will help you as an aspiring/new product manager in your workflow:
1. The only thing that can make or break your product is to know your customer in and out
2. We all have inconspicuous personal biases that can adversely affect our decision-making if not validated using data
3. Defining a problem clearly is more crucial than crafting a solution to the problem
Knowing In and Out about your customer
Although the topic might seem very plebian and apparent to a majority of my readers, I would like to point out that it's easier said than done. The definition of knowing the ins and outs of our customer depends from person to person as well as from organization to organization. For an early-stage startup like ours, it meant interviewing the customers (here teachers and tutors) thoroughly to not only understand their impression of our apps but rather to dig deep enough to know the actual pain points they face in the methods that they were already using before bumping into our app. To obtain this data we had to track individual user’s app usage behavior and then go into performing contextual user interviews. Conducting contextual interviews helped us to ask more pin-pointed questions that would not seem transactional; rather, it would flow in a storyline manner thus letting the user divulge more information that would have otherwise been lost in a transactional interview style. Accurate and in-depth analysis of the data helped us unearth formerly unknown value propositions and helped us not only make feature-level changes but also aided in charting a better direction for the product’s future.
Getting rid of inconspicuous biases
When I took up the task to find out why certain teachers were dropping off of our app, I didn’t think I had to deal with any kind of biases that I had against teachers. It only became apparent to me when my team and I scrutinized the first set of responses gathered from the user interviews I conducted. I had presented the team with a conclusion that most of them were dropping off from our app as they couldn’t find the content they were looking for (in this case, the classes we hadn’t updated our app with yet). But soon enough I noticed that I was only interviewing teachers from tier 1 cities and most of them taught classes that we hadn’t targeted yet. So naturally, the problem that was pointed out by these teachers didn’t give us any new insight. Rather, conducting interviews of teachers in tier 2 and tier 3 cities with poorer internet access helped us figure out that the subjective question submission was a real pain for students, which drove them away from our app. So my inconspicuous bias of targeting only tier 1 cities could have potentially misled us to pursue problems that weren’t maybe on the priority list of the user base we were targeting.
Importance of well-defined problems
More often than not I found myself excited by the cool feature that our product could have, only to be thwarted by the counter questioning that would point out fundamental flaws and non-idealistic consequences of implementing the feature. I was rightly pointed out by my CEO to focus on defining a problem before jumping to a solution. I realized that with a better definition of the problem statement, solutions became easier and more air-tight as a whole. The more time we spend on making the problem statement pin-pointed, the easier it gets for us to not get distracted by vague solutions that take longer to implement with not unpredictable outcomes. A well-defined problem is the stepping stone of a great PRD — Every time your developer doesn’t call you up for doubts which causes unexpected delays you will thank yourself for making the problem statement as clear as possible to leave no room for assumptions while crafting the solution part of the PRD.
Conclusion
In conclusion, I think success for a product starts with understanding one’s customer (user) deeply with genuine curiosity and ends with a well-defined problem statement. Along the way, conducting bias-free research to validate ones’ ideas is important. These are just a few novice ideas that I hope to build upon in the near future.
Well, these were just a few things that I picked up in my first month of internship. These ideas were rather introductory steps in my path to becoming a better product manager. I hope to add more value for aspiring PMs in the upcoming days, weeks, and months by continuing to share my journey and learnings. I would like to hear your thoughts about the article and would love to connect and talk with y’all if you feel like dropping in a DM.
So here is a link to my LinkedIn profile.
