I joined Pratilipi in April as a Product Designer, when COVID-19 had just broken out. Read on, as I share my experiences as a Product Designer and how I transitioned to a Product role in 6 months.

I was quite excited when I joined Pratilipi. I knew it would be a great learning experience, and couldn’t wait to get started. I was offered the role of ‘Product Designer’ towards the end of March and I accepted the offer right then. COVID-19 cases were starting to rise and WFH protocols had just been put in place across organizations, so presence was already increasing in virtual workspaces.

The idea of starting my first full-time UX role online wasn’t particularly pleasing. I thrive by learning from people and being in an environment around folks to bounce off ideas and learn from — zoom calls just didn’t seem to cut it. Starting a role at Pratilipi, was in itself different from how it would’ve been at usual organizations. I had worked with flat, lean teams, but this was a step up. Let me explain:

Pratilipi’s culture is anchored around its people. We’re highly ownership driven, and seldom do we performs tasks assigned by ‘superiors’. There are priorities, goals and if you feel that a hypothesis is worth exploring and can drive growth, you’re free to experiment with the same. Of course, there needs to be some backing and rationality behind the hypothesis, but this freedom is present across teams.

Although this was exactly what I’d hoped for when I joined, the idea of being left alone to explore was slightly overwhelming and I began questioning my abilities, especially since I was WFH.

I had introductory zoom calls with the team, where we discussed how I could start out. Based on their recommendations, I learned that it was good practice to start off a new role by solving low-hanging fruits — these were well spottable issues which if solved could give good ROI. This made sense because:

• As you solve low hanging fruits you pick up momentum and prove your abilities.

• By doing so, you gain the trust of your teammates who start to believe in you, bringing credibility.

• This enables you to pick up tougher, more complex problem statements with confidence.

I identified a set of UI/UX problems which I thought were low hanging fruits and ranked them by urgency and ROI. As I got on a call with the Product Head to discuss the same, she said that these could definitely be worked on, but that she specifically had a challenging problem statement in mind for me. Over call, she gave me some context about the onboarding problem at Pratilipi — our goal was to improve the % of users completing their first read upon installing the app.

The onboarding problem wasn’t quite a low hanging fruit. Past theses had been experimented on and it wasn’t an easy number to move. But at the same time, I had the opportunity to work on a challenging problem. I had worked on the onboarding of Tring, but this was in an entirely different context — different problems, different users, and most importantly, the difference in scale. We had barely shipped Tring to 500 beta users whereas Pratilipi was at 1.5 mn DAU when I was working on this problem.

After doing my initial research and going through the current onboarding flow, I was confident that there was scope for improvement. Even if my first set of experiments failed, I’d learn from them and iterate to improve the funnel. I pinged my product head and told her that I’d love to take it up.

I worked on my experiments for almost a month and was able to drive a single-digit % growth in our onboarding funnel. Although the outcome was positive, I had taken too much time to churn out experiments, especially considering that I had no proven track record, within or outside of Pratilipi. I will talk about this in detail later.

After my first relatively successful experiments, I was confident about my abilities to a certain extent. I was still not quite satisfied because of the turnaround time of experiments. I had been with the team for a month and had just worked on one set of experiments — I knew I could do better.

Post onboarding, I wanted to figure out / do two things:

• Upskill myself and chart a path to step up to product management.

• Experiment rapidly around different problem statements to — 1) figure out ones which I wanted to work on in-depth, and 2) rekindle my lean, iterative nature as I was being too cautious.

To do this, I picked up a few problem statements which required varied approaches. Over the next couple of months, I always had 3–4 problem statements which I was working on at any given point in time.

I ensured that I was fast and iterative in nature to learn as much as I could, in order to fuel my path to product management.

“That’s what she said” — Michael Scott

Working on onboarding was time-consuming for me. This was because I was trying to solve it upon understanding the depth of the problem, and doing that meant learning to use Amplitude to understand users. This was the first time I was using Amplitude and a universe of user data was like porn to me- I spent time looking at a lot of data and not using it for anything solid/impactful.

Pratilipi is extremely lean, and the team (especially product) aims to churn out experiments quickly and iterate on them. Taking a month to even produce experiments wasn’t quite ideal.

I was hired as a product designer and I had to prove that I could get things done as a product designer before showing I could do much more.

I didn’t even realize a month had passed since I was working from home and the number of feedback loops in place were less.

Post my onboarding I decided to speed things up and took up 3–4 problem statements at once to ‘make up for lost time’ and prove myself. I learned the hard way that prioritizing is very important. For a week or two I was a mess and couldn’t keep up focus across different contexts. I wasn’t solving every problem to the best of my ability because of the constant context switching.

A candid discussion with my Product head and CEO helped me understand this, and moving forward, I prioritized my time better, only focusing on 1 cognitively taxing task at a time. Others on my plate were usually less cognitive or execution-oriented. This learning was quite important, especially if I wanted to step up into the Product one day.

Upon numerous discussions with my mentors and having worked in Product teams, this is my mental model of what Product management essentially is.

User & Design: All about users, their journeys on the product, and its visual aspects. Involves understanding the user and designing simple but efficient flows to achieve a goal.

Business & data: Data is an essential part of understanding your user behavior. An important aspect of product management is to translate user metrics to business goals and KPIs. North star metrics that startups strive to improve are usually a reflection of their future monetization strategy/business model.

Engineering & tech: Tech startups are at the forefront of innovation. Technology is vital in today’s context in terms of being an incredible catalyst for innovation and large scale distribution. That being said, understanding how your product is engineered and the tech stack powering it is a vital aspect of product management.

These 3 parts can have different levels of importance across different startups. This is highly dependent on the problem being solved and the approach to the same.

Something which I’ve also observed is that breaking it down from a skillset/domain point of view doesn’t quite paint the complete picture. A product manager does much more —

• Figuring out what problem statements are worth picking up and deciding their scope.

• Planning, strategizing, prioritizing.

• Understanding and mobilizing people and resources available.

• Communicating effectively and bridging stakeholders’ expectations and output across domains.

User Interface: UI refers to the visual aspect of the product and connecting design elements like colour, font, typography, etc. to your users and the problem you’re solving.

User Experience: UX is how you understand your users and generate insights to fit the product experience with your user’s mental model. This involves talking to users, doing research, deriving insights, and using them to create logical flows on your product which leads to user satisfaction.

Product: Good designers understand the intersection of product and design. Understanding metrics to understand users, and connecting the user experience with business goals is important. Ultimately, your design has to impact north star metrics or proxies associated with the same.

I’ve spoken with PMs and mentors to understand what the best time to transition is, and have learned that there is no real ‘best time’ as such. A good starting point although, would be when you have a good, in-depth understanding of at least 2 out of the 3 key aspects of PM. Most importantly, you should feel more excited than intimidated about stepping up.

As a product designer, I was good with user and design, which meant that I needed to get better at data and tech. These are my learnings on how I actually stepped up and I’ve broken it down into 3 parts:

From day 1 of working as a designer, I didn’t restrict myself to the role I was hired for. I took advantage of Pratilipi’s culture and took ownership of the problem statements I was trying to solve. I was highly data-driven, and I wanted to get a comprehensive, in-depth understanding of the problem and user before working on a solution.

An important part of my transition was the ability to quickly learn while executing and up-skilling as and when needed.

Example: I wanted to understand users in depth, and at scale, user interviews don’t cut it. The sample you talk to, more often than not, will not be reflective of the universe of users you’re solving problems for. (Sampling is a skill in itself and we can get a close proxy of the universe, but at scale of 1.5mn DAU the effort vs ROI didn’t quite make sense).So, I quickly picked up Amplitude, a tool we use at Pratilipi to understand user data at scale. It’s a great place to understand behavioural data, identify user patterns and leakages in funnels.

When I wanted to do analysis anchored around data points which weren’t captured on Amplitude since they were stored in the database, I realised that I needed to use SQL. So, I became proficient enough to run simple queries on my own.

Although courses work for a lot of people, I seldom did any — I learn best by doing. My teachers were articles on the internet to understand basic concepts, beyond which my team, the experiments I did and the mistakes I committed taught me best.

I constantly made it a point to have a working understanding of intersection teams. Wherever I sensed the opportunity to learn something new, however difficult it was, I did it as long as it was relevant.

By the 3rd month or so, I had a good grasp on user analytics and in fact started helping a few of my teammates with Amplitude and how to make the most of it. I loved looking at user data and translating it into insights leading to either identifying a problem, or a trend which could be used to solve a problem.

To achieve the transition, I specifically paid attention to my data skills and understanding of Pratilipi’s tech stack. I’ve gotten considerably better on the former and am constantly working on the latter as I solve problems.

I constantly kept in touch with our product head and kept hinting at my expected trajectory — through my work and attitude. It was not an accident that I was doing work beyond a designer’s role, and I made it clear that I could learn fast and get things done.

Within a few months of my joining, in our 1-on-1, we discussed my goals, charted out a path for me to explore product management. Although both of us were on board with the fact that I could explore Product full-time, we agreed that I had a lot more to learn if I wanted to step up.

Over the next months, whatever problem statements I worked on, I ensured that in the majority of them I could dive deep or contribute from a Product pov. I constantly reconciled with my PM on if I was heading in the right direction and if my problem-solving ability was getting better.

Apart from whatever I was working on, I solved Product-first problem statements in my free time and discussed my learnings and solutions with my mentor during 1-on-1s.

3 months into the role, I started attending scrum meetings every day, to understand what tasks were being prioritized, where the engineers’ focus was and a bigger picture of how Product at Pratilipi worked. This also helped me understand tech feasibility to a certain extent in terms of timelines, bottlenecks, etc.

Every day, I worked to learn something new and in turn bridged skill gaps which made me more confident about stepping into a Product role.

After I was confident enough about stepping up and figuring out a replacement for the Product Designer position, I had a final talk with the Product Head and CEO, where my transition was finalised.

I can’t thank the Pratilipi team enough for the room and opportunities they’ve given for me to grow. Onward and upward guys ❤

Fund me to encourage writing more if you liked this piece and don’t forget to share this with aspiring PMs, especially if they’re currently designing!

I joined Pratilipi in April as a Product Designer, when COVID-19 had just broken out. Read on, as I share my experiences as a Product Designer and how I transitioned to a Product role in 6 months.

I was quite excited when I joined Pratilipi. I knew it would be a great learning experience, and couldn’t wait to get started. I was offered the role of ‘Product Designer’ towards the end of March and I accepted the offer right then. COVID-19 cases were starting to rise and WFH protocols had just been put in place across organizations, so presence was already increasing in virtual workspaces.

The idea of starting my first full-time UX role online wasn’t particularly pleasing. I thrive by learning from people and being in an environment around folks to bounce off ideas and learn from — zoom calls just didn’t seem to cut it. Starting a role at Pratilipi, was in itself different from how it would’ve been at usual organizations. I had worked with flat, lean teams, but this was a step up. Let me explain:

Pratilipi’s culture is anchored around its people. We’re highly ownership driven, and seldom do we performs tasks assigned by ‘superiors’. There are priorities, goals and if you feel that a hypothesis is worth exploring and can drive growth, you’re free to experiment with the same. Of course, there needs to be some backing and rationality behind the hypothesis, but this freedom is present across teams.

Although this was exactly what I’d hoped for when I joined, the idea of being left alone to explore was slightly overwhelming and I began questioning my abilities, especially since I was WFH.

I had introductory zoom calls with the team, where we discussed how I could start out. Based on their recommendations, I learned that it was good practice to start off a new role by solving low-hanging fruits — these were well spottable issues which if solved could give good ROI. This made sense because:

• As you solve low hanging fruits you pick up momentum and prove your abilities.

• By doing so, you gain the trust of your teammates who start to believe in you, bringing credibility.

• This enables you to pick up tougher, more complex problem statements with confidence.

I identified a set of UI/UX problems which I thought were low hanging fruits and ranked them by urgency and ROI. As I got on a call with the Product Head to discuss the same, she said that these could definitely be worked on, but that she specifically had a challenging problem statement in mind for me. Over call, she gave me some context about the onboarding problem at Pratilipi — our goal was to improve the % of users completing their first read upon installing the app.

The onboarding problem wasn’t quite a low hanging fruit. Past theses had been experimented on and it wasn’t an easy number to move. But at the same time, I had the opportunity to work on a challenging problem. I had worked on the onboarding of Tring, but this was in an entirely different context — different problems, different users, and most importantly, the difference in scale. We had barely shipped Tring to 500 beta users whereas Pratilipi was at 1.5 mn DAU when I was working on this problem.

After doing my initial research and going through the current onboarding flow, I was confident that there was scope for improvement. Even if my first set of experiments failed, I’d learn from them and iterate to improve the funnel. I pinged my product head and told her that I’d love to take it up.

I worked on my experiments for almost a month and was able to drive a single-digit % growth in our onboarding funnel. Although the outcome was positive, I had taken too much time to churn out experiments, especially considering that I had no proven track record, within or outside of Pratilipi. I will talk about this in detail later.

After my first relatively successful experiments, I was confident about my abilities to a certain extent. I was still not quite satisfied because of the turnaround time of experiments. I had been with the team for a month and had just worked on one set of experiments — I knew I could do better.

Post onboarding, I wanted to figure out / do two things:

• Upskill myself and chart a path to step up to product management.

• Experiment rapidly around different problem statements to — 1) figure out ones which I wanted to work on in-depth, and 2) rekindle my lean, iterative nature as I was being too cautious.

To do this, I picked up a few problem statements which required varied approaches. Over the next couple of months, I always had 3–4 problem statements which I was working on at any given point in time.

I ensured that I was fast and iterative in nature to learn as much as I could, in order to fuel my path to product management.

“That’s what she said” — Michael Scott

Working on onboarding was time-consuming for me. This was because I was trying to solve it upon understanding the depth of the problem, and doing that meant learning to use Amplitude to understand users. This was the first time I was using Amplitude and a universe of user data was like porn to me- I spent time looking at a lot of data and not using it for anything solid/impactful.

Pratilipi is extremely lean, and the team (especially product) aims to churn out experiments quickly and iterate on them. Taking a month to even produce experiments wasn’t quite ideal.

I was hired as a product designer and I had to prove that I could get things done as a product designer before showing I could do much more.

I didn’t even realize a month had passed since I was working from home and the number of feedback loops in place were less.

Post my onboarding I decided to speed things up and took up 3–4 problem statements at once to ‘make up for lost time’ and prove myself. I learned the hard way that prioritizing is very important. For a week or two I was a mess and couldn’t keep up focus across different contexts. I wasn’t solving every problem to the best of my ability because of the constant context switching.

A candid discussion with my Product head and CEO helped me understand this, and moving forward, I prioritized my time better, only focusing on 1 cognitively taxing task at a time. Others on my plate were usually less cognitive or execution-oriented. This learning was quite important, especially if I wanted to step up into the Product one day.

Upon numerous discussions with my mentors and having worked in Product teams, this is my mental model of what Product management essentially is.

User & Design: All about users, their journeys on the product, and its visual aspects. Involves understanding the user and designing simple but efficient flows to achieve a goal.

Business & data: Data is an essential part of understanding your user behavior. An important aspect of product management is to translate user metrics to business goals and KPIs. North star metrics that startups strive to improve are usually a reflection of their future monetization strategy/business model.

Engineering & tech: Tech startups are at the forefront of innovation. Technology is vital in today’s context in terms of being an incredible catalyst for innovation and large scale distribution. That being said, understanding how your product is engineered and the tech stack powering it is a vital aspect of product management.

These 3 parts can have different levels of importance across different startups. This is highly dependent on the problem being solved and the approach to the same.

Something which I’ve also observed is that breaking it down from a skillset/domain point of view doesn’t quite paint the complete picture. A product manager does much more —

• Figuring out what problem statements are worth picking up and deciding their scope.

• Planning, strategizing, prioritizing.

• Understanding and mobilizing people and resources available.

• Communicating effectively and bridging stakeholders’ expectations and output across domains.

User Interface: UI refers to the visual aspect of the product and connecting design elements like colour, font, typography, etc. to your users and the problem you’re solving.

User Experience: UX is how you understand your users and generate insights to fit the product experience with your user’s mental model. This involves talking to users, doing research, deriving insights, and using them to create logical flows on your product which leads to user satisfaction.

Product: Good designers understand the intersection of product and design. Understanding metrics to understand users, and connecting the user experience with business goals is important. Ultimately, your design has to impact north star metrics or proxies associated with the same.

I’ve spoken with PMs and mentors to understand what the best time to transition is, and have learned that there is no real ‘best time’ as such. A good starting point although, would be when you have a good, in-depth understanding of at least 2 out of the 3 key aspects of PM. Most importantly, you should feel more excited than intimidated about stepping up.

As a product designer, I was good with user and design, which meant that I needed to get better at data and tech. These are my learnings on how I actually stepped up and I’ve broken it down into 3 parts:

From day 1 of working as a designer, I didn’t restrict myself to the role I was hired for. I took advantage of Pratilipi’s culture and took ownership of the problem statements I was trying to solve. I was highly data-driven, and I wanted to get a comprehensive, in-depth understanding of the problem and user before working on a solution.

An important part of my transition was the ability to quickly learn while executing and up-skilling as and when needed.

Example: I wanted to understand users in depth, and at scale, user interviews don’t cut it. The sample you talk to, more often than not, will not be reflective of the universe of users you’re solving problems for. (Sampling is a skill in itself and we can get a close proxy of the universe, but at scale of 1.5mn DAU the effort vs ROI didn’t quite make sense).So, I quickly picked up Amplitude, a tool we use at Pratilipi to understand user data at scale. It’s a great place to understand behavioural data, identify user patterns and leakages in funnels.

When I wanted to do analysis anchored around data points which weren’t captured on Amplitude since they were stored in the database, I realised that I needed to use SQL. So, I became proficient enough to run simple queries on my own.

Although courses work for a lot of people, I seldom did any — I learn best by doing. My teachers were articles on the internet to understand basic concepts, beyond which my team, the experiments I did and the mistakes I committed taught me best.

I constantly made it a point to have a working understanding of intersection teams. Wherever I sensed the opportunity to learn something new, however difficult it was, I did it as long as it was relevant.

By the 3rd month or so, I had a good grasp on user analytics and in fact started helping a few of my teammates with Amplitude and how to make the most of it. I loved looking at user data and translating it into insights leading to either identifying a problem, or a trend which could be used to solve a problem.

To achieve the transition, I specifically paid attention to my data skills and understanding of Pratilipi’s tech stack. I’ve gotten considerably better on the former and am constantly working on the latter as I solve problems.

I constantly kept in touch with our product head and kept hinting at my expected trajectory — through my work and attitude. It was not an accident that I was doing work beyond a designer’s role, and I made it clear that I could learn fast and get things done.

Within a few months of my joining, in our 1-on-1, we discussed my goals, charted out a path for me to explore product management. Although both of us were on board with the fact that I could explore Product full-time, we agreed that I had a lot more to learn if I wanted to step up.

Over the next months, whatever problem statements I worked on, I ensured that in the majority of them I could dive deep or contribute from a Product pov. I constantly reconciled with my PM on if I was heading in the right direction and if my problem-solving ability was getting better.

Apart from whatever I was working on, I solved Product-first problem statements in my free time and discussed my learnings and solutions with my mentor during 1-on-1s.

3 months into the role, I started attending scrum meetings every day, to understand what tasks were being prioritized, where the engineers’ focus was and a bigger picture of how Product at Pratilipi worked. This also helped me understand tech feasibility to a certain extent in terms of timelines, bottlenecks, etc.

Every day, I worked to learn something new and in turn bridged skill gaps which made me more confident about stepping into a Product role.

After I was confident enough about stepping up and figuring out a replacement for the Product Designer position, I had a final talk with the Product Head and CEO, where my transition was finalised.

I can’t thank the Pratilipi team enough for the room and opportunities they’ve given for me to grow. Onward and upward guys ❤

Fund me to encourage writing more if you liked this piece and don’t forget to share this with aspiring PMs, especially if they’re currently designing!