Tag: akash jain

(This passage is a summary of the conversation with Bharath Mohan. The audio transcript can be found here.)

Adopters of any new innovation or idea can be categorized as innovators (2.5%), early adopters (13.5%), early majority (34%), late majority (34%) and laggards (16%), based on a mathematical Bell curve put forth by Everett Rogers in his book titled “Diffusions of Innovations”. The book broadly suggests that if you have a product that is of value, you often times have to pave the path for the consumers to be the beneficiaries of this idea. It’s the product designer’s role to design how a product is used across the dispersion of users. This ultimately determines the principles of design and the features that your product consists of.

While I was doing my PhD in IISc, I worked on designing a myriad of algorithms for information retrieval. A typical internet user reads content that could range from currents events, such as the war in Syria, to topics as specific as Product Management. I’ve always dreamt of a system that can bring the most relevant information to a user – without the user searching for it. Pugmarks.me connects the context in which you are browsing through these articles by following the digital trails you leave behind. It then uses its context engine to recommend the next article it considers you should read packaged in a seamless experience.

Designing Pugmarks.me has been an exciting experience, which included research in algorithms, building a real time crawling and retrieval system, and constantly learning from users. We’ve followed some Mantras in our product development – especially because the product requires inputs from multi-disciplinary areas. Everything has to tie in, to each other. Nothing is known prior and has to be learnt along the way. A “product management” approach would not work. A “waterfall” model to design would not work. “Powerpoint presentations” would not work either. Our product management is less of “management”, and more of design and evolution.

The Pugmarks Mantra

Unlike Facebook or Twitter where the problem’s technology core is simple and scaling is complex, our problem’s technology core is complex akin to the likes of Google’s search engine and NEST. Hence, over the past 1.5 years our product has been opened to a smaller set of users which gives us data to refine the product further ultimately paving the path for a larger cross section of consumers to enjoy the benefits of the product.

Some of our Mantra’s are:

• Be metrics driven: Once we analyse our features metrics we identify ones that are successful and bolster them to make these our ‘super class’ features. While we do this, we bin our users into “Fans”, “Tried but dropped off”, “First day drop-offs”. The ‘tried but dropped off’ is where we focus our energy on. We do data analysis, interviews and direct emails – to understand why they drop off. What we learnt is that they mostly drop off because of the “inconvenience” of a new product; either added latency, extra memory consumption, instability of the browser, etc. These reasons give us new things to work on and improve.
• Usage versus Users: We are building our product with the goal that even if few users come to try out our product, they all stay back. Between usage and users, we prefer high usage between a small number of users over low usage in a high number of users. If our product cannot engage users for a long time, any amount of marketing will still not help.
• Focus on real Virality: Virality is often confused with just having a Facebook share or a Tweet button, or slyly making a user talk (spam) about your product in his social channels. Virality for us is the inherent quality in our product which makes the user want to talk about it. We consciously ask ourselves, “What will our users want to talk about Pugmarks to someone else?” These viral loops must be strengthened and not social share buttons.
• Constantly question your assumptions: In our initial iterations, we felt our users will be concerned over privacy. Soon, we realized that the paranoid would never use us anyway – even if we gave them a lot of control. The ones, who used us, felt we were not building good enough models for them. So, we moved away from user supervised learning to a completely automated learning system. We imagine our current user telling us, “I’ll tell you everything about me. Now help me in ways I’ve never seen before”.
• Continuous Integration: We never take up features or tasks that take more than two weeks to launch especially one’s which require a lot of people and require extensive build times and planning. If you finish the code and if it’s lying unused, there’s an opportunity cost lost because that code could very well engage a user or maybe incite him to talk about the product to someone else. This is a loss for us, hence, we continuously integrate.
• Own the full user experience, end to end – From messaging to user touch points to the backend algorithms: A user doesn’t appreciate information until it is delivered in a way that is useful to you and is needed by you. We obviously needed a team that was capable of building this experience end to end. Our team considers every aspect of the product, from the touch points to the user, how the product interfaces with the user and also how the product communicates with the user using the technology algorithm we created.

#PNHANGOUT is an on-going series where we talk to Product Managers from various companies to understand what drives them, the products they work on and the role they play in defining the products success.

If you have any feedback or questions that you would like answered in this series feel free to tweet to me: @akashj