The 2nd and 3rd Ps of being a PM

I guess I’m ultimately calling this the 3Ps of being a PM. Very Kotler. Much jargon. In the off chance that you missed the first post where I talk about Prioritization being the first and foremost attribute of a product manager, you can read it here. 

At the outset, a product manager is required to have a very good understanding of the market, competition, business models, future trends apart from knowing the user thoroughly. The insights gained from the above and channelized into better decision making is what, I reckon, constitutes the second important P of being a product manager — Pulse. 

I may be oversimplifying it but with my limited experience and reading about product failures and successes, it is very important for the product manager to have her ears close to the ground. This enables you to not only understand the environment in which your product is being used/consumed but it also helps you predict/anticipate for the foreseeable future to a certain degree. 

  • Getting a pulse of your customers’ problems, needs, aspirations, behavior helps you build better products. Clearly, a no-brainer.

  • Getting a pulse of your competition helps you identify your competitive advantage. Go a step further and talk to your competitor’s customers. It helps you beyond the realm of product management, say if, Company X is kick ass at marketing. Can those serve as inputs to your internal stakeholders? Or can there be possible synergies that can be explored to benefit you and the competitor?

  • Getting a pulse on trends helps you build better products. Trends would encompass everything from market/economy to consumer/behavioral to technology. How would you incorporate these trends to make your product better?

  • Acting on impulse helps you build products effectively and efficiently. Here’s a really neat graph published by Hacker Noon which hits the spot about what I’m trying to get at. This point transcends the scientific aspect of being a product manager and makes it seem like product management is also an art form. Unfortunately, this can be learnt only through experience, but here’s a heads up nonetheless.

All in all, pulse, is a very fluffy word to describe what I just wrote but I believe the best product managers have this as an unsaid trait. It comes naturally to the curious and the ambitious. Personally, I’ve been trying to better myself at getting a pulse of the aforementioned things. I try to read more, I listen to relevant podcasts and I avoid any blinders restricting my vision lest I miss out on anything. 

So…great, you’ve nailed your product-market fit, you’ve validated your ideas, you’ve prioritized your backlog…what next? 

The third important P of being a product manager is Project Execution. Notice, how I don’t say project management. How a product manager brings design and technology together is what constitutes execution to me. Project execution would certainly vary from company to company. In more established companies like an Amazon or Facebook, a product manager isn’t alone in execution. One works with technical product managers, program managers, engineering managers, tech/dev leads and so on. But if you’re in a seed-funded or series A funded startup, product managers end up playing a larger role in execution. The scope of responsibilities vary, but I’m going to talk from my own personal experience. 

  • People — The success of project execution solely depends on your team. It is important for the entire team (designers, engineers, QA testers) to be on the same page. But hey, you’re a product manager. You have no authority over everyone else. This is where as a product manager, you need to play your ‘people skills’ cards well. I strongly believing that motivating the team before and after the project, irrespective of the size of the release, is key to having the team stick together. You show them impact, the potential of a product they’re building and how important each of their contributions are. A product manager must in no way take credit away from the team, after all they’re doing all the heavy lifting. Sure, you “conceptualized” the idea but make no mistake about it — your team will lose faith in you.

  • Timelines — You will need to approximate timelines pre-development while sprint planning. You will need to get finer timelines from design and development. You will need to give out timelines with additional buffer, wherever necessary, to your stakeholders. Timelines are sacrosanct. There will definitely be times where you don’t meet these deadlines but it’s crucial to inform your stakeholders about any delay and possible alternative timelines.

  • Development — If you’re a non-technical product manager, you would be solely reliant on your engineer leads or senior engineers. Invariably, engineers do come back to product managers with doubts, cases missed, cases where they’re block. It’s your role as a product manager to ensure that any doubts/blockers are swiftly resolved. You gain the respect of an engineer if you clear her blockers promptly.

  • Testing — One of my strengths as a product manager is that I’m very hands-on with my product during development and testing. The more rigorous the testing, the fewer chances of your product failing in the user’s hands. Once the engineer(s) hand over the product to the QA team for testing, I step in between to do a pre-UAT (user acceptance test) where I try to ensure that the product is behaving as it should for the users’ major cases. I say ‘major cases’ because you are generally constrained for time. The pre-UAT testing phase significantly reduces the back-and-forth exchanges between QA and engineers. Once the QA team gives a sign off on product testing, I usually perform a UAT thoroughly to ensure that the product is ready to be shipped.

  • Shipping — Here you have it, your feature/product moved from a staging test bed to your production servers. I prefer to ship out new releases on Tuesday, Wednesday, Thursdays or when the next day is not a holiday. That’s because in the slightest chance that there is a bug, you have the team available to quickly re-ship a bug-free version as soon as possible.

  • Post-shipping — Is a product manager’s job done after shipping? Hell no. Sure you may have dusted your hands and got that awesome product released. While this doesn’t fall under the purview of ‘execution’, how else will you measure how successful it is? Are your users using the product as intended? Whether it’s a beta release or a full fledged roll-out, it is essential to choose the right metrics and have those metrics closely monitored either via data pulled from the database or analytics tools like Google Analytics or Mixpanel. A topic like measuring success metrics would require its own blog post.

So there we have it — Pulse and Project Execution, the two remaining Ps in what makes my three essential Ps of being a product manager. While I can’t cover everything with this 3Ps post because, let’s face it, product management is a fluid field, part science and part art. 

I would love any feedback on this post. Do write in at me@vcent.in if you would like to talk further about product management. 

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.