Handling PM Interview Assignments

Picture Credits: tnstateparks.com

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. 

Problem
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.

Users

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. 

Needs
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.

Priorities
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.

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

Comparison
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.

Recommendation
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. 

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. 

• Step by Step process of creating a data-driven roadmap
• Prioritization based on Product Lifecycle 
• Frameworks to use for building a comprehensive data-driven roadmap

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?

• Biases part 1 
• Biases part 2 

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. 

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. 

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. 

Physics for Product managers

The very first products/inventions known to have been created by mankind were all physical in nature and Physics was born as a study of the laws of nature. Physics is the study of the behaviour of matter, and its interactions with space and time. It is the basis of mechanics and all machinery ever made. Somewhere in the last few decades with the advent of software as a stream of academics and a popular career option, we stopped focusing on physics. And the impact is evident - so many products created with millions of dollars, disappear into oblivion. There is no dearth of designers, software engineers, and product managers who have lost touch with the most fundamental science of Physics. in fact, the one piece of software that is known to apply the laws of physics most of often is Virtual Games - and now we know they are the most popular software.

Here is an attempt to look into a few topics of physics and how they apply for Products. It is aimed at product managers but even engineers and designers should find it a fun read.

Inertia (static and motion)

Whether it is a B2B product or a B2C app, inertia is a BIG bottleneck that product managers need to be aware of when designing new products/features. In physics, inertia comes from the mass of an object - due to which it holds its state. If it is static, it will oppose the motion. If it is moving, it wouldn't stop until some force is applied to stop it.

Product users also exhibit inertia - because of which they will always oppose change or disruption that product/feature can potentially bring about. Always! Even when they have purchased it, even when they are convinced that they really want it. Great marketing and word of mouth can lead the users to be convinced about signing up, downloading your app or even paying for the subscription, but, it takes a while before they are engaged. That's why you need to track acquisition, conversion, and engagement separately.

In physics, Mass is also a function of gravity. We weight lower on the moon than on the earth. So we should also check what gives the product its inertial mass? Is it a set of behaviors, culture (of a society/company/geography/country)? How deep-rooted is the behavior in the context?
What works in one market may not work in the other. The inertia in one market may be absent in the other.

A lot of products die out, trying to change the behavior of their users. You have to accept the simple law of physics that suggests that because of inertia users will continue to do what they are doing - until a strong enough external force is applied for a long enough period. And that's why incentives like deep discounting on e-commerce and free rides on ride-hailing platforms are a norm. They act as the strong external force needed to bulldoze users to change their existing behaviors or adopt new ones. Nir Eyal in his book Hooked describes how new habits can be created.

So, if you are creating a product or a feature that will change the behavior of the users, or that seeks a change in behavior to be useful - STOP! first get the marketing budget approved, or at least get your plan to fight the inertia in place before you move ahead.

Here is an awesome thread by Paras Chopra (Founder, Wingify) summarizing mathematically how this works? Conservation of probability-mass. 


Your users may not always need monetary incentives, the force could as well be internal. Can you move them, to get them moving? Your content, packaging, onboarding needs to trigger strong emotions. Here are the feelings that motivate people, in the order of strength - FOMO, Scarcity, Pride, Sadness (Compassion), Delight.

Whatsapp, for example, created your network from your contact list. Tinder starts showing you potential matches without taking many details from you. Facebook suggests you possible friends without you having to look for them. Having a tab on the intrinsic motivations of your users is extremely important - you need to know their Hopes, Dreams, and Fears.

Another place where product managers have to struggle with inertia is within the organization itself. For a big org, it is easy to believe but even the smallest of teams can get set into a routine very soon. Product thinking often requires product managers to bring in new tools, new processes, and new people - and every time you introduce something new you face inertia. You have to be aware and solve for it, the way you solve for it for the products.

Law of conservation of momentum 

We talked about inertia. Mass can be seen as how bulky the product is. Larger the product, the larger the force required to accelerate its growth. Hence, all modern practices are striving toward leaner products, leaner processes.

Friction

Friction/Drag is an external force that opposes the motion. In effect, it also opposes the external force you apply to move an object. So, as soon as you are done fighting inertia, you start fighting friction. Applies very well to products. Every interface is a potential point of friction. And I am not just referring to the user interface here. Any layer where your product meets another internal or external layer can be a point of friction - UI (product meets user), Delivery/Support(people meet people), Hardware (product meets system), Software - Third-party integrations (product meets other products) Software development (people meet people).

To make things simple I have categorized friction - so that it is easy to identify it and fight it. There are 3 types of friction in Products:

1. Physical: Physical friction is the most apparent. It is caused by a bad user interface (UI), unclear messaging, unintuitive placement of features, difficult usability, non-intuitiveness of the flow. A lot has been said about how to design better so I wouldn't focus on rehashing that. I'd just recommend reading the "Non-designer's Design Book".

2. Systemic: And then there are less apparent constraints that drag the experience back. It can be due to constraints of the Hardware or Software, Network speed, Sensor limitations, or even the Organization. Whether People meet a System, or People meet People, every interface is a potential point of friction. It might be easy to diagnose these constraints but it is hard to rectify them. However, in most cases with some effort, all of these can be optimized for better. And just like inertia, another level where product managers need to solve for friction is when people meet people. Your sales guy wouldn't talk to the operations and ops gang will just create support tickets that never reach the developers. A lot of time goes into setting up communication right. How the organization communicates internally has a lot of impact on products. So, removing this friction is one of the primary duties of a product manager.

3. Cognitive
This friction is the hardest to identify. Expectations, Ego and other behavioral issues often offer resistance to your product engagement tactics. Lack of trust is a big issue for a new product. And there are quite a few other Psychological biases that keep users from trying your product, trying all features, adopting it and engaging often. When users are past their inertia, there are more forces (biases) that drag the adoption rates. PMs need to know about these biases and how to leverage them.

Leverage  - Levers and Pulleys

Archimedes famously said, “give me a lever long enough and place a stand and I will move the earth.” Most mechanical machines work on levers and pulley mechanics. It teaches how a small effort can translate to a larger work done. We know for a fact that 20% of the activities generate 80% of results. There may be smaller things, e.g. improving the signup flow, making action button more prominent - that can have a disproportionate impact in growth, as compared to, a new feature that might not move the most important metrics.

Identify your business goals, what moves your product towards achieving the correct goals and focus your energy on pushing those levers. One should create a comprehensive data-driven roadmap - and then executing the roadmap is all about regular relentless prioritization.

Entropy 

Every new product/feature increases the entropy of the system for a limited period. As a product guy, it is our prime responsibility to reduce the entropy in User's Experience. I recall how introducing a new set of more appropriate, better-looking icons drew flak from the users at one of the Fintech SaaS products I worked for. The earlier icons may have been inappropriate and confusing (if not wrong), but the users (of this B2B product) had trained themselves to the current set. Changing it to appropriate icons confused the users and resulted in a lot of support calls and chaos. My learning - whenever I introduce something new I would introduce clients to it long before it actually gets to production. I would also create very readable release notes that users would love to read and enjoy - and also educate themselves about the new features.

Work does not convert 100% into the output. Some will get dissipated to create entropy. That's why perpetual machines are not possible. But this does apply to chain reactions in nuclear physics.

Chain Reaction -  Nuclear physics (can it be related to network effects) 

Most of the time the energy of the system remains conserved. So, is true for products. Growth is directly proportional to the effort. However, a lot of products in past grew disproportionately because of something called viral-ity, or network effects. 

A product is said to have a network effect when the users realize that having more users of the product will make it more valuable for them. This means they have an intrinsic motivation to brag about the product and get more people to it. Once a product's user base has realized the network effects - the product's user base grows much like a nuclear chain reaction. 

In the end, there is continuum. Everything in the universe has an ever-expanding scope. Beware. Understand your SPACE-TIME better. Both space and time can vary your product strategy. What is trending today, maybe a flop tomorrow? What works in one market may not work in other.

So, that was a little fun with analogies where Physics meet Products. Hope you enjoyed it.





If you managed to read all this, do leave a comment for Ujjwal Trivedi.