5 Learnings from a Product Manager
Like many people today, when I was attending school, I didn’t imagine myself becoming a product manager. Why? Simply because I didn’t know about such discipline. Moreover, as a formal job, it didn’t even exist in my country of origin — Armenia. Like many other millennials, I decided to become a programmer and so I studied computer science.
It wasn’t hard to find a job, and at age 19 I was developing Windows Phone games at a mobile laboratory called mLab ECA. This is where I started questioning myself on how a good product or user experience should look. We did not have a dedicated PM at that time and were designing the game logic ourselves.
When releasing a game, I would then go on and read user reviews with fascination. The idea of people all over the planet using my app and liking it was fascinating. Long forward, I joined PicsArt — a mobile app that is now the #1 photo editing app in the world, as a Windows Phone developer. Some years later I would sign a paper that stated my position as — Product Manager.
Product management is one of those jobs that requires continuous learning. By now, my main experience is in building consumer products. So here are 5 learnings I gained through experience and reading.
#1 Users hire your product to do a job for them
In the traditional way of thinking, we compose user stories by putting a heavy focus on user demographics — gender, age, country, etc. User stories start with a description of the user, goes through the needs and goals. When discussing “Jobs to be Done” framework prof. Clayton M. Christensen brings up the following concept that in some way contradicts the User Stories.
Users have different jobs that they need to do. In order to be able to execute those jobs, they hire products that would do the job. These products may do the job completely or assist the user in improving productivity, quality or/and an aspect related to the job. Take Uber as an example. No matter what demographics, users of Uber have 1 job to be done which is reaching from point A to B on time.
Some users prefer to have rides in more comfortable cars, some prefer a driver that is not talkative but the basic need still remains the same — going from point A to B on time. If there are more ride requests than there are drivers, and users are not able to request a ride, they realize that Uber doesn’t do the job well. And as a result, they hire Lyft in order to get their job done.
Using this framework has eased the process of feature prioritization for me because I put the main focus on 1 fundamental job that my upcoming feature will be doing. If 1 feature is not enough to do the job, I will make the product scope bigger or reprioritize it in favor of other features that will solve a fundamental user need and do the job.
#2 Make your product your hobby
Product Managers are the user ambassadors inside the company. We should empathize with users to better understand and feel their needs. And there is no better way of increased empathy than wearing the user’s shoes and using the product yourself. But there is a catch.
If you use it forcefully you will not be able to take the product manager hat off and become a user of your product.
Here is my case. I was building video editing features for the PicsArt app for nearly 2 years, but for some reason, I rarely did video editing myself. This all changed when a teammate of mine suggested that we post Instagram stories of video edits we make and share them in our Close friends' circle not to feel embarrassed when posting weird stuff.
And it really helped. Each day we started making more and more complicated and artistic videos. In the process of creation, I started understanding better which features are more important for a use case and which are not. This then helped me to be prepared better for doing what is described in the next point.
#3 Go talk to users
Being influenced by success stories of the iPhone and the next big thing that users even don’t know they need, many PMs including myself are often too concentrated on strategizing around the whiteboard trying to find the next feature or product that will become a big hit. In reality such products are 1 in 10,000.
Try counting all revolutionary and trendsetting products that were created in the last 10 years. You might not reach 100. But there are so many problems and needs that users have now and need a solution for. Call them user pains. The best solution for understanding those pains is going out and talking to real users.
There are 2 types of user research — qualitative and quantitative.
Qualitative Research
In qualitative research, we analyze individual users trying to identify complex details of user pains that would otherwise be hidden for quantitative research. Here are 3 methods of qualitative user research
- User Testing
There are many services that allow product managers to test their products or assumptions on real users without meeting them in person. PMs define certain criteria for the user such as demographic or apps they need to be using and the platform finds such users to participate in the test. I use User Testing because of its large user base. The research process is the following:
You write a set of questions or tasks a user should answer or conduct.
Questions can be open-ended or with predefined options to choose from. In the case of mobile apps, you can also give certain tasks for the user to complete using your app and they will record the process on camera. Afterward, you analyze results and understand what frictions the users had while interacting with your product and which features they used with ease.
Survey Monkey is another great service that enables creating custom surveys and sending them to users. In this case, you can embed the survey inside the product flow and receive feedback from the users without the need for them to leave the app or website. For example, one can do a survey when a user cancels the subscription to the product in order to understand the reasons behind the cancellation.
2. Onsight interviews
While online user testing provides a look at real users' actions, there is no better way to empathize and understand users than meeting them in person. Such meetings are called user interviews. You can conduct them once a month by finding users that correspond to the criteria you need. Believe me, it is not that hard to find a user if you are building a consumer product. This can be students from universities or friends of employees or just random shoppers in the mall. Best interviews will take up to 30 mins. Sometimes you will only have 5.
In this process, your job is to listen and observe as much as possible. Users will start using your product and you will see all of the frustration and joy they have while using certain features and flows. This will not only help you identify problems and opportunities, but also give more emotional motivation and connection with your real users, motivating you to do the best for them.
3. Customer support and user reviews
Nearly any product has some flow where users can give their feedback. This can be Customer Support email or application reviews on the App Store. My rule of thumb is to treat 1 customer support complain email as 1000 because only 1 of 1000 would take their time to write an email. You should appreciate this investment from the users and constantly read their feedback. I have a habit of reading user reviews about my products several times a week. Besides, our customer support team analyzes tickets and reviews and prepares reports on top requested features and top problems.
Quantitative Research
While qualitative research helps you identify real users' needs and problems, it is not enough ground for prioritization. If you get 1000 user reviews a month and conduct 100 user interviews then in the scale of 1,000,000 monthly active users this feedback might only represent a minor segment or a niche. A Product Manager’s intuition grouped with qualitative research has big subjective matter in this and in order to bake these assumptions with more objective reasoning we need a scientific approach. Quantitative research focuses on analyzing user data and finding insights that would help understand and prioritize user needs and problems. Here are 3 methods of quantitative research
- Analytics
Tools like Facebook Analytics and Google Analytics enable you to track user actions through events that are fired whenever the user does a certain action, like Clicking Sign Up button or opening the Profile page. This data is then visualized through different methods like Funnels and Cohorts to dig deeper and find insights. The best part is that they are free tools and are very easy to integrate into your new or existing digital product.
2. Data Scientist
While analytics tools can give you answers to simpler questions like the number of users trying a feature or percentage of users who successfully complete a funnel, there is a number of complex questions that need deeper analysis. This is a Data Scientist’s job and if you have one in your team then it is great. For example, you can ask to find the top features that increase the probability of a user paying in a given period of time. In his article, a good friend of mine talks more on the topic of studying data science as a superpower for a product manager.
3. A/B testing
How can we measure the real impact of a new feature? Did it perform as we expected? Did it fail? Did it worsen the metrics? If we are not able to give answers to these questions, then we steer the product blindly.
Say you released a new feature in July and had DAU increase. What portion of it was due to the holiday season and what due to the new feature? Did the new feature even have any input in this increase? The only real way to find this out is A/B testing.
We give 50% of users the new feature and don’t give it to the other 50%. We then compare the metrics of these two segments to see how much the feature actually affects. A/B testing is also called split testing. It enables giving multiple variants of the product to equal-sized segments of users and comparing metrics for each segment. In my experience, 14 days is a good timeframe for simple design A/B tests. When doing them, one should be aware of doing 1 change at a time. If you do 2 changes in variant B, you will never know which change was positive and which negative. There is a number of tools for A/B testing in apps and websites ranging from free services like Google Firebase, up to more complex, paid ones like Apptimize.
#4 Your MVP is too cooked
MVP stands for a minimal viable product. What product managers often misunderstand is the meaning behind the word minimal. In many cases, a product is shipped with 5 features that work terribly buggy and is called an MVP. In reality, though, an MVP might have contained only 3 features that address the main user pain and worked more stable. It is way less embarrassing to ship an unfinished product fast and validate its need than to take time in polishing a product that nobody wants to use.
MVPs are designed to test assumptions about new products. If those assumptions are invalid, the product needs to be pivoted. This is one of the fundamentals Eric Ries describes in his book “The Lean Startup.”
Each new feature is an assumption from our side that might be false. In such a case, building a fully functional and polished product would be a big waste of time and energy. To minimize such a risk, product managers can find creative ways of shrinking the product scope to the bare minimum that would validate or invalidate the core assumption behind that product.
Lets do a case study. We have a video editing app and are thinking of adding a new feature that would remove the selected objects from the video and backfill the areas so that it looks like these objects were not originally in the video. Creating such a feature might be a great success story or a huge fail based on how big of a user need this solves. Such a feature would require AI algorithms that would work slow and make the app size bigger.
Bad MVP
- Create an AI algorithm that removes the selected object.
- Optimize an algorithm (a.k.a model) to be a smaller size and work fast. Being a research task, this might take 6 months or even more to complete.
- Release the feature once reached an optimal model size and speed to be run on most smartphones.
Good MVP
- Create an AI algorithm that removes the selected object.
- Host it on powerful servers.
- Whenever the user clicks to remove the object, upload the video to the server, remove the object and download it back. This might take some time but not as much as it would have taken for a non-optimized algorithm to run on a mobile device. Also, the app size isn’t affected as models are hosted on servers.
- In order to not overload servers with millions of requests, start with rolling out the feature to 10,000 users.
As we can see, Bad MVP would take 6 months or even more to execute and in case of failure, it would be a really big one. Team morale would shutter. In the case of Good MVP, it would take much less time to develop and would help to validate the assumptions the team had while designing it. In the case of successful validation, the research would continue until optimizations are enough to do the processing on the mobile device itself.
#5 MVP is not the final product
While point 4 focuses on testing assumptions and failing fast, we should not forget that a validated MVP needs to be developed into a polished and fully functional product. Many teams once released the MVP treat it as the final product and rush in creating a new feature. In such cases, after a while, the product becomes buggy and seems like a pile of unfinished features stitched together in an unorthodox manner. MVPs are mostly validated among early adopters that are eager to test new products because of pure enthusiasm. At a later stage, a more generic audience has higher expectations around the product quality and is less tolerant of bugs.
These were some of the learnings I had during my experience as a Product Manager. If you find them useful give this article a clap. Part 2 will be coming soon. Thanks for your time and keep learning!
