Stop firefighting PMs: Cheers to Processes!

Simon Sinek says we should “Start with a Why”. So let me start this essay as well by answering why should we even have one on this topic. I have seen many orgs end up making huge PM teams and lean heavily on Engineering processes but not enough PM process to ensure PMs are doing well.

While everyone is focused on productivity and quality of Engineering, but the processes for quality PMing is negligible or non-existent.

What’s your PM Process (not development process)?

Here is why a PM-Process is extremely critical:

• We’re always Firefighting: PMs lose focus on business objectives and find it difficult to prioritize correctly — leads to more firefighting, “busy” work, burnout. This also leads to building things no one really wants — or more surprisingly features that they say they want but still don’t adopt. You can’t really be creative when your ass is on fire.
• Loss of Engg Effort and Productivity: PMs keep hopping from building one feature to another instead of achieving the outcome — this leads to customer frustration, loss of engineering bandwidth, worst of all loss of motivation. UX Coach Jared Spool has some amazing insights on the cost of frustration.
• Complex product: PMs work on islands, they focus on their specific areas/modules/features instead of the user’s whole experience. That makes them look for unstable hacks, workarounds, or complicated features that end up creating a complex, less maintainable product and a never-ending Tech Backlog.

How did we end up here?

If one or more problems look relevant to you, do spare a thought on how did that even happen. I’d ask another why. Why did this happen:

• No set process for PMs —you are mostly making ends meet, building one feature and hopping on to the next feature
• No templates for requirement gathering, design, documentation (PRD/Jira ticket), release notes or user manuals, or if there were templates in the beginning — no one knows now.
• No quality check on PMing — no formal channel to gather PM’s efficacy. Tracking it back from Product failure is too little, too late.
• Frequent change of direction — while sometimes this is circumstantial, short-term planning and sticking to the plan is critical for efficiency, keeping up motivation, and avoiding burn. It could be you or HiPPO.

#burn

So, what do we do?

So here are some solutions that will, over a period of time, help us get rid of all these problems.

1. Articulating your PM Values and Principles
2. Creating/Following PM Processes

PM Values and Principles

PM Processes will change based on your maturity and need, but your PM values and principles would most likely remain unchanged for a very long time.

Here are some product management values for starters:

Empathy: Being Empathetic creates trust and helps the PM lead without authority. Also, helps PMs build the right thing, reduce ambiguity, avoid tussles, boost morale. It also involves creating readable documents, responding quickly to emails, and creating delightful user experiences.

Curious: Being curious is a precursor to being innovative. Probe the customer, probe the stakeholder, probe the market, probe the existing data. Is there a better way to design it, do it, market it, sell it?

High-Agency: High Agency person looks to bend reality to their will(Copied from this awesome twitter thread). They either find a way or make a way for themselves. Get things done.

ROI Focused: As discussed earlier that we should start with a Why. Focus on how much value the user or organization will be getting because of this product/ feature/ change/ tweak leads to faster/better decision making. Ask: Is it worth the effort that we are going to put in?

Clarity: The world is messy and getting messier. It’s important to constantly reduce entropy by creating reasonable plans and sticking to them. Document unambiguously, use simple and clear language with visuals, go the extra mile in teaching all stakeholders the value, and working of what’s been built.

PM Principles

The guiding principles are derived from the values, that help us with two distinct things

1. Put values into practice
2. The principles help us create and improve different PM processes so that we can solve the problems identified at the beginning of this essay

Here we go the 8-Fold Path:

1. KYC (Know your customer): Distance relationships don’t work. The longer we stay away from clients the higher the chance of us losing control over priorities. Dedicate time periodically to talk to a client/potential client — internal or external. Additionally, attend a sales call or a client demo. In some projects you’d easily get a chance, in others, you will have to make efforts to talk to your clients. It’s not a one-time thing, it’s a continuous activity. #empathy
2. Think Problems, not solutions: The magic is in defining problems such that finding the solution is reduced to a logical/mathematical problem. #roi-focus
3. Show, Not Tell: Be as visual as it gets. Add screenshots where you can, A high fidelity wireframe is better than a hand-drawn one is better than nothing. Write copy, not lorem ipsum, the copy is design. #empathy #clarity
4. Own the Emotion: A product is not just getting the correct feature/ functionality — it’s getting the correct emotion. Measure emotion, not just numbers. Emotion comes from the overall experience — that includes the full suite of features, products that the client uses. Keep an eye on the complete experience not just our specific feature/product. #empathy #high-agency
5. KYP (Know your product): Eat your own dog food. Invent ways by which you, your team, or some internal team is able to use the feature and give brutally honest feedback. If you can’t use it no one will. #empathy
6. Think Outcomes, not Output: If you aren’t measuring, you are not improving. Ask about business goals for every decision, call out when the goals are unclear. Building the feature is just a 20% job done. If they aren’t using it, our effort is wasted. Repeat: We measure emotion, not just numbers. #roi-focus
7. Ask: Ask what’s new (and what’s stale). Prod the clients, the stakeholders, the engineers, the data. Question the current state, and ask if there is a better way. #curious
8. Write it down: Life is short, memory is fleeting. Write down your thoughts, specs, sprint themes, roadmaps, plans, and the reasons for making those decisions or making that plan. Document key decisions and thoughts in a shareable artifact and share it with all stakeholders. #clarity #high-agency

PM Processes

Success is a process. This 8-fold path can help you build PM processes based on your context, maturity, burning need.

Processes will be contextual, temporary and you should evolve them with your team, not in your cabin.

I am not describing the processes I’ve built, because they are contextual and suited very specifically to the orgs I’ve worked with. However, if you absorb and articulate your PM Values and Principles they’d surely guide you to create the right processes.

For example,

• the Think Problem, not solution principle can lead you to create a documentation template or a checklist(better) where all your docs start with problem analysis first. And you may need a temporary process to foster this documentation discipline among all team members.
• Own the emotion may suggest a need for regular communication and coordination among different product peers/teams. A Bi-weekly demo/standup?
• KYC/KYP can suggest adding a step in your regular documentation/release process. If it ain’t dogfooded it ain’t released.

If you have any issue in creating your Values/ Principles/ Processes I can help. When you focus on the PM’s problem you are trying to solve, articulate your PM Values and Principles — the process part will be easy.

Thoughts? Questions?

--

Originally appeared on medium

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. 

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.