It's another world under the microscope

It's amazing what one can discover under the microscope. Good friend and pathologist, Ochichis, often sends me amusing photos of oddly shaped red blood cells. Whether it's your eyes playing trickery or something else, you be the judge. 

Fascinating, non?

The first P of being a PM

The idea for this series of posts stemmed from a completely different discussion I had with a colleague on the differences between product management and program management. I won’t delve into that but what got my mind racing was me trying to introspect on a product manager’s role. After running through a whole host of responsibilities and attributes, I finally narrowed it down on Prioritization. I believe this is the first and foremost task a product manager has to be responsible for. I did cover this briefly in my introductory post of my first month as a Product Manager. 

Why is prioritization important?
As a product manager, you are measured against metrics related to your user’s goals. These metrics could range from Gross Margin Value (GMV) to Average Order Value (AOV) to Engagement (DAUs, Cohorts) and so on. There is absolutely no room for anything else if your features/releases aren’t impacting the metrics the most. It’s the holy grail. Intercom published a really informative read on prioritization. They subscribe to a model called the RICE framework — Reach, Impact, Confidence and Effort. Each of these parameters are scored and the overall RICE score determines the priority of a feature. Honestly, it cannot get simpler than this. But I personally also like to leave some room for judgement and intuition as well. What follows from prioritization is the product roadmap. 

Roadmap vs Ad hoc Requests
A product roadmap is created after you are done prioritizing tasks and features/releases. Depending on the stage of your company, you may have a roadmap for a quarter, a year or possibly even more than that. I’ve only worked for small to medium sized startups so my product roadmaps haven’t gone beyond 6 months. I believe that once you’ve gotten the items in your roadmap prioritized, half your job is done. But wait…

…and just when you’re mid-way feeling good about your roadmap going on as planned, someone from the marketing team makes a feature-request. Someone from Finance asks for alterations in certain dashboards. Long story short, it’s a balancing act between handling ad hoc requests and ensuring you’re still on course with the roadmap. On receiving an ad hoc request, I ask myself (and the stakeholder) these high-level questions:

  1. What is the impact on my user and the aforementioned metrics?

  2. Can I measure this impact? Short term gain or long term gain?

  3. How much of a pain point is it to the stakeholder/user?

  4. Can I quantify or measure the pain point or criticality of #3?

  5. Can it be resolved or shipped with a complementary feature which is already in the product roadmap?

  6. What is the effort (quantified by time) involved?

There are more questions but I’ll stick to the above six. Based on these, I take a hard call on whether to pursue ad hoc requests at that time or post-pone working on it or shoot it down all together. 

What certainly helps is organizing your engineering team into developers who can work on long term features and shorter term features separately. I have seen this through experience as I’ve faced resource crunch working with small teams of about 5–6 developers. I may have groups of 2 or 3 developers working on the big ticket items which typically have a development effort of more than 1-2 weeks. On the side, I will reserve one developer who will work on relatively smaller features (development effort of ~3 days or less). If you can draw up a mental picture of a Gantt chart, you will realize that I am constantly shipping small features and/or bug fixes on a regular basis without having the major chunk of my roadmap affected. In light of this segregation of resource, I would then assign the ad hoc requests (post scrutinizing on whether to take them up, of course) to the developer working on short term features. In the worst case scenario, I would be able to get to those ad-hoc requests in a few days. There you have it, my approach on handling a roadmap with ad hoc requests. (Vincent’s secret sauce much?)

Dealing with stake-holders
By nature of the PM role, you will be dealing with multiple stakeholders and inevitably, everyone wants their requests as soon as possible. To be specific, I’m talking about internal stakeholders of the company such as marketing, finance, sales, operations and others. Prioritization becomes important more than any where else. As I had described earlier, there will be times you have to shoot down proposals or feature requests by nature of failing the ad hoc test. I wish there was a surefire way of coming out with a win-win outcome. It’s subjective and depends on the context of the discussion. I have learnt though, that being empathetic with your fellow peers is a step in the right direction. Back up your reasons with data, guesstimates or strong hypothesis to ensure that your stance defensible. Without these, it’s all about people management skills. On the flip side, do take into account that these stakeholders are equally important to you and the success of your product roadmap. One such example would be at the time of product launch, you’d have to coordinate with the sales and marketing teams to conduct demos with customers/sales representatives. I guess you get my drift, right? Product managers need to develop people skills to handle such situations. 

If there was a punk rock song about product management, it would be ‘Prioritization Über Alles which translates to ‘prioritization above everything else’. It determines the success or failure of your product. 

Stay tune for the next post — The second P of being a PM.

Traction: A Startup Guide to Getting Customers

It's book review time. Since its release, Traction has become a fairly popular book, often recommended to start-up founders, aspiring entrepreneurs and anyone who is keen on growing a business exponentially. After having spent a significant time in early-stage ventures, I decided to give this book a shot to see if it resonated strongly with me. 

Traction starts off by emphasizing greatly on a method they call the 'Bullseye Framework'. True to its name, it is a process which involves narrowing down on that ONE channel which will give you the most traction initially. This may seem very intuitive but you'll be surprised how many companies get that wrong. In summary, the 'Bullseye Framework' requires you to brainstorm on all possible traction channels, rank them on the basis of potential, run quick tests for hypothesis testing and then finally focus on that identified channel.  As you progress through the book, you'll realize how central this process is for companies (as shown in the examples) in identifying their first channel.

With that as the crux of the book, the authors go on by enlisting 19 different traction channels that have worked for companies across industries. There is a dedicated chapter to each of those 19 traction channels. Some of the obvious traction channels mentioned are SEM, SEO, Display ads and Public Relations. Some of the not-so-obvious traction channels listed in the book are Engineering as Marketing, Community building and Viral Marketing (yup!). Each of those chapters outline the how-to, benefits and impact of the said traction channel. What adds further value are real world examples. One such example is about Mint, a website which helps users with managing finances. On starting up, the company had a goal of signing up 100,000 users in 6 months. By following the Bullseye Framework, Mint realized they could target personal blogs as their first traction channel. This led to 20,000 users signing up even before the official launch of their full-fledged product. Crazy, right? Once the company realized they were exhausting blogs and weren't seeing a spike in growth, they resorted to Public Relations as a channel. This eventually led the company to signing up 1 million users during their first 6 months. 

What I love about this book is that it appeals to both the layman as well as the seasoned marketer. Unlike many "management" books, Traction does not faff about. There's no jargon, no worldly business advice, no bullshit. The book stresses upon a simple framework, emphasizes on hustling hard by rigorously testing traction channels and repeating the process in case of failure. The book also talks about the importance of dividing your time between traction and product development.

Traction is a short read but I can see myself getting back to it whenever I have to ponder upon any of the traction channels mentioned here. If it were up to me, I'd prescribe this book as essential reading for all business school students because this is as real as it gets.

You can buy the book here.

Hairklutz (#tbt)

I find haircuts liberating. On the occasion of having a haircut today and it being #throwbackthursday, I thought I should revive this old blog post (circa December 2008) of mine. In this, I express an interest in going bald and wrote about a barber who refused to cut my hair short. Pretty random, yes. I'm also not correcting some obviously glaring typos that I now see. Read on. 


Brimming with new found enthusiasm, I dashed off to a nearby salon. I had revived the long lost feeling of wanting to go bald. This feeling first overcame my rational-thinking about two years back. It was more about succumbing to peer pressure at that time because a couple of my close friends and I had made a pact to remove every strand of hair from our heads. What became of that pact? Well I chickened out. I had to, for I realized I actually had a lot going on and I just couldn’t let some foolish pact destroy me. Until that point of time, I was maintaining an untarnished reputation of a (deceptively) simple bloke; I was interning at a reputed company and something like a shiny bald head had the potential to raise eyebrows and who knows it could’ve well caused a furore in that conservative environment.

This time it was different. I couldn’t care less. I know I won’t be subjected to a before-and-after scrutiny by any acquaintance of mine, because quite frankly I know no one here. On that positive note and with a brimful cup of enthusiasm, I dashed off to a nearby salon.

I found the barber in a pensive mood. He probably hadn’t had a customer all day. With the ol’ wave-of-the-hand-in-front-of-the-face, I got his attention and the cutting of hair got underway. As opposed to how the biblical Samson felt about haircuts, I’ve always felt it was in a way, metaphorically speaking, self liberating as it injected new life into me while getting rid of excess baggage. This time though, I was going for full self-liberation!

I directed the barber to use the machine and shave off everything. Paying little attention to what I had said, he flexed his fingers and crackled his wrist joints and finally spoke, “It won’t look good on you, sir”. “But this is how I want it”, I demanded. Again, casually chewing his paan he proceeded to trim the sides of my head without paying any heed to what I had to say. I was flummoxed. My calm disposition prevented me from leaving the place promptly and I somehow consoled myself with the thoughts of telling him to trim it all off when he’d reach the top of my head.

The scissors slowly meandered around my head, cut a micrometer of hair with each stroke and paused. The barber would then take a moment to analyze his work and with an artistic gleam in his eye, he’d proceed to slash another couple of micrometers. What Monsieur Van Gogh (ha!) didn’t realize was that he spent close to twenty-five minutes only on the sides of my head. Maybe it was his intention to do so while slowly and tastefully culminating to the top or maybe he was just bored. That seems perfectly fine if you are a, dare I say, connoisseur and an appreciator of fine (hair-)art. I’m not and my plans of getting a brisk haircut were thwarted by this fool of a person. I had to put a stop to this madness. “The sides are quite short…that’s fine. Now cut the top as short as you’ve cut the sides.” That sure told him right?! He nodded in agreement but the moment I mentioned, “…use the machine”, he was taken aback and disapprovingly said, “It’ll be very short. It won’t look good. I’ll use the kenchi and give you a nice slope-cut”. At this point of time, I was convinced that he wasn’t going to be able to do what I asked. I gave up point blank and ended up getting just another haircut. I could smell victory in his faint humming. Bastard.

Somehow I can’t get over the barber’s unwillingness to use the machine and do as I wanted. Maybe it’s just me, but I suspect that he actually enjoys his job and that a machine-shave would probably have just destroyed the simple joys of doing everything by hand. He even took his own sweet time and I can only guess that he was savoring each stroke and each blissful sound of the ‘kenchi’ going ‘ka-chissh’.

Who knew that a stupid tale like this would have certain undertones suggesting something so essential in today’s world like job satisfaction?  Silly as it is, it’s made me realize that following the herd and landing up with something average is a big NO for me. So if you’ll please excuse me, I’ll go brainstorm my plans for 2009.

My first month as a Product Manager

This post has been long overdue. I had been wanting to write about my experiences during my first month as a product manager but alas, it has already been close to four months now. That said, I refuse to change the title of this post because 'My first four months as a product manager' has lower search volumes on Google, so boo! On a serious note though, I am quite enjoying this new role.

Here's a little background on how this came about. In the recent past, I've been enamored by product managers steering products from conception to shipping their final avatars. Yay, boat puns. Let's cruise along shall we? I was envious of the, for lack of a better word, complete ownership they possessed over products. Product managers are mini-CEOs in a way. Also, if you've spent enough time on Medium, you cannot escape reading an article that isn't remotely product-centric. That further fueled my curiosity to learn more about this specific function. Apart from that, I have been an ardent follower of certain non-traditional product guys like Justin Jackson and Pieter Levels. They are independent product makers and they're prolific to say the least. It amazes me how they get things done efficiently. Please follow them on Twitter, you won't regret it. Anyway, sometime in February this year, I was asked by my CEO if I would like to work in product management (since he knew where my interests were). I latched onto this opportunity instantly and the rest is history. 

Four months down the line and all I have to say is that this journey has given me immense learning and it's been both challenging and rewarding. I'll try to give my own perspective on this by listing down some of my key takeaways and observations below. 

Business Impact & Prioritization
Every function in a company needs to impact the business positively. That's pretty obvious, yeah? But in the wake of prioritizing various aspects of building a product or prioritizing development efforts on different products, that's where things can get tricky! This dilemma can be solved easily by asking yourself few simple questions like "What value does this create for the user?" or "How does this feature/product translate to revenue directly or indirectly?" Before you call me out on being a capitalist, let me clarify. Say you introduce a feature which improves customer experience, it could directly lead to higher NPS scores (feedback scores), increase in number of active users (DAUs, WAUs, MAUs), positive word of mouth and many other such things. All these eventually could translate to cross-selling (if your business has that), repeat purchases and customer referrals, in turn contributing to your top line. On the flip side, it goes without saying that bad product decisions can be disastrous, leading to resource wastage, losing time and the opportunity cost of building something else. While I'm only scratching the surface of how a small product decision can have a butterfly effect in a business, it is imperative that there's enough thought put in to prioritization of tasks. At the same time, product managers are also required to make impromptu decisions while juggling resource utilization, stakeholders' expectations, managing detours in plans, staying the course with earlier commitments...oh the list is endless. This role will probably bring out the best in you as a manager. 

Speak To Your Customers / Stakeholders Regularly
I would actually rate this as the first point because everything revolves around your customer or stakeholder. Instead of elaborating further, I'll pose a few questions. Who are your building your app/website/software for? What problems are you solving for your users? Who is your core audience? What are their behavioral patterns? Do behavioral patterns differ across the spectrum? Can you segment your users into different user-personas (a popular technique)? Have you tested your beta-product with your users? What feedback have you gotten from them? Can you predict what users would like in your product? Users may not be proactive in providing feedback. More often than not, feedback is synonymous with negativity. To get to the point, a product manager must talk to users regularly. You need to know what works and what doesn't work. That is the only way you'll get an inkling on what to prioritize and build. 

Read Constantly
Product management is as much about being technically sound as it is about being creative and knowledgeable. The only way to ensure that you are on top of the latest trends, product-related news, principles, methodologies, new technological advancements and more is to read constantly. To get a primer on product management, I started off by reading Lean Product Playbook by Dan Olsen. There is no dearth of material on the interwebs on these topics. Personally, I like my information consumed blog by blog. Among the many blogs and newsletters that I follow, I have found Intercom's and Invision's to be great resources. Their blogs are fantastic and cover a lot of ground on product, startups, design and customer success. For everything else, follow ProductHunt - a brilliant resource that showcases new products, podcasts and articles. 

Tools, Tools, Tools!
One of the perks of being a Product Manager is that you get to immerse yourself in other people's products. These could be tools on analytics, heat-maps, customer support, roadmaps, productivity, bug-tracking, wire-framing, design and so on. You gain a certain appreciation on how these have been built. If there's one tool that I adore the most, it's Balsamiq. I feel it's the perfect tool for creating wireframes and low-fidelity prototypes for your ideas. The flexibility that Balsamiq gives you will make you forget drawing rough mockups with pen and paper. You can flesh out your product concepts and create navigation flows with ease. In this way, you save a lot of time by creating mockups quickly, getting feedback on the same, making any necessary revisions and eventually getting high-fidelity prototypes out for the development to commence. Using the right tool that one is comfortable with and one that gets the job done is important. Here's a pretty cool resource which lists some pretty nifty tools that product managers would find useful. Czech it out here - http://softwareproductmanagement.co/

There's this really popular post on Quora which talks about 'What distinguishes a top 1% product manager from the top 10% product managers'. You have the who's who in product-management give their two cents on this topic. I reckon it's a really good read and I recommend you to check it out. There are times when I go back to that post myself, to have a self-assessment of sorts because every time I re-read those Quora responses, I'll find something new that I can improve myself on or do differently. I'm sure it'll resonate with anyone who's just venturing out into a product management role. On a personal front, it's still early days for me but I feel I'm confident of landing up somewhere around the top 5-10% product managers in the coming months. There's plenty more that I'd like to talk about but I'll reserve that for a follow up post on my progress. So until next time, let this popular Venn diagram percolate your senses till you attain product manager zen. 

what_is_a_product_manager.png