I spent two years of my life in business school, fell off the blog train, and have finally returned to the real world. I am now a product manager at VMware in Palo Alto, which is surreal when I think about it. I was drawn to Silicon Valley by the power of some invisible magnet; even the dissipating sheen of the Valley hasn’t dimmed the excitement for me. I feel lucky to be here, and I want to make the best use of this opportunity that not many people get. One of these opportunities most recently allowed me to sit it on an intimate discussion with Robin Matlock, the CMO at VMware. She shared with the group her five mantras for success in the context of empowering women in business and I want to list them here for posterity.

Have a growth mindset: I haven’t read the book, but I believe the general idea is that even if you think you’re not innately skilled at something, you can work towards getting good at it. I definitely think there is truth to the idea that some things just come more naturally to people (athletic prowess, mental acuity). But I also believe that hard work and repetition can be substitutes for natural talent, and that requires a change in mindset.

Ramp up your resonance: Find your voice. We play a passive role in the dialogue and expect to be heard without actually speaking. If you have an informed point of view, then you need the courage and voice to assert that. It is okay if there’s gaps in your knowledge – people at work do this all the time and I often mistake confidence for competence.

Network: It’s a journey, not a destination. Set a goal for how many new people you want to meet, and more importantly, think about who it is you want to meet (internal, external, customers, peers). Don’t clump with people you know, and this one for me is personally harder than it sounds.

Move on to move up: Fight hard on the court but once the fight is over, let it go. Don’t take it personally, don’t dwell on it. This one I think speaks for itself.

Connect with your core: Spend time to introspect and discover what truly matters to you. If you’re not working towards some larger purpose, there is truly nothing anchoring you to your job.

Finishing the first year of my MBA at Anderson and starting an internship at one of the giants in Silicon Valley have so far served to make me more cynical than ever when it comes to innovation. It’s not like I was particularly optimistic to begin with, but now I visibly cringe when I hear the words ‘ride-sharing’ or ‘on demand’. The app market is saturated, Google and Facebook have monopolised the ad space, and e-commerce is Amazon. This leaves a bunch of oft-used acronyms like AI, AR, and VR. While I’m skeptical about the more wide-spread applications of VR in the near future, I’m completely on-board with AR, especially with Apple’s new ARKit that is going to bring AR to the mainstream. While we mostly know AI as personal assistants or chatbots, I am hoping to see more of true AI (not mere lip-service) in a wider range of industry verticals.

Insert futuristic Matrix style image here

My main motivation behind this post was to talk about what could possibly usher in a new way of computing—quantum computing. There are two reasons why I am incredibly excited about this.

This is true engineering; not an app, not a vague idea, but an entirely new school of thought. At a very basic level, scientists and researchers are redefining the study of molecules (or quasi-particles).

This technology is no longer theoretical, it is poised to become a reality within the next five years. Google, Microsoft, Turing, and Rigetti are all working towards achieving quantum supremacy (the point where quantum computing outperforms classical computing). Google has even gone on record to say that by the end of 2017, it will have a 49-qubit system.

The ramifications will be enormous; the capabilities of quantum computing systems far exceed anything we have in existence today. In attempt to learn more about the underlying mechanics, I picked up The Theoretical Minimum thanks to a recommendation from Susan’s Book Club (highly recommend). I’m not going to lie, it’s a pretty daunting topic to learn about, but every time the lightbulb goes off when I understand something, I smile.

I’d love to be ahead of the curve when the quantum wave hits; I want to continue to read and learn (next on the agenda is Quantum Chance). I also recently discovered the most amazing thing – you don’t need access to a lab to get your hands on this technology. Rigetti just released Forest 1.0., an API for quantum computing in the cloud. I can’t wait to get my hands dirty — sometimes I really wish I’d stuck to the engineering route but that’s a post for another day.

I just read a great post by Dan Wolchonok at HubSpot about the impact of retention on user growth and revenue. At face value, this sounds pretty darn obvious, but really it isn’t until you see the models that you realize just how much of an impact this one metric can have on your product.

There are many different ways to calculate retention, the most common being what percentage of users returned within a predefined period of time since they installed the app. Most mobile apps push for an increase in users with an inorganic app download campaign, however users acquired this way are less likely to retain, meaning that the number of installs ends up being just a vanity metric. You would onboard users month on month, but the number of users would remain more or less the same because of people churning out of the app.

The interesting thing here though is that for all intents and purposes, you can tell people that your user base is growing! The true story though would be that in Month 1, your growth rate was a cushy 30% but in Month 2, your growth rate has shrunk to 5%. I liken it to a leaky bucket. Unless your inflow is greater than the outflow, user growth is impossible and therein lies the importance of retention.

Like Dan says, the impact of this can be seen on retention as well. If the app was a freemium app with in-app purchases, it is likely that only users loyal to the product or users that can’t function without your product will begin to pay for it. That means you need to retain users for a certain period of time before they become actual payers. If your retention numbers are crap, then you’re not going to have enough revenue. You could try to increase the revenue you get from the payers that you do have do even things up, but that rarely ever works.

But yeah, there’s a nifty Excel sheet in the blog post which I haven’t had the chance to play around with, but I’m definitely going to! Check it out. As a side note, I really appreciate when writers model this kind of stuff with real world examples and data because otherwise it ends up being this totally abstract concept that I’d never think to even apply in the first place.

I recently met with my friend and former colleague, and over a few drinks we started talking about how our careers have panned out. While I’m fairly happy with what I’ve done so far, his trajectory has been extraordinary. When I asked him how he did it, he told me

Perception is everything.

He started out as an engineer but he quickly rose to the ranks of a technical architect in a remarkably short period of time. His abilities were revered at my previous company, simply because he was able to do things much faster and better than anybody else. By his own admission though, he isn’t half as good as he pretends to be. Whenever there was a large project to be done, he volunteered—even if he didn’t have a clue about how to start. He just believed that he’d figure it out along the way.

This was alien to me. I have this tendency to defer to authority, especially when I recognize that someone is more experienced than I am. If I am not a subject-matter expert, I feel like I should keep my mouth shut. This also ties into the feedback I received from my manager right before I left

Be more aggressive.

I think people know more than I do. And yeah, I suppose humility isn’t necessarily a bad thing but in the context of being a product manager, it’s the worst. As a PM, you need consensus and you constantly need to push new ideas into the pipeline. If you let yourself get beat down by everyone around you, then you essentially become useless.

I was great at execution, every feature that I owned made it into production seamlessly. But it was in the more unstructured areas that I floundered. While others firmly held to their beliefs, I didn’t feel confident enough to have a strong opinion. What I’ve come to learn is that no one knows everything, no matter how old they are or how experienced they are. This is way easier for me to say but much harder for me to practice.

This is something I absolutely want to focus on during the MBA. Learn how to be more aggressive and forceful, in order to make my voice heard and defend my opinions vociferously. I also want to learn how to bring structure to unstructured problems. I work much better within the parameters of a defined framework, but real business problems don’t fit into neat silos. I know I need to get better at it and I’m determined to work towards it.

In order to succeed in the tech world, the most frequently touted piece of advice is to find a mentor—a mentor is someone you aspire to be and has probably been down the same path that you have. And then of course, there is advice about how to find a mentor.

Follow them on Twitter.

Ask for a coffee chat.

Be useful!

I bought into all of it because it seemed way too easy. Have coffee with this one person and your career will just miraculously take off. BOOM!

If only that were true.

This whole process of finding a mentor and all the rules involved (don’t ask someone to be a mentor, it has to be an organic relationship; coffee is okay, dinner isn’t yada yada) seem like an elaborate dating ritual and a total waste of time. Why? Because with the internet and the ability to cyberstalk possible “mentors” comes the ability to get all of this knowledge for free (no coffee involved)! All the best possible mentors in the world are sharing their wisdom for everyone to consume. They’re answering every question you could ever have and then some.

For instance, as someone interested in product management and entrepreneurship, I have subscribed to over 15 newsletters, 30 blogs and 50 Twitter accounts. There’s more information there than I could ever hope to consume. There are live podcasts, snap stories, interviews – there are infinite ways to learn. And the best part?

It’s free.

It’s from some of the best minds in the industry.

It’s geography agnostic. I have the same opportunities to learn sitting here in Bangalore, India as someone in Silicon Valley does.

Would it be cool to get a cup of coffee with say Mark Suster? Sure, just because I would have a chance to meet someone I truly admire in person. But meeting someone for the sake of meeting someone with an agenda to further your own career doesn’t sit right with me. If you really wanted to learn, there are mentors abound. You just need to look in the right places with the right intentions.

Talk to people because you want to talk them, not because you identified a list of probable mentors on a spreadsheet and you now spend a good hour a day kissing ass on social media.

I’m not opposed to the idea of having a mentor, but I object to how we go about finding one, or really even the need for one in its current definition. Personally, I’ve gotten to this point in my career by having role models, not mentors—just absorbing everything they so generously give to the world has helped me advance my career. So yeah, stop trying to look for that one elusive mentor. There is no shortcut to success. True passion and interest trump all the other bullshit in any case.

It’s been a while since I last blogged, and I can only say that I’ve been managing my time poorly! I really need to get better at this. In an ideal world, I’d like to come out with one blog per day, but I feel like I would be setting myself up to fail, which is why I’m not going to commit to that just yet.

In any case, I’ve learnt a tremendous lot since I last posted. The stuff I’ve learnt can easily be the fodder of several blog posts, and this is going to be the first of many. My first lesson is that product management is nothing without data. To run a successful product company means to build a product and a system to collect data from the product.

Collecting data can’t be an afterthought.

You can choose whether or not to analyze the data you collect, but you need have systems built in from Day 1 that have the ability to collect and store this data.

Fortunately, there are now multiple tools that can help you do this which is why there is no excuse for neglecting this step. I’m working on a project that at first glance is intensely creative, but the thing is each decision about the product is driven by data and not gut instinct. I’m prone to saying stuff that is just based off my intuition, things like “this menu is too complicated, users won’t understand it”. I know better now.

This isn’t a conclusion, it’s an opinion—a hypothesis. Every hypothesis needs to be tested and the only way to do that is with relevant data. So in this particular example, I would look at the following aspects of the data to see if my hypothesis is correct.

How many people even use the menu?

What buttons in the menu are they clicking?

Are people getting to where they want to go through the menu?

If a significant percentage of users are able to use the menu effectively, that means my original hypothesis was incorrect. It’s taken a while, but I now know not to make unsubstantiated observations based on my gut (unless something is obviously terrible or amazing). When there’s something new you want to introduce to the product, then A/B testing is the best way to decide which version is most successful.

In a nutshell, an opinion is a hypothesis. Test it until it’s bulletproof. Only then does it become a conclusion. The only way to test anything is data. You need qualitative analysis to understand what the data is saying, but the first step is to collect and store data (which most companies miss from my personal experience). Don’t be that guy.

Most days on the job, I feel like all I do is reply to an endless barrage of emails. But I guess that’s what product management comes down to essentially – making sure all the stakeholders involved are in the loop of every decision you make. In the beginning, I didn’t see the importance of really documenting every single conversation, but I soon realized that it was a necessary evil.

Firstly, it introduces accountability. If you have committed to something or if other people have, then putting it down in writing gives more weight to the commitment. Secondly, people have short memories. Having this stuff written down means you always have a trustworthy source of information to look up when you need to. And finally, when you join or leave a company, the whole “knowledge transfer” process gets much easier when your email is properly organized and archived.

These are a few ways that I have set up my own inbox. Now, I’m a little anal because I can’t stand those Inbox (29) notifications… which means they need to go and they need to go fast.

I use Gmail filters extensively so that I don’t have to look at build updates or JIRA tickets unless I want to. They get marked as read immediately.

I don’t like to Star emails since I think they just go completely off my radar – I prefer to keep those emails I have to respond to as unread. It annoys the crap out of me, which makes me reply to the mails much sooner.

Boomerang is a great tool because half the time asks from the PM are routinely ignored unless you actively follow up. If it weren’t for this, I’d have to dig into my Sent mails more often than I’d like to. Another feature from Gmail Labs I can’t get enough of is the Undo option. I might be an idiot, but I have this habit of accidentally sending out mails when I’m only halfway through. Being able to hit Undo when I do this is a godsend.

Finally, I use SaneBox for my personal email. So far, I love it. I can’t be bothered to unsubscribe to all the promotional emails I get (the downsides of having a really old email account), but SaneBox makes sure I don’t have to see any of them (nor do I get notified of them). Every week, I have a quick glance at all the mails that are brushed under the rug to make sure nothing important goes into that black hole. SaneBox is smart and learns from your actions; it honestly saves me a ton of time.

I don’t think I would go as far as far as Cal Newport though who believes email is the bane of modern existence. Email is just a tool, how you use it is upto you as an individual. Could the tool be improved? Sure. But until then, all of us slaves to email need to make the best of it.

Most people in the tech industry can attest to the fact that the definitions of roles vary across industries and companies. This definitely holds true for product management. In smaller companies, it isn’t unusual for a product manager to be an analyst, a UX designer and a project manager rolled into one. However in larger companies, the role of a product manager is more strictly defined. But regardless of how you define the role, there is one thing that always firmly lies in the bucket of a product manager – the metrics.

Analysts can certainly help dig out relevant data, but I strongly believe that a product manager should be just as familiar with the tools for data analysis. In any case, getting the data isn’t the hard part—making sense of it is. Now there are mainly two points during the product development lifecycle that data comes into play

While deciding what feature to build i.e. identifying the metrics that a feature aims to move

While conducting a post-mortem of sorts, to see if the feature achieved its objectives

But in my own experience, I have found that as the primary stakeholder of a specific feature, I tend to be biased towards the success of the feature. This is when I unconsciously start to mold the numbers into a narrative that fits my own agenda and choose to ignore data that doesn’t neatly fit into said narrative. Fortunately, I’ve become hyper aware of this over time and I’ve come up with a few internal checks to make sure it doesn’t happen again.

Some of these might be obvious to more experienced PMs, but they surely help me make the right decisions in order to draw true conclusions from data.

Before the feature goes into development, identify metrics that the feature aims to impact and make a projection about what those numbers will be. This could be anything from increasing engagement by 10% or reducing the bounce rate by 5%.

Put this down in writing and don’t touch it until your feature is rolled out. This will help test your hypothesis without any bias.

Looking at the data immediately post-release is important to make sure that everything is working as it should (no major bugs, no obvious issues). However, don’t draw conclusions about the success or failure of the feature just yet.

The feature needs to be used by a statistically significant number of users over a pre-determined range of time to obtain results within a confidence level. I’m borrowing from how most A/B tests are conducted; I believe the same principles would apply here as well.

Once you’re convinced of the accuracy of the data, compare it to your initial measurement and projections. Seek the truth and nothing else.

If the numbers clearly indicate that your feature didn’t work as expected, trust that your numbers are correct (assuming you did all the due diligence in steps 1 to 5) and you were wrong.

I will caveat this to say that there might be situations where your data is completely off, but this is where your intuition and PM spidey senses come into play. Qualitative analysis is important, but don’t let that overshadow what your data clearly proves. I would definitely recommend reading this excellent blog post by John Vars, who talks about The Bipolar Nature of Product Management (I was hugely inspired by it).

I’ve posted before about the Idea, Build, Launch and Learn loop, but the essence is that getting feedback about a design is the only way to grow and improve your product. Now I know this a questionable metaphor so bear with me—my career is my most important product.

As an overachieving wannabe perfectionist, it was always hard for me to hear about my weaknesses. I’ve realized only recently how important it is to power through the discomfort to get the feedback I really need. The feedback can come from anywhere in the totem pole: your boss, your peers or even your subordinates. In fact, the more diverse the pool of people giving you feedback, the more effective it will be—just like you would interview a variety of customers about your product.

I recently received two pieces of crucial feedback that I’m incredibly grateful for. The fact that this was corroborated by multiple people makes me confident that these are areas I really need to work on. There were two things that stuck out to me

I need to be more assertive. Now most people who know me might find this hard to believe because I’m usually a pretty outgoing, opinionated person. The thing is though, I have this need to please authority figures. I like approval, heck I yearn for it. I also respect people who are older and more experienced than I am, and I tend to defer to their opinion instead of defending mine. However, I’m learning that I don’t need to be the smartest or oldest person in the room to have a valid opinion—as long as I’m able to justify my stand, I shouldn’t be afraid to actually take a stand. I know that I will be surrounded by some pretty strong personalities in an MBA program, so I’m looking forward to holding my own.

A lecture on the subject of questioning authority…

I need to be more analytical. Give me a structured, well-defined problem, I can solve it like most people can. But unfortunately, most problems in the real world are vague. A huge part of problem solving is defining the problem and devising a framework that considers all of the inputs and variables; I still haven’t figured out this bit. The lack of knowing and the uncertainty frustrates me. Instead of thinking at a macro-level, I settle for thinking at the micro-level. This is part laziness and part ignorance. In order to fix this, I intend to read more about problem solving frameworks that successful “problem solvers” use. Lateral thinking is something I could benefit from too. Again, practicing case studies in an MBA should help me get better at this, like they say the first step is admitting you have a problem.

Wikipedia defines regression to the mean as the phenomenon that if a variable is extreme on its first measurement, it will tend to be closer to the average on its second measurement—and if it is extreme on its second measurement, it will tend to have been closer to the average on its first. In simpler terms, things even out over time.

Let’s say you have a really terrible headache. You happened to drink a glass of orange juice and three hours later you feel much better. You would then attribute your recovery to the Vitamin C in orange juice. Now you start drinking juice every day to prevent headaches and voila, you haven’t had a headache in two weeks! Orange juice = No headaches.

But there’s a logical fallacy here—if symptoms are excessively severe this week, then next week they should be less severe simply by random fluctuations. If treatment is only sought when these symptoms are at their worst there will almost always be a coincidental recovery. This appears even if the treatment has no effectiveness whatsoever.

It’s simple enough to understand, but I’m stunned that I never actually knew about this as an actual principle until now. It kind of makes me wonder about all the statistics classes I took in school; what the heck were they teaching us?! I mean this is useful, real-world stuff that biases our thinking in every conclusion we draw and every decision we make. For that reason alone, I’m determined to learn more about behavioural science and statistics this year. I’ve started with Thinking, Fast and Slow, and next on the list is Predictably Irrational: The Hidden Forces that Shape Our Decisions. If anyone has any more suggestions, I’d love to hear them.

Posts navigation

About Me

My name is Nikitha Suryadevara and I am a product manager. I work on the cloud platform at VMware but my interests extend to containers, consumer tech, quantum computing and other seemingly unrelated topics.