Friday, August 7, 2020

Product Thinking: Be a Problemist!

People don't buy a Rolex watch to manage their time better. 

What else is a watch supposed to do? In this case, clearly, it's solving a very different kind of problem. Knowing what kind of problem you are solving for your customer, or through your product (whichever comes more naturally to you) unveils the way to a more effective product roadmap. Painkillers, Vitamins, and Candies all make million-dollar businesses - only if you know what you are creating and market it that way. If you positon a painkiller like a vitamin it won't sell. If you position a vitamin as a painkiller, you might get sued. 

Product Management is all about finding real problems of real users who are really looking for solutions. So, in this post, I've tried articulating a framework of doing a problem analysis instead of thinking of a solution. I have extensively talked about this framework in my talks and workshops and it works wonderfully well for a lot of people.  

Remember that the problems set is a subset of the user's Needs and Want

As a PM, you should be spending significant time in exploring the details and finding the root cause of those problems. In fact, while I just defined this for PMs, this is completely true for all startup founders. You must be solving for a pertinent problem of your existing/prospective user base. 

I am not suggesting that you are not responsible for solutions. I am saying that solution is not what you should worry about until the problem is well understood. Solutions will either be obvious or will reduce down to some logical or mathematical problem once you've done a good job of analyzing the problem. 

FAQ: What if I am not really solving a problem? 

Feel free to call your work an Art. 

Harsh? Truth. 

If you aren't solving someone's problem, you've no reason to believe they'd pay you. Even in most narrow context - if your shiny new feature or design or CSS change is not going to solve a real pain point of the user, you are putting money down the drain. Btw, if you think that Facebook, Tiktok, and Netflix of the world aren't solving a real problem, think again. 

FAQ: What if it's a value add (versus solution to a problem)? 

Well, if you aren't concerned about clear ROI, then anything is fine. Typically the "Value add" products/features make a limited impact for a small set of users, mostly for a limited time. A harsh truth, again. But, if that's what it is, accept it and you'd still do well. There are other problems as highlighted in the illustration below.  

Now that we've seen some deep dive into why focusing on "Problem" is critical let's see how we can deal with it. It looks like a step by step process, but it will quickly become a mental model once after trying some steps for some of the real situations you come across. 


1. Define the problem

Recently a startup founder was seeking mentoring and he pitched to me a digital business card organizer and I asked him what is the problem he is solving. He started talking about the solution. I stopped him and asked what exactly is the problem he was solving. This time he described it well - the problem he was trying to solve was that people miss out on their network because their network is not well organized. And then, at the earliest opportunity, he switched back to describing the solution again. He wasn't convinced that I am NOT his customer. He kept asking me to imagine situations I have never gotten in to and use cases I've never had. 

If you enjoyed the story this far, let me tell you that this is true for roughly 6 of the 10 founders I meet or half the PMs I've interviewed. A problem defined as a solution is not the right problem to solve.  

It's hard, really hard, to define problems while completely ignoring the solution. But, every effort in the right direction helps. 

If you have a feature idea or a solution ask what problem is it suppose to solve? Whose problem it actually is? 
Ask who's the "ideal" customer? and if the answer sounds like "Everyone", it is very likely a wrong answer.  

Quick check: In most cases, if you've defined the problem such that there is only one obvious solution, your definition needs improvement. Problems are usually multi-causal and can be solved in many different ways. 

2. Categorize the problem

This applies to any product and any startup. If you are going to remember any piece from this big essay, then remember just this part. Categorizing a problem gives you the approach to solve it, but more important than that, it also tells you whether you should be solving this problem right now or park it for later. If you have been a product manager long enough, you'd have heard about "Ruthless Prioritisation". This is where it happens. 

You need to categorize the problem into one of the following categories. 

Latent - User has a problem but the user doesn't even know they have a problem. How's that possible you think? Well, people didn't know they need to brush their teeth twice a day just 70 years ago. They didn't know in India they need a RO (water purifier) 20 years ago. Like they don't know they need an air purifier in 2020, wait for the next 5-6 years and see how it becomes a 'need'. A lot of things from personal undiscovered health ailments (mental disorder, diabetes) to your vehicle-is-eating-more-fuel-than-required to global climate change fall under the latent problems. People at large don't know they have this problem and if you are going to create a solution for that problem, they wouldn't buy it. 

You'd need persistent educational/marketing efforts, for years, to turn a latent need into a want.    

Passive - Users know they have a problem but they are not interested in solving it. This seems worse than the latent problem, but it is not. Now that the user already knows they have a problem, you have a higher chance of converting them sooner. But if the user is not solving for it yet, you know that the problem is not big enough for them yet. Insurance, Anti-virus, Inbox-zero, Cybersecurity products, Pay later, Accessories like a Health band typically fall under this category. 

Bundling your product with something people buy more frequently works great for products in this category. Also sells well if it is part of a new 'trend'.   

Active - Users know they have a problem and are actively looking for a solution. However, it's not a burning issue. It's a leaky tap and not a pipe burst. So they'd think more, they'd tend to care a lot about the cost, quality(UI/Feedback/Rating), their processes, competitive analysis, etc. The sales cycles are long and you need to keep retargeting your ads to the prospective leads. A book-keeping saas for SMB, a Math tuition app for a 10 yo, a Compliance/Auditing tool for Finance Department, an advanced SEO optimizer are some products that typically fall under this category.

Active follow-ups, retargeting ads, discounts, more value-add offer work for these products.      

Urgent - User's ass is on fire and they know it. If you are making a product that she needs, and wants and is a burning problem for her, just make sure you're there at the right time to take the money. In most cases the big urgent problems of the market are solved already, so you might find a lot of comparable competition. If you don't have the distribution, being 10x better is the key. Lending products, Travel booking, Communication apps, etc. fall under this category.     

Perceived - These are imaginary problems. They do not exist, but like ghosts, some people are convinced of their existence. Solution - VooDoo. It's more about communication, presenting facts, building relationships, tweaking the UI, changing the error message, standing on one leg, or whatever it takes to change their false perception. Could be some placebo or add-ons in the product, but most of the time, solutions will lie outside of the product. Imaginary problems need imaginative solutions.  

A few things to note:

1. Markets are dynamic - people and their problems, their needs, and their want are changing. So, while you start with a latent problem it "may" become urgent in a few years. 
2. Things like a global pandemic or demonetization can turn the situation VERY quickly. The same problems can go from latent to urgent almost overnight. Of course, you can't bet on these black swans. 

3. Reframe the problem 

Here's a brilliant article that discusses reframing problems at length. It gives examples of how a slow elevator problem can actually be reframed as "wait time is boring" and can be solved by installing a mirror in the elevator. How a dog adoption problem in the US was actually a poverty problem. 

The existing framing may not necessarily be wrong, this step is more about finding a better problem to solve. 

Here's some fun from Reddit, that says adding a faster spinner solved the perceived problem of a slow website. 


Here are a few quick questions that you can try to answer, wrt the problem at hand. Particularly, for a feature ask it can help reframe the problem:
  • Is it an incentive problem? - They have no reason to do the right thing. If I can guide the delivery boy who speaks the local language, I have no incentive to learn how to locate the delivery address on the map correctly. 
  • An expectations problem? - They didn't expect they'd need to do this. They didn't expect to fill a long-form. Where is all the artificial intelligence?
  • An attitude problem? - They just don't want to do this (no good reason). Inertia is real, no one wants to change their behavior. 
  • Perception problem? - New things have historically never worked, so they don't want to try. 
  • Misinformation problem? - They are convinced, other similar products behave differently. Victims of competition's sales pitch or content marketing. Other products have that one feature and are obviously faster/cheaper/simpler. 
  • Is the problem stemming from another solution? - Some other feature/constraint in your product makes them believe that the new problem has to have a similar solution. 
A solution can lead to a new problem

I wanted to drop some hints on how to solve each of these problems, but the post is about being a problemist. Trust me, focus on reframing the problem, and the solution will appear. 

4. Measure the problem 

How many users are affected?
It's ok to start by asking around, estimating, back-of-the-envelope calculation so that you can take a quick call on how to proceed further. If your product is instrumented, you should be able to find an actual number of users facing this problem. Even if the product is not instrumented, if there are active users, you should be able to dig data and find some number. If it's a new product just take guess whether this will be useful for 80% users or 20% of them. Important is to have a number and make sure it is written down in the documentation you do - PRD/Jira ticket/Whatever.  

How much are those users affected?
Can the impact be quantified? How much cost or time or life does it save for the users? 

Another good proxy is self-discoverability. How likely is the user to discover the change/feature by themselves and use it? If it is very likely, then we are talking about high impact.

5. Ignore their solution

The #1 reason why people have to change their roadmap too often is because they base it what customer asks them to build. And when they go to the next customer, they'd ask something else. 

It's hard to be blunt to the customer or ignore their solution and ask them more about the problem. In their mind, it is already fixed by the solution they suggested. So listen to them first. Paraphrase and in your narration, you may induce items from your curiosity that forces them to think as well. Then ask questions and do a deeper analysis of their problem - need - want. 

If you leave it to them, they'd color the Taj. 

However, reaching a granular level is secondary. I see most people struggle to even rephrase the user need/problem as a "problem" instead of jumping to the solution. Recently, I spoke to a stakeholder that works closely with the customer and asked him about the customer's pain. He described that customer wants an attendance management system for their drivers. I asked him what is the "problem" they are trying to solve? He reiterated, that the client needs an attendance management system. He was partially surprised, what about a simple "attendance management" bit I could not be getting. Another stakeholder suggested that we have tried some basic solutions in the past and no one uses it. So now the problem apparently is to create an "attendance management system" that is "usable". I spoke to the customer directly. 

Hint - A problem defined in terms of a solution is a wrong problem to solve. 

Here's more detail, "The customer was unable to track the presence of the driver within the campus for the prescribed duty hours, because of which they are unable to decide on prorating the remuneration for the driver. The client estimates that this leads to delays in payments and even overpayments of about 10%. As of now, the client depends on manual records and driver's trip records. There could be exceptions, in which case, the driver may not be working but still getting paid for the day." 

When I dived deeper into conversation with the customer I found that in most cases where they might make a mistake of capturing fewer trips for a driver, the driver will reach out to provide enough evidence and get it sorted. However, if they are paying extra - no one complains.  

So, as I spoke to the customer, I found that there is just one distinct problem. The question customer struggles to answer every month is "Am I overpaying?"

All I wanted to know was that the client fears he is overpaying. That's the REAL problem that needs to be solved. 

My solution, a simple report that lists all the drivers who should not be paid the full package. I had everything I needed to create the report so the effort was about 20x smaller than creating a new system. The turn around time was quick and the solution was sufficient to solve the problem. 

So, the quick mantra is just to ignore their solution. Follow all the earlier steps and figure a solution from the ground up. It will be fun and will save a lot of time and money, more importantly, the disappointment of creating something that no one ends up using. 

6. Devise your solution

Finally, now that you've earned a doctorate on the problem, the solution would be clear. More than the solution the problem analysis gives you a clue about how to approach the solution in the right way. How to drag the solution so that it lies somewhere in the problem-need-want area. Many times, you would realize that the problem is not alone, it is a bunch. And there could be more than one solution to solve it. A lot has been written on prioritizing the different solutions and building them so I'd skip that part. However, here are some useful tips for the solutioning process.
- Document it - Write it down. What if you die tomorrow? Leave the world a better place. Make sure you define the problem analysis in the document (at least briefly). Begin your documentation with a problem analysis - whether it is a PRD or quick Jira ticket or handwritten note. It's not an afterthought, just begin with it. 

- Prototype it - Big change? Always prototype it with a hi-res flowing prototype. Notice how the first prototype and the third one are shockingly different. 

 - MVP it - If you have a risky assumption about the problem or the client or the solution - do an MVP. Test your assumption. There is a lot written on MVP so I'd not repeat it. Just remember this that if your MVP is not testing the riskiest assumption it is not an MVP. I love to use spreadsheets and no-code tools for MVPs.  
- Build the solution -  Once you have gone through the earlier steps, or have low stakes or absolute clarity on what needs to be built or it's a small change. Just build the solution that appeared from the problem analysis. 

7. Measure the solution

I'd not call it complete if you don't measure the solution against your problem. Achieve the problem-solution fit before you go for the product-market fit. Solving the wrong problem ends up measuring the wrong metric. Measuring the right metric is extremely important. It's not about how many features you build or how fast you build them, it's about how quickly are you able to achieve the business outcome. 

When you chase the wrong problem or wrong metric.

Once you try to follow this approach with strong intent, after a couple times, I assure you it takes lesser time to do the problem analysis than you took to read this post. 

Be a problemist! It's goooooood. 

Long ago in a PM job interview, the interviewer asked me if I was part of the problems team or the solutions team. Frankly, I did not even understand the question then.

But then over the years, I've realized what it meant. It's now one of my most frequently used phrases when talking to my team members - "Remember, we are the 'problems' team".  

If you reached this far, you are quite a reader. Please leave some comments for the author. 

Saturday, February 15, 2020

Customer Success (not PM) is the role of the Future

Source: News Examiner

I feel that Customer Success teams have an opportunity to deal with humans where tech/products can't. As more people realize that how much ever user-centricity they build in the product, it's not going to engage people like people do - more folks will look for the right customer success guy.

Particularly in enterprise products, the stakeholder chain is large and includes user, customer, economic buyer, influencer, recommender, and in most cases saboteur. The stakeholder chain is also dynamic - people move, policies change. A technology product is far too passive to respond to the dynamism in real-time. It needs ultra-smart people to keep at the pulse of the relationship.

In fact, both CS and PM have a lot in common. Both roles have a very fluid definition across organizations, both require a very wide range of skills (more wide than deep), and are expected to fill a lot of white space. Product management has matured a bit in terms of definition, frameworks, and tools. It has gathered way more attention and popularity then it should and Customer Success apparently still hasn't caught the fancy of the right people. I believe as startups mature in their thinking and Customer Success matures as a field, this will be a very sought after role.

In many ways, CS is the CEO of the Client relationship (that limited business). They architect it, nurture it, rally resources (including product/technology/human), make decisions, tell stories, negotiate, persuade across the internal and external stakeholder chain - all with an intent to make sure the business improves. They are more likely managing P&L in most organizations and not the PMs. And I've seen founders wonder how they can make PMs own P&L, or should they even. It probably looks like the right approach but it doesn't seem natural to get this rolling.

It's because often product guys should do what they should - manage the product. Product success is definitely their responsibility, but, business success is way more than the right product. Business is about building trust and managing it. Customer Success very nicely placed between product and sales - just how product roles nicely sit between tech and sales.

If you are into CS or getting a chance to get into it - grab it. The future will need you more.

Tuesday, January 7, 2020

How to "Get Shit Done" as a Product manager

A PMs guide to Hustling

Everyone says that a PM needs to hustle, make it happen, get shit done. No one tells how?

Here's a quick framework based on the Chanakya-Niti. If you do not have the context of Chanakya, you can call it RRRTR.

Chanakya's Niti (Policy) says:

You can get something done by Saam (Request)- Daam (Reward)- Dand (Reprimand)- Bhed(Threaten) to be applied in that order. I've added a Repeat loop to it, Chanakya might have considered the same as part of Saam (Request), but I wanted to be more apparent.

A lot of times we face Opponents in our work. Bear in mind that the "Opponent" is not an enemy, it's a temporary state where someone is resisting the change and we are pushing for. It could be a friend, relative, even our kids. So in the entire text wherever I say opponent or adversary - you don't have to take your swords out.

Also, when I say office Politics I don't mean it in a devilish, dirty way. There are hierarchies in flat hierarchical structures. There are people - old and new, there are designations - higher and lower. There are personalities - strong and weak (in terms of influence). Here's what politics means by the Wikipedia definition:

And there are, in every significantly large organization, some politics that stems from its history, culture and people. Heck it takes only two people to have a power struggle, it is definitely there in small orgs - it can only be less or more apparent in comparison with others. It cannot, "NOT" exist.

So, now that I've defined the two words I am going to be using, I imagine you've lowered your guards and swords and are open to see things in a different light.

Here's how I've found the Chanakya's principles handy in navigating through the office politics and getting shit done by all people - Big and Small.

Disclaimer: I am no politician or expert. I am just trying to articulate what has worked for me, and many good managers might already be doing it instinctively.

Request (Saama)
One can always get most of your tasks done, even by your opponents if you make a polite request with a reason. When I am stuck I first try to cajole directly. A request with a strong reason works much better than just making a request. E.g. "I need this by today because...". However, in an office environment where you have many stakeholders to manage, it pays to have good relations with a lot of people. I'd regularly meet people over lunch/coffee, engage in banters, and also uprise them about the latest product stuff we are on to.

It takes a while to actually understand their pain points, challenges, and motivations. It requires a lot of careful listening. But, once I know these it becomes so much easier to collaborate with them. The focus has to be on them and their way of working. E.g. Some people are good with emails, some are good with calls - they find it hard to track emails. Whatever nasty email I dropped them, they will not pay any heed to my request. But, I later realized that I can simply make a call and get shit done instead of getting hung on my belief that "Email is THE professional communication medium". Little things like this help in engaging with people in the right way.

It always helps to ask if the person you are requesting to, is the right person for the job. Particularly in Asia, people have a hard time saying no and can end up wasting your time by not telling you that they aren't supposed to be doing this. When in doubt I ask who can do "this".  When I am asking the right person I get a volunteer. When I ask the wrong person, I get a referral. 

In addition, what has also worked is influencing through a peer. Sometimes work gets done better and faster because their friend asked them to do it instead of a random leader of another group.

Reward (Daama)
Daam literally means Price - indicating paying the price. It can also be taken as Bribing. In our context, you obviously won't be offering money to people under the table. But, sometimes you literally do - like a pizza to a team working late. Like negotiating a comp-off for a person putting in a weekend for your cause, providing a bit of leniency in work hours etc. It goes a long way in building a personal connection for a professional cause.

This has limitations, as you may not be able to do that to people who do not report to you. But, you can loop in their manager in an appreciation email. You can potentially recommend them for an internal award.

Exchange favors of other kinds. Sometimes a promise of help is also very effective - imagined gain is higher than the gain itself.

Threaten (Bheda)
Imagined fear is a very effective tool. Sometimes the threat of an escalation works better than escalation itself. Threats can be direct - "I'd have to escalate" or subtle - "I'd see if I can find someone who can do this."

You may be able to outnumber the opponent in certain cases by getting either more people pitching in your favor or more people against your opponent. Lobbying with influencers works the magic.

Who you know is more powerful than what you know. And what you know about who you know, is even more powerful. Bheda literally means distinction or division. It also means secrets - alluding to blackmail. Again, this may sound dark, but, hustling doesn't see boundaries. Also, how you connect with people and how you present your case is the difference between building and ruining relationships. E.g. Once a team manager was acting too bureaucratic, wanted me to follow a process that I had no time for. I had to jokingly add a small reminder of how a mistake he did in spite of me following the required process, had cost us some pain and rework. I did not have to tell him that he owes me a favor. Opponent's vulnerability is your power. Again just taking this out of context, it sounds plain evil. The team manager in context is a workplace-friend, we've spent a lot of time in banters and coffee machine conversations. He just gets too many urgent requests, so I have to convince him about the severity.

Reprimand (Danda)
When nothing works you have to take the unpleasant route. There is a well-known rule that one should appreciate in public and reprimand in private. One should keep that in mind. The best form of reprimand starts with the right questions and a curious tone (not a suspecting one). I focus on asking Why and listening attentively to justifications. It is important to be conscious about this, otherwise, you may not be able to have complete control over your communication.

Sometimes you may not be in a position to reprimand (e.g. if they do not report to you). You have to escalate and outnumber your opponent. When everything else fails you may have to coordinate with someone who can command action. Again, what you know is less important than who you know.

Persistence matters. The last time you made the request you might have found her at the wrong time and she denied without much intent. Or, maybe she wanted to take up your request but forgot. Or, she still wants to do it but she has scheduled it for later. How will you find out until you follow up? "But, I shouldn't need to follow up" is a flawed argument in most of the practical situations. Sanjay Swami (VC @ PrimeVP) once mentioned his mantra for startups - you eff up if you don't F'up (You F*** up if you don't Follow-up). It's an important mantra for all hustlers.

So here it is then, my strategy for hustling. 90% of my tasks gets done with Request and Repeat. But then, there is a nice line in a Hindi poem by revolutionary poet Ramdhari Singh 'Dinkar':

It translates to  -

"Tolerance, forgiveness, mercy is worshiped only when there is an established power behind it."

It's not the tolerance of the meek that people talk about, it is tolerance of the powerful that is celebrated. So, while Request and persistence work nicely, they mostly work when one has established the power to use "other means" of getting things done.

If you liked what you read, please leave some comments for the author. 

Tuesday, July 16, 2019

Handling PM Interview Assignments

Picture Credits:

When I talked about how to crack PM interviews recently at a workshop, there were a lot of queries around assignments. Assignments are a great way of learning how the candidate thinks and applies his knowledge to a new problem statement. Most assignments are interesting, and as a PM you should be enjoying doing such a thing. Here's a framework I use to tackle the assignments. Have seen 100% success at the assignment round so far. As the world does it, and, for my own recall I call it PUNPICR (Pun-picker)

This is how I structure the response that I create to the problem statement given (as an assignment). I may not use them as explicit sub-headings in the document, I use it as a subtle structure underlying the document. I like to use it as a checklist instead of a template. Based on the context feel free to split, merge, reorder the following sections. 

Identifying the problem(s) correctly is half the solution. Rephrase the given scenario and put down how you see the problem. Product is usually a Solution to a Problem. That Problem is what you need to elaborate on. Call out your assumptions. Imagine yourself as the founder/CEO/owner and then describe why this is a problem, how big is it etc. Any data that you site from the internet can be helpful. Do mention the source.

Who has these problems? OR Who is the target for the problem that you are trying to solve through your solution? Everyone is obviously the wrong answer. As specific you can get a better understanding of the Target Group you will showcase. You can talk about personas, demographics etc. 

What are the needs of your users? And what are their hopes dreams and fears? Sometimes it would make sense to explicitly write them down, sometimes it doesn't help to be apparent about it. But, doing that analysis will help you focus the solution better.

Which of these needs and problems is BIG? You should totally present the impact versus effort analysis that clearly shows solving which of the problem will have a bigger impact on the target audience.

Go ahead and put down all the ideas that can potentially solve the problem. All of them, good ones, and bad ones.

Play the devil's advocate and identify why one idea is better than all other ideas that you've put out or may have been obvious. Sometimes, more than one idea may be awesome in your eyes. If that is the case, just choose one for elaborating if you can't pick all of them.

Keep the best for the last. Now is the most interesting part that you've been restless to present. The Solution. Since you've established the background, state the obvious. Why is this the most preferred solution? And then, describe the solution with Diagrams, Wireframes, Pictures, User stories, Analysis, Business Model etc. whatever it takes to establish the idea clearly.

Also when you elaborate on one solution, feel free to talk about the costs, the pricing, and projections on how you break even, etc. Deep diving into one of the ideas showcases your business mindset and analytical skill. In the absence of numbers please assume based on your general sense. The closer you are to real numbers the better it gets (Google is your friend). 

Happy interviewing!  

If this post has been helpful, do leave a comment and let me know. 

Wednesday, June 19, 2019

New to Product Management : Here's what to read and learn

Interesting can get overwhelming... 

New to PMHood? 

Here are some posts that summarise my learnings over the years in product management. Some links are from my own blog and some are from original awesome articles that I could never improve upon. The articles have been listed to make it look logical - however, the order actually does not matter.   

Product Management is NOT what you think it is.
Begin with a jolt. This post was picked by NextBigWhat for republishing. A lot of new PMs wrote to me saying they could relate to it and asking for the help on what they could do about their predicament. 

Then, what is product management?
  • Basics: I tried covering the basics in my first ever video recording. It is not terrible and has been rated by 1000+ product enthusiasts as 4.4/5 stars, so I can assume it is worth your 30 minutes.  
  • Also, another post was a bit on the fun side but again appreciated by a whole bunch of people who thought this was highlighting the right things. It is about how we product managers are kind of double agents.
Bread & Butter: How to write a good PRD?
The silicon valley product group came up with how to write good use cases. Who can beat this?
And here's a PRD Template, if you don't want to cook up your own format. I and my team uses this format. 

How to gather requirements?
Your customers/users can't tell you what they want. You can't do surveys and find this shit on the internet. Brainstorming and clever imagination also don't help. You'd have to go out of the building and talk to humans. This e-book is my favorite when it comes to understanding how one can talk to people in a way that helps in gathering their needs and understanding their hopes, dreams, and fears. It's Simple and drives the point home really well.  

How to create Roadmaps? 
This is something I created from scratch. I use it, and I recommend it to everyone I have taught so far. 
How to evolve a development process everyone loves?
As you scale your teams, processes become extremely important. I've been in that situation multiple times and have figured that the best way to design a process is to evolve it with the team. This post is about one such situation and how we were able to create a new process together. 

Some Psychological Biases and How we can leverage them?
What are the potential pitfalls and how to avoid them?
If "Adrak ho gaya hai ye aadmi" rings a bell and you have similar thoughts about the product then you should totally learn about ginger growth

Physics for product managers
A little revision of elementary Physics and how it still affects us as PMs. Thanks, HC Verma. 

Books and other resources
Here are some free ebooks that you can read. 
Books: (It may look cliched, but there's a reason everyone suggests these books) 

  • Zero to one (General perspective about technology products/startups)
  • Non-Designer's Design Book (Quick & Interesting read, helps you know enough design to be able to talk to designers)
  • Design of Everyday things (To develop a perspective on how the world works, very critical for product thinking)
  • Don't Make Me Think (Absolute essential for basic concepts of good UI design)
  • Lean Startup (Good value, essential for learning the parlance popular in startup/product world ) 
  • Thinking fast and slow (how user psychology plays a role)
  • Checklist Manifesto (a good book to learn the importance of processes)
  • Crossing the Chasm (a gem of a book if you are in an early growth stage and scaling)

These are the books that I've found useful as a PM. However, as you grow it will help if you'd read more books on economics, marketing and scale.  

Other than these, "This is Product Management" is a good podcast to subscribe to. 
I recently (Aug' 2019) started hosting a podcast at TheProductManagement

Economics for product managers
Just for starters, you should at least know about the Game theory.  
And it helps in more ways than one to know how we reached where we are today  - World History in 20 mins is a great start. History is arguably a very interesting subject and if you dig into the potential reasons for historic events, you'd find them very revealing. 

Learning is endless, practically you could learn from Movies and Anime, but, I'd rest the list here. You already have a load to cover. All the very best. 

If you found this useful, you should totally leave a comment below. 

Monday, June 3, 2019

Product Management: Dreams & Heartaches

A whole bunch of newbie product managers and wannabe PMs are a victim of content marketing.

They've imagined a discipline/role that is not practical. Their world view is based on the enormous amount of reading material, the free ebooks, the blogs, the podcasts that they get free access to. The material may be actually helpful and well received by the known thought leaders across the world. However, if one looks at the most popular material on the web, it is either from companies selling their culture or companies selling their courses. And guys who are consuming this without much context of product management practice are setting themselves up for disappointment.

I'd add two instances that triggered this rant:

Case - 1: A techie, say Kriti, is doing a formal product management course but can't see the similarity between what she sees the product managers do in her current organization versus what she thinks they should be doing based on what she is being taught. She is confused about whether she has picked the wrong course or whether her colleagues are doing it wrong. Both could be possible, but, since she's not the only one finding that disconnect, I can see that something is broken.

Case - 2: A startup maverick, Vivan is an energetic fellow. He joins a mid-sized company and he wants to become a product manager, knows a lot about what's happening around in the world of product management. The source is, of course, the internet and the articles from the product course companies and SaaS companies which have built their story on content marketing. That's the world view he comes with and when he gets a real opportunity he is not able to match it up with the imagination. He thinks there are things that PM would be doing and certain things he would not be doing. Which ideally should be the case, but, as a PM you gotta fill a lot of white space. You need to get shit done. But, he is confused. Within the first few weeks, he starts to think about whether he is in the right role.

And then I ran a quick poll on twitter to see if there are others suffering. More than 50% think they aren't doing what a PM should be doing. 

Product Management articles look so perfect. But...

Honest enough?
A lot is written in retrospect by content writers, who have to come up with a story that sells. Even when it is based on true events they can always sequence the events and modulate certain sections to make it presentable. Makes for great reading, also drives the insights home, readers can definitely learn from it. I love reading them and drawing from them. However, as an existing PM, I can imagine the missing details. Those who haven't really done product management - have no way to read what's left between the lines.

One part of the story
They tell you what they did, what was the philosophy behind it and how it turned the tide. Some may also occasionally talk about what didn't work. All carefully drafted and showcased. What you definitely miss out on is that what you see is just tail of the elephant (sorry tip of the iceberg is too cliched). There is Chaos, Failures, Frustrations that are usually summarised in a line for completeness. In fact, there is no use of writing about or reading up the gory details of things that did not work. But, since you are inspired by reading just one part of the story over and over, you are set to be disappointed by reality.

Race to the bottom
As someone who's selling a course or a certification program, you have to meet your numbers. Which means you have to get more people to the top of the funnel, get you excited about "Product Management". So they try to make it look cooler. They have to build upon the imagination of others to stay relevant and capture more market. And that's where they're setting people up for disappointment.

The predicament 

The excitement about Product Management among youth is palpable. Everyone from non-Techie technology graduates (at the IITs) to management trainees from IIMs/ISBs and even people with 10+ years of domain experience is trying to get into this field. Some of the hype is justified and some are not. And there are various articles that bust the myths around product management as well.

However, in my 14 years of experience in the industry and those 6 kickass years as a product guy - I've come to realize that any role at a progressive organization is a lot about hustling and getting-shit-done.

And it is not all about the newbies being at fault. Many startups, organizations also create PM function without much deliberation. They see a gap as they scale and think what they need is Product Management to fill it up. The lack of understanding is evident if you just have a look at the PM JDs on job portals. There is an eerie similarity in all of them, and most of them are quite disconnected with what the real job would be like. E.g. A 2 years PM experience guy  - JD says should be experienced in creating Strategy and Roadmap  - really? (Note that they are an e-commerce site being used by millions of users)

Here are some samples of JDs for an e-commerce company, a fintech, and an ed-tech company:




They are themselves so unsure of what they want. All they seem to be looking for is a person with some proven logical, analytical capacity and communication skills - In short, an MBA from Top Tier institute, preferably with Engineering background. How do you reckon your unsure employers will provide with certainty and job satisfaction?

There are Dreams and there are Heartaches associated with the Product Management function across the board. Anyone planning a career in this needs to be more objective and better informed. It's cool, but, there's a lot of dirt under the rag. If you aren't up for it, find something better.

If you liked what you read, do leave a comment for Ujjwal Trivedi. That's a great way to converse with the author. 

Thursday, April 4, 2019

A JD that can find Yoda!

The Job Description should be an easy hint for a smart candidate to tweak her resume and prepare for the interview. It may sound controversial, but, I believe if someone is actually able to do that and crack the interview, they are worthy of an offer. :-)

Rant: Most Startup JDs I come across are poor copy-paste jobs of a lazy junior recruiter being coerced into doing it by the hiring manager (the actual person hiring for the role). If you haven't thought about it yet - the job description is your first impression, your first interaction with a potential hire. JDs are not supposed to be outsourced to a recruiter, it should be taken up by the hiring manager/founders themselves and should be the first step to the entire hiring process. Which means you start with JD and map the entire hiring process for the role accordingly. End of rant.

Here's my simple checklist that is good for any Job Description - Tech/Ops/Product/Mktg.

  1. Exciting things about the company (Readable - 100 words - short paragraphs)
    • Describe in 100 to 150 words divided into short paragraphs
    • Describe how you are challenging the status quo in the industry, world
    • What's been your startup's achievements so far
    • What's been the impact and what is the potential impact of the work you do
  2. Exciting things about the role, what a person gets to do, what's the potential impact this role can have on the product, the team or the company
    • List of 3 to 5 Bullets
    • Don't be too salesy - you should set the right expectations
    • Mention your products( for PMs), technology (for Techies) you work on, clients (for Sales) you work with, tools or anything that is relevant for the role in context.
  3. Perks and Benefits
    • Bullet list of 4 to 8 points
    • Include Both monetary and non-monetary benefits (like generous leave policy, food, insurance, etc.)
  4. Eligibility (Qualifications, Experience level, Location, Nationality, Gender)
    • Be as clear as it gets.
    • If you are looking for premier college graduates only, please mention that upfront. Personally, I find that a discriminatory criterion, but being honest helps both you and the candidate.
    • It helps to mention which criteria are hard and which ones are flexible. Is it B.E./B.Tech/MCA or only B.Tech.
  5. Expectations (from an Ideal Candidate)
    • Bulleted is better, 5-7 points are usually enough, beyond 10 is unreadable
    • Put both Mandatory skills and the Good-to-have ones
    • Being reasonable and clear is expected. If you are not going to ask someone to handle P&L, don't put that in expectations. It works both ways, the candidate will also expect to work on stuff that you put under expectations.
    • It is understood that expectations may not match 100% with someone's skills and experience so keep room for that.
As I mentioned earlier, the interview process and type of questions should map to the job description. If you expect a person to work in ambiguity and don't evaluate for that skill - it would be such a waste of opportunity.

If this was helpful, please do leave a comment for the author. 

PM is a Double Agent

Most Popular on this blog