Lessons from Ex-Google & Facebook Product Manager

Rags Vadali, is currently Chief Product Officer at Lantum and has been involved with building and shipping software products his entire career - both as an engineer and a product person.

‍

1. Utilise communication tools

There are a few class of tools that, as product people, I think are quite indispensable to get your job done effectively. First, there are tools that enable us to quickly express our ideas as prototypes, visuals etc. I benefit from using Sketch and Proto.io, with these being the two tools that I use on a daily basis.

The second set of tools, are tools that help you express these ideas to your engineering counterparts. Nowadays in the world of Agile, that is any sort of project management tool. My preferred one is Jira, but there are others that people use so that engineers and product managers can come together.

The third critical set of tools are the ones that enable you to understand data about how your customers are using your products. Our preferred tool right now is Mixpanel, but in the past I've even used Google Analytics for the website. It's quite a powerful tool.

And finally, I think you need to have team communication tools. The job of a product manager involves communicating and over communicating. At my previous company, 4th Office, we used our own tool internally, but other tools include Hipchat, Slack etc.

2. Test your product early

It's a unique stage of a product’s life cycle, where you just have a sufficient amount of a product to put it in front of users, but you don't have enough users to get usage, to decide whether it's working or not.

One thing that you can do, is what's called a 'Starbucks test'. Essentially, we go to a Starbucks, set up a little station with a camera (we put up a GoPro to record it) and offer to buy people their coffee, as people come into the shop and while they wait, you get about 3 to 5 minutes of their time. Just give them your product and ask them to use it and give you instant feedback.

It's an effective way to get unbiased first user impressions to test, "OK if this a simple idea that we're building, is this is going to be actually useful when people just encounter the product in the wild?" because that's how they're actually going to encounter it in real life. It's very, very valuable, especially when your product is still in a bit of an idea stage, because you don't need to have a full product to do this kind of testing right.

Another example is when you're working on a more complex product such as a marketplace. We were working on this product that was connecting publishers with advertisers. You can imagine you would have to build a lot of infrastructure to be able to test that product. What we did is we actually faked it. We would get on the phone to both sides, and essentially offer to them what the product would offer, and then we would do the connections in the back end. It was a great to test feasibility of the ideas on both sides, but also to get an insight of what they would need for this sort of stuff to work.

This is really invaluable and a good way to get cheap feedback before you actually spend a lot of time building a lot of features. Once your product gets to a stage where it is actually ready for people to use it, quite a useful technique is bringing a few users in to a session and basically recording their entire usage of the app. When you ask somebody how will you use this app, those answers are all very targeted to what you've asked them. But if you just let them be to use the product and basically capture all of their reactions, once you do anywhere between 6 to 8 of such interactions of users using it, you can actually get invaluable feedback in terms of patterns.

Where are people getting stuck? What do they do? What do they not do? So those are a few ways in which I would approach very early stage product testing.

3. Ask the right questions

When hiring, I ask people to describe what a bad day at work looks like and I throw it in the middle of talking about products or about something completely unrelated. I love this question because it's something that I find people aren't prepared for.

But more so, I want to get into what is it that motivates them to do good work. What are the kind of things that they would rather not see in their workplaces? And it's a two-way question right, so for me I want to just judge if I can offer this candidate the right environment to come work where we are. At the same time I'm trying to get a sense for what is the best conditions under which this person is going to work so that you know, I can create those conditions for them.

4. Learn from your mistakes

A long time ago when I was still an engineer, I walked into a performance evaluation and my manager at the time actually gave me a bad evaluation. I sat there a little surprised, and I said, "Hey!" and I listed all the things that I had done. He said, "Rags, perception is reality". That I think is something that at the time I was kind of mad at him about. But overtime you know, especially as I've been working in more product roles, I realised it was quite profound feed. Because if you think about it, a product manager’s role is about managing multiple stakeholders at once. You have engineers & designers who they work with on one hand, customers, sales, internal clients on one side, and their managers, the people who report to them.

It's very easy in that situation to compartmentalise information to different groups. So for instance, if you're talking with engineers and they give you an update, it's very easy to forget to give that update to the marketing team, and essentially time and time again what you run into is there is dissimilar information that different people know that you work with. That basically creates a perception among people that is very different for the same product that everybody is trying to build together.

It goes back to what he said, "perception is reality", everybody then thinks that the product is in a very different state, whereas everybody is working together and it's the same thing. So I think for me it's been one thing that is on the top of my mind to make sure that, that perception of the product, or whatever we're building, is well managed and handled, because otherwise it can actually really hurt the products that you're building.

5. Define your KPI's

The approach we take is that we want to have one primary KPI and focus everyone’s attention on to that one, and then from there you derive a bunch of secondary KPI’s. For instance, for the current lifecycle of the product we are in, we have a few hundred active users and we are in a beta kind of situation. So the most important thing for us is usage. So our primary KPI is the number of active users, and because we know that through everything else we can do it could be good or bad, but if our active user base is not growing and growing fast, we’ve got a problem.

The way to define what is the most important KPI, is to look at what you know are the five to ten things you want to measure and say which is the one that you absolutely need to be nailing.

6. Find your ideal process for devleoping new products

I would consider mine to be a three-stage process. The first stage is validating your core hypothesis, and this is something that you can do nowadays without actually having to build the product. This is usually done by building prototypes that are as close to the real thing as possible, and putting them in front of what you would consider your target users. So with the feedback you will get, it will lead to what I'd call fast failure. So either this won't work, or you find the few things that you think are resonating and valuable enough for you to then move on and to invest a little bit more to go on to the next stage.

The second stage is building an MVP, or Minimum Viable Product. So this is where you build a product that has features that work, but it doesn't have a lot of the bells and whistles. It’s essentially enabling you to test the hypothesis that you came to in the first stage, but with a real product with a wider set of people, and you don't have to actually talk to them to do it. So you can put the product in their hands and do it, and you're talking about a few hundred people here. The goal of this is to get initial what you would consider product market fit. So you wanted to build something for this particular group of users. Is that actually resonating with your target group?

And if that phase also proves to be positive, that's when you go into a more developed third stage, which results in a classic beta or like closed beta sort of a thing wherein you actually add a lot of the bells and whistles if you will, add a lot of the hygiene features that these products need, and from then you release it at scale.

- Rags Vadali

‍