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. 

PM is a Double Agent

I love spy movies.

[Disclaimer - this is mostly for fun, if it gets insightful, consider it a planned coincidence]

But, it was very recently that the word Double-Agent caught my attention. And the more I read about it on the official CIA website (Yes, I did!), the more I felt that the Product guys are freakin Double Agents!

Well, no I don't intend to say that we pretend, or spy, or do clandestine activities or act on behalf of the enemy. Please let go of all those negative connotations associated with the word. What caught my attention was their loyalty to more than one party and their ability to switch loyalties. Just like double agents, product guys do that - all the time.

But then, as I read about them, I felt a lot of the attributes kinda map one-to-one with product management function. So, let's get to it.

What does that mean?

Let's follow the Jobs To Be Done framework and ask, What is a Product Guy hired to do? Well, not many startups really have a unique/clear answer to this. Some just hope to get a few good guys together and let them figure out. But, let's assume there is clarity about what are they supposed to do in startups - Manage products. 

Easy? Not quite.

What is that supposed to mean? It means they are responsible for everything from deciding what to build to shipping a quality product on time and making sure it sells. But they neither create, not sell  - they just ensure it happens. Add to the predicament that, they don't usually have authority over these creators or sellers. They are loyal to both creators and sellers (and management, and everyone in between). But their biggest loyalty is to the users of the product. A product manager is the voice of the customer.

Usually, it is the user who's missing from our meetings and conference calls. So the PMs end up pitching on behalf of them, most of the time. However, they also have to pitch for their tech teams in front of the business teams, and for business teams in front of the tech guys. They're found negotiating a bit clarity from the business, and a bit speed from the development team. They push back sellers on behalf of creators and push creators on behalf of sellers. It's almost funny if they find both the parties together in a room - you find the PMs practicing diplomacy. And they are loyal to the management, in front of everyone else.

So, if PMs are like a double agent, they are likely to be on a critical mission and they need to be at the top of their game to be effective.

So what makes a great double agent?

CIA suggests that being a double agent needs both competence and sophistication. And a few more things...

• Thorough knowledge of the terrain and the language
• Ability to build Rapport at all levels
• High order of ability in complex analytic reasoning
• A detailed understanding of the adversary
• Transparent Communication
• A solid grasp of behavior patterns
• Enough time from other duties to run the Ops and Report it well

If you aren't already able to see how PMs match with Double agents - here's my quick take on the same. 

Ability to build Rapport at all levels

The greatest spies never did those James Bond or Jason Borne type stuff. They just made right friends and treated them with a lot of alcohol.

Building rapport is far beyond knowing their language. It needs a lot of likeability and and an intense effort for relationship building. It comes from listening, understanding, perceiving what's being said and what remains unsaid. Being available, sharing interests, initiating conversations that go far and wide creates rapport when done effectively over time.

Thorough knowledge of the terrain and the language

If you were a complete stranger, you'd feel as if the tech-guys around you speak in code language. No wonder some of it is even called coding. And they don't trust anyone who doesn't understand their code. In fact, its true for both geeks(devs) and artists(designers). If you need any intelligence (intelligent inputs), you need to win their trust over. So as a PM you have to warm up your vocabulary around both "data models" and "visual hierarchies". If you can't speak like them you can never befriend them enough to be able to seek favours. And you can't get shit done if you don't have their blessings.

Knowledge of organizational plugs and levers can help you navigate swiftly through the corporate jungle (or startup mess). A product guy needs to know the handlers, the operatives, the assets and the sleeper cells in the org. That's where not just the geography, but history of how things came to be what they are at present is a useful knowledge. It helps you leverage the right people and pull the right levers, whenever there is a need.

High order of ability in Complex Analytic Reasoning

In a simple world problems can be paired in to pairs of cause and effect. There is a cause to an effect, a reaction to an action. In a real world though, when a lot of simple cause and effect pairs add up, it's hard to find what cause correlates to which effect. Add to the mix, that correlation may not lead to causation. That's what a complexity looks like. What you need is a beautiful mind, to look through the matrix and find patterns.

A detailed understanding of the adversary

Product managers need to know their competition, potential competitors and the third parties that they integrate with. It also needs to know collaborators, potential collaborators and their competitors. This view of market essentially helps them make sense of why market is behaving the way it is - and also predict what's coming next. This can define your next move - or save you from taking a wrong one.

Transparent Communication

Trust is the most important factor in smooth functioning of a product guy. And trust comes from transparency - being transparent both internally and externally. Since you keep switching loyalties, you are always under suspicion. And the only way to build lasting trust is by communication - sincerely, transparently, effectively.

A solid grasp of behavior patterns

Vanity metrics are honey-traps. Enough has been said about how important it is to understand biases of yourself and of your users. Once you have a solid grasp over the behavioral patterns - a lot of instinctive decisions just land right. It takes both skill and experience to avoid your these traps like your own biases and chasing vanity metrics. And it takes effort to identify the right targets, and start taking more data-based decisions.

Enough time from other duties to run the Ops and Report it well

How many PMs have you seen complaining of not being able to do the Product stuff? They're always firefighting. But the good ones find time to take a step back, analyse the scene and report it well - both internally and externally. Remember, nobody really understands what you are doing (and perhaps they shouldn't). So a lot depends on how well you report it.  

And One last thing that the CIA doesn't say! 

They have a right to disown you. You're expendable. When reigns change or when soverignity is in danger or at least some higher authorities think it is, you'd be the first to be asked to take care of yourself (by yourself). It is not an exaggeration to think that you are pretty much on your own, Always!





Liked it? If you've made this far, you should totally leave a comment for Ujjwal Trivedi. 

Avoid Ginger Growth in your Products

Does your product look like this?

Usually, GROWTH is a good thing. However, there is a very common problem of unbridled feature growth in both B2B and B2C products.

Feature ideas typically come from everywhere but the problems most dear to the HiPPO, and those of the loudest customers get much more attention than other real problems. So over a period of time, the products undergo a skewed growth in size, complexity, and utility. At Artoo, we used to call it the GINGER GROWTH. For those who did not get the connection - Ginger root is a leguminous stalky root used as a spice. It grows very erratically - from just about everywhere, that's not what you want to happen to your products. And for some of you familiar with Bollywood would know - "Adrak ho gaya hai ye aadmi..." If you don't get it, just ignore it.  

We realized there are a small but a significant number of features that were unused, under-used, un-released, not-so-useful, not-used-as-intended and even unusable. In most cases, making products leaner is a more painful exercise. It is hard to say NO to feature requests, and even harder to say it when there is a client using it already. Killing a feature is harder than deciding to build the new ones.

Why not?

Wasteful: One should avoid Ginger growth to save efforts now and more so in the long run. Ginger growth is an indication of lack of focus, which means you are building features users may not care about. That's wastage on steroids.

Onboarding/Training the users take longer - New Users find it complex, Trainers spend more time and overall it directly increases the costs.

In B2C products it may cause an early churn in acquired users, In B2B it may lead to slower adoption, user dissatisfaction, falling NPS/C-Sat scores.

Re-engagement/Monetisation is difficult as the users may not be able to leverage the full potential of the product.

Your product is more likely to get disrupted by newer simpler products. Very likely that's how you acquired your clients - by presenting a simpler solution to their existing problems.

Examples of Ginger growth

Featuritis or Ginger Growth has plagued every org and every product I have known. However, here are some examples from the consumer apps so that everyone can relate to it better:

• Facebook - How many features do you see on a facebook page? I stopped counting after 50 visually apparent ones on the homepage, did not count recommendation algorithms. How many do you use? I counted 7 that I frequent. 
• Evernote - A designer friend once claimed that only 15% of the Evernote app is used by any user, but it's not the same for every user. That means that the 15% most used features are spread across the entire feature-set. It sounded interesting and believable. However, I could not find any evidence to support the claim so I did a bit of a survey myself. It was hard to gather clear quantifiable insights, but it was very clear that most people focus on their favorite set (20%-50%) of the product, and they ignore the clutter. Now Evernote has been able to survive and thrive in spite of its ginger growth, but it's not a nice model to follow. 
• There are more examples of Linkedin, ShareIT, Hike Messenger and Truecaller which are getting obese with more features regularly being added to the clutter. Fortunately, they have large smart teams to find these issues and they also keep killing them regularly.  

Identifying Ginger Growth

Here are a few simple but strong signs that indicate Ginger growth.

• Engagement spread thin: A few features are widely used, but a lot of features are mildly used. It's hard to find a clear set of features that no one is using at all. 
• Discoverability is difficult: It's getting hard to highlight what's new in your product for the users to start using it, they mostly remain undiscovered.  
• Who worked on this?: The question comes up every time they want to fix a new issue or enhance a module. None of the teams is confident that they know the entire product well. Usually, the PMs, QA, Support and some sales guys must have a pretty good command over the product/module/feature that they own. 
• Product Documentation is in the head and in the code: More than 50% of the product documentation is very stale and almost useless. This is not a necessary condition, but is a strong sign and is unfortunately very common.  
• Increase in a number of support calls from new users: Typically when the feature set is a large the training/onboarding is not enough. End-user ends up seeking support for multiple small things.  
• Onboarding/Training is taking longer: It takes more than the onboarding to make user find their Aha moment. Training sessions might have become longer and less effective. 

 Reasons for Ginger growth 

• No Compass - Usually, everyone driving a product has a plan. But, if it's not clearly defined, and well-drafted as a data-driven roadmap and is clearly evangelized with the team, it simply cannot be executed by a team. It might work for smaller teams, but not for teams more than 10+ members in it. Imagine navigating through a jungle. You either need a common compass that clearly shows them one true-north or a road-map that everyone can clearly see and follow. Usually, you need both. Creating the right product is quite like navigating in the jungle. If the team doesn't clearly see a road, they will end up beating their own paths.  
• HiPPO - (usually the CEO/CTO/CPO) - In the book Throwing the elephant, the Boss is frequently compared with the elephants. E.g. However young, thin and naive it is, an elephant is at least 10 times heavier than you. The Boss is not an elephant but has super-powers that can make her weight-in like that. Usually, the HiPPO will exercise their powers to keep changing the plan because "they can". The reasons may be lack of discipline, lack of focus or lack of understanding of how it impacts.  
• A few loud stakeholders - Sometimes some of the internal or external stakeholders (clients and sales) are louder, more nagging than others. And in the absence of a transparent, data-driven, mutually agreeable roadmap, the team can give in to their demands. 
• Chasing vanity metrics: This is a distraction that anyone might have. Product and Growth guys get it often. If you are going to build features to hit numbers that your product does not need in long-term, you will accumulate a lot of deadwood very soon. .   

How to avoid Ginger Growth / Featuritis

Saying NO to features is hard - whether it is your idea or theirs. It's almost never a possibility for product guys have "Saying No" as a tool. But, there is a lot that you can do to check whether you are ready to commit for a feature or not. One way I do it is to keep a checklist right as a part of the PRD that I or anyone in my team creates. This document is referred by everyone from sales to engineering and sometimes even clients. See my PRD template here.

This enforces asking the right set of questions right at the beginning of the ideation process.

Don't take "solutions" from your customers

This is particularly evident for B2B software. You create a roadmap and in the next customer visit it seems to be useless. You re-do it, and another client visit brings you back to square one. Remember that we are hardwired to think in terms of solutions - instead of elaborating or articulating our problems better. So when you meet clients of your customer-facing stakeholders don't take solutions. Ask a lot of whys and understand the problems and design your own solution.   

Find the right metrics to chase 

Does it align with the vision? This is the most cliched question everyone would suggest asking, and we usually have no way to clearly check for alignment. The solution is to find the right metrics that help you achieve the vision. The basic metrics are related to Acquisition, Conversion, Monetisation, and Engagement. However, we need to choose a metric that marries business with user-experience. For an e-commerce site, it could be the number of repeat transactions, for a utility product it could be the turn-around-time. Basically one should focus on optimizing for one of the following - attention, transactions, or productivity. Decide on a north-star and the levers that affect it - chase them.

Ask: is it core to what we do?

You often build features to please that one client, close that one sale and end up getting some half-assed features. This is because we often view the product as a monolith. We should split the product into multiple layers for simplification. This helps in logical separation, better technical architecture and keeping things robust. The sooner you start thinking of product in this way, the better and easier it can be.

Simplify your Products into different layers

With this approach, it gets easy to make decisions when a client/stakeholder makes a new request. You can decide what's core and what not and treat it separately.

Ask: will it still matter after 5 years?

If it will, can you afford to not do it well and carry the technical debts for that long? If it wouldn't matter in the long run, how much time do you want to spend on such a thing right now? This helps in seeing things from both a short-term and a long-term perspective. You can treat the short-term things differently and have a phase-out plan for them even when they are not live. This gives you a strong focus. And this also keeps the product clear of featuritis.

Execute your Roadmap!

Enough has been said about creating useful roadmaps. Executing the roadmaps needs very strong intent from the owner and other stakeholders who can act as potential saboteurs of the plan. Product guys need to train-up and train-down their hierarchy about the importance of planning and sticking to the plan. However, it makes sense to expect changes and plan for them. I'd always keep a 20% flexibility.

MVP Everything

A feature idea/request usually stems from a pain point. You may not want the most elegant solution for it immediately. As a product guy, I would always ask how can this pain be solved without building a new feature? Sometimes the workaround works wonders and gives me enough breathing room to decide what needs to be built and how impactful would it really be. And also enough data points for the stakeholders to see.





If you have reached this far, you should totally leave a comment for Ujjwal Trivedi's post.

What to do during 4 years of engineering?

Quite a few nephews (cousin's kids) are getting into college this year and I've been repeatedly asked suggestions about what college, what branch etc. would be better. My simple reply to most of them is "It Doesn't Matter, they won't get a Job". Decide the college and the branch with this thought in mind and you will decide better. What will matter at the end of these 4 years is how much they can learn about surviving in this wild world. 

I've been thinking about doing this post for long but then, finally, I put down my thoughts today. What triggered this is that a stranger read some of my answers on Quora and reached out asking similar questions. Thanks. I hope this helps you too. 

It's great that you are thinking about making the best of these 4 years already. I wish you the best. 

As of now don't worry about a job/startup. Just try to do more of what you love to do. If you think you would like to do something, go ahead and try it out. Create opportunities for yourself, don't wait for them to appear. Only by trying multiple times will you learn if you like to do something or not. I have tried my hands at 70+ things (yes, I maintain a list) to learn which of the things I love doing versus which I do not enjoy as much.

But, money is important. The earlier you learn about it, the better it is. Let me give you some fundamentals of money making with some over-simplified examples. 

There are only two skills required to become wealthy - 

1. Creating something, 

2. Selling something. 

Everything else is labor. 

Anything that gives you money in exchange for your time is "labor". E.g. a Doctor can only earn for as many hours as she can spend. If she earns 1000 per hour, She can only earn 24000 per day (which is not even practically possible). But, if you have created something that can be copied and sold - you have a product that can earn a disproportionate amount of money even when you are not working on it. E.g. You build an App that users buy, you create just once but people will keep buying it even when you are sleeping. There is no real limit to how much you can earn because it's not dependent on time. 

So always try to learn these two critical skills of creation and selling. Creation is not only about software or hardware, it can be concepts, art as well. Selling - in itself is a complex thing. You need to learn management, communication, positioning, psychology, negotiation, statistics and quite a few other things. It can look overwhelming, but you have a lot of time. 

How you learn Selling, is by learning about people. How you learn about people is by:

1. Reading - Read a lot. Read anything, everything that you find interesting - fiction, non-fiction, history, news, business. Over a period of time, interests will keep changing and you'd learn a lot about different things. Reading books is one thing and reading situations is another. Ideally, Travel helps you learn the most about people, and books are a good hack since you may not be able to travel as much. 

2. Applying - Don't miss a chance to sell. Sell your ideas. Sell what you have created. Sell your services. Organising clubs and events at college can be a great learning experience for all this. Make friends with a lot of people. Do public speaking, volunteer, do social work, play sports.   

Since you are going to be into engineering and you like programming, you'd definitely acquire the power of "Creating" something.

Learn any technology deeply. Try to use it for the simplest of things you want to do. Learning even the oldest - C/Java language can be very helpful. All technologies are similar, just that the syntax used is a bit different. In fact, you may not try to learn the latest and most trending thing. Because trends phase out fast. The basics last forever. However, it would help to learn machine learning since the world is getting data rich very fast and they need more data engineers than ever before.
  

Certifications

I don't believe in certifications. It's just a standard external validation that you have learned something. Doesn't tell much about your abilities. Do it if you like it. Its value is always doubtful. However, learning is always important. Self-learning is the best bet. One awesome way to learn is by creating stuff and learning all that is needed to do that, another one is to help others in learning something. Udemy/Coursera have opened up so many opportunities to learn online from the best teachers in the world (sometimes for free or at very low prices). Take those free courses sincerely. I have moved from tech to business and moved up the ranks without any business degree. I've just leveraged a lot of these free courses, slideshare, and ebooks. Being sincere is more important than being serious. 

Learn about open source see how much software people all over the world have written and shared extensively for free. Fork repositories on Github, share all your ideas and creations freely and extensively. Connect with people who you can't reach out to, on Twitter and Linkedin. See how you can help them. The Internet is your friend, always feel free to ask questions and give answers. Ecosystem works that way - if you can give, you can take. 

Don't forget the FUN part. 

The reason I keep repeating Do What You Love - is because that's where the fun is. We are always bound by things that we are obligated to do, so doing something just because you love doing it is extremely important. I'd just want to add that sometimes it is ok to not do anything, idle around, gossip with friends and watch TV. Have fun while you are learning, and learn while you are having fun.  

Cheers, feel free to reach out to me if you have any specific questions or if you feel you are stuck. All the best. Here's something that you'd find helpful as well.



If you have reached this far you should totally leave a comment about how you liked it and share this post with others.