Leading Product in a Fast-Moving Scaleup

Read the Full Transcript

The following transcript has been altered for readability. 

Becky Flint: I’m really excited to be here, and great to connect with you Sridhar. Just a fun fact, so you probably noticed. Sridhar and I actually worked together for quite a bit of time a while back. We did a lot of fun things at PayPal and he is leading product at an amazing company called Chatmeter. So I’ll hand it over to you Sridhar and tell us a little bit about Chatmeter and what’s exciting.

Sridhar Nagarajan: Yeah. So thank you, first of all, for inviting me to participate. I’m super excited to be here, and congrats again on your fundraise. It’s always good to get validation externally and from investors on product-market fits. So that’s awesome to hear. Just a little bit about me and a little bit about Chatmeter. I’ve been doing product at various different places over the last couple of decades. And Becky and I spent many years together at PayPal where we actually did some pretty cool projects, including the launch of PayPal Australia, which I thought was one of our crowning glory. We had some fun times there.

So what does Chatmeter do? Chatmeter is a far cry from PayPal, moved all the way from FinTech to work in MarTech. We’re an online reputation management company. So what we focus on essentially is helping brick and mortar businesses drive online traffic to their store. And we do that by providing these brands with local insights and solutions. The world, despite the massive drive towards eCommerce and online shopping, still has a significant chunk of total commerce offline. Brick and mortar stores need to differentiate themselves to be able to get those people into their stores. Especially now in light of the pandemic, it’s becoming more and more important to do so. So that’s what we do.

We provide these insights and solutions to these businesses in three ways. One is we ensure brand alignment. We establish what’s called brand consistency by fostering localized experiences for the brand increasing customer acquisition. So it’s making it easy for consumers to discover these brands over the competition. And this is becoming a mantra all over the place.

Becky Flint: Thank you so much. And I really appreciate the context. It’s interesting where you mentioned the time when we worked together at PayPal. When we started, it was mostly just the online experience. And then over time, we realized, that online, offline multi-channel is so essential. So I know today we want to talk a little bit more about scaling products. We’ve gone through different scaling journeys. And some of the topics around scaling product really are around the team, the stakeholders, and trade-offs in resources. So we’re just going to touch upon all of them around the areas.

So maybe we can get started on talking about teams. And before we started the session, we actually talked a little bit about how the structure of the team, how the way we work off the teams definitely has gone through tremendous change. Even when we were at PayPal, when we were a leading global expansion, by default working with the people in all locations, that is different from what it is today. So share a little bit with us on when you build teams as you’re scaling Chatmeter and other companies. What are the key challenges and the things that you learn are helpful to the other companies out there to think about their teams and structures and the growth?

Sridhar Nagarajan: Yeah, things have definitely changed. And I think things have changed materially over the last two years, since the pandemic. And the idea of, A, building teams and then, B, scaling them has evolved and morphed over time. Additionally, the one thing that has remained fairly consistent over the course of whether we were at PayPal, where we were at a much larger company, or at a smaller organization where I am right now at Chatmeter is building a culture of collaboration, and collaboration across not just the product function, but across all functions. So that’s super important. And it’s becoming more and more important now that we’re not in the same room solving problems on a whiteboard. While that happens once in a while, it’s not always the way the problems are solved today.

So having that culture of collaboration from day one is quite important. And as companies scale, that’s the one thing that typically drops off. And while the intentions are always positive and people always want to be collaborative, it’s not that people are necessarily averse to it, it just becomes more subconscious. You are like, “Oh, I sent an email. So I guess things happened and/or actions are getting taken.” Or “I sent a Slack message and something happened.”

While that is true, I think it also leads to a lot more tactical focus and you end up resulting in the immediate, in what needs to happen now, what needs to happen in the next hour or in the next day, as opposed to balancing that with what needs to happen in the longer term. And in order to have effective growth and scale team, you need to look at a balance of the two.

This leads to the second part of this. So how do you then plan for this? And it reminds me of a quote that sticks in my mind. And I have seen it attributed to a lot of people, but I think it was originally coined by a scientist. But essentially what it says is, if you cannot measure it, you cannot improve it. I mean, it’s not a new quote, it’s just that’s what the reality is. And in science, it’s very obvious. However, it’s harder to do that when it comes to building teams and scaling for growth.

One thing I found fairly effective is making sure that the teams, as they grow, have a fundamental set of KPIs that everyone’s marching towards and measuring. And the team itself is not just at the product level, but everything needs to roll up way. So you have the situation where you have the product team that then relates to the business metrics. And that relates to the corporate metrics and so on and so forth. So I think that’s a good way to start.

Becky Flint: Yeah you touched upon so many very interesting topics, so I’m just going to dissect them.

The interesting thing is that even though we were distributed, we were actually working differently in the context of distribution. Meaning that you have the capabilities in a group and then you have another capability in another location. So it’s almost like the APIs of components that are talking to each other has a lot less, that you have more defined the function, and then you just use the API to work with the function. In the past, when we worked at PayPal, we had product managers in one location. We had some engineers in one location. We had some engineering in the other location, and then we have business partners, let’s say in another country. So we do have distinctive connection points and it’s less frequent because the PMs work a lot closer every day.

So in today’s environment, what you mentioned is not just with COVID, even slightly before COVID, we already started to have PMs in multiple locations, engineers in multiple locations, so that the API model doesn’t work anymore. You can’t just do end of day in sync, or just once a time in sync. So why don’t I just go back to you on that?

Because what I noticed is when that happens people try to reduce complexity. They create an “agile” team, a scrum team, a pod. So the pod started to have smaller numbers of communication. You have a product manager, maybe a designer, a couple of engineers, and then you work in that pod. And then you have relatively less interaction with the rest of the company just because it’s more convenient.

However, obviously, that leads to some other problems. One that we have seen is that one is the pod may shrink and expand in need. Like in this pod, let’s say owns a certain area of product, that areas of product sometimes need a lot more work, sometimes it needs less work. And similarly, it becomes a little bit challenging because there’s no way to have both visibility and juggle between them.

So how’s your experience on this topic and how do you manage them?

Sridhar Nagarajan: So there’s no simple answer to it. However, I think it also depends on how the product platform is structured. It makes it easier if the platform is pod-friendly. As we were at PayPal, we were a fairly evolved platform where we could say, hey, risk merchant services consumer working on relatively independent pieces of the business and the code and the process. And they really interfaced at minimal amounts. And while in a smaller organization, that isn’t always the case.

We’re in a situation where platforms aren’t that well defined and, A, it’s also you’re not dealing with such big teams and the pods, while they are technically independent, more often than not, you need to spend a lot more time collaborating. And I think it’s important here too, and I hate to use the word “process”, but I think at some point in time, every single company goes through this aha moment and you go, well, “process”, isn’t a bad word, it’s an important part of growth. And it doesn’t have to be heavy. It doesn’t have to be burdensome to the organization and to the way the organization works, but it’s important. It’s very, very important.

And now, there are tools that are available today. Dragonboat’s an example of such a tool, which is available today to help with this process without making it burdensome. And going back to this idea of whether you have two or three scrum teams and each of them working together, the way we do it is we typically do the planning, technically yes, at an annual level, but it’s super high level. It’s like, “Hey, what do we think we should be more focused on?” And we have some very high-level plans.

And then quarterly is when we start looking at, “okay, well, let’s look one quarter ahead and really start diving into what we need to actually build and assigning the work to, while it can be done by pod A or pod B or team A or team B and then at what point do the teams need to come together and building that collaborativeness into that process so that everyone’s aware of, Hey, you know what? If I’m working on the social module and there may be some interfaces to the reputation module”. Okay. Well, great. When that happens, I need to pull that team in because there may be some work that gets injected.

So it is super important to keep that in mind and have tools that clearly allow you to plan to know when I’ve got six initiatives, I’ve broken it down to enough detail, and I know which pod’s going to be working on it, which team’s going to be working on it. I know when that’s going to happen. And then I know, for example, when to pull the teams in without making it burdensome and saying, well, you need to write this doc and that doc, and you need to get it signed off and approved and so on. So I think having that flexibility with tools is super important.

Becky Flint: Right. And I think what you said is so true. Obviously, Dragonboat came into the world because we’re facing these problems. And then that’s how we’re ultimately solving the problems with both people and technology. So, yeah, I definitely have been to an environment where, because it’s so difficult to communicate and collaborate a team in different locations, they’ve broken things into parts, and then they were so independently operating, and then they don’t have a good way to collaborate together. Then you have this one is like an org chart you’ve written over the product, right. You could clearly see this is written this way by a different one because little nuances do not connect together.

And the other part is it creates a lot of tech debt. Because in the ideal world, I want to work with this team to get things together. But because we didn’t align the direction, that roadmap of priority and we couldn’t get their support because they have their focus, then we end up just working around our code and writing a bunch of stuff and trying to make it happen. So over time, it becomes, not only just a better user experience because the org chart’s all over but also, the tech debt over time. People don’t realize tech debt a lot of time is product-induced, not really engineer induced. It’s called tech debt but it’s really product decision leading to it.

Sridhar Nagarajan: Yes. And it’s usually introduced by the need for speed.

So we’re introducing processes to solve very specific challenges rather than for processes stake. So I think that’s super important because, ultimately, when you’re small, and most companies now all work agile. But what agile allows you to do and enables you is exactly what you said. It’s like, well, it’s all about testing and learning, everyone from the board down to the product manager wants. It’s like, “Hey, let’s test and learn and see if it works.” And then you’re right. That’s how you introduce tech debt because it’s like, well, Hey, it’s just a test. Well, let’s just figure out how to get the test out there. And we’re like, do you really want to spend four sprints building this hook, or do I want to spend three days just building the work around it?

And then you have this over and over again and you go, oh, you know what? This actually worked. Now let’s iterate, let’s grow it. So every time you test and learn and iterate and then, all of a sudden, you have a product and you find you have thick, but then you realize you also have a mountain of debt. And yes, absolutely, I think that’s the one thing that I think a big distinction between a startup and a company that’s a bit further along in maturity is we can’t afford to introduce that much debt. We have got to be careful about it as we plan forward.

Becky Flint: Yeah. I think you’re spot on. So we have a live audience question around that modeling on a fast-growing startup product team. They’re trying to figure out how best to think about pods. At which point you start to think about pods, and how you restructure into pods. I’ve definitely seen your team grow and you maybe have one or two, how do you think about this? How do you evaluate when you have another pod, how do you structure them? And when are you going to change them again?

Sridhar Nagarajan: So taking a step back, the key thing for the success of a team is based on the team being able to deliver more than the sum of its parts. So let’s assume that in this situation, and again, going back to my usual mantra of you need to measure everything and you measure the velocity of every team and of every single sprint. And what we’ve found is teams that are super cohesive, tend to over-deliver, it’s not rocket science. I mean, you’ll find that the velocity, it takes a while to get there but once you’ve built this team and it says it’s a team of five people with three engineers, a QA person, a product manager, and a designer, of six people, it takes probably a quarter or six sprints or so to get to a point where everyone’s really humming along.

So one thing we don’t want to do is disrupt that. So reorganizing pods just for the sake of doing it is not the right way to do it. It’s more about how do we assign work to teams that are really humming along. So what we typically do is our teams, they’re not super-specialized, right? We want teams to be very knowledgeable about the entire platform and the entire code base. So anyone can pick anything up and you basically present an initiative to that team and say, hey, look, go and make that happen.

Now of course there are times where we may find that the teams actually get a bit too large and then the efficiency goes down. So, once a team gets about eight people or something, it really doesn’t work and then you need to break it up into two teams or something. But restructuring teams into pods usually you’ll see the primary reason would be when velocity starts right dropping. And you can see that, right. If you have five teams or three teams or whatever, you’ll see the velocity of each team and you’ll know, for example, “Hey, there’s one team that probably requires a little bit of adjusting.”

Becky Flint: Right. I totally hear you there. There’s a mantra, I heard it from of one of my VP engineering firms saying that you can break up the work into a team or you can break up the team to work so that obviously depend on whether this is a high functioning team, so then you just give work to the team. Versus if the team is expanding, so you’re going to have to have multiple teams anyway, then you can break up the work. I think the other elements about that are really around, especially for a growing company, let’s say. Every company starts with the one product manager, you’re going to have a multiple, you’re going to have more, you’re going to have more. So at that time, there are a lot of thoughts around how do we have somewhat ownership, like using the example at PayPal.

We had ownership of the risk at checkout and then over time, those teams expand more and expand more. So in your case, when your team going through growth, and then you’re adding more…let’s just say you started with one PM or you started with one or two PM, you’re adding more PMs. How do you think about the structure, the ownership of the PMs? Do you say you own this protocol, you own this protocol, or you say you own this segment of the customer? How do you think about the structure of that?

Sridhar Nagarajan: So in the ideal scenario, and we’re fortunate to be in somewhat of that type of scenario is to have product managers own a products soup to nuts. And what I mean by that is everything from creating the business case to then delivering the product and maintaining it. I mean, that’s how product people and product managers, in general, get satisfaction. They’re like, “Hey, look, I get to basically make decisions on a specific product. And I understand the market, I understand the customers. I understand what are the key innovations happening? What are the challenges that are facing? What kind of headwinds and so on.” So having that level and providing that level of ownership, I think if it’s possible, that’s the way to do it.

But as teams grow, then you can essentially have a team on that product line right. I think PayPal was interesting because it was a gigantic platform so it was a slightly different approach. So those types of things, I think lead to more complex conversations, but in our situation right now, I think we’re a bit more fortunate.

Becky Flint: Right. I definitely think the evolution of the structure is the ability to what makes the most sense to deliver a set of value to your customers, business value regardless if is the product line, or it’s the segment of the product. Obviously, when you get bigger, you have to have multiple ways to slice it. And even for a smaller company, you have a similar thing. So that leads to one of the other questions, the topic, which is around the stakeholders, the alignment, the juggling things, and the trade-offs. So we’d love to hear a little bit, obviously, every company faces that. And then how does your team manage it and how do you keep people aligned?

Sridhar Nagarajan: So that’s a lot of questions. Well, let’s start with trade-offs and resourcing, and then we can talk maybe about alignment.

Okay. So let me talk a little bit about managing with the resources that we have and how do you do these trade-offs? So it again goes back to KPIs, and KPIs that drive the business. Essentially investment, at least the way we approach it is it’s based on ROI for every initiative. Whether it’s what we call a voice of customer feature that’s benefiting an existing customer or a voice of prospect feature, that’s going to help us gain a new customer, we need to have a pretty clear understanding of what the impact is going to be. And then, balancing that against what we think at least at a high level, what the cost of building out that product or feature is going to look like.

When it comes to features, we typically, want to look at chunks of investment based on, again, as I said, retaining revenue or new MRR. And is the key here is again, a very interesting quote years ago, when I was the PayPal. It had the course, and one of the instructors said, “Your opinion, although interesting, is irrelevant.”

So it’s because opinions are great but when we’re building scaling products, it’s more about what needs to happen for groups of customers, large segments of customers. And that helps us get the data-driven decision making, and then helps us assign and allocate resources as needed.

Part Two, limited resources, I think that’s everyone has. If everyone could get their entire roadmap down, I think there’s something wrong or clearly, there’s an idiosyncrasy there, but essentially, when it comes to limited resources, which is a reality for all small startups, it’s about categorizing and allocating investment. And the way we approach it is we allocate based on four key buckets. We look at it in terms of new features. And this is what I talked about, whether it’s a voice of the customer, the voice of prospect, or innovation. Then we have another bucket called system reliability. This is primarily things bug fixes and, and making sure that things are on track. And then there’s infrastructure and then professional services.

And those buckets can vary depending on the type of company. But ultimately, the key is to be able to figure out the allocation breakdown based on stage growth. And typically it biases work towards reliability and infrastructure and even professional services as the company matures. So it’s more towards new feature investment when we’re still establishing product-market fit.

And then the other part of it is staying disciplined with it. So being disciplined about resource allocation and doing periodic lookbacks, and we do this on a quarterly basis and reallocate based on investment performance. I know I sound like an investment manager at JP Morgan, but it’s actually true. I hate to sound like that being a product manager, but that’s very important and that’s where tools like Dragonboat are very helpful because you can do a look back and say, well, I invested this much here, this is what the product adoption looks like. This is what the revenue looks like and does this make sense? Do we need to invest further?

And the periodicity or how quickly and how often you look back depends on again, the cheer of the company. Sometimes you need to look back once a quarter. Sometimes it’s once every two sprints, sometimes even once every sprint.

Becky Flint: Yeah. I think you touched on so many things. First of all, think about resources and scarcity. When we grow up professionally at PayPal, we got a couple of hundred engineers, thousands of engineers, we never had enough resources. It was never enough. And I think the portfolio approach makes so much sense because it is impossible to sift through hundreds of product ideas and features, and even try to how can you score things based on what? All these are very interesting of how, if we want to say product management is to drive an outcome and for you to drive the outcome, which is not one, right, it’s multiples, like retention or revenue and all these are different. They are all important. It is just they have a different level of importance at a different time.

So, if you don’t take a portfolio management approach to it, it is an investment. Product managers are like investment bankers, right. You basically say I am deciding what our engineers are to be working on. And their talent is one of the most valuable assets of the company, right? So we are indeed in making investment decisions that you’re working on these things, that’s the investment decision, right? That’s the things that we put into it. And then the things coming out of it are leading to that. I think savvy product leaders and Chief Product Officers definitely have to take this approach.

And you touched upon a little bit of Dragonboat. Actually, there’s a question from the audience, why did you choose Dragonboat over roadmap tools?

Sridhar Nagarajan: Yeah. So we were using another roadmap tool prior to it, and it was very much a cosmetic tool to communicate the roadmap to key stakeholders. And we were realizing that ultimately, and as we all know, it’s about the ability to close the loop, right?

You need to be able to close the loop. And so they say, well, it’s great. So not in just communicating a pretty Gantt chart and then keep updating that game chart, but what actually drives the inputs into that Gantt chart. And that’s essentially what Dragonboat was. We were looking for a solution that offered that. It’s like, well, we have all these inputs. We want to be able to manage and track how much want to invest and how that investment is actually doing. And then also manage, for example, things like scoring each one of our initiatives to help us prioritize what we should do first versus second.

And then once we have all of that done, and the inputs are well defined, the output, which is the game chart is relatively straightforward. That’s the easy part. So that was one of the primary reasons why we did this because we really did want to be able to have a single source of truth of our initiatives. And I’m not saying by any means that it’s perfect right now, but you least we have a place where, because we work with all our tactical planning happening in Jira and we do more of strategic planning in Dragonboat. And then the interface between the two also is super useful because we can then transpose initiatives from Dragonboat into Jira so that they flow downstream into our sprint filing process.

Becky Flint: We knew that the strategic part of the product is quite essential really just to determine. You could have a very high velocity as a team and then build everything perfectly, but if you feed the decision in there, not in the best way, it’s not going to drive the outcome we want, right. So remember at PayPal, we had this process that we spend so much time, so many spreadsheets and ultimately, it was tough to have those conversations, to debate on well where we should invest. But it’s also important to have that conversation and difficult discussions upfront and early on. So that would really determine the direction we want to go.

And I was looking back, to think how amazing PayPal has become from a single product to multi-product portfolios. And as painful as it is to operationalize, it is in essence really the foundation that drives it.

Sridhar Nagarajan: Absolutely, and I think it relates to one of the other questions I’m just looking at that came through is, how do you keep all the teams aligned as they grow? And how do you manage who communicates what and when? And this is exactly it. So as the teams grow, that is exactly the secret sauce. Because the one thing that has happens as teams grow, and I remember having these conversations the early days at PayPal is we were just spending a lot of time in meetings, just communicating with people about, “Hey, this is what I’m doing,” and “What are you working on?” And then, “Well, oh, maybe we should collaborate here and maybe we should solve this.” And it was very organic. I think we’ve evolved a lot since then with the help of multiple tools.

Also again, to use the word “process” where what we typically do is, and we’re small enough to be able to get away with it. I don’t know the person who asks the question of how large the company is. But the most important thing I think is first, of course, is building a culture of collaboration throughout the product life cycle. So from ideation through research to design, implementation, launch, and growth, that’s part one. And then consistent communication. And this is across the board, not just internally, but with the customers, with the board members and development team, so that everyone’s aligned and everyone’s aware of what’s happening and coming down the pipeline. By no means, are we perfect, but we attempt to do that because I think it’s important to know everyone marches into this same drum beat and that’s important.

And this is where good product management helps and the product can play the role of what I call a servant leader because product managers are not necessarily the drivers. Ultimately it’s yes, we’re driving the execution and sometimes product strategy, but product also plays a huge amount in making sure everyone is aligned and everyone’s aware of what’s happening, whether that means setting up product review meetings.

For example, what we leverage is we have product review meetings across the board, whether it’s with our cross-functional teams or design review meetings with our cross-functional teams, with our customer-success managers, with our executive team, we also then have meetings and/or well-documented product briefs that are shared broadly, right? We want to share the product brief, and everyone has a chance to comment on the product brief. And we use confluences to write out the product briefs, not giant essays, but, hey, here’s kind of what we’re trying to do. And here’s what we’re trying to launch.

Our designers spend a lot of time communicating what it is that we want to build with the engineering team and with the cross-functional team. So doing this on a consistent basis, and this is where the product manager helps, right? Having these conversations and driving these conversations with the stakeholders to make sure that people are getting the information that they need.

Now, how do you know whether is it too many meetings or not enough/ that’s a tougher question because it depends on the company culture. There are some companies that are very meeting-oriented and there are other companies that people love to read, and they’ll just go, you know what? Just, all I have to do is upload my document or my product brief and send out a Slack message and say, send your comments. And people will just comment on documents and over it. In other situations, no, we have to bring a team together and do a review.

And for example, at PayPal, we had to do more meetings. At Chatmeter, it’s more meeting-heavy. So we do spend a lot more time on that. Yeah, it depends on the culture.

Becky Flint: Yeah, I definitely observed part of those behaviors as well. I think what I’ve also noticed is that, especially with the remote and distributed different teams, it’s going to be a hybrid multi-channel approach. So you will have a system of information, we call it source to choose and whatnot, so that people can read it, they can comment it. But then you also have a live, synchronized moment where you can have a conversation to talk about it so that people will only cover things they want to talk about more. And the other ones, you already know, you have information there. So that’s synchronized with a tool or information access method plus the live sessions seem to be the more norm these days.

Sridhar Nagarajan: Yeah. And I think one thing I would also caution, I think is that with people, more and more companies being remote only, or remote first, it does become you end up with this Zoom fatigue is real, right. So I think there needs to be a good balance around this. Because while Zoom fatigue is real, it’s also hard to keep people engaged when everyone’s just remote and sitting in front of their terminals all day or in front of their computers all day.

So it’s about finding that balance and being able to engage the group, virtually. And there are some nice tools that allow for it. We use a tool called, for example, Miro. It’s like online whiteboarding, and I know they are customers of yours too. So it’s pretty cool because it helps with the conversation, especially with synchronous conversations and even asynchronous to an extent.

Becky Flint: Right, right. It’s definitely true. So I think there’s another question around product operations. Do you have product operations and what do you think about their roles if you have one?

Sridhar Nagarajan: Product operations is a big gray area. So we have sales operations, and we have prime analytics, which I think together probably would be. So it depends on the type of company. Again, for us, mostly operational roles in product are around analytics. So we have product analysts and business analysts, and then on the sales op side, the same thing, right. We have data analysts who look at this data. And it’s a very important part of the company, especially for someone like us, who’s very data-centric and data-driven in our decision-making. And the team’s really responsible for making sure that everything that we do can be measured, can be instrumented, and can be made visible.

So our significant amount of time is spent building dashboards, internal dashboards, and we call it data wrangling essentially because there aren’t perfect tools out there to be able to wrangle data from multiple different data sources. What I mean by that is, that we have click data that comes in from the front end, collects at the web layer. And we have tools like Mixpanel that collect that data. And then we have event data that swarm the database, and then we have our customer data logged in our CRM system like Salesforce. Lastly, we have billing data in our billing system. So we need to be able to pull all of this together to really get a 360 view of what we call our Customer J dashboard. And this is where product analytics comes in.

And product ops, we’re not big enough yet to have a full-on product ops team, we just primarily focus on product analytics. But sales ops team does a lot of work on gathering the front end of that data, especially with Salesforce.

Becky Flint: Right, right. So in many ways, a lot of companies have the product playing that role. So you are like you’re wearing multiple hats, both as running product, running team, you’re also running your own product ops in some ways, right?

Sridhar Nagarajan: Yeah. I think where we’re right now, we’re not at a point where we have gigantic teams. So we run fairly nimble. And yeah, when I say teams, it’s teams of one, two, or three people, right. It’s not like teams of dozens of people.

Becky Flint: Right. I want to touch upon one last topic and then I think if anyone has past questions, please do also just submit as well. One of the things that you touched upon a little bit earlier around, KPIs and goals and MRRs. I think those are great in terms of a more measurable, relatively near-term focus. How do you balance that near-term value and the goal that we get quite often from a business to the long-term product strategy and the vision, how do you typically think about this and incorporate it into your organization?

Sridhar Nagarajan: It’s a tough one. So for us, we usually plan out about a year ahead, right? We’re not looking decades ahead or five years ahead, we’re looking to a year ahead and that’s what we call our long-term product strategy. And what we typically do though, is in order for us to be successful since we’re small and we have limited resources. So we break our long-term product strategy into shorter-term tactical deliverables so that there’s not a disconnect.

And then, because our customers are enterprise customers, we usually need to wait a few months to get that feedback. So we’ll get that feedback and then it’ll help us inform our roadmap three, six months down the road. So that’s typically how we do it. That way we know what that end goal is. And we also know, for example, the other thing from a longer strategy standpoint is, well, where do we want to set the benchmark? Do we want to win? Do we want to get to parity or do we just want to scratch the surface?

And it’s important to layout because we’re in a pretty competitive space and can’t win in everything. So we say, okay, well, there are certain areas we know we can be competitive, but we don’t necessarily have to win. And others we just need to check the box. That’s the trade-off that we make. And we say, okay, well, that’s how we’re going to allocate investment. And some may take 24 months to get to, some may take six and or somewhere in between.

Becky Flint: Right. There are a couple of things that just jump out. It’s interesting where a lot of times, if people think about strategy, either as a product manager figured out such big words or from some of the product executives to feel like it’s just like a vision, there’s not much to think about the strategies, the vision to operationalize into actual execution. And I think the way you think about it is if I were to paraphrase is that most company at a certain size, looking at a year probably is a long term in the world we’re in. And then really the way you think about long term strategy really is to say reflecting the understanding of the market and competition.

That’s number one. What is driving strategy? It’s looking out like from now to a year in, what would our market look like, where our competition would look like, and then really trying to make sure we don’t get behind. Because if you look at over a quarter, then we would say, oh wow, the whole world has changed and we’re completely left behind. So the long-term strategy really is to see the period of time away from our day-to-day.

In the industry where we are, that’s long enough, a year or so probably makes sense. And then, the focus is on market and competition, what it could mean for us. So that’s something I think it’s great. Just strategies is just not an empty term. People throw this word so much out there, it becomes just not useful, but it’s really, really important to have to look up to see where we could be and then where our threats are.

The second point really, it’s so cool that you said that. That’s exactly how we think about that as well, is it to win, is it the check box, or it is just not become a no, right? People won’t turn you down because you don’t have it. You won’t win, but you are going to have to have that, it’s sort of the hygiene feature. I think at least these three categories, it’s so funny because I remember we had one of the strategic sessions with Brent Bellm.

And I think it is so essential for product teams to think about what is our bet? Those are the differentiators. What are initiatives, which is to translate our strategy and focus to stay somewhat alive and competitive? And what are just the features and those other things? It really delivers to features. Right. So I think having that kind of thought process is so critical to just move the product organization forward.

Sridhar Nagarajan: Yeah, it sounds easy, but I think the hardest part people always say, go from strategy to tactics. It’s actually, that’s where the real work is. So it’s easy to just say, we want to build this cool stuff but the hard part is about, hey, will it be cool enough? Will it make money? Will it drive usage or is it just going to be a vanity feature?

Becky Flint: Exactly. Well, it’s so fun to talk to you about scaling products. I’m Becky from Dragonboat. We’re the Responsive Product Portfolio Management platform. And Sridhar from Chatmeter is head of the product. All of us are growing, which is good news. And it also means we have lots of opportunities for you as well.

You can find more information about both companies. And also, if you are interested in joining Dragonboat we have multiple jobs available.