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.