Full Transcript: Alok Pareek on the Product Love Podcast

This week on Product Love, we revisit a conversation with Alok, the founder, and EVP of Products at Striim.

By nature, Alok Pareek has always been curious. As a kid, he had the tendency to question why and how the systems and products around him were built. To him, complaints about a product or an experience were fascinating as they provided insight on how people perceived things. Instead of adding to their complaints, he had an inclination to defend the way things were made and how they operated.

The intricacies behind a product’s creation only fueled his thirst for knowledge. What was the product team thinking? Why was something designed like this? What was their justification?

It’s probably no surprise then that his curiosity led him to product management. Without an innate desire to question why and how things were made, would there be any product managers in the world?

His habit of peeling back the layers of a product and dissecting its’ nature only helped him examine his own logic behind creating products at Striim.

We also discussed the challenges of creating products that last, and Alok shared great advice for product managers.

I am now happy to share a lightly-edited transcript of that conversation. Whether you prefer audio or love reading, I hope you enjoy it!

You can check out the original post here and stream the audio version here or subscribe on iTunes today.

Eric Boduch: Welcome lovers of Product! Today, we’re here with an old friend, Alok Pareek. Alok is currently a founder and chief product officer at Striim. Alok, can you give us a little bit of your background?

Alok Pareek: Sure. So first, thanks for having me here, Eric. Currently, as you said, I’m a founder at Striim. I run all their product development and strategy. My background, I started my career awhile ago at Oracle where I was in their database development team for over a decade, working on the kernel itself. And then I was a CTO for a company called Golden Gate where we specialized in some data related products. Then about five years ago, I took a foray into starting something from scratch, and now we are at Striim.

Eric: Awesome, awesome. You’ve always been a passionate person. Why are you passionate about product?

Alok: Well, it’s hard not to be passionate about product. One of the interesting things… very earlier on, I’ve been sort of curious by nature, as a person. Every time, you look at different systems in the world or look at products in the world, you often find that people are complaining about something, frustrated about something, or sometimes they are thankful about some experience they’ve had. My inclination was always to defend why somebody built it that way. It was never to say, “Yeah I’m also frustrated by this.”

I used to try to be curious about what were some of the constraints and boundaries. When somebody designed this, what were they thinking? Wasn’t it obvious to them, for example, that this would not be such a good experience? I’ve always been sort of built that way since I was a kid. I don’t know if that passion ultimately took me down the product line but I do think it has something to do with that.

Eric: No, I think it is. I think it’s difficult building products that people really love. It’s a challenge.

Alok: It is. Absolutely. Especially, products that are there to last. Often times, there’s a spectrum of different things that come and go. Some of them are quite ephemeral, and they just come in to be the buzz for a short period of time. But to make real products last and potentially at scale, that is a much harder thing to do. It goes back all the way to in my view to systems, how things evolve, not necessarily just products but also customs or rituals. If you take a look at why things exist, and things that actually survive. I’ve always derived a lot of inspiration from nonsensical things. There will be superstitious things about, “Hey, you shouldn’t do this. You shouldn’t walk under a ladder.” I’ve always gone back and sort of been curious about why that evolved that way. Why did that phrase stick? There is a parallel between designing and building simple, long-lasting good products to see what emerges ultimately as sort of equilibria or the stable state of something.

I think it is a challenge to actually get something long-lasting and meaningful, and especially one that everybody has positive feedback on. It’s not a simple thing.

Eric: Yeah. When you think about something that people love, it’s not just the product, it’s the whole experience around it. It’s all those interactions, all those touchpoints. You’ve mentioned rituals, right? Talk to me about rituals or superstitions and one that you learned about that had a cool background.

Alok: I mean, there’s a lot of interesting things, right. For instance, when I was growing up, there was this thing about that if you sneeze, your grandmother would say, “Don’t leave the home right now. Bad luck is going to befall you.” And that time, you’re a kid and you just kind of hang out. You don’t really think much of it. As you become older and you wonder back. I mean there’s sound advice in that. In olden times, what she learned from her grandparents that there weren’t a lot of doctors around, they were in remote areas. It was sound advice that if you fall sick and you go further from your home, you might actually die.

The application of that to the product part is this thing about sometimes I’ve often found that my own team and engineers might rush to fix something. They’ll be like, “Oh the customer has this problem? Let’s fix it this way.” As opposed to taking a step back to see, “Could I have prevented this in the first place? Is it a real problem? Or is it a manufacturer problem?” I think I’m drawing a parallel between those two things but there are these parallels. You can introspect, as well as reflect on these things because if they lasted, there is some truth to them. That’s sort of what my point was.

Eric: Taking it down that road, product teams – what attributes do you look for in a product team?

Alok: Well, I like people who have a lot of energy, who are not afraid to come in and raise ideas and question. I’m not afraid of that. I actually like people like that. I think those are the type of people who are serious about changing things. That’s definitely one trait which is somebody that has a lot of energy and passion for both contributing meaningful towards change. That’s one. Two, being very ethical. Being disciplined and ethical. I think I look for that in people. Typically, people who jump around or unfocused, I find them generally… they have a use. But for a product like Striim that is more of an infrastructure thing, it’s meant to be long-lasting. I find that that’s not quite the place for them but people who really have this passion towards saying that they want to bring something to market longer-term to survive and to sustain. I look for people like that, who have built a true product that has lasted.

Partly, I’ve done that when I walk. No matter what part of the world, it’s great to actually walk a street and look at a logo, be it a bank, or a retail shop or you’ve built something that these guys are using. That’s a great feeling. I look for people who have that kind of attitude, that kind of vision. I like it when lots of people use my services, my technology, my product, or my platform. Obviously, they have to be smart. That’s a given.

Eric: What about domain expertise? I didn’t hear that as one of those. Is that important or is that something that can be taught? Do you specifically look for that when you hire?

Alok: Well, I think it depends on the role when you’re looking for people. In certain roles, it’s a lot meatier than others. In general, if you have a very… let’s say if you have someone order the charts, then I don’t think it matters that much. There are people like that. Very rare, but you can find people like that. From an engineering point of view, I just look for … from a development point of view, I just look for very, very smart people. Great programming skills, great coding skills, design skills. On the product management side, I do think that domain expertise matters. And again, with product management, in my view, there’s a range of responsibilities one may have.

There are people who typically might be more concerned with how to actually take something to market, which is the product marketing management aspect of things. Then there are the true inward facing product managers, for example, where they might have to literally write specs and talk to engineers. In that area, if you truly want to contribute, and not sort of be more at the periphery at the product then I think domain expertise matters because it helps you shape and drive the product pretty great. I think sometimes it depends on the product as well.

Eric: Absolutely. You’ve worked on a lot of technical products in your career. So that leads us to technical skills for product managers. Must-have? Or does it vary a lot on the type of product they work on?

Alok: Yeah, I agree with that, Eric. I think it’s heavily dependent, in my view, on what type of product you’re working on. For example, the type of stuff I work on, it has to do with technology at a very low level. These are things that we are really shunting around bites between machines and across a network at high speeds, worrying about latencies, things like that. So when you are designing something like that, I think you cannot be anything but technical if you want to drive that product. If you are not technical, obviously there’s a lot of value that you can have in the product team but I would probably then tend to use that kind of expertise in more in the user acquisition side, or go-to-market side because there are people with tons of expertise. This is changing.

If you take a look at how we bring products to market right from SEOs and how you think about user acquisition, search terms… There’s a lot of that type of expertise that potentially someone who is deeply technical in that specific domain may completely lack. I think you do need a combination of those two things to truly bring the actual product to market. So technical expertise matters to the point that if you’re contributing to the product,  and meaningfully from a design point of view, from a functional point of view. Number two, if you have a product that is actually being used by enterprises, operational teams and you have actually not sent your dev team, but product managers. The product managers have to have that amount of confidence and credibility in the technical aptitude to meaningfully bring in requirements towards reshaping and getting the next version of the actual software and the product.

Eric: So now you’ve done product management at big companies, big software companies like Oracle. There have been startups, Striim being the most recent that you’ve been working at. Talk to me about how those might be different from a process standpoint, from an expectation standpoint, maybe from an organizational standpoint.

Alok: Yeah, it’s a good question. Very different experiences in my view. In a large company, let’s say like Oracle. I actually had two separate stints at Oracle. One was the first ten years and they acquired my previous company and then I had another three years there. They were slightly different so let me talk about that piece first.

At Oracle, what I found was that you already had hundreds of thousands of customers that, by the time I got there, that they were marketing and shipping their product, too. To a large degree, the amount of innovation and the rate that you could bring new features out was curved almost. So if you have some earth-shattering brilliant ideas, but by the time it gets fruition, by design, there’s an amount of time that takes for that to come because you have to worry about legacy constraints. You have to figure out backward compatibility issues and all those things that come into the product cycle.

So a product manager these days, despite them having the desire and the capability as well as the input from the customer to change things, they don’t necessarily have that kind of impact where they can come in quickly and steer the ship in a new direction or even in an impactful way and that’s at a large company. The funnel coming into the product design cycle for its’ next iteration, it is comprised of a lot of different legacy considerations so that is very different. When you contrast that to a company like that to Striim where you have employee one, two, three, right? You have actively no loop coming in this stage. This is where your vision matters. This is where your own imagination matters and you really have to believe in yourself to take that leap to say, “No. I’m going to get to the first version of that thing on my own accord.” It pushes your limits. It forces you to think a little bit further to say, “No. Why would they buy this? Why would they use this? Why do I believe this is the first time this thing is coming to market?”

I think that’s a different way of doing product management, so I think that in a startup, you really truly… it’s a cliche that you have to wear multiple hats but there’s no getting around it. You don’t have the budget to just go around and hire because you don’t know what you’re building. Often times, even though the fundamental driver of your idea is constant and can be sustained, the actual manifestation of that from an implementation point of view is likely as every entrepreneur knows. You also know this, I’m sure. It changes. It’s not quite clear. You can be quite rigid whereas there you’re curbed. Here, you almost have to stretch yourself and be very, very flexible and be willing to change so I find that to be the contrast between truly large enterprises and startup.

Eric: So what words of wisdom would you pass to product managers now? What words of wisdom would you pass to the startup product managers and those product managers at Oracle? Those new product managers working at Oracle? And would they be the same, or would they be different?

Alok: Good question. I don’t know if I deeply thought about that but I think that is commonality at least instinctively. The people who go and bring product management at Oracle, IBM, or Google – when they start off, I think that they better learn from people who have been there awhile. If they try to come in and say, “Hey these are my ideas. I’m gonna change it.” They’ll likely hit a wall and get disappointed very quickly.

For startups, I would actually encourage them to get people from these larger companies because I think that there’s a discipline that these guys build of saying no. It is important in life. It’s a very common mistake that people want to do everything. I think that’s true that you have to be able to say no, that’s not a good idea. No, this is why we’re not going to do this. I think what happens is that you hear that a lot in big companies. It’s not always good. But I think what happens is that you have enough of that input, where you can easily take the trashy ideas and push them to the side because you know it will never fly with some customers.

If you have no experience and you’re a product manager joining a startup, you want to do all these things but you don’t know how. You don’t know what actually it means to be adopted by more than a hundred customers. Leave alone a hundred thousand customers, right? So I don’t know if I answered your question.

Eric: I think you did a good job of answering my question.

Alok: Another thing I want to say is, be on the nerve center. If you’re a product manager, you don’t want to be on the periphery. You want to be on the nerve center of a product, especially at a large company that is truly a revenue generator for the company. You learn a lot. You’ll be able to contribute a lot, whereas some companies have thousands of products. So it depends if you’re a great product manager and you really wanna drive things, be on the nerve center is my recommendation.

Eric: So what trends do you see coming up that are important for product managers that they should be aware of? What should they be concerned about?

Alok: I think two things come to mind. One, I think the nature of how software is being developed. Products can spend a larger domain but I’m restricting my comments at least for the technology-oriented products, and software-oriented products. The way software is being built is changing very, very rapidly. It’s all of the tooling around it, the actual process around it, the integration process, the deployment process, the rollout process… It’s just in a flux right now. To a large degree, we have learned this from the likes of these mega-companies like Google, and Facebook, and so forth. Because of the sheer nature of the challenges they’ve had, where they’ve had to deal with such a scale which a lot of other companies have not dealt with before.

They were forced to do a lot of homegrown tooling, and that’s why you kind of see the whole open source movement around it that resulted. They build it, and they want other smart people to say, “We’re stuck. Help us.” This becomes a very interesting cycle in the software development process so I think you need to be aware of that. That’s changed from how things were done twenty years ago where you kind of came in, had the requirements got in phase, had a functional spec and you have a design spec and you vote towards the product. I think that’s changing. You really have to be much, much more on your feet and agile.

Agile is such a loaded word. Everyone uses agile. You do have to be agile. You have to be flexible. That’s one. The other is the approach to market. I think earlier product managers were thinking how once something is built, they would go in for the enablement process for their teams. For their field teams and say like, “Here’s our proposition. Here’s how we’re going to our customers. Here’s how we’re going to pitch our product.” I think that’s changed. I don’t think that model fully works in this day and age.

I think product managers have to loan the new tools that are coming up, like things I’ve alluded to earlier like what are the community forums where developers are asking questions related to my product, and how do I actually go there and incentivize these guys to come to my website or come to my community forum? Or come to my support side? So start asking questions. I think you have to be creative in a different way. You have a traditional model of sales enablement and I think that’s changed dramatically. You still need it. What I’m seeing is a shift in how customers are purchasing products where they have pockets of people in their company who may just learn about some cool product or some great technology through word-of-mouth so they say, “I want to download this and try that out.” So product managers need to be aware of: Who is downloading that? What is their nature? Why are they doing that?

Then having that loop with them to reach out, at the right time, to see if they’re at the right point and if they could need help in a certain way before the sale machinery kicks in. I think they need to be aware of that. They need to absorb that to be successful.

Eric: What’s a product you really love and why?

Alok: It’s hard not to appreciate the iPhone. It’s a great product. It unifies and integrates several different products. It makes several products obsolete. It truly has become indispensable. Smartphones, at large but the iPhone in particular because of the simplicity of its’ design, the simplicity of its’ interface, and the wide penetration they have been able to get. If it was cheaper, then it would put other phones out of business so that’s my personal opinion. I’m really impressed by that. I think they’ve done a tremendous job of obtaining both the mindshare and being super productive. Making us super productive almost in every facet of our life, no matter what age you are or no matter which culture you’re in. It’s admirable on what that product has done.

I would also think that Striim would be a product like that. I’ll do a plugin here. We’re also trying to change things differently, where we’re trying to catch things on the wire. The sooner you are closer to the origination of an event or data, trying to deal with it, so that you don’t get into that massive data dilution problem later on. It goes back to my earlier comments about the cat and preventing something. One of the interesting things is… we’re all generating so much data today and it begs the question, “Where are you gonna store all of this data?”

You just can’t store all this data. Our own minds don’t function like that. We don’t store every single thing we hear, right? We organize it, we compress it, we index it in our own brains. I think it’s important to take a lot of incoming dilution to say that it’s uninteresting so I’m going to background it. I think at Striim, this is what I’m excited from a product standpoint, we’re doing that. In the future, we’ll solve this massive problem of dropping uninteresting stuff at the edge. Because otherwise, that will become a problem over the next few years so I think that’s what excites me. I think that’s also going to be a very impactful product.

Eric: Awesome. What gave you the inspiration for Striim? It was WebAction then, now Striim, right?

Alok: It was actually a combination of two things. One, I definitely have to thank our previous customers when I was challenged with this face of data replication. With data replication, you want multiple copies of data. As you’re making the copy, sometimes, things happen while you’re copying stuff. DNA works that way, right? Arbitrations happen. Things change. Same thing with data and a lot of customers would ask, “Hey. Something is changing here. Can you tell me what’s changing?” It was hard in the previous product that we had to fully give that visibility. It’s sort of that early visibility in the pipeline in itself.

You’re copying something from Point A to Point B along the way, we could actually tell you what was going along with it. That was visibility inspired by our customers trying to ask those kinds of questions where they were believing that something was going on within their business but they had no visibility. That is one. The other is an actual evolution that goes back to loving to build things and if you take a look to where I started off from when I was contributing to the Oracle database kernel, where you store data then have data replication where you have it for high variability and for application. Now you’re putting intelligence into that, which is the next step of it. It’s to say as data is coming in – can someone sniff it for some intelligent patterns and anomalies for either fraud or business intelligence purposes? I think it’s a combination of AR customer feedback, and two, partly just trying to innovate to the next version of the product.

Eric: You’ve done a lot of cool things, so what are you most proud of?

Alok: I don’t know if the question is from a product standpoint but…

Eric: It’s open-ended.

Alok: I think it’s the people I work with and some of the teams I’ve built and things I’ve learned from these guys and the mentorship. I don’t feel like this is a job. When I work with younger engineers, they come in with all these ideas and you mold them back and forth. I truly love that. It doesn’t feel like a job. On the product side, I’ll refer back to what I said earlier – there is no, at least in an urban city, there is no city block where if I walk 100 feet that I don’t see a customer that is using a product I’ve contributed to. That makes me very proud. I like building things like that which are being used in everyday life. You’re making an airline reservation, you’re making a phone call, you’re making a banking transaction by transferring money. But I think those are the things I am proud of.

Eric: So, three words to describe yourself? One of my favorite questions.

Alok: I think curious is definitely one. I like being curious to the point of being probing. I like to know how things work, especially the things I’m very interested in. More on the fundamental level. Definitely, I would say that I’m a curious person by nature. Two would be long-term consistency. I think if you say something, you should be able to stand by that no matter which error you’re in, or at least be easily able to either retract, justify or defend that, which comes down to more of an ethical type of thing that I talked about in terms of whom I look to hire. What you say at one point has to stand across time otherwise it goes back to the same product thing where we can’t really build meaningful products today if you say A, and then the next day, you’re saying the opposite of A.

As I go through my career, whichever product I work for, you have to be able to say this is the best at what it does, and then be able to defend that ten years later. Because in life, you end up talking to the same people and so that long-lasting consistency is something else I aspire to be consistent in that fashion. For the last one, I would say I’m also flexible. I think that’s something life teaches you. As you go along, our constraints… not everything can be changed by you so you try to control it at the degree that you can. In the end, you have to be flexible to adjust for the other variables that surround you and incorporate that, and then go forward. I would say flexibility would be another one.

Eric: Stylish?

Alok: Hahaha, wouldn’t be in the top three!

Eric: Thanks Alok. It was great. I enjoyed this.