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.   

Evolving A Sprint Process That Everyone Loves

What is fun for a team of 10, quickly turns in to a nightmare for a team of 25, and a disaster for a team of 50.

Every time I see a startup scale up, I find them running in to and complaining about quality issues, communication break-down, stressful work environment, demotivated teams, and chaos. Typically, all the roles that CEO/Founders were doubling up as (Product/Tech/Sales) pretty much need to be handed off. And that demands a quick influx of team members who can take up these responsibilities. And it also makes people adopt standard processes that seem to have worked for others. That, unfortunately, creates even more stress.

When new people join, they bring in new knowledge and experience, and also a baggage of cultural orientation. And they are expected to hit the deck running. So, without being immersed in org culture, they have to take up critical communication and leadership roles. What you end up doing as a founder is distancing yourself from the core team you once managed directly. Even if you are pro flat hierarchy, what you are creating is still a hierarchy. And when done all of a sudden, it creates subtle panic and chaos. While startup life is all about chaos, ability to organize and structure this chaos is what separates winners from losers.

The success of a product is undeniably a function of its quality. And software product quality, in turn, is a function of its development process. You don't realize it initially because passion trumps over the silly hacks, issues, rework. But as you start hiring beyond your core team, you'd have people in the org with whom you communicate via other people. Unorganised/Assumed/Naturally-formed structures often create hurdle in the flow of information.

Even a flat hierarchy is a hierarchy. 

The more distance you have from the last node of communication the more important it is to think about setting up a process and create a communication map for the organization. It is critical since the success of your product is directly affected by what processes are you following to build it. In next part of the post, I'd discuss some abstracts from a real situation I was tasked to change and how we, as a team, were able to evolve a process that everyone loved following.

Software development process 

Let me try to describe at the high level, the situation we were in. We were split across different locations with both the product, the design and the tech teams spread evenly across the two locations. Teams at both locations were used to following their own half-baked development processes and tools and even the culture of interaction and cross-team communication were different. Add to that, multiple products with a common set of features, different technologies, platforms and different leads.

The general expectation was as follows:
 - everyone is occupied enough,
 - everyone knows what they are supposed to be working on and why,
 - are enjoying their work,
 - are working efficiently and
 - at any point in time, it is easy to determine if we are making good progress

Nothing exceptional about the expectations. Pretty basic, right?

None of them were being fulfilled actually.
 - people would generally complain they're either too free or too stressed
 - forget the why part, they were frequently breaking each other's code and spending a lot of time in rework
 - motivation? this wasn't really pushed as much by the management. It was more of a personal agenda as I was interested in making sure everyone is happy and content with what they are working on.
 - we had no way to tell if everyone was working at their optimum efficiency
 - every time we needed to determine status, a guy had to go around in the office and gather status

Most org related issues are non-unique. If you can relate to the situation described above, at the high level, feel free to add the people issues, ego-clashes, old versus new, the quick hackers versus the quality conscious, messy details, the nuances, the little friction points, and other problems you've experienced or can imagine. We've probably had most of those as well, in different quantity and flavor.

So now that we have a real flavor of the situation I'd take you through the journey of how we dealt with it all at once, but slowly.

Now, when I look back it seems easy. But, when you're in thick of things it can be really overwhelming. Because, I didn't know the entire problem, and there is no standard way to solve these that I was aware of. Plus, since it was assigned to me, everyone expected me to give them a fix. Like right in the first meeting, the question was what process should we be following from now on?

Answer - I don't know. But, I guess I can never give you a process. We can try a few things and evolve something that works for all of us.

I could feel the disappointment. People weren't convinced. Decentralization can be painful. (Do you hear it, crypto-fans?) However, stubbornness is a virtue sometimes. A weak argument said with conviction lands better than a strong one said without it.

Here's how we were able to evolve a process:

1. Started with a simple Team occupancy chart and allowed developers to share how occupied they are during the next sprint. Let people know you trust their word. They could simply fill it with any number they deemed fit. Usually, we used to get values like 25%, 50%, 80%, and 100%. That was a good reflection of where we stood, and what we need to make all values 90-100%.

2. Created a Sprint calendar. We decided on 2+ Week Sprints (meaning it should have 2 weeks of development ). It started with a Backlog refinement meeting where we made sure we had enough time for developers to do estimations, development and enough time for the QA to test and release. So technically, it was 3 weeks between the start of the sprint to production release, but in-effect we had releases every two weeks. Religiously did Retrospective meetings to understand the problems and solve them one by one. Made sure it is followed. Trust is important.

3. We identified 3 KPIs that we needed to improve. There were more KPIs on and off, but these stayed throughout. This was the crux of setting up the new process.

•  Minimize creep: the tasks being added in the middle of the sprint.
•  Minimize rework: (reopened tickets) for developers and testers.
•  Minimise residue: tasks left over at the end of the sprint.

The first sprint meeting was not really about introducing any process, but just making everyone cognizant about the KPIs. When we did the first retrospective, people were listening more seriously and suggesting how we could improve stuff. And from the second retrospective onwards we started seeing some improvement.

4. Improve communication, encourage everyone to speak out openly. Not everyone knows how to articulate their issues well so bear with people getting worked up. Accept mistakes. Don't point other's mistakes, allow them to accept it. Don't allow others to point a finger at anyone, let people get comfortable to own up. Give people enough time, keep asking "what else". Once we knew the KPIs, everyone had really nice suggestions to improve them and we just accepted and experimented with most of them.

5. Note down action items. Assign it to people and Convey it to them clearly. Follow up.

6. People felt empowered and started looking forward to this meeting. We started with checking progress on the KPIs, and then the retrospective basics - what went well, what didn't go too well, what needs to change. What initially took 90 minutes started reducing down to less than 60 mins of meeting.

Impact

It took about 4 sprints to have a process that everyone was happily following. Here's a quote from one of the emails I wrote when I introduced the process - "The idea is not to have process overheads but be little more disciplined and organized in our work so that we can get stuff done with less stress." 

The process wasn't created, it was evolved. It was a loosely defined process that evolved over a period of time and everyone contributed to it. It wasn't set in stone but everyone knew how to go about doing their stuff. Most of the decision making was still left to people's judgment. Some of them needed a little handholding here and there, but most of it was smooth.

• Everyone was occupied enough and we knew who's free when. 
• Overall there was a sense of belongingness, content
• Work was more evenly distributed and everyone knew what they are doing through the week (and weekend ;-))
• Every day we had a clue about where we stand and how things are progressing

Achievement (1500% improvement)

The entire exercise did not dramatically improve our efficiency. But, we exactly knew what's feasible to deliver in what time without stressing everyone. The high point came in when we were able to optimize an annual exercise, that historically needed a stressful fortnight. It was reduced to just one late night effort. 15 days and nights of stress got reduced to just 1 night. A 1500% improvement would sound outlandish, but, numbers are funny.

I hope this gives you some clues about how you can improve the development process in your organization. I am happy to take up any questions you might have.

Liked it? Have questions? Write it out.



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