How to let your User guide your Product Roadmap
I am one of the co-founders at Pratilipi. In the beginning, I looked after language operations and then shifted my roles to whatever the company needed at the time. I did stints in Design, Marketing, Partnerships, and New Initiatives. About 18 months back, I shifted to Product Management, a role I knew little about.
Yesterday, I gave my first public talk (thanks to Hellomeets team) on my learning and observation about product management, with a specific focus on user-guided product management. I am trying to provide a summary of the talk below.
For me, Product Management is about figuring out answers for a bunch of hypothetical questions. And most importantly, finding the right trade-off to prioritize them against the user impact and resources in hand. The problem statements could be an outcome of data analysis, your intuition, business requirements, or it could even come in the form of inspiration from the competition. But amidst all this, sitting in front of screens, what users are looking for we often miss. I believe that if we are the users of our product or listen to our users regularly and sincerely, building the right product gets 10x simpler. Data alone doesn’t work as well.
When we keep listening to our users, we gradually start developing a habit or intuition to come up with the thesis which resonates with their pain points. A thesis or a problem statement derived like this, may not have a natural or obvious solution. Understandably, many product managers try to avoid this approach because of the lack of enough existing data to support such a thesis, and hence, the risk may seem much higher. These PMs would instead prefer a data-based thesis to take probabilistic bets and try to connect the dots looking backward.
I was one of these PMs when I started my product stint.
However, it is a process of continuous learning. While data is crucial, the best way to have long term sustainable growth is to let your users guide your product roadmap.
My first task as a Product Manager was to explore ‘newsletter’ as a growth channel. In Pratilipi’s context, a newsletter is a collection of personalized stories for readers. Initial pilot testing was a success, and we had to scale it to the entire registered user base. It was great learning by all means. We started with figuring out the right third party email service providers and then later on iterated over what to send, when to send, how to send while keeping a constant check on spamming. Next couple of days, we worked on various small features and a bunch of A/Bs — real quick, to move some funnels to improvise engagement metrics. In a nutshell, we were working on low hanging fruits but nothing that really moved the needle.
Meanwhile talking to users, we saw a gap in the way things were organically happening on the platform. Pratilipi being a storytelling UGC platform, we see varieties of content getting created on the platform daily. In this pool of contents, we saw a pattern emerging out.
A small but quickly growing number of stories published were in the form of an episodic story. Writers would publish these individual episodes, wait for their readers to give feedback, and would publish the next chapter. Around the same time, while talking to readers, we came across an apparent lack of discovery for the next/previous episodes. Also, these random episodes started surfacing in recommendation across the platform.
It was evident that our users needed something better for writing and reading episodic stories. Any right solution to this would include a substantial system design change. And being a new Product Manager, I had my fair share of doubts about its impact as there wasn’t enough data to support.
My intuition was that the cliffhanger triggers in episodic stories might bring the readers back on the platform to know what happened next. While writers will share a tight feedback loop and hence will publish more frequently. Aside, I was also confident that this would strengthen the reader-writer bond due as the readers will feel like they are part of the creation process. The only uncertainty in my mind was will this behavior scale to move the topline metrics, particularly given the amount of time we will spend building it. Which also meant that I have to figure out a way to keep the team (and myself) motivated for a long time.
We decided to build and launch this in a phased manner. It was essential to keep everyone aligned with the objective and validate our thesis. And hence, the first phase was to build a hacky solution to connect the next chapter in the sequence and launched it first on the web and then on App. The result gave us an idea about its usage and potential. The hacky fix improved an overall Avg session duration for non-logged in users by 12.5% and for logged-in users by 22%. With this clarity, now the team was convicted of building this feature end to end.
Unlike general problem statements, this one was both product + engineering heavy in nature. We broke down the entire feature in three phases. 1. discovery of episodic stories across the platform 2. UX of the episodic story 3. publishing of episodic stories. To build this end to end, we needed the worst of critics to help us understand what could go wrong. As if it works out, then it might impact the established behavior of reading and writing on the platform at scale. I consider myself lucky to get a chance to work with a brilliant team where people shared complementary skills. Developers and a product designer started working on the solution day and night. And after a couple of missed timelines, we launched it on App. :)
I have worked on many new features and many more optimizations where the data was more precise and the ROI more obvious. But I have never worked on anything that moved the needed as much as this did. While attribution to a specific product feature is hard, we have seen both the creation and consumption of stories grow exponentially.
Over 21,000 new episodic stories are created in the last two months alone, and these stories are read over 160 million times! Average read of an episode is over 2X of average read of any other form of content published on Pratilipi, resulting in over 60% reads/user and 13% additional time spent reading on the platform.
To summarize, I am not saying that we shouldn’t focus on data. I am emphasizing to focus more on users and*really* listen to them. They will teach us, they will guide us, and they will make the product more successful.
