Innovating in an Established Industry With Harish Pandian of Alcumus

Kayla: Thanks for tuning into Product Chats. On today's episode, I talk with Harish Pandian, who is the VP of Product at Alcumus and we talk about meeting users where they are, using a data first strategy, and also how to impact an industry that's been around for a while. So hope you enjoy the show and don't forget to leave us a review.

Kayla: Hey Harish. Thanks so much for coming on today.

Harish: Hey, Kayla, nice to be here. Thanks for having me.

Kayla: Yeah. So in a minute or less, can you tell us about yourself?

Harish: In a minute or less? Right. I am Harish, currently VP of Product for EHSQ in Alcumus. A little bit about my background. Most of the experience for me came from early state startups.

Harish: A lot of figuring out product market fit and build stage. For the last years, I've been a part of three startups, which either went through acquisitions or successful investment rounds. And the most recent one was eComplaince, which got acquired with Alcumus. Then I took a larger role within the team to build out the product team, to build out the product approach. I currently manage a portfolio of about five products within Alcumus. Everything related to EHSQ which is environment, health, safety, and quality.

Kayla: Awesome. And then something I wanna kind of talk about is that product market fit. Can you dive into that a little bit?

Harish: it's a very interesting concept. Product market fit truly is not something that's achieved and just dropped off. It's something that you have to continuously work on.

Harish: But it's really figuring out the sweet spot between what is the customer problems that you're trying to solve for and how ready are the customers to actually have those problems solved in innovative ways. And finding an intersection between that and the solution that you offer is really what product market fit is.

Harish: It's taking the solution. It's taking the opportunity that you have and actually commercializing it. If you think about a specific problem you could have four different ways to solve it. Which of those four different ways is the best from a commercial standpoint and where the market is ready and the customers are ready to approach it and basically consume the product.

Harish: You never stop it. Like I said, we continuously discover it. Continuously enhance it. As we go through in any industry, users usability pattern changes. Buyers buying pattern changes. Now we see a lot of product growth formats within the SaaS industry. So adaptation curve changes there.

Harish: It's one of those things where you just have to keep continuously working at it. It's typically a little different in the early state startups, cuz you're trying to find the first step into the door to make a problem or a solution commercially viable. As you start to grow, it's something that you'll have to keep just focusing on day in and day out.

Kayla: So with that, right? How do you figure out what to focus on? Like, do you have any favorite frameworks or like right now you're working on five products. So how do you figure out how teams prioritize and what they should be working on?

Harish: That's a very good question because a lot of the time, the place where organizations miss it is in the alignment of how that value is delivered. Goes back to fundamentals.

Harish: I strongly believe that product's job and product manager's job is to own the problem or own the opportunity. And you really focus on how you are adding value to the end user or the customer to change their day to day lives or change how their problem is being solved. Once you figure out that, and once you figure out the problem, the solution and the how and the why that correlates towards it, everything starts to kind of fall in place.

Harish: Then comes your strategy. If this is how we are delivering value, let's find a framework to quantify it. Then you can break it down into specific competence and align your teams around it, towards approaching that value. But really it comes down to understanding the problem really in depth, understanding what are the contributing factors and how does your solution solve the problem for the end customer or the user in one way, shape or form.

Kayla: So when you're trying to understand better about like the challenges or the problems that your customers are solving, are you going out and doing user research or what does that look like to make sure that you're actually building out that like product market fit?

Harish: User research is a very big and important component. It's made wonders for us at Alcumus.

Harish: I'll talk a little bit about that. Before that there's two areas that we definitely look.

Harish: The one is that broad market research. What is the total addressable market? Where is the industry growing in broad terms? We do have relationships with the industry analysts to understand how the industry's growing.

Harish: What kind of solutions are customers looking at. At a very broad strokes level to see if that problem has opportunity in itself from a commercial standpoint. But the real work where the rubber meets the road is when it comes to understanding problems at the user level. So there are different types of user research, evaluative, generative so on and so forth.

Harish: The generative research, which is more open-ended trying to understand users in their own native environment and try to understand how those problems impact them on a day to day basis is what really drives down to how we can accomplish those. From Alcumus' perspective, we do a bunch of things.

Harish: We do broader discoveries through calls, through surveys with our customers. We also do more in depth generative research by actually going out and talking to users. And even if they're not users, if they're a target end user who may or may not be in our ecosystem. One of the simplest examples is we provide software for construction, like construction workers on the field.

Harish: We found out a good way to chat to them is just show up at 7:00 AM to the near McDonald's near construction sites. And they're happy to talk usually to provide insights into their day. That's been a very effective one for us is to do more of user research.

Harish: But doing those user researches really open up our insights into the problem that we are actually solving. It exposes the biases that are really on the ground, and then you can actually tailor your solution towards how you can modify that.

Kayla: So I think something you touched on that I think is really interesting, right, is it's understanding the customer journey, but also when you're doing that research, you are understanding even more the customer journey, right? Hey, they get up, they go to McDonald's or where are they? And you're meeting them where they're at. So it's super, I think, interesting that you're going this like deeper level of let's actually find out their day to day. Right. But also you're thinking of it in a, like a very creative way of how can we get them at like the opportune time, right. They're not at the end of the day, they're at the beginning of the day, they're fresh. They're able to think they're able to share with you that kind of information. So you can figure out that market fit.

Harish: A hundred percent. It's very interesting. We've had conversations during the lunch hour during the morning, even outside sites. It's just people talking to people, right? You'd be surprised how many people are just willing to have a five minute conversation to share information about their day. That's simply , what we are asking them to do.

Harish: And you're right. A lot of the time when we think about a user persona. Even when they're using an application, they are still, it's a part of their day. The time has to come from somewhere. They're busy doing some other activities. So understanding what else they do really brings focus into how you want to tailor that experience. How short or long that engagement should be. What's top of their mind, so it starts to paint that picture really well.

Kayla: So with that, we're gonna hop back in a little bit, but I wanna kind of take a step back and learn more about how you actually got into product.

Harish: My product journey is, I've been around a lot of places. My background was in mechanical engineering.

Harish: So I did bachelor's in mechanical engineering and fortunately, or unfortunately, I never had the opportunity to work in it. My first job was a quality analyst for a tech consulting firm. So from there on, I moved to a business analyst role within a tech consulting firm. And then I did a few projects at a more business level and I kind of liked the business aspects of it.

Harish: I went to masters at Schulich, I did masters in business administration with marketing and strategy. Came back into the workforce and joined the more business side of things within software. So my role evolved into client implementation manager and client services manager more with account management and software product development.

Harish: Along the way, I founded a small startup company that I ran for two years, that's really what took me to product management. It was a services company and we also built a software product, which was back in the day, a barcode scanner before barcode scanning was a native iOS and Android capability.

Harish: And that really brought me into trying to solve a problem for customers and for users and to productize it, to package it and take it to the market. After I wrapped up with that, I got into full-time product management. Was with Postmedia on the B2C side for about a couple of years. Then I worked with the FinTech startup called Sensible. Very early stage, trying to figure out product market fit for an AI driven software product.

Harish: And then I landed at Alcumus as head of product at that time as the first product manager, or the first product executive, trying to build out the team. And the rest was history over the last four years with them.

Kayla: So with that, you mentioned you were the first product executive. So for like aspiring product leaders, what are like a few things, if they're gonna be the first product manager, product executive, what are a few things that you can kind of share with them as things they should start thinking about or things they should start doing as they're like first priorities?

Harish: Absolutely. One of the first thing that any product manager should do is own the domain. That comes into understanding the problem really well, understanding the solution and understanding the processes and tools. If you go out to pragmatic framework, there's so many areas where you can learn about, there are so many tools that are available today that weren't 10 years ago.

Harish: So consume all of that. Create the best practices for prioritization for road mapping for running your sprints and scrums and so on and so forth. So be strong in fundamental basics and execution. If you cannot execute and deliver something that you are imagining or deliver some value that you are proposing or you've figured out through research, then everything else falls apart.

Harish: So that's the first step. Be really good at execution. Be really good at delivery.

Harish: The second step. And this is where I've seen a lot of product managers struggle to grow into leadership roles, which is basically the ability to communicate and influence outward and upward. The core team, and the core problem, solution statement kind of comes naturally for product managers.

Harish: They'll be able to influence designers and engineers and data folks a little bit more comfortably in the domain. When you start to expand your horizon, how do you influence sales? What's in it for them? How are you making their life easier from a go to market perspective? How are you influencing customer success and all the way up to C-suite?

Harish: How is your product in line with the business strategy? How are you helping the organization move in a specific area to conquer the next big thing? And that's one of the things I definitely recommend product managers to focus from day one. Storytelling, the ability to communicate an attitude simply able to synthesize whatever you want to communicate in like five minutes or under.

Harish: These are essentials for basically any professional to grow into leadership, but specifically for product managers, given the cross functional aspect of it and given how much impact they have on the business of other departments and the organizational strategy itself, that would be my biggest recommendation. Start working on that as early as possible.

Kayla: That's something that like, I hear a lot, right. Get buy-in from all your different audiences and know how to talk to the different audiences. Right? You're not gonna talk to like a salesperson the same way you're gonna talk to the CEO. But it's about like understanding and I guess at the same time, right?

Kayla: It's a parallel of understand your customer and your customer could be like, who consumes your product, but your customer could also be the CEO. Your customer could also be sales, right?

Harish: A hundred percent. That's exactly what it is like from a communication standpoint, you need to understand your end customer or user or your audience and tailor your message towards that. And sales is a very good example, like if you are going to pitch in front of a VP of IT and VP of operations. Obviously you are prepared to go into certain level of technical conversations, right? Product managers have to think about the same thing. If you're going to talk to the CEO and CFO, make sure that you are talking about ROI, how much investment do you require?

Harish: And what is our capability to execute those kind of things. If your audience is VP of customer success, let's talk about how does this impact our customer onboarding journeys. The time to value, like how quickly can we get a customer in place? So you want to tailor your story towards it. I don't want to seem like you want to be good storytellers and makeup stuff, but it's more about actually talking to their pain points and how your suggestion addresses towards that.

Kayla: So with that, right? Talking about pain points, right. You can understand the pain point and then you get all these ideas. Right. When you're sitting down with these construction workers, you're getting a ton of ideas. You might be getting ideas from sales, from success and something you mentioned was prioritization. So how do you figure out with all these ideas, what you're actually gonna prioritize and what you're gonna put on the roadmap?

Harish: Okay. I will probably break that into two concepts. We don't want to prioritize ideas. We want to prioritize problems. Problems are the ones that we prioritize based on how impactful it is for a customer. And we want to solve for the end user. The ideas come from the solution side of thing. Once you've identified that this is the problem that we need to solve, the solution can be, like you said, there's like 10 different ideas. There are systematic frameworks to go through the solutions.

Harish: One of the best examples is a design sprint. I've seen that being very handy with designers and especially when user facing applications, take the problem, break it down into a one week sprint where you come up with 10 ideas, quickly prototype each of these ideas by the end of the week, just test it with the simplest form of prototype to get some leading indicators on what kind of solutions will solve for the problem.

Harish: I'm diving very specifically into user experience side of things, but the same framework applies to even data related problems or any sort of problems that we can solve within a product space. Prioritize the problems. Solutions get as many ideas as possible, validated against a hypotheses. And basically you go around and test the hypothesis to see if there's traction towards it.

Kayla: Awesome. And so I wanna kind of shift gears. So you work in an industry that's been around for a while. Let's talk about like how you've created change and impacted that industry.

Harish: That's a very good question. So if we look at employee health and safety, right, it's an industry that's been around for over 70 years now, and it's a fairly mature industry, which hasn't seen significant disruption in the last 20 years. But if you still think about the problem in itself every year there's over 300 million workplace incidents happening around the world of serious impact.

Harish: So the problem still exists in a vast area. So when we started down this journey, we were like the status quo is not good. There needs to be something better. And through data analysis, we found out that the organizations that were safe did something very, particularly different from the organizations that were not that safe, which was basically a specific type of behavior their end users did more activity in identifying hazards.

Harish: So we went down and we started doing user research to understand what's their day to day and what's their biases. And we learned that the real barrier to somebody reporting a hazard or not is not at the application layer. It's in their day to day. It's because they're busy and they're very biased in terms of the value that these safety programs provide. They were not contributing towards the program in itself. And if they did, they were inherently becoming safer.

Harish: So taking down that problem and understanding it really, really to the core, even if it's a day to day problem, even if it's the simplest thing like Uber. Like if you take the taxi industry that's been there for the longest time, how do you disrupt it? Let's get to the user's biggest pain point and understand what is their ideal state, and then let's solve for that. So once we learned that their biases were really understanding the value behind the safety, we tailored our strategy from creating complex workflows to how can we educate the user that if they do something it's valuable.

Harish: How can we experientially provide feedback and provide data to show that every single activity has a consequence and that's for the right benefit? And once you start modifying the behavior at the end user level, people start doing more stuff and it starts to affect the outcome at a very high level in terms of safety. So again goes back to the fundamentals. Like let's take the problem, whether it's a status quo or a new problem, but really get down to understanding the depth of it from a user perspective from the contributing factors perspective.

Kayla: So with that, something you mentioned is data. So like what are you looking at? How do you make sure that you're actually using data or that you're leaning in on the data when you're building your product?

Harish: The data is a tricky one because you can use it. You can also abuse it. You can pay, you can modify, paint the picture that you want to have. When it comes to data, like couple of things that really help us.

Harish: From day one, think about the data that you can gather. You will gather you have already and how you will use it. A lot of the times I've seen applications and products being built without that approach. And then you come and look, start looking at the data and the data doesn't make sense, or it's not structured enough for us to make sense out of it.

Harish: So have a data first strategy, at least in today's world for every single product. Use the right tools. There are plenty of tools available all the way from really quick and easy ones like Mixpanel, Amplitude, Pendo to more in depth ones like Looker, Sisense or Power BI and so on and so forth. Have a tool in place, prepare to gather data from day one and create hypotheses and structure to understand how you want to tackle those particular data points.

Harish: You go into the solution side of it. Let's say what's a problem. And if we solve this problem, what will the ideal end state for the customer or the end user be? Now, can we quantify it? Can we quantify with two or three different things? And if I take the Uber example, like, can we say if the pain point is finding a ride quickly, can we quantify it?

Harish: Can we say that in the future we will make customers be able to find a ride within five minutes or within two minutes. Within our own framework for our health and safety products, the KPI that we set at the first place was, we want our end user to be able to submit a hazard in under 60 seconds. Is that even possible?

Harish: We don't know, but at least we've set that as the ideal benchmark and ideal goal. Now all our data tracking follows towards that approach. The data's anchored by every hazard, by every person. The start time and end time was locked. So the data architecture has to come really early from the problem definition and KPI identification standpoint.

Kayla: So with that, obviously sometimes your predictions aren't right, right? You make up these predictions, you're like, we think they're gonna be right. So how do you create the space within your team to allow for them to, I would say the word is like fail or come up with like a wrong prediction. How do you create that like safe space for your team?

Harish: That comes down to culture. That really comes down to how you develop culture within your team. You want to orient your team members to be in a very comfortable space to fail and to learn from it. And more importantly, to fail fast and to fail quickly. One of the things that we've embraced in the past is we look at our team structure, our team output in terms of outcomes.

Harish: For example, let's say there's a roadmap item, which is on a specific area. We try to quantify the OKR, not as a delivery or not as do this feature or do that functionality. Let's just quantify that in terms of an outcome. Now, in order to achieve that outcome, you probably will fail two, three times.

Harish: It's okay. Let's just consciously front load, the failing. Let's try a few prototypes. Let's come up with as many hypotheses as possible and go around it. The only thing that I would recommend is think about one-way and two-way doors. The two-way doors are things that you can go and you can always back out.

Harish: So it's okay to go a little bit more aggressive in terms of experimentation in those places with live audience and live usage. If you fail, it's okay. You can always turn back. And if it's a one way door, if it's a big architectural decision, then you want to pay more due diligence, but really comes down to culture. Don't call it as failure, call it as learning. Let's call it learning. Like, what are you going to learn in the next six weeks about this particular problem before we actually go into the depth of it.

Harish: And discovery mechanisms, help user testing, helps just changing the semantics around it probably helps. It's something product and engineering have to work together in creating that culture and being safe around it. That should hopefully that helps.

Kayla: So I think something that you bring up as a really valid point is kind of rephrasing it right. As a learning versus as a failing. Right? And being able to like just that shift in the wording, right allows people to be like, okay, well, instead of this, me feeling like a failure, because I didn't have this correct hypothesis what can I actually learn? So when you're actually trying to learn or look at this like feature that didn't work or your hypotheses that didn't work, are you sitting down in a room every week? Or like, what does that look like for you and your team?

Harish: For me and my team, so there are a couple of ways we do it. One is from a learning perspective there are experiments that the teams conduct systematically. There are discovery sessions that they conduct systematically. Every project or every product has core KPIs and certain milestones along with it.

Harish: We usually review it once a month, at least at my altitude, I review with the team once a month to look at what's the progress update. But the team in itself is looking at on a weekly basis. Every week all the squads get together and they look at the experiments that have been conducted as a part of their progress.

Harish: Depending on the size of the experiments. If it's something really quick that's totally fine. But some of the experiments go for a couple of months. It's bigger once cuz you have to create an onboarding flow. You have to test it or you have to create a feature and you will slow roll it for the users for the first 30% of the users to get it in the first week, get some feedback and then look at it.

Harish: So really the feedback loop might change based on the solution itself. But it's important to programmatically have it in place based on the feature or capability or problem being solved. We make some decisions upfront. Is this something that we can just AB test? Is this something that we can experiment by testing with a select group of customers?

Harish: Or is this something that we need to have a full on beta before we launch? And we have that discussion early on between the product managers and product marketing managers, and they have a plan in place. Usually that plan kind of drives how you want to go about experimentation.

Kayla: So we just talked kind of about like leadership and allowing people to fail. So I want to ask you, what is one piece of advice you would give to an aspiring product leader?

Harish: For an aspiring product leader, one of the things that I would always say is like for any product manager, just get to the root of the problem, understand it the best as possible. Nobody should be able to outweigh the depth of the problem other than yourself. The solutions we don't care, like there can be multiple solutions, but get to the real depth from a user perspective, from a business perspective, understand why the customer or the user is making certain decisions on a day to day basis. Getting to the depth is absolutely important for any product manager. For a product leader the important piece is altitude.

Harish: You need to be able to operate at a higher level altitude, but at any given point of time, be able to dive into those details. And really that ability comes by the understanding of the problem. So for me, particularly right now, there are four products that are actively having commercial strategy behind it.

Harish: I'm operating at a higher level altitude, but at any point of time, if there is a problem, or if there's an opportunity, just the understanding of what this problem, what this product solves for a customer, for a user at the core level will give you the context to dive deep. I've never seen a successful product leader, not having the ability to dive deep and have those conversations whenever required. Obviously with certain level of clarity. It won't be too in depth, but that would be the biggest thing that a product leader can cultivate. The ability to move up the altitude and go down deep farther than required and have a solid understanding of the problems that you're solving.

Kayla: Well on that note of leadership, what roles are you hiring for?

Harish: We just hired a director of product last week. So that was good. We are hiring for senior product managers in growth. There's a lot of positive traction for us in our industry there. So we are looking at digital acquisition and growth a lot.

Harish: We are hiring for product designers and then a ton of engineers, product marketing managers, content writers, technical product writers and creative content developers for products. Those are the positions that we are hiring for aggressively. Actually we have about, I think, 50 or 60 open positions open today across Alcumus and probably two thirds of them will be product engineering.

Kayla: Great. And then where can people find you?

Harish: Alcumus.com. All of the positions are laid out there. If not, LinkedIn. Always happy to connect the dots for anyone who's in the network either at Alcumus or otherwise. LinkedIn is a very good place to even reach out to other product leaders within Alcumus, other engineering leaders within Alcumus regarding any positions or opportunities there as well.

Kayla: Awesome. Thanks for coming on today.

Harish: Awesome. Thank you.

Kayla: Thanks again to Harish for joining us on today's episode of Product Chats.

Kayla: If you want more product resources, feel free to head over to Canny.io/blog and we'll see you next time.