We are excited to share the third episode of The Product Management Leaders Podcast with you! Our aim with this podcast is to connect you with some of the top PM leaders and share their real-world strategies and tactics for building world-class products. In today's episode, Grant Duncan speaks with Rohit Valia, VP of Product Management and Strategy at FICO, a publicly traded company. You probably know FICO for your FICO credit score but they do much more than that. Rohit has also led teams at Oracle, IBM, and Sun Microsystems.
Listen to the episode here, or continue reading!
Grant Duncan 0:05
This is the Product Management Leaders Podcast in which you hear from some of the top PM leaders about their real world strategies and tactics for building world class products. It's sponsored by Voximplant, the leading serverless communications platform and no code drag and drop contact center solution. Voximplant enables product leaders and developers to integrate communications into their products, such as embedding voice, video, SMS, in app chat and natural language processing. Join over 30,000 businesses trusting Voximplant. Now let's jump into the show.
Grant Duncan 0:41
Hi there, it’s your host Grant Duncan. Our guest today is Rohit Valia, VP of Product Management and Strategy at FICO, a publicly traded company. You probably know FICO for your FICO credit score but they do much more than that. Rohit has also led teams at Oracle, IBM, and Sun Microsystems. Let’s jump into the discussion!
Grant Duncan 1:08
Hey, Rohit, it's great to have you on the Product Management Leaders Podcast today. So to get started, can you share about your role and what company you work for?
Rohit Valia 1:19
Sure. So currently, I head the technical product management team for analytics at FICO. For those who are not familiar with FICO. FICO is great at looking at data and using our analytic solutions to predict consumer behavior. So we leverage that insight into building automated data driven decisioning. Most of you are probably more familiar with the FICO score, were in the FICO scores business as an example, we'll take a score and use that to predict a consumers propensity to repay debt. And so then one of our banking customers would use that to decide whether or not to lend money. So my role at FICO, you know, is to lead the technical product management team. And that encompasses many areas. So I might bore you with some of them, but it's a long list. But they all come together. So I think the reason I go into that is to kind of explain how all that is required, essentially, when you're trying to do automated decisioning. So we have one part of a portfolio, which is called the decisions portfolio. And this is about a low latency, high performance decisions engine. And this is based on our market leading FICO Blaze Advisor product. It's used by the leading financial institutions to make centralized decisions. As an example, in consumer lending. We then have our express optimization portfolio of products, which includes our market leading complex mathematical solvers. And these are used by enterprises looking to optimize resources. As an example, Southwest Airlines would use it to enable the planners to easily manage constraints and trade offs to find an optimal crew schedule each month. So when you're making decisions, you'd kind of tie these two things together, so you're getting to an optimal result. We also have an identity resolution engine, a part of my team, which is looking at the graphical relationship between entities such as a person and how other persons may be related to that person, say when you're trying to discover fraud by consumers, or say, know your customer situation, where in banks, you want to kind of know more about the relationships amongst those people. And so in addition to that, we also have a pretty well rounded portfolio in my team that includes analytics and machine learning, because as you know, machine learning is now being used more and more to power analytical decisions. And so we have tools for both the altering the model development side, as well as the deployment and operationalization of those models. So we have all the ML Ops as it's called, area where we help data scientists to author in notebooks with Python, and build scorecards and decision trees. And to get going, one of the things we'll hear from most of our customers is getting good data is part of their biggest problems. And so we work with data as well now we're building some new tools that obviously do the usual data ingestion with ETL, etc. But also going to new areas such as data explanation, data treatment, and that allows for model experimentation and model explanation. And from there, we are able to create business terms that are used in decisioning, or generate features that are used in the analytic model. So in the end, my role ends up being trying to bring together all of these technologies in a way that a company can leverage all of our tools and solutions in a consistent way to meet their business goals.
Grant Duncan 5:34
Yeah, wow, no wonder you're a VP. Those are lots of technical areas to work on. Interesting. So with such a broad array there of products, how is your team structured?
Rohit Valia 5:53
Yeah, so as you know, companies grow, obviously, and the specialization of roles increases. And FICO is kind of at that juncture where our product management team is getting more specialized. So we recently have split the inbound and outbound product management functions, as it is commonly called. With inbound, being more focused on the technical product management, and outbound kind of focusing more on the customer and market-facing side of product management responsibilities. So my team is focused on the technology management, and making sure that we are able to provide the development team with a clear set of requirements to work on. And we have functional leaders in each of these areas that kind of manage, what we call in Agile terminology, product owners. So using the safe principles, we have product owners that are assigned to various Scrum teams. So my team essentially manages those backlog items for each of the Scrum teams and also works with the outbound product managers to ensure that we are representing the market needs in our prioritization, as well as, as typical product managers, working with UX and documentation and other aspects of the product delivery.
Grant Duncan 7:33
That's really interesting that you guys have the inbound outbound split like that. How have you found that to be working for you all? Do you think it's a positive change?
Rohit Valia 7:45
Well, I mean, I've been in many different organizations including Sun Microsystems, and part of the time in smaller companies like Platform Computing, and IBM and Oracle as well. And in each of those companies, as well, as you kind of find that the teams have grown too large, it certainly helps to have more focus for managing your own workload and sanity, and in FIFO, we've kind of done both. I mean, till recently, product managers wore both hats. And so when you're wearing both hats, you're kind of split in your time prioritization, as in, you're trying to figure out, do I make sure my customers are happy? Or do I make sure my engineering team gets my slice of time, so they are working on exactly what I want them to work on? And so there's advantages of, you know, that model in that the product manager has a complete end to end view, personally, because they're involved in the customer relationships, as well as working with the engineers. So they have the technical, our day to day exposure as well. But the benefit of the split roll is, like I said, more focus and rigor to the area that you're focused on. So now as technical product managers, I find the team has more time for thinking through technology, innovation, looking at roadmaps in a clear manner that does not get clouded and interrupted, I would say, sometimes with other customer activities. And the outbound product managers are able to focus on the business aspects whereby they're looking at pricing and discounts and, you know, customer and market facing issues. So so I think It does over time require some degree of, I would say specialization, especially at this scale, because you want consistency on the one end for our customers in how products are getting priced and what packages they can buy from us. So holistically, they can look at things from that perspective. And we can focus, as now, my time frees up, to look at, you know, the user experience of the product in a more holistic manner. And our product managers can participate in that, as I said, from a more technical perspective.
Grant Duncan 10:40
Yeah, yeah, that's great insight, I'm sure others listening have thought about making that split, or at least this will probably give them some new ideas to see if they should consider that. So for you and your team, what metrics do you report and track on?
Rohit Valia 10:57
So I leave out the external metrics that FICO reports as part of investor calls, and such, right, so those are, you know, those are well defined, and they follow industry standards. And they are evolving as well, right as FICO kind of transitions to more of our business moving to SAS, and that change happens. But for my team, again, you know, focusing on the technology side, the biggest metrics, I would say we track relate to transactions. So transactions is kind of how most of our business is conducted with our clients in the sense that the solutions we provide them can usually be represented as a volume of transactions, whether it's loan originations or fraud transactions, so a lot of those use cases can be represented as transactions. And so my team's solutions are typically built in a way that you can count those transactions. And, and then if it's not transactions, then the other aspect of it is the usage of the Kubernetes pods. So many times when you have compute intensive tasks that are associated with our offerings, say in any kind of simulations or calculations, so those tend to have a lot of compute usage, of course, memory based boards. And so that's another thing that we track. Now, as we are offering SaaS services, the trick in SaaS is, and I've kind of been in the cloud industry for almost 15 years, pretty much, since I was at Sun and we invented what we were selling then as grid computing and utility computing. So the notion of having some density of usage rate, which you can count in different ways, but what we have is, worldwide, we have different environments in which we provide our customers access to our solutions. And in those environments, we need to have a certain scale of transactions to be profitable. So we are looking to essentially ensure that our environments have the right number of clients. And by right, I mean, there's obviously, economics of scale when you have more clients in a given environment, because the costs get amortized amongst the larger number of clients. But we don't want to... even though the software may scale to essentially allow us to keep adding more clients on the same environment, we sort of tried to balance it so that we don't have what we call a too large of blast radius, that, say, something untoward was to happen in one environment, it doesn't impact a large number of customers. So we kind of also balance on on that side of things. So I would say from a metrics perspective, I think it's mostly about managing the SaaS service in a way that's efficient and profitable.
Grant Duncan 14:26
Yeah, fascinating. I can imagine just the scale of the data for FICO is so massive, I can see why that's super valuable. You briefly talked about prioritization a bit earlier. Can you share how you think about prioritization in general and how you make trade off decisions?
Rohit Valia 14:47
Yeah, sure. So when looking at prioritization as a Product Manager, your role is very often defined to be, you know, "CEO of the product". Right? So when you're making those decisions you're trying to figure out, you know, where is my roadmap heading. And so when you are trying to specifically prioritize one feature over another, you are trying to balance between, many times, the current customer need and future sales potential. And while they should be normally very aligned, sometimes they're not. That comes from... as a Product Manager, and this is kind of where I throw in that the Product Manager is different from a Project Manager, right? As a Project Manager, you might be tempted to just take the feedback your client gives and you just implement it. But as a Product Manager, you want to be, you know, going as some of our leaders in my team have pointed out to where the puck is going. So the trade off decisions that you're trying to make are, do you invest in something that's current, which will benefit your current customers and certainly remove some of their irritants today, and how much do you invest in the future products where you know the market is heading, and in fact, some of those irritants will go away, because you would have given them something better? So it's kind of like, instead of breadknife, we're going to give you an automated bread machine. So why should we sharpen this knife, in a sense, right? So those are kind of the prioritization decisions that you end up having to make. Sometimes Product Managers are probably in the best position to make those decisions, because they have data on not only what customers are asking for, but also where they see the market heading.
Grant Duncan 17:04
I like the go where the puck is going analogy! How do you think about determining quarterly goals for you and your team?
Rohit Valia 17:17
I think the goals have to be aligned to, again, you know, as kind of steering a big ship, right, unless we are all moving in the same direction, we could all run in many different directions, which would make all of us run fast, but not get anywhere together. So the way we kind of work it at FICO is through a system called OKRs. Objectives and key results, if you're familiar with that.
Grant Duncan 17:50
Yeah, they're very popular these days, we use them too.
Rohit Valia 17:53
Exactly. And so we've kind of, I guess, been using that as a way to align the company goals. And so typically we publish our company goals, which are high level goals, you know, you'd expect there to be no more than five of them. And usually, there end up being more, so then you kind of say, okay, in those five high level goals... what I like to do, is for the team to try to do a bottoms up goals, which is like they would come up with their priorities, what they're seeing in their customer base, in their products, the needs that are emerging. And then, you know, we don't want to ignore those, but we do want to find a home for them in the overarching company goals. So we want to make sure that the goals that are coming up, they do find an alignment to the company's strategy. And obviously, the ones that align to the company OKRs are the higher priority ones, because we want to make sure we address those. And then there may be some outliers, which may make sense for certain teams to do, but only after they've kind of addressed the company goals. So that way, you know, you kind of get your your company goals, your team goals, your personal goals, sort of in that order of priority.
Grant Duncan 19:25
Especially if because of your particular product management role, working with engineering teams is very crucial. Can you share about how you work effectively with engineering?
Rohit Valia 19:40
Yeah, so essentially, especially as technical product managers and having that product owner role, which is kind of a safe term that we use. So the notion here is that Engineering has to respect the product owner, as if they are the customer, right? So the product owner has to act as the customer. And in fact, their role involves them, when they are accepting stories from an engineering completion perspective, that they need to think of that as if it's the customer saying, what you're delivering to me, will make my life easier and will work as advertised. Right. So there's that aspect of it. And I think engineering values that, because then it makes it real for them, because you're representing that all the work that they're doing in the end is to satisfy our clients. And so as the product owner, you are the proxy for the client, in that team. And it is your job to make sure that what's getting produced is of high quality and value to our clients. So really, the way it works is that, you know, when you're writing these requirements, so that's on the accepting side, but when you write these requirements, a good product manager or product owner will write them in a way so that it clarifies who the actor is. Actor, meaning what role of a client, or sometimes it can be, there's no human involved, it could be a machine to machine interaction, right? So you're able to define exactly who the actor is on on that subsystem. And what do you expect that outcome to be? So setting up the requirements in the proper way with the right acceptance criteria is really helpful for engineering, right? Because you could put some pretty loose requirements without giving the boundaries of what is acceptable. And that doesn't help anyone because, you know, a sprint later, you're like, this doesn't work like I thought it would. But your thoughts don't count. It's what on paper. So you have to kind of define it better, basically. So that's kind of I think the the biggest value product managers can provide their engineering counterparts, is to have well defined goals and expectations and acceptance criteria. And a clear backlog of requirements.
Grant Duncan 22:34
And do you have guidelines for how the product owners should create those requirements and the acceptance criteria? Or has everyone kind of been trained well enough?
Rohit Valia 22:45
So this is actually an evolution in FICO's journey. We've been, you know, adopting safe as, you know, the framework, the Agile framework. And a large part of the core teams that are working together in this agile journey, have been trained in the safe principles, which includes... and part of the split in product management comes from aligning to those safe principles, where the role of the product owner is clearly defined. And so I would say that we are on that journey, where we are clarifying for various technical product managers as to exactly what's expected of product owners. In fact, I'm leading a cross team, you know, community of technical product managers across FICO, to start the standardization in some of these areas, so that we can have a consistent way of both writing the stories and defining what we call done, right? Because everybody tells you, I'm done. But the definition of done is very vague. So we call it the definition of done. And that really comes from that acceptance criteria that I mentioned. Right? So having a clear acceptance criteria, which would establish what's expected, performance goals, stability goals, you know, there are some things which are just universal, like, you know, we assume every product from FICO will have passed security checks, scans, you know, a whole bunch of stuff. But when we're talking about features, we still need to define, like, you know, maybe performance expectations, usability expectations, like simple things, like you create a login page, but now, when I log in, it works but it takes two minutes to return a result once I'm logged in, so that's not acceptable, right. So we might say I need a login page, but it would be a lot better if you said, I want a login page that will, you know, log users when 10,000 of them are trying to log in at the same time, concurrently, and return a result within, say, five seconds. Right? Now, if you didn't do that, I mean, engineering could give you a login page. But when, in the morning at 9am, everybody's trying to log in, which is what generally happens, you'll have a huge delay, and a number of them are going to get timeouts.
Grant Duncan 25:30
Yeah, that's a great example of clear definition of done being helpful. Yeah. Very cool. How do you think about customer engagement and communication in your products?
Rohit Valia 25:45
Yeah, so like I said, I think customer communication happens, of course, at multiple stages of the customer's journey, and kind of bringing the journey to start at a pre sales level, right, because, you know, you have multiple touchpoints with a customer and it starts from their first impressions, it may be through a trial, you know. So the journey for a customer with our products, generally starts much before they became our customer. And it's not just that FICO, I mean, I was at Sun a long time, and a lot of our products were actually open source, so customers would have tried and used our products, even before we ever knew they're using our products. And so the the definition of customer engagement is is kind of fluid, right? I think in the world of SaaS services and open source software, you may actually not be aware how much your customer truly knows about your products. Because they experience it, they may have experienced it at a past company, they might have access to it through trials, they may have access to open source projects. So we kind of have to craft our products in ways so that we are prepared for their engagement with our products through all of those life stages. In fact, I would say when product managers are defining their products, and we used to do this at Sun, more so because a lot of our products were very high volume, that in the trial stage itself, we would have ways in which customers can experience our product. So there were well defined guides on how to try our products, right? So if you're defining products that are high volume, possibly, it might make sense to consider customer engagement starting at that point, right. But now, when we are kind of in a high touch customer engagement, that's when you know, you might be doing live demos, and the narrative and breadth of use cases that you build into your demos is useful. So for instance, everybody knows, FICO is in the financial services domain, the FICO score certainly is. But a lot of our products are actually very much applicable to almost every industry, like the Southwest example I gave. So our products can be used to optimize a credit risk portfolio, but they might just as easily be used to solve a scheduling problem for an airline. And so when we are crafting these demos, we need to kind of think in terms of that the customer may actually be just about anyone. So purposefully, in some of the cases, I've tried to build, you know, customer experiences for our customers to try out our products in other industries, like a health care app, you know, which demonstrates all of our capabilities, just with a different spin on it. So you can see that these capabilities are more generic, and will give ideas to even ISVs on how FICOs products can be used in other ways beyond the current set of customers. And then so as you're kind of thinking through this, it's about what collateral, what demos, what communication channels will you be at? Right? So it's quite obvious that in highly interactive one on one meetings, you're able to customize your message, but you have to think in terms of scale by way of communities. So FICO does have robust communities around our products. We have a community.fico.com site. So we engage with customers there as well. So that's part of the communication, and opening up channels of communication that you have to kind of think through.
Grant Duncan 30:05
Yeah, I think community is becoming an ever more important thing, especially if it's a technical product, or is dealing with code in some way. So one of the things that everyone deals with is failure. How do you recommend PMs to think about dealing with failure?
Rohit Valia 30:26
I would say it's better not to have any. But, you know, but it happens, right? It happens to everyone. And, you know, it's kind of an old saying that you learn from your failures. But the trick is to truly see and analyze them. Right? So, I mean, dealing with failures is obviously, one would say, a learning opportunity. I'm still a big fan of not failing, but, you know, if you do fail, at least learn something from it. And the way to learn from it is, I would say there's probably broad categorization of why you might fail, right? So you need to kind of look at... as an example, it could be a case that you were just early in the market. And so timing could have been the reason you fail, you did everything right. The same thing, had you done five years later, might have been a success. And many times, you'll find that happens. And I'll give you an example of Twitter, iy had an app, I think it was called Vine, which was like a short video app. And that didn't quite take off, it was pulled off the market. And now I find Tik Tok. And it's everywhere, right? So what's with it? It was a very similar concept, and Vine failed, but Tik Tok was a huge success, and everybody's kind of doing it. So obviously, you can see where one failed, another succeeded. Now, you can kind of try to, you know, dissect it to see what caused that failure, and what, you know, what somebody probably saw as that failed experiment, and build upon it, and made it a success. So the idea might not be the the thing that didn't work, it could be the timing, it could be the execution, it could be the marketing of it. So I think that's the thing to learn from failures, is to be able to analyze, and see how you could have done better. And sometimes it's just rinse and repeat better.
Grant Duncan 32:55
Yeah, that's a good example. So if I give you a magic wand and you had one wish - you could solve any product management problem, what would that be?
Rohit Valia 33:06
Mmm hmm. So problems for you know, Product Management, vary quite a deal based on the organization they are placed in. Right. So different product management groups are empowered differently. So one of the things that, you know, if, if product management is truly the "CEO", I think that I would say, the, the most liberating thing for a product manager to be empowered to make all the decisions and be held accountable for them. And I think that would be a great, I guess, empowerment of product management and product managers, and give them the leeway to operate much, much more efficiently. Now, obviously, like I said, every organization is different, you know, sometimes a single product is the beachhead, the company is trying to promote, and sometimes that product is part of a web of strategies. So everybody's got to play their part, and kind of fall in line. So there isn't truly a magic wand. But certainly, you know, playing closer to the product managers, the CEO of the product kind of maxim would be a great way to empower product managers.
Grant Duncan 34:42
Yeah, that's a great one. I'm sure a lot of listeners would resonate with that. So how do you explain to your family or non-technical people what you do?
Rohit Valia 34:56
So you know, my family. They're big into sports. I have boys who play squash and watch almost every sport. So I think I could probably get across to them with a sports analogy, right? So the product manager is more of a coach. They're not really doing the coding, but they're there to make sure the team has their place, right, and they're a well functioning organization that is delivering to the goals that have been set. Now, they're a coach, they are not a team owner. So there are people that will be looking at what the coach is doing, and providing, you know, higher level goals for them to align to. But I think that's kind of the closest way to think of it that they're, they're the coach for the team and making sure they have a high performing team.
Grant Duncan 35:56
Yeah, no, I haven't heard that analogy before for it, but it's pretty good. I like that. Alright, last question for you here. Thank you, you've provided a lot of great insights here today. So I really appreciate you coming on. Who is one of the person that you think we should have on the podcast?
Rohit Valia 36:13
Oh, you know, I think from my perspective, I think to get even better view and glimpse into FICO would be our CEO, Will Lansing or even Claus Moldt, our CTO. I mean, they have a huge advantage in getting, you know, our customers perspective on these things, and also directionally on the industry as a whole. And they'd be able to give your audience a much better view into FICO's business, it's markets, and actually a lot of what is transpiring in in the technology and financial world.
Grant Duncan 37:00
Very cool. Yeah. Would be great to have them on. Well, thanks so much for coming on today, and hope you have a great rest of your day!
Grant Duncan 37:08
Thanks, Grant. Thanks for having me.
Grant Duncan 37:16
Thanks for listening to today's podcast, and thanks to our sponsor, Voximplant as well. If you're looking into how to improve your communication and customer engagement, check them out. Lastly, if you enjoyed this episode, please leave us a review and tell your friends, so that others can find it more easily. Have a great day. And feel free to reach out to me, Grant Duncan, if you have any questions you want asked in our next episode.
