Processing Process

Shilpa: Hi, I'm Shilpa Mohanty. I'm a product manager. I work at Vibes Media here in Chicago.

Suzanne: Welcome to the show, Shilpa.

Shilpa: Thank you.

Suzanne: You've got a significant amount of product management experience - but you also have experience as a marketer, experience as a developer, experience as a business consultant. You're a true triple threat in the industry and I'm curious if you can share with me and our audience how did you find your way into product management specifically.

Shilpa: Sure. I'm from India. I did my undergrad in computer science engineering and graduated in 2011. While I was doing my undergrad, I was involved with a startup in my university, and it was called vigyan.com, which meant knowledge in English. And we're group of seven, eight folks. Two of my seniors started the company and we were launching this website e-commerce platform for students. I was involved in the development part of it because I was a computer science engineering student. But I was always interested in how they're going and meeting students, and they used to do a lot of promotions at different tech fests and other events. I was always fascinated by going and talking to people and getting their feedback about how they like our platform and all of that.

So, I was always very interested in the business side of things. Then I graduated. My first job out of college was Infosys Limited where I worked with the sustainability unit within our organization and we were a team of probably around 50-100 folks. There are a few people here in the United States who were client-facing because we're working with a lot of clients. Then our team back in India was involved with the product development process about creating the sustainability and compliance reporting solution. That was our core product.

I was involved in all facets of the product development process. I was involved in the development, moved to the data side of things, then moved to the quality assurance and then I was also involved in the business team, writing requirements, and looking at the agile our way of product development, all of that. But I was always very curious to understand why are we developing the product and what is exactly that we are trying to do? How is it solving a pain point? I was always curious about the business metrics, how the business is functioning, how the client is willing to get our product.

Marketing was a very seamless transition for me because I was involved in client demos and I wanted to see how we are pitching our product and how well we're doing and how well we're tracking the metrics with respect to marketing and sales. That's when I decided to do a transition from the the world of technology to social media and digital marketing.

I came to the United States and decided to join a non-profit. So, I joined Safety Water, which was for the cause of providing clean water and against fracking and all of other things. I did social media marketing for them, which was, again, very, very technology-oriented and it was not something just pure marketing or traditional marketing. It was very, very technology and I would say data-focused. So, I did that for a while and then decided to go do my business education for my MBA. That's how all these business consulting things, everything came back into my life. I felt that I was much more inclined towards building products and understanding the entire start to end lifecycle of how you launch a product, how you come up with the idea, all of that.

That's how the different backgrounds gelled into what I was doing then, but my first passion was towards products. So, that's how it all came together and I realized that product management would be a role where I would be able to utilize all of my interests, passions and just deal with a lot of things at the same place.

Suzanne: Right. Just to go back in time for a moment to Infosys. So, you described it that you started there as a developer, out of school, and then you quickly moved across departments. You went to data, you went to quality assurance, and ultimately into the business analyst side. I'm curious: were you driving those transitions? Was it a function of you were getting bored as a developer, so you wanted to try something else or your management was moving you along through those processes?

Shilpa: I think it was a combination of both. What I usually do is, every time I'm working on something, I not only work on that, I would also look at the other things and try to take up additional responsibilities. When I was a developer, I would be interested in how the sql side is working. How are they batting queries and what exactly they are doing, what are the models they're building SSRS, SSIS, data models and everything. So, I would do my normal day-to-day job, and then I would just go and sit down with them, do some peer work and learn what they're doing. That somehow caught the eye of my boss or the senior director then.

He was always very encouraging and supporting what exactly I wanted to do with my career. So, I told him I was impressed with the data side of things. He moved me there. After a while, I was like, "I want to do the testing of the product. I want to see. I want to understand the entire ... the different test case and the different ways our product can work, and think about the different edge case and the scenarios and all of that." And I moved to the quality assurance.

Finally, it was like, "I want to understand the business side of things. I want to be in client services." He always supported that, so it was a combination of both and I was lucky to have him guide me throughout the way.

Suzanne: The other thing I think is interesting about all of the different experiences, professional experiences, that you've had is the scale of the company has varied so significantly. I think Infosys is somewhere around a 100,000 people globally. That's a really huge organization. Vibes, where you are today, how many people working at Vibes?

Shilpa: 155.

Suzanne: Very different kind of scale. You mentioned a few startups along the way, so I think, there are even some smaller organizations and then a few more probably somewhere between where Vibes is and where Infosys was. Is there for you an ideal scale of a company where you feel that you thrive the most?

Shilpa: Yeah. That's an interesting question. I've worked with bigger enterprises, worked with clients who are really big, worked with smaller clients, non-profits, startups, all of that. I always feel I'm comfortable in a position where I can come and contribute towards the processes and create an environment where I'm comfortable working. For example, at Infosys, even though it was a very big company and we were a big team, there was a lot of chaos and ambiguity about what exactly we were delivering. Even though there were processes, probably they were not rightly suited for me or I wasn't very comfortable working in those environments.

Again, in startups, you have no processes at all. You're actually creating them, so again, it's very difficult to create a culture, to create the processes that people would actually adapt to. And then there are companies like Vibes, where there are processes already, but you know with a scale. We're actually rapidly growing, so there is a lot of scope of improvement and introduction of new processes. I myself feel comfortable in those roles where I can come and bring more change management and use my background to make certain changes that can actually create more efficiency for the company and can actually come up with better efficient processes.

So, I would say, a middle level company would be ... Or maybe a company where there is some set processes, but then, things that I can come and change and easily cater it to the way I want, or the way it would be best suitable for innovation and other stuff to grow.

Suzanne: I love process as well, so I want to stay here and talk about process with you. I think the first thing that's coming to my mind hearing you speak is acknowledging that process and the way process has to evolve changes not only at the scale of the company in terms of number of employees, but also, where the company is in the product life-cycle. So, you talked about Vibes being sort of a fast-growing company. In a lot of ways, that's like we're quickly outgrowing our own processes, maybe even processes that two months ago or six months ago served us quite well. Talk to us as a starting point about when does a new company in your opinion have to start thinking about process, and are there a handful of processes that you feel are essential to have in place in whatever form, whether you are three or five people or 50 people.

Shilpa: I think till the organization reaches a maximum amount of, like 50-60 people, that's when I personally feel there is a need of introducing processes. Before that, it's mainly a startups in the organization where everybody in most case working together in teams and they're not set teams for each of the function of the company. Like, maybe the same guy is doing product, the same guy is doing marketing. There's no requirement of having set processes, but a few things that would help the team to work faster could be really helpful in any startup kind of organization. Once you cross the threshold of 50-60 people, you start having different teams. You start dividing up responsibilities and making it more precise and specific toward that team that is supposed to deliver. I guess introducing a few processes here and there, that can reduce the friction in how the teams interact and work together, could be the starting point.

I think I really appreciate the fact that the companies that actually rapidly grow, that rapidly innovate, have smaller team structure. They have processes that are very, very and tightly coupled, yet highly predictive. You know that this is how the team is going to function, the dependencies are reduced, the waste is reduced, and all of that. I guess, as you start growing and scaling up, you need processes to match up to everybody's comfort levels and everybody to feel safe and feel more productive to perform. I guess it depends on the companies, but yes, I mean the more flexible you are at creating processes, it's much more better for the organization.

Suzanne: Have you worked on the development side in particular? Have most of the environments that you've worked in been agile environments or you had some experience in waterfall software delivery as well?

Shilpa: In my initial years of experience, yes. I worked with Infosys and they were waterfall and then they moved to agile later on. I remember writing long requirements, specification documents and then just writing them for about two or three months with so many bullet points that I would lose track of what I have written a few weeks back. And then we moved to agile. I think since then, I'd always been in agile environments. I think I much more enjoyed working in an agile environment rather than waterfall.

Suzanne: I think one of the things about agile ... well, they say the right agile is the one that works for you. Certainly, in my experience going into organizations who are becoming agile or doing some form of agile, there's still a lot of challenges associated with it. Especially, if you look at scrum as an example. It's a low documented structured process. These are the meetings, this is how it works, this is when we go away and do things, this is when we come back and review the things that we did. Given that you are so passionate about process, I'm curious about your opinion on why it's difficult to be agile, even though I think most organizations would agree that it's philosophically correct and why do companies struggle to become agile or companies who are agile drift back toward waterfall over time.

Shilpa: I think all the teams or all the organizations that I've worked mostly have been agile. I think process ... When we talk about process, we talk about people, right? Agile, when it has its well-documented philosophy and the steps and the different ceremonies that you perform for an agile team doesn't go well with everybody in the organization at the same point of time. There are people who might enjoy the structured way of doing things. There are people who are just there to deliver and do not want to be restricted or bounded by any such ceremonies or any such meetings or any such well-documented stuff and the set structure of processes.

I think the biggest challenge is how do you align the entire organization or your team just to follow those agile principles or follow the set things. That becomes a big challenge when you're working with bigger teams and you're delivering bigger projects, which are dependent on multiple teams at the same time.

I guess, what's required is experimentation. Agile is pretty flexible. You can just make it more suited to how you deliver or your organization delivers work, and who are the customers you're catering to finally. For example, at Vibes, we have about 6-7 teams. We have pretty small teams and we do a lot of experimentation. So, we have teams that work on kanban. We have teams that work on pure scrum. And then within each team, we actually differ on how we do the retrospectives, how we do the planning. Planning is universal across the teams, but the way we execute the different agile principles is very different.

And then, we do retrospectives on a regular basis. We have something called esteem health check activities that we do with the teams regularly just to get their feedback in response to whether they think the stuff that we're trying to do with the process is working or not. We actually take the feedback a lot into consideration and a lot seriously because that counts, right? You're ultimately working with people, and if they feel and if everybody unanimously feels the process is working for them, then fine. We can continue with that process for some time. But if it doesn't, then there's obviously room for experimentation and just trying out new things and seeing how that works out.

Suzanne: Tell us a little bit about what is Vibes, for the folks listening in who maybe haven't heard about the company.

Shilpa: We are a mobile marketing technology company. What we do is we help marketers unlock new revenue by arming them with the technology and expertise needed to succeed in the world of mobile marketing. We work with a lot of retailer brands, lot of other brands, to manage all of their mobile marketing campaigns, such as text messaging, mobile wallet, push messaging, all in one single interface. So, we have a mobile marketing automation and technology SaaS platform that our clients use to talk to their customers, so essentially the end customers.

Suzanne: What is your specific role there at Vibes? What are the products that you're managing in particular?

Shilpa: As I mentioned, we have this platform, which is the Vibes engagement platform and I manage the integration. So, I manage the public APIs, I manage the mobile database, I manage the incentivator engine that gives out incentive codes and all of that. So, I manage the backend of the platform.

Suzanne: Right. Let's talk about the API for a moment because when you have a public API, your customer are typically the developers of other organizations, possibly the developers that work for the clients you have that use your platform and maybe want to build on top of the functionality or integrated in a more custom fashion. Possibly other developers, like my organization, that might want to leverage some of the services that you have and wrap them inside of an entirely new type of product. Do you have any advice for how to create good developer relationships through the API community? What should you do to make developers like working with you versus not?

Shilpa: We have a developer portal. We have a technical writer in-house. We work together to ensure that we have a very interactive and simple interface to understand what APIs are we offering and how exactly does that work. So, it's very important to have that communication channel clear and concrete and very simple, so that the developers, even though they have a question, they can easily ... If they reach out to us and we give them the exact length or just tell them about what exactly what they're looking for, they should be able to understand on their own what kind of API bops are they trying to make or the [inaudible 00:18:15] stop and all of that. I think that's very important to have a very strong developer portal where you have all your information about the different APIs that you're offering, the different callbacks, the different errors, and make it as more engaging as possible. We have a system in which they can directly chat with us on the developer's portal through comments and all of that, and we take that into consideration and just have that as open and as simple as we can.

Suzanne: As a developer yourself, have you had the experience of trying to work with the API of another product and it wasn't set up as friendly and as customer-centric as what you've just described there?

Shilpa: Yes. I've worked, as a developer, with companies where they wouldn't have a developer's portal first of all, so everything would be through emails and they would send their documentation. We just go over it. As you see, currently there are lot of companies that offer even a superior developer portals where we have different examples lined up. You know how that API bop is going to work in different formats. It could be JSON. So, those examples were not present at a time when I was a developer and I always had the difficulty of just going to and fro through emails and not being able to understand what exactly am I supposed to do. I mean, the documentation scene is, I think, developing rapidly. A lot of bigger companies who have these great API products are making more engaging developer portals and I think that is the point to start to actually create a conversation with people by using your APIs. That should be the minimum start point and this should be there for a company who has public APIs.

Suzanne: Yeah, I think I would echo your sentiment that documentation, and thinking about the importance of documenting stuff like your own API, use a new form of product management in and of itself. So, I think a lot of the times, we neglect process and you've spoken about the challenges that can come with that, when an organization is growing, when the right processes weren't set up to begin with. And then, we can overlook opportunities to bring process or bring product management to even the backend of the business, like the one that you manage because a lot of times when people think of product management, I think the mindset is B2C. We always go B2C in our minds, so we think end customers, end users. In a business to business application, like you have at Vibes, number one, not only are your end users sort of a constellation of different business functions within any organization, but then, as we spoke about, you also have these developer end users who, let's be honest, developers are their own very specific breed of people. They need a place to feel connected with the product.

Creating value is an opportunity that presents in all kinds of hidden ways, not just in the more traditional business to consumer path, if you will.

Shilpa: Absolutely.

Suzanne: Let's change gears for a moment. I want to talk a little bit more about experimentation. I know that you are describing experimentation in the form of being agile. But I'd love to hear more about how you in your own career embraced experimentation on the business side, as well. How have you taken that philosophy and applied it to success in some of the organizations that you've worked at?

Shilpa: Sure. So, while I was doing my MBA, I got to go work with a lot of headgear clients. As we know, headgear is a very strict, it's a very regulated industry. And then there are things that wouldn't or there are situations or organizations or entities within the headgear industry that wouldn't be open to experimenting. But I come from a statistical background, so continuous improvement or lean six sigma, and all of that, is where you actually try to experiment and see if you can reduce the variation or you can actually reduce the amount of waste that is there in the headgear business industry and all of that.

So, I was creating this mobile app for Cigna. The idea was to create an app that would cater more towards B2C audience because off late ... Before the Affordable Healthcare Act was introduced, Cigna's majority of the business was concentrated in the B2B space. Thy wanted to go out and cater more towards individuals like us and sell their business. So, the idea was to experiment, come up with a new business model, come up with a new idea where they can create and communicate the value for the consumers.

I guess, those projects where I was allowed to work on the business model side of things and bring an ad value with respect to experimentation and creating new business models and creating new strategies to cater to new audience segment and new market was very interesting. And I also worked with American Medical Association in the same period of time and we built an assessment, an analytics assessment maturity model that a lot of healthcare clients here in Chicago used. It was, again, experimenting. It was finding out what the healthcare organizations like Blue Cross Blue Shield, like Blue Health Intelligence, I think it was Catamaran Health, and there are few other healthcare organizations that are now adapting analytics to find out the data and to find out what else they can offer from their business side towards consumers and how effectively they can understand the consumer behavior and offer much better services. I think I got an opportunity to experiment there as well.

With a lot of projects, it's always important to understand what is the pain point you're trying to solve and how you can give out a better solution or a new solution and innovate at the same time. So, experimentation in the way you would deliver the strategy, in the way you think about the strategy, is important. I think I got an opportunity to work with a lot of Chicago-based companies and just changing the way they think, and leveraging data to deliver the services.

Suzanne: I want to come to data in just a moment, but what's interesting about the experimentation mindset, and I think how this ties back to even what we've already been speaking about in terms of where company is in its life cycle or scale. I think many of our listeners certainly are familiar with the ideas introduced in a lean startup, in a lean movement, are familiar with concepts like minimal viable product.

One of the things that I find to be an interesting moment of inspection is how do you truly experiment with minimum viable products when you're doing it inside of a large established organization, as I think are some of the examples that you have. It's one thing for me and a friend who have a zany idea for a product that just might work to conduct a little generative research and maybe build a very small, functional component of a product, to see if there's interest even in small scale. But when you get into a large organization that already has existing customers, that already has a brand and brand equity, presumably the stakeholders become much more protective about experiments that come out of the organization. So, how does the process change in your opinion when you are experimenting entrepreneurially within a large organization?

Shilpa: I think what I've seen mostly in companies in Chicago, there's a lot of movement around that. How do you bring innovation? How do you bring transforming innovation in organizations that have their own core set of offerings, their own set of customers. It's very difficult to innovate different business models or different strategies and it's not at all possible when you are executing in one set of line and then you want to introduce this another track where you want to innovate at the same time.

I think what we need is, we need more people within larger organizations who would understand the importance of creating a separate core advantage, a competitive advantage in today's scenario. What we see, we see a lot of disruptions happening everywhere in each and every industry. What we need is we need a slightly different mindset or maybe a growth mindset wherein you maybe create a separate track of product development within your organization that is solely focused on innovation, that's solely focused on creating more MVPs more rapidly, testing and experimentation and collecting feedback and all of that. I've seen that happening in a lot of larger organizations now.

Even at Vibes, we're working mostly on innovation track right now, coming up with an innovation framework. I've worked with American Medical Association, which is a very, very orthodox ... not orthodox, but a very traditional organization in terms of how they've done business so far. But they want to seal themselves or protect themselves from the disruptors and have more innovative offerings, so that they don't get disrupted at anywhere in the near future. Everybody's slowly trying to get that in order to create a very solid competitive advantage in the marketplace. They need to have certain things, which are very unique and could be adding much more value than what their core products or their transactional business does.

So, I've worked with some other consulting opportunities where, again, the idea is to innovate. The idea is to have or develop more number of MVPs and just go out in the market and test it on and just execute on it. So, I think those two tracks have to be kept separate. As I mentioned, we need more change mindset or changed thinking around how we deliver things and how we need to innovate at a very, very rapid pace.

Suzanne: Does that changed mindset have to start at the top, at the executive level in your opinion? Or can that kind of changed mindset be influenced and informed by the bottom-up in terms of folks who are actively working on the products, connecting with the opportunities at the base level?

Shilpa: I think for larger organizations I would say it has to be bottom-up, it has to be influenced. If you're working with a smaller crew, if you're working on an idea that you are developing for your regular product launch, whatever deliverable you have, and if it is trying to iterate on it, and create something in a very different fashion, at the same time trying to innovate and just creating that culture from the bottom-up, saying that, "We like to innovate, we like to work on different things, apart from what we are delivering." So, finding out time here and there, going to meetups, working on side projects.

At Vibes, we have something called days of impact where we have two or three days dedicated between iterations just to work on side projects of things that would have an impact to our existing projects. Having something similar to that, having happiness, having a culture where people are interested to work on something totally different than what they are working on a day-to-day basis. Could be helpful in driving or pushing up the value of innovating, the value of doing something apart from the transactional stuff.

I think in small organizations, it's usually top-down because the leadership is mostly ... You know, in startups and how things work. They want to be really aggressive and be more innovative rather than the larger scale organizations.

Suzanne: If I'm listening into this conversation right now and I'm working as a developer, as a product manager, as a user-experience designer, within a larger scale organization, where there is a significant amount of, call it bureaucracy, call it layers, between me and the leadership at the highest level and I'm observing, we're not innovating, we're not disrupting ourselves, we're not embracing experimentation mindset. It's not endorsed or celebrated within our culture. What can I do to try to initiate some of that change?

Shilpa: I think it's very important to create groups within the organization who share the same kind of thought process as you do for more entrepreneurial and who want to bring or add value to the existing deliverables by doing something different. Finding those individuals, forming groups, maybe having meetups, maybe having lightning talks, within the organization, just making it like how a lot of organizations have book clubs and other things that goes on along with the regular work. Having something, which would create a separate track of innovation or just thinking about this strategy but from a different perspective, discussing or creating meetups, going to different other events, and conducting event within the organization would be really helpful. Just trying that movement there and collecting as many folks as one could within the organization.

Again, having these maybe a few days here and there just for hackathons or just for working on different business plans or just thinking about different out-of-box ideas for the existing business models that the organization has. Just kind of facilitating those discussions and finding a group and just going from there.

Suzanne: Yeah. Why I bring up the question is because a lot of times what can happen for folks who are working in a larger organization, or frankly even in small organizations, is you start to sense that the culture and the activities that believe in and that you want are not there. Generally, that leads you to a fork in the road, where one option is, "I guess I'll just keep going along with this and be an unhappy and/or losing my sharp edge" because you just start to become desensitized to it. You stop caring in the same way. Or you kind of look at the place and say, "I'm out of here. I'm going to go to an organization that's better." I think there is sometimes a missed opportunity to just simply reach for the brass ring yourself and say, "Let's do this."

Probably there's a lot of reasons why people don't have success in that approach. It has a lot to do with management, and how well or not well you're supported by your closest supervising team and the supervisors above that. But I think sometimes it's just simply nobody thinks to take action themselves.

Shilpa: Yeah. I know. That happens at a lot of places. I have friends and when we meet and they talk about our work, a lot of my friends would say, "I'm not getting that support" or "I'm not finding like-minded people in my organization. What could I do?" My only advice to my friends or people who are going through that kind of thing in their organizations would be just to constantly learn on the side. It's always important to find advocates within your organization. At least, there should be somebody who would understand and listen and find value in what you're offering.

If not, then it would be wise to work on a side project, just to cultivate that interest. Never let it go just because your work environment doesn't support it. Going to meetups, meeting people, just learning something on the side. There's so many online courses and stuff happening. Work on a side project could be helpful in that regard, but if you find advocate that would be great because if you find just one person, you start just interacting, collaborating, working together, and you never know your two-member group could actually become four, five in few weeks.

There are a lot of organizations who do these feedback reviews wherein they send you surveys to talk about what's working, what's not working. It's very important to always open up and say what's not working and why is it not working. Just to make a business case, right? What you are actually proposing could add value to the organization in some way or the other and that the organization should pay attention to it and kind of making it as strong as a business case as you can. If none of those things are working, then probably look for the right opportunity to get out of the organization.

Suzanne: In listening to you speak, I think it's excellent advice. I'm also want to call attention to the fact that you very much practice that which you are recommending here because you and I met at a meetup right here in Chicago, for that matter. So, you're out there and you're constantly connecting with the community and staying sharp and staying fresh. So, I think it's all excellent advice.

Talk to us about, first of all, what is data-driven product management in your words?

Shilpa: I'd say a product management, especially when you're making a product code map, when you're thinking about the vision about your product strategy and all of that, you interact with a lot of cross-functional teams within the organization. Be it sales, be it product support, marketing. You have your business development, you have your other operations team, all of that. A lot of those discussions around how you create a product code map is very, very gut-based and very much like ... One of the salespeople would say, "We have this request coming in from this prospect or a lead and we want this feature to be there." Most of the discussions is never around data, is never around how you're making those decisions, where are the metrics, what exactly are your initiators, what are your goals, and how are you trying to measure them and achieve them. But it's mostly around, "This is what the customer want. We want to make them happy. We want to make this person happy or that client happy."

So, data-driven product management according to me is leveraging data, whether it's process, whether it's in what you're trying to achieve with your product code map, or whether it is the execution, like how you want to increase the team's productivity and achieving what you want to achieve in the few iterations or quarters. Using data as much as you can to, again, talk to your stakeholders and bring an alignment across the various teams in an organization to build what you want to build. Just make it much more quantitative as it can be.

Suzanne: Is there an example that you can share with us about some of the ways that you're leveraging data in your own product management focus? I think this idea of quantitative insights, again, there's a lot of conversation about how you can use that to optimize the funnel for example. So, again, if the vertical that you're owning has more to do with "How do we acquire customers? How do we activate them? How do we engage them more fully in the product." It would strike me that given the aspects of the product that you own, there's going to be different metrics that matter. So, what are some of the metrics that matter to you and what are some of the ways that you've been able to leverage a data-driven approach to find success even in this kind of backend product management that we speak of?

Shilpa: At Vibes we have a few metrics, so we have a few SaaS metrics, we have API metrics, and we have the general business metrics. Where we use data the most would be especially making the decisions around how our roadmap should look like and then using those metrics. So, when we have a few higher level goals to achieve every quarter or every year, we have a very scientific approach of using the metrics to make the outcomes of what we are trying to achieve by designing the codes. Let's say, if I want to decrease our customer acquisition cost, what are my goals? If I have these two top priorities for the next iteration, are they actually meeting that matters the most to me?

So, out of all the metrics that we have, let's say for API, for SaaS, for our general business metrics, we try to pick up those three metrics, that's the revenue or churn or the monthly recurring revenue from the business side. Are we trying to meet those three metrics by the decision that we are making and if we're trying to do these n number of projects, how are they meeting those metrics or how are they meeting the outcomes that we want to achieve? We want to achieve, let's say, X percentage of monthly MRR increase and how are we going to do that?

When we're trying to come up with a concrete list or a backlog of items that we want to discuss with our stakeholders for bringing them down into quarter level cones, we're using data around the metrics, as in this has been historical data till date with our metrics and we think these projects could add value to those metrics. We just give them a fictional number, let's say, this project would increase this metric by maybe 20% or 10%, 15%. The approach is very much tied with respect to data, with respect to how the data has been historically on metrics, what are the decisions that we are trying to make, and how that is affecting our top metrics. And then, we try to come up with outcomes that we can match later on once the project has been pushed or delivered by, "Okay, this is how much we moved the needle by." We have this three step or layered process of making decisions and making the prioritization of the features that should roll out first.

Suzanne: Tell us about your roadmapping process currently. Is each product manager at Vibes owning their own product road map, and then at some point, those various road maps are being synthesized at a director level? Do you personally inform the roadmap decisions or do you simply support roadmap decisions that have been articulated by somebody else?

Shilpa: At Vibes, we all support single road maps. We don't have a particular road map for each of our teams, but we do have certain teams or certain projects that our team would like to work on or could be very crucial with respect to what the teams have been working previously and what matters towards our overall company vision.

What we do as a team is we talk to different individual stakeholder groups, so we have requests coming in from each of our stakeholder groups and we combine them altogether into one single unified list. Then we have a prioritization framework with respect to a lot of different metrics and different parameters. Let's say, revenue we have financial risk, we have revenue metrics, we have metrics related to how much market excitement or market positioning that feature can offer. We take the list off request from all the stakeholder groups. We put numbers for each of those projects or initiatives across the different parameters and then decide on the top priorities that we want to work on and just get feedback from the stakeholder groups and try to sell them on the pitch that this is how we came up with the decision of what we want those three or four or five top priorities. The roadmap is something that the product team works together on and we do it every quarter because we have quarterly initiatives and quarterly priorities and quarterly road map.

Again, we also have a yearly road map that we decide in the beginning of the year. That is something that we take a lot of market excitement, market positioning, customer validation, what customers want, all of that, into a road map, but that's not very concrete, but the quarterly priorities or the quarterly road maps are very, very concrete with respect to what data-driven prioritization framework that we use.

Suzanne: So, when you get into these quarterly roadmapping sessions, how many people are typically in the room at a given time negotiating this discussion?

Shilpa: When we do it among ourselves, the team, which is five of us. When we're doing it across multiple stakeholder groups, we have leads from each group. So, it's usually about seven or eight stakeholder leads and then it's us. So, it's 12 or 13 people in a room together. But, again, as I mentioned, if we're all just talking about what each individual team wants, the discussion can be very chaotic, but when we have this framework with numbers and with the ratings, the project scorings, that we think are the most appropriate ones for those projects, it becomes much more easier for us to have stakeholder buy-in.

Suzanne: Yeah. What you're describing is a weighted scoring approach to prioritization. One of the activities that I love to do for students that take my product management course is whatever we're learning, that's almost the secondary thing that's going on. I just like to put a bunch of people into a group and then have them figure out how they're going to reach consensus because I think this is such an important part of it, whether you're a larger organization, whether you're in a smaller organization, is this idea of alignment. How do we align on our goals? How do we align on what's important? I think weighted scoring is a really good approach because it removes the sense of arbitrariness that can sometimes emerge from when someone just says, "Well, that's not a priority." Based on what, right? When it feels too rooted in a gut feeling or somebody else calling the shots, if you will, weighted scoring can help. But sometimes even weighting the different items can lead to a whole bunch of discussions or debates. So, it's a process to get people rowing in the same direction.

Shilpa: Yeah. I think the most challenging part is to get an alignment on the framework that the product team's using to make those decisions. If these stakeholders feel that the framework is very, very data-driven, data-oriented, they usually are convinced much faster rather than, "Okay, why did you pick that up in place of the other one?" I think that helps a lot, having the weightings and having the rankings and all of that.

Suzanne: We traveled so far along and in the end we came back to process because these kinds of frameworks, they're just processes for: what is our process for how we make a decision? What is our process for how we elevate those projects or initiatives that we want to focus on over the next quarter?

Shilpa: Absolutely.

Suzanne: Shilpa, we do a segment on the show called, "Get the job, learn the job, love the job." I would love to start by asking you what advice would you offer to somebody listening in who is looking to become a product manager, whether they're coming completely from a different industry or whether they're coming from a developer role or a marketing role, and longing like you, to have a little bit more of a holistic involvement in the job.

Shilpa: Sure. A lot of people ask me whether it's important to have a technical background becoming a product manager or do you need an MBA to become a product manager? I would say, the first and foremost quality, if you want to get into product management and want to love what you do as a product manager, you have to be really, really curious about things, ask a lot of questions, understand what exactly, why or how products are built and what's the process of introducing a product and how successful products become really popular or really solve an important product.

So, having that curiosity, having that problem-solving mindset is very important for anybody who wants to get into product management. Anybody who loves solving problems would be a great fit because you can learn technology, you can understand how you need to communicate with different teams and different groups within an organization. But what is more important is to have this continuous way of thinking and trying to solve problems and all of that. So, I would say, understanding how an industry or business works could be helpful. Having a little bit of technical background would be really helpful. And then, if you're good in communication, you're good in understanding, working with teams, that would be super helpful. But just trying to see how you can leverage your background, whatever it is, to just make it much more pinpointed towards solving problems and being a problem-solver could be helpful to getting into product management.

And then, of course, you have to meet the right people, you have to apply to the right positions that matches with your background. I think I've seen, if you have some domain expertise within an industry, it's easier to find a product management job in that industry. So, maybe you could start from there. If you have done a lot of healthcare projects, worked with healthcare clients before you could probably apply to a healthcare product manager role. That would be easier to get. I think just understanding more about the business, about consumers and just having the curiosity to learn, I guess.

Suzanne: Yeah. I couldn't agree with you more. I say often the two most dangerous words when used together, "I" and "know." I think especially as product managers, the minute that we start to occupy "I know" space, we forget to ask the right kinds of questions, we forget to consider why is this happening, and all of the experimentation, all of that validated learning process dissolves before our eyes because it's predicated on the asking why and making an assumption or a hypothesis and then trying to find out the answer.

Shilpa: Yeah.

Suzanne: So, I agree. I think your advice about, I would almost frame it as daisy chaining. So, saying, "Okay, so you don't have the product manager title on your resume and you know you want to get into product management. You've worked as a project manager for this healthcare company. Go leverage what you know about healthcare and your passion for wanting to be involved in product as a starting point, even if that's not the ultimate place that you want to be as a product manager. But once you start getting more experience as a product manager, it's easy to then kind of do a jump into a different vertical because what you understand is the processes and the frameworks for product management, and learning the industry becomes the new thing that you'll be doing."

Shilpa: Totally.

Suzanne: What about hard lessons learned on the job? Speaking from your own experience or speaking from ways in which you've seen folks struggle because sometimes we make it sound easy. I think you make it sound very easy, but you have tremendous credentials behind you. What about product management is harder than it seems?

Shilpa: It's working with a lot of teams, working on a lot of projects at the same time. So, people say, "Oh, women are good multitaskers. They can do a lot of things at the same time." And it always takes your focus away from something that you're working on just because you have to be on a different project or you have to work on a different deliverable or goal that is required for your role or responsibility. I guess, the challenging part is to balance everything. The challenging part is saying no to a lot of things, a lot of distractions, and just focusing on what exactly needs to be delivered at that point of time. Having this, again, the lean thinking in your head that, "I would be working on stuff, but let me attack the first problem and attack the important problem first and just go on from there."

Creating that sense of order in your head while you're a product manager is very important because what product managers do is, it's anywhere between strategic and tactical. So, you work on strategy and the next moment you have to answer questions from your team on a certain feature that they don't know how to deliver. Then there is product support. You have requests coming in from your customers, some production issues, bugs and all of that. So, I think it's very important to have a nice balance between all of these and then have an order in your head on what you're working and be focused in any given point of time, and just get it done. Just be present in the moment and just attack everything. That's the most challenging part to maintain a balance and the schedule done [inaudible 00:53:40].

Suzanne: Given that you have participated in so many different types of roles, as we spoke about earlier, but ultimately settled on product as being the favorite. What can you say about why you love the job?

Shilpa: I love it because I get to work with so many different disciplines and teams. I have a marketing background, so I get to work with marketing and sales. I get to know the business. I get to understand the strategy and how a product can make a very big difference to the entire corporate strategy of the organizations. I get to work with executives, the leadership teams. I get to work with the support guys, with the developers. I was a developer myself, so sometimes just seeing the code and discussing about the technical architecture actually tickles my brain because I come from this engineering background and that of course it's always great to know and learn new concepts and see how code is being written and just get involved with those guys.

The fact that I get to work with all of these teams in one single day is absolutely fascinating to me because overall if you want to see ... I'm working for the entire business. I have this business mindset and trying to see if I'm solving this problem, how it's affecting the business. At the same time, I'm evaluating the technical risks, so it's a very holistic role, which I love.

Suzanne: You talk about you see the code or you're having a conversation about information architecture. Is it tempting at all to go back into domain specializing or domain expertise because the trade-off, you described, "That I get to touch a bunch of things." And I would definitely echo that sentiment for myself. I love that my job lets me participate across a number of different centers of gravity. But sometimes, if I'm doing some wire framing or more deeply involved in, say, customer research, I'm like, "This is so fun. Why do I have to leave this?" Do you ever feel that way?

Shilpa: That's the hardest part, yeah. I do. I work on a couple of side projects. I'm learning some new technologies, so of course, sometimes I think I wish I could be the developer on this particular piece of functionality. But then, again, the tradeoff is I always wanted to be on the business side and contribute more in the strategy and growth of an organization. So, I always feel that, fine, that's good. But then, maybe some time later, but now. Maybe I want to learn more about the industry, more about the organization and how it functions, how it operates.

Suzanne: Yeah. It goes back to what you said: focusing on the right things in the right order.

Shilpa: Yeah.

Suzanne: Do you have any recommended resources for our listeners, books, blogs, podcasts, other that you think would be worthwhile to check out across any number of topics really?

Shilpa: Absolutely. For product management, I go to Medium. I look for product management articles, but then, there are so many. So, you have to actually go to filter as in find out the actual focus, what do you want to learn more about, which aspect of product management you want to learn more about. So, I think Medium is a great resource for anybody who wants to read anything from technology to startups to product management to machine learning. Almost everything.

Then there are podcasts like 100 PM. I think there's one more, which is TIPM, which I usually listen on. I forgot the-

Suzanne: This Is Product Management.

Shilpa: This Is Product Management, yes. I think those two are great podcasts. I read a lot of books, so I would recommend a lot of great product management books. You can go on Amazon, you can find books like Hooked or Lean Startup Thinking and ... forgetting a few other names. But mostly, on the lean startup, those books could be recommended for a child thinking of product management, and all of that. And then, Mind The Product, I really find their site very useful, and also on their Slack Channels. They keep on posting stuff, PM resources, lot of discussions happening around small specific topics around product management. And I think I find that as a very useful resource.

Suzanne: Excellent. All of that is great and absolutely Mind The Product is an excellent organization. Lots of local meetups. Do they have local meetups for Mind The Product here in Chicago?

Shilpa: Yes. They had one, a product tag meetup recently, few weeks back, at Yellow, which was about MVPs. It was great.

Suzanne: Awesome. Thank you. Last question before we wrap. Is there a professional or personal life philosophy that you subscribe to that describes your approach to being in the world?

Shilpa: This is something that my mom tells me. Don't ever feel that you're doing something, which is irrelevant to why you're doing it. So, my mantra in life is to continuously just go out, meet people, learn and then work on my strengths, make it much more stronger. Also work on weakness as well. Never ever feel that anything I'm doing is small or doesn't matter or doesn't have value. Everything has a value attached to it. Always continuously seek what you want to learn and you keep learning.

Suzanne: That's a beautiful sentiment and I think you're absolutely living into it. Thank you so much, Shilpa Mohanty, for being part of our show.

Shilpa: Thank you so much. It was a pleasure, Suzanne.