In this episode I am talking to Kaushal, a fellow product manager, and we are discussing multiple challenges while working with the remote teams, ways to address these challenges, and engage teams effectively.
Transcript (courtesy of Otter.AI)
Please note that the transcription below was generated automatically and may contain misspellings and errors. If you want to help with cleaning the transcript – please get in touch!
Vlad G 0:07
This is real world product management.
Hello everyone. This is yet another episode of Real World product management. And I have another guest for you guys today is kachelle Vyas kachelle. Could you please introduce yourself? Tell us a bit more of what you did and what you’re doing right now.
Kaushal V 0:30
Hey, hi. So my name is Kaushal. I’m joining today from London which is where I’ve been living for the past few years. I am originally from India. Some of my interests include behavioral economics, international music and cinema, mindfulness and playing cricket. Professionally, I’m currently leading product growth and monetization at a company called pocket. pocket is a mobile banking product for the funnel. underserved and it comes with a contactless MasterCard. I’ve been at pocket for just about a couple of months. But over the over the past few years, I’ve been lucky to have led various successful products. My my first product management role was with a Kids TV app called hopster. I was the first product manager there. And you know, one of the highlights of my time there was was that during all the years that I was the product manager, the app was recognized with the best of 2014 best of 2015 investor 2016 titles on the on the Apple App Store, which was which was quite an interesting achievement for a small team based out of London. After that, I spent some time with a company called game sis who, who are an online gambling product company. I was looking after a product called called unicorn unicorn apps, which was a Large platform product. And my demo here was also interesting in that I work with a really large team of about 30 people and we were split into four different products, courts all working on the same product. After that, I spent some time in the in the b2b space, I was with a company called Global app testing who were a crowdsource QA testing company. And, you know, I was looking after the supply side of the product. And yeah, beyond that, I recently moved into FinTech with with a company called pocket. And today, I’m happy to share some of my experiences here with with lead.
Vlad G 2:45
Cold, thank you. And my apologies for mangling the name, I’m horrible. With names. You mentioned that with your first engagement, your first gig as a product manager. You work with you work with the kids app. And my understanding is that the user and the customer in best scenario are quite different the customer, usually the distinction that I make is the customer who is the one who’s paying for it, and the user is the one who ends up using it. So your customers and adult and your user is a kid. Yeah. Did you guys how did you guys approach that in the b2c market? I I see this constantly in my daily life with a b2b products and that it’s normal. So how did you guys tackle that? In the b2c space?
Kaushal 3:33
Yeah. So that’s a great question. I’ll start by just giving a very brief context of what the company tried to do. So So hopster is is UK top grossing and top ranked Kids TV app, the vision of the company was to make screen time smart for kids. traditional television is is you know, littered with ads and is quite popular. And, you know, hopster wanted to give parents a better option. And the way we would do that is by having some of the best video content from around the world and pair that with with various learning games and storybooks. Right. So that’s the context. Now, coming to your question. So, you know, in the, in the early days of hopster, the app experience was designed around a two to four year old and chances are that a kid that young is, is probably not able to read or not able to make sense out of language. And so so the app experience was was, you know, without any text without any sort of information, and it was it was designed as an intuitive experience. Now, as a result of that, what what had happened was, you know, The apps abandoned rate was quite high. And what that means is about half the users who installed the app from the store would not come to the app again. And that was that that was a waste of our acquisition money, basically. And, you know, what we realized was that the apps first time user is a parent. So it is a parent who would install the app from the store and do a sanity check before the parent would hand the app over to the kid. And because we did not do a good job of onboarding, the first time user, we were seeing a lot of them just abandoned the app. And so that is when we realized that you know, we we need a different approach. Yes. You know, the app. The apps main user is a kid. But a parent is an equally important user because it Is the parent who makes the decision to buy the app and and and, you know, hand it over to the child. So, our approach to this challenge was was around building a timeline. Right? So we would we would think about all the all the touch points with the user and the customer and sequence them. And, you know, so the first time user is a parent chances are the second user is a child. The third or the fourth touchpoint could again be a parent, you know if they are renewing a subscription or if you’re if the Wonder child to explore some new content. So what we did to alleviate the the abandoned rate problem was basically build an onboarding experience that would give parents the confidence to hand the app or to the child and You know, interviewed some parents around what, what they would like to see before they would trust the product with their child. And, you know, a few things came out like parents suggested that they wanted to understand what was free and what was paid in the product. So the product was was a freemium product. So some content was free, some was paid. And parents wanted to know how that worked. parents wanted to feel that you know, the offering is is is safe, it is curated it is it has the kind of certifications that kids apps should have. And so yeah, like the, you know, the onboarding experience was was around trust around giving them the confidence around explaining them what the offering was. And in addition to this, we you know, we we also wanted to Encourage the parent to create an account so that we could we could get them into our CRM. And this was simply a business sort of objective around this because, you know, if the parent is not engaged the first time around, chances are it is really hard to engage them second or the third time around. So yeah, like the onboarding experience was around, giving the parent the confidence that the product is safe for the child, and also encouraging them to create an account in the in the app.
Kaushal 8:32
So yeah, so I first prototype with onboarding, addressed both of these concerns. And we saw that the abandoned rate of the app came down significantly. So it was half. So earlier, the abandoned rate was at 50%. After the first iteration, it came down to somewhere around 30 or 25%. And then we kept iterating over it eventually. It came down to about 10%. Pretty so so this hopefully gives some idea about how we thought about, you know, the user and the customer being different. And designing the app experience based on who is engaging with the product at which touch point,
Vlad G 9:21
though is this is interesting, thank you think of sharing this is really cool, as you keep saying they’re different, but they’re both engaged. I wonder in, in the current terms, I don’t want to really bring up specific frameworks. But if you’ve, if you use any specific approaches, I don’t know empathy, maps, journey maps, personas, jobs to be done. Or you just kind of intuitively built that timeline with touch points.
Kaushal 9:49
Yeah, that’s an interesting one, I guess. I guess, um, you know, at various points in my time at hopster. We’ve we’ve used Like some of the frameworks that you mentioned, jobs to be done is certainly one of the more popular frameworks around around product, building the product for the right user and, you know, helping them helping them do the right job with the product. I’m trying to think if there is like a singular framework that could, that I could I could talk about here, but yeah, like from what what I remember it was it was like a mix of of using user personas. jobs to be done. And, and the timeline based approach at at various points in time because, you know, like the onboarding, case study that I just talked about is is one of the many other use cases that we designed the product for. And for four different use cases, we would have you used different frameworks. So yeah, like there wasn’t like a one.
Kaushal 11:07
One size fits all framework that that we were using across
Vlad G 11:13
across all of the touchpoints across the whole product. Right. That’s, that’s, that’s, that’s a great answer. Thank you. It’s, it has to be the right tool for the right job. You can’t, you can’t really say yes, this is the only thing we’re using. Alright, cool. So, once you’ve left that company, you transition to game six, the online gambling platform. Yes. And I have I actually have a bunch of questions about this one. One is, I wonder, how did you approach platform as a product? How did the whole concept work? Was that an internal platform? Was that a platform you guys offer to the market? Can you elaborate on that a little more
Kaushal 12:01
Sure. So I’m again going to start by giving a little bit of context around around the company. So gives us is a is a leading international online gaming operator. It’s one of the one of the larger ones in the UK it operates brands such as virgin casino virgin games jackpot, Joy heart bingo and, and some others. I was a part of a department called player services and Play Services, as the name suggests, looked at everything outside of the games themselves. So placing bets or payment gateways or promotions or hybrid apps, load times registration, etc. Right. And the product I was looking after was called, called called unicorn unicorn apps and it was essentially a brand new platform for The company and what I mean by that is, is that, you know, the company had been around for a good 1015 years by then. And its main products were still a desktop first was still desktop first products. And this was 2017. And if you’re if you’re not mobile first, then then you’re probably not going to survive for long, especially in the b2c market. To my product was the company’s foray into the mobile platform. And it was also a platform for a quote unquote platform in in a in a different sense of the word for the rest of the company’s products to plug into. So yes, there was a front end aspect to it, but there was also a back end aspect to it in that a lot of the company’s other services such as payment gateways and KYC, and promotions and recommendation engines, and everything. would plug into that product, which would then be showcased to the user on the front end. So it was platform in like a couple of ways. One was it was a replacement for the desktop platform. And it was also a place for the rest of the company’s products to plug into.
Vlad G 14:21
Let me rephrase my question a little bit. You’re still you’re still product managing that platform? Yes. Okay. So this is this is just to give you a reason for this question. Yeah. This is something that a lot of companies are struggling with is coming up with the rationale. Why should we call the platform a product and what’s in it for us? I mean, it’s a platform. It’s not like, you know, a product that we can offer, package and sell. It’s our internal platform, kind of like a CRM and by the description, which you said is it It feels again, I don’t know enough to really call names here. But it seems like it’s a universal, kind of like a business. Can business processes boss or data boss feels like it. I’m not saying I understand what it is. I don’t have enough data to go on. But it just feels like it is a platform but not a product. How did the company rationalize that, hey, let’s treat this as a product. How did that happen?
Kaushal 15:30
That’s That’s an interesting question. I think I think. Well, yeah. I guess your question is also about the semantics of what is a product versus what is a platform? Yeah. And thank you. So
Kaushal 15:46
in, you know,
Kaushal 15:49
the the company’s model, revenue model or other the company’s business model was you know, having a solid white label gambling platform that could be spun off as you know, a custom made branded product for for brand a and could also be used, you know, you could apply another branded skin to it for for another brand and so on. So, I guess I guess it was a platform in the sense that it was
Kaushal 16:32
it was it was helping all of the other
Kaushal 16:37
Microsoft services integrate with with something tangible and the company’s rationale around calling it a product and you know having a product squad and product management resources
Kaushal 16:56
dedicated to it was was simply because
Kaushal 17:00
It was important for the company to to make
Kaushal 17:07
steady progress on that front
Kaushal 17:10
simply because the the internet landscape was changing right? desktop, a lot of desktop first technologies like the product was product used flash so the desktop product used flash quite extensively. And you’re probably aware that flash died a terrible deaths over the last few years were different, like all all the mainstream browsers have now stopped have either stopped supporting or provide a very limited support to flash. And so it was you know, it was it was in the company’s interest to to have a different product out there which could become the company’s main product, which we could sell to other brands. So, to me, I like it, you know, it made a lot of business sense for the company to get this product up and running in a matter of a few months, which is why it was it was given the title of product, but in the pure in the pure semantic sense, it is it is it was effectively a platform. It was not necessarily building new kinds of interfaces, it was just giving some of the old interfaces a new
Kaushal 18:53
place to be visible. If that, if that makes sense.
Vlad G 18:58
It makes it Yes. Thank you for explanation it definitely makes a lot more sense. Once you started talking about platform being a white label capability for for to be spotted for other brands and for other micro services to plug in. It’s starting sound is Yes, it did sound like it has it. It has all the rights to be called a byproduct. So yeah, it definitely makes sense. Thank you for elaborating. And it paints a better picture now in my head, at least in my head. The explanation. Okay, so you mentioned that’s that’s the place where you had 30 developers and you were split into the multiple teams, you called them. I think you called them squads. You have to work on this one product. So that’s another interesting challenge that I’ve seen in multiple engagements where product is large enough to warrant large development team but then you can’t really manage 30 4050 people you have to break them up into product teams or agile teams, however you want to call it show and challenges that I’ve seen. And this is this is kind of the question for you What have you seen, on your end Mike might provide what I’ve seen on my end was, it’s hard to come to a certain level of understanding, especially when teams are both varying the either old teams are very innovative and trying to get things done better. So they there look for opportunities in all the areas not specifically the areas that were assigned to them. And they, they have good intentions, right? They try to do better, or teams are very passive, and they only do what they were supposed to do. They’re not looking for ways to improve things. They’re not looking for opportunities to innovate and improve. And it all falls on the product manager to kind of run around and tell everybody what to do and do all the orchestration. So what was what is this what is your story? What is What was the situation with those teams?
Kaushal 21:03
It was?
Kaushal 21:05
Yeah. So because
Kaushal 21:08
so as I mentioned in my previous response, because it was a very important product for the company, and it was quite a large initiative within the company. We had a huge backlog. And this also meant that we, we we needed the all the technical muscle, all the resources we could. And so so the 30 people, we had included developers, designers, QA people from insights, business analysts, and product managers. And, you know, it’s like having a single product squad of these many people is basically not not practical, because it it makes all of the it makes the team unwieldly like having meetings with everyone involved. Coming to consensus is essential. It’d be hard. So it was just, it was purely for practical purposes that we were split into smaller squads. And each of these smaller scores about was about seven or eight people. And but all of us all of these squads were working on the same product. But because we had split into smaller groups, and because because each of these groups had their own ceremonies, you know, a couple of them use Scrum, a couple of them use Kanban. They had their own retrospectives, etc, etc, etc. It seemed that we we were working in a fragmented way. And we are sometimes pulling the team in in opposite directions as we were not fully aligned. We would
Kaushal 22:48
as I said, we would have individual backlog grooming sessions.
Kaushal 22:52
We that there wasn’t a complete sense of ownership. Like if if a bug would come up it it would take About about a day or so to figure out which score out of the four was accountable for that bug, and who would be the best person to fix that. So, so to summarize the challenges were around alignment ownership and And generally speaking of cohesion that was lacking among the squads. Now, of course, you know, as a pm This was making my my job really hard. So I wanted to get around these issues. So, so myself, a couple of the tech leads and and their Delivery Manager. We, we had a discussion around what we could do, and a few things came out, right. So this is, as I said, the problems we were trying to tackle were alignment, sense of ownership and a sense of cohesion, the way we went about alignment was was by creating a shared vision. Right? So I wanted us all to define the North Star that would guide everything we do going forward. So I gathered everyone in a workshop for a couple of hours and got every one of them to write their views on what we were trying to do on posted notes. And I, you know, I wanted to ensure that everyone was involved in that. I would encourage everyone to think about the why the quote unquote, why the purpose and
Kaushal 24:46
you know, like the, what came out of that was, was like
Kaushal 24:52
a singular statement which meant we want to help Apart customers quickly find discover and place bets on the games they love. Right? So this I mean, to an outsider like you, this may not be the most relevant thing. But yeah, like this statement gave us a sense of purpose. And this statement sort of was unique for all of us. So all the force courts would look at this statement for guidance. And on the back of this on the back of this vision workshop, I then had another workshop where we talked about our success metrics. So we’ve we’ve defined what our y is, we now wanted to define our water. So, so far for us, basically, we were looking for something that that would tell us that we are making progress on the why and to serve the country. out the success metric was was around time to wager. And what this meant is like from, from the point that a user logs into the product, how long does it take for them to place a bet. And the lower this KPI, the lower the time it takes for the user to wager, the faster it is for the user to find the game. And that was our definition of success. So we knew our y we knew our what and and this sort of guided everything that we were doing so earlier the teams are moving in opposite directions like some of them words. The some of them wanted us to pursue initiative a another squad was was quite passionate about initiative P. But now now that we all sort of agreed on you know, guys, this is what we are trying to do. It gave me a reason to do so. argue with them. And you know, like so if a certain team would say that we are passionate about initiative a, the next sort of counterpoint to that was, hang on, is this really taking us along the lines of where we want to be? So, so yeah, like this, this has the vision workshop and the success metric workshop. It helped
Kaushal 27:28
all of our conversations around alignment.
Kaushal 27:33
Now, the second bit was was, you know, around creating a sense of ownership.
Vlad G 27:40
I’m sorry, hold on one second. I want you to continue. But I have a question in regards to your Yep, go to the alignment part. So you’ll created the shared vision you have created the shared success metrics for the whole product. So you would have all four teams kind of driving towards this same direction. How long did it take them to agree with you or to agree amongst themselves to these common metrics? Was that just one workshop? Or did it take some time for them to come to kind of come to grips with reality? It
Kaushal 28:18
I wish it was just like this, these couple of meetings that you know, we all agreed on, on what what we want to do. But yeah, the reality was, was different. Out of the workshops like the the the main objective of the workshop was to was to get people’s thinking, right, get people thinking about a single question. Even if our thoughts were different, even if some some of the team members thought differently about about the vision, or the success metric, that’s fine, but at least they started thinking about it and it took me like, at least two to three weeks to sort of negotiate around around these two things. So, you know, like, it’s it’s really important for us to get the vision statement clear in everyone head in everyone’s head. And, you know, which is why the wording was quite important. So yeah, like it did take me a good few days or a couple of weeks to sort of have everyone agree on a singular statement. There certainly were different differences in the way we thought about what we’re trying to do. And the workshop simply brought all of that to surface. And it allowed us to start having a conversation around around this topic.
Vlad G 29:53
Okay, before before we could do one more question that I had, what would you say was the top What’s the top contention point or top tension point? There’s so in other words, you know, there’s usually like minor things that can be either completely thrown out or just kind of a compromise on or, you know, you can reach a compromise and something but there would be one or two pain points with each team that they really take a hard stand on says no, this is really important to me. I don’t want to compromise on it. But you know, I mean, I do want to compromise on it. But I want to I want to sell it for the heart. Sure, sure. So what do you what what were the points? without going too much into details? What were the points that teams didn’t really want to budge on until the last moment?
Kaushal 30:40
Yeah, so if I remember correctly, like one of the contention points, or rather, one of the main contention points was around what we should commit to as our success metric. As I said earlier, because it was a platform product, a lot have other products sort of plugged into plugged into our product. And we would serve the information we received from from from all of those other products. And so in some way our product relied on the information we would get from them. And it relied on the performance of those all of those products. So if if our KPI was say, you know, time to wage, or how long does it take for the user to place a bet from the time they log in it, it covers a lot of other things that happened between those two milestones. And for some of those things, we would rely on someone else’s product. And, you know, our performance was at the behest of their performance. So I remember that some teams were hesitant around committing to this as a KPI. Simply because we would be held accountable for this. And, you know, if not, if we did not have 100% control on what we are trying to impact, then is it really worth committing to that? And so yeah, like that was that that was one difficult conversation or other a few difficult conversations that I had to I had to have with the team. Makes perfect sense to me. I can see why they wouldn’t want to commit to that. But I see why. Yeah.
Vlad G 32:30
As a product manager, you would have to, truly so I definitely understand it. Okay. Cool. Thank you. That was that was really interesting. So you have two more left you have ownership and cohesion.
Kaushal 32:43
Yes. So
Kaushal 32:47
as I said earlier, you know, the ownership issue was mostly around, you know, if an issue came up with a certain feature, it took me a while to figure out who would be accountable to fix that. And, you know, I like to think that that engineers are highly skilled problem solvers. So, so I like to start by defining the problem or the opportunity, instead of instead of my saying, you know, here is a feature that we want to build. I prefer, I prefer presenting the problem first saying, you know, X percent of our users are facing ABC problems. And we want to pursue we want to explore solutions to these problems. So So, you know, once I’ve, once I’ve defined the high level problem, the solution exploration could be a team effort. So the solution does not necessarily have to come from the designer or the product manager or someone higher up the ladder. You know, if the team is invested, I think if the team is involved in the solution making or solution design process there there is an automatic sense of ownership like engineer, if an engineer is involved in in saying you know what the best way to solve so and so problem is such and such, then if in future an issue comes up with with that solution, the engineer is much more likely to, to sort of own up to that and and find better ways to fix that problem. So, so yeah, like the way we
Kaushal 34:33
went around creating a sense of ownership was
Kaushal 34:37
was mostly around how we would present new feature requests as problems who solutions needed to be found out. And so, that was around creating a sense of ownership and around creating a sense of cohesion. We You know, we a couple of couple of things come to my mind one was having a group backlog grooming session where instead of having like individual backlog grooming sessions we would have a single backlog grooming session where every every squad or at least one member of every squad would be invited and you know, we would talk about up and coming features which we would like to explore and what this helps with was what was that every team was aware of what was what was going to be worked on in the in the in the near future and by what team. So So that was one and the other was having a group retrospect So, so this is where we would discuss process improvements across the entire group and not within the individual squad. So So yeah, like having a group backlog grooming session and having group retrospective sessions, we were able to generate visibility about what the entire group was going to be doing. And also discuss, it also gave a forum for everyone to talk about how we could improve as a as a as a group, rather than individual squads. So yeah, like a In summary, the way we went about solving some of these problems were step one, create a shared vision. Step two, have a sense of ownership. And step three, involve everyone in you know, in a group retrospective and a group backlog grooming session, to have visibility and a sense of cohesion.
Vlad G 37:00
Cool, thank you, I might have missed this in your answer. But did you end up with the same cadence same ceremonies across all squads or they kept whatever they were using just came to the gel ceremonies for
Kaushal 37:18
the whole day. The The, the existing ceremonies that the squads had were not affected. Because they were they were anyway important. They were anyway required rather. And, but because we did not have a forum where the entire group was meeting, we needed that forum for visibility and for discussing process improvements.
Vlad G 37:43
Okay. All right. That makes sense. Okay, I mean, I folders fancy I kind of expected you guys to come up with a common cadence common framework, common kind of a job approach is something we in our organization are advocating for because it’s not, it’s not necessarily improves cohesion while it actually does. But that’s not even the main goal. The main goal is predictability of the results. And kind of alignment across, across multiple teams working on the same on the same product or the same project or within the same initiative, the same work stream, if you will. In our in our model in our governance model, everybody’s using whichever system, whichever framework, whichever agile approach they like, we don’t basically we’re not going to tell you which one to use, just as long as you stick to one. Everybody should be using one because it improves predictability and improves the quality of overall delivery. But it’s interesting to see you guys having different experience. And my understanding is because you didn’t do that it that doesn’t Straley it doesn’t automatically means you’re Right, you’re still you still weren’t successful even without instituting the common agile approach across different teams.
Kaushal 39:06
Yeah, I guess I guess it’s
Kaushal 39:09
there is there’s only so many battles that that that product manager can can fight. Right. And it was really important for me to to find the important battles. So yeah, like there is there was a, you, you you, you get someone you give some right. Yes, I wanted to get a few things done in the way I saw fit. And in return, of course, you know, the team deserved to do a few things that we they want to do them.
Vlad G 39:39
Okay. Okay. Make sense? Again, in the same full transparency, I’ve seen teams not having same frameworks, not even same cadence, but still kind of moving forward. Because they had different maturity levels. And and that’s perfectly fine in my book. I mean, I’m not saying they have to, but It looks, you know, from overall experience looks like this. This is a better approach, but I understand you. I understand the ways you have to find your battles. And I’m with you on that one. Believe me, I know what she’s talking about. Okay. All right, cool. So moving forward. Let’s talk about the third or the other engagement that you had in the b2b company that you mentioned. Yet again, I like how you give the overall background first, and then we dive into detail. So she’s gonna let you do that. It looks it works well for me. So she’s worked well for audience. And now we’ll dive a little deeper.
Kaushal 40:39
Yeah, so. So yeah, this this is about my time at global app testing. And global app testing is a cloud testing platform. Our our clientele included customers like Facebook, Google, Microsoft, Spotify at some point shell G, and so on. And what we do is we help these brands test their products out in the real in the real world with real users in in various parts of the world. So it’s a, it’s a classic marketplace like model where you have a demand side and supply side on the demand. on the demand side, we had these big brands who need to test their international products out in the wild. And on the supply side, we had a crowd of professional testers around the around the world. And if I remember correctly, your question is about the challenges like the challenges if relevant to product management, in this setup, right?
Vlad G 41:43
Correct. Yes. Since you’ve said yeah, full remote setup, b2b and this is before the pandemic. So how did you guys do that?
Kaushal 41:52
Yeah, yeah. So to working at a global app testing was an interesting experience in terms of orchestrating distributed teams. We we had product sales, marketing and finance teams in London. And all the other verticals like tech, QA operations, data science. We’re in, we’re based in different parts of the world. Even within my product squad we had, we had to work with at least at least three time zones. And, and this made it a little bit tricky for us to move together at at first. Now, the challenges were primarily primarily around engagement within the team. It was, it was it was hard to have live discussions, it often happened that it’s it’s lunchtime for some devs when you want to discuss something important, and it’s, you know, it’s it’s, yeah, it’s it’s not lunchtime in London. I know the challenge was that it was It was hard to generate team chemistry because we were not co located. And needless to say that English was the second language it was its third for me. And this didn’t really help at the at the start. So our meetings early on, they were quite dry, you know, with with little to no participation from the team. And this led to again, a lack of ownership, slower velocity and, and, and communication gaps.
Vlad G 43:35
So
Kaushal 43:37
in order to come around some of these problems, we we made a simple, simple start, we had the team members lead the recurring meetings like stand ups or retrospectives. And after some time, like after if, you know, a couple of weeks or so, the team members who are leading these meetings, They started seeing that that everyone else responded well to their instructions during the meeting. And that gave them the confidence to participate. The the concerns they had about about English being their second language early on, they were they were less of a concern now because they saw that they were able to successfully lead some of these meetings.
Vlad G 44:26
So allow me to interrupt you for a second. Yeah. Was that just one appointed person specifically, per team? Or did your rotate that facilitator role across different team members to kind of see who would who would do it better?
Kaushal 44:39
It was. So I like to think that they’re all of these groups are like especially the startups and the retrospectives they are for the team, rather than for the product management person or someone else. And I personally think it’s it’s great if the team of volunteers to to host Any of these meetings and but in our case, what was happening was it they were being orchestrated by the product manager. And as I said, it wasn’t helping. So we, we started going around the team. So it would be a single person leading the standards auditor just retrospectives for a week or a sprint, and then they would pass it on to someone else for the next sprint.
Vlad G 45:26
So rotating. Yep. Good. Yep. Thank you. So,
Kaushal 45:31
yeah, so after that, we we also switched to having asynchronous communication. And, you know, async communication is when when you send a message without expecting an immediate response. For example, you send an email, I open and respond to that email a few hours later. And synchronous communication is when you when you send a message and the recipient processes the information and responds in Immediately so in person meeting in person communication like meetings are purely synchronous communication. Now, the way this helped us was it, you’re probably aware that engineering requires deep work right in that you would want to work on on specific agendas for unbroken, uninterrupted periods of time. And having asynchronous communication allowed us all to do deep work. It reduced interruptions. It gave us time to think about what question was being asked explore a response before sending it and you know, plus, because we are in different time zones async communication was was innovate inevitable
Kaushal 46:58
but
Kaushal 47:01
My order the product management specifically saying that, you know, we don’t need to respond to questions live, I think that went a long way in, in alleviating any of the concerns that team members had around around communication or life meetings. So, three I like moving from sync to async communication was another thing that that helped our communication challenges. We then beyond that, we started having virtual coffees you know, with with with a slack bot, bearing three members of the team and scheduling a meeting for them. And if you remember I said earlier that you know, we were lacking team chemistry because we are not in the same location. So, when when you are in the same office, you can probably go out for lunch, or go out for a drink after work or go out for coffee with you colleagues and you know, you get opportunities to know your colleagues or your team members better. So yeah, which is why we started exploring having virtual coffees. And we would, we would do celebratory lunches. So after launching a feature, we would all have lunch on a video call together and talk about food, talk about what what we just launched. And we also talked about stuff happening outside of work. And, you know, all of this allowed us to know each other better, and, and help build some sort of chemistry. And lastly, like one of the most effective things that worked for us was epic ownership of feature ownership. So we wanted to cultivate, as I said earlier, a sense of ownership and accountable In the team, and we started having the system where we would make an engineer and owner of a feature alongside the PM. So So this engineer would be involved in product discovery for that feature. The product discovery would be led by the PM, but yeah, the engineer was was had the option to participate in that process, or be present in the conversations with the stakeholders or with customers. And, you know, this made them much more engaged. And I guess, I guess, you’re at the end of the day, the engineer is the one who’s going to be building the solution. And the closer the engineer is to the problem, the more effective the solution is, at least in my opinion. So So yeah, like it was a mix of these things like In summary, you know, having having the team lead the recurring meetings, then switching to asynchronous communication, having virtual coffees and celebratory lunches, and having epic ownership, like all of it was a combination of all of these things that that helped us get into a good rhythm and help us build some sort of chemistry as a team over a period of time.
Vlad G 50:32
Thank you. That is that is really interesting. I just have a question. I didn’t want to interrupt you. But I had a question when you said you had an engineer, as a single, as a single person, being the feature owner or participate heavily, heavily invest in property discovery around that particular feature? Yeah. How did that align with a business continuity We’re all people when they’re standing up engineers may come and leave, you know, people have, you know, their problems, they may go on extended vacation or extended leave. Things happen. How would you it was there any backup? How would you alleviate this this risk from from a business standpoint? I need the I need to make extensive changes to that particular feature why someone was on? I don’t know, two weeks vacation.
Kaushal 51:27
Sure. Hmm. That’s an interesting question.
Kaushal 51:31
We, so, this was this was purely, so epic ownership was was
Kaushal 51:41
we would we would ask engineers to volunteer rather than we would rather than us saying that so and so engineer is the epic owner for for this epic or feature. And so, so the the early conversation we would have with with the squad was mostly around You know, who’s number one who has the right skills for this required for this feature? who is who is available over the next quarter or next couple of Sprint’s to work on this. So, so yeah, like some of the some of the concerns around ensuring that there is a continuity in in that the person who is who is who’s capable of building the solution is available to build that solution for a good amount of time. So that that that was addressed at the start, in the case where, you know, the the engineer had to take a break or or they leave the the left the business. If I remember if my memory serves me, right, it was, the engineer would I mean it would it would be a standard handover process where the engineer would basically work with One of the one of their colleagues, and, you know, write up stuff that that would make sense to this other colleague, and then pass on the ownership to them. So yeah, like it was a combination of of ensuring that the engineer is available right at the start before we begin the feature. And then in case of the engineer leaving midway through the feature, it would be like a regular handover to to a colleague.
Vlad G 53:27
The reason of, well, there are multiple reasons why I was asking this question, right. But one of the things that I have experienced in some of my previous jobs and engagement was that there was a particular feature in the legacy product, which was the main product offering of a company I was working for, and there was one and a half people who knew what’s going on and half half of a person not not the real half person I was a business analyst who kind of understood the business processes and some of the technology involved in solving for that particular problem. But then there was the one engineer who built the whole thing end to end. And when that engineer for whatever reason became not available, I quite honestly don’t remember what happened. Just because it was it was a remote development team. And I just at some point, I just realized that the person is not there anymore. And I started asking questions like, Hey, we have this change coming up. And we need to we need to ensure that there is a you know, we can apply those changes. And when you figure out what to do without that subject matter if I see it, yeah, it turns out that what again, I don’t know exactly what happened. He didn’t leave on good terms. And he was not available. He was not available for any kind of even for consulting and they’ll became a big problem for the company because they didn’t have anybody else. The It was a legacy code and would take them, I don’t know, two months to even figure out what’s going on because there was a lot of patchwork, and logic and business logic on top of technology logic, spread across multiple store procedures on different databases. It was it was a nightmare. Every time every time something like this pops up this this nightmare scenario pops to my head. Are you guys gonna deal with that?
Kaushal 55:28
I mean that that does sound like a terrible way to end things for an engineer.
Vlad G 55:35
Just sometimes it is what it is. And then again, it I’m not really I don’t really remember what happened and they really care at this point. I’m just saying this is the business. This is the business scenario that whenever you are thinking about assigning responsibility, that’s something that’s a risk you need to alleviate somehow.
Kaushal 55:56
They’re like on the back of what you just mentioned, I remember that You know, the the tech lead or the architect was was always consulted on on whatever feature or or or a solution we have building. So even if like an engineer was the subject matter expert for a certain feature, they would have consulted the the the tech lead or the architect and, you know, so there was always another brain who, who would have some context of what the solution was so, so that was our like Plan B if that happened, but thankfully we did not have a situation like the one you mentioned.
Vlad G 56:38
Yep. That Lucky you. All right. As we coming up to coming up at the end of the hour, I have a couple of questions. They are regular kind of same thing I asked every guest on the show. And I started I started offering a choice which one you want to tackle first. There are two questions. One is in this new world, and I remember, you know, you said that you just started a new job a few months ago. So it sounds like you started your new engagement union job right when the pandemic hit or thereabouts. What How? So the first question is, how were you affected by this new norm or this, you know, new situation? And the second question that I always ask on this podcast is, do you have any questions for me? So this is your chance to turn the tables around and ask me for whatever whatever questions you have. Hopefully, we’re not going to, you know, discuss world politics or you know how to solve the world hunger or develop a vaccine because I have no idea I’m not the life science, less as expert, but something around product management will do nicely. So either one you want to you want to tackle. Either one you want to go with first or second. Let me know
Kaushal 58:03
Yeah, the second is is is fine. The second one is okay. About the first one, you know, like,
Kaushal 58:10
I’m just wondering if there is
Kaushal 58:15
yes, the crisis has had an effect on the business. I’m just wondering if if I would be okay. Talking about it on a public forum. So, if I can probably speak about how it has affected the way we go about our day to day rather than the impact on the business.
Kaushal 58:44
Does that does that sound okay?
Vlad G 58:46
Yep, sure, whatever, whatever. Again, this is more as more of a recurring theme. We’re all living in this new world. So, and some of the previous guests started with how they go about doing forming their job responsibilities. And we always slip into, you know how this affects personal life because now we are working out of our personal spaces, not workspaces. So it’s it’s inevitably, you know, merging affect each other. So however you want to tackle this, by all means.
Kaushal 59:21
Yeah. So, tell us I’ll start by start with the first question around how this crisis has has affected day to day work and product management in general, at least for me.
Vlad G 59:36
Yeah. So,
Kaushal 59:38
of course, you know, large majority of the companies have have have encouraged their employees to work from home. And pocket is no exception. In fact, yeah, like we, even before the government announced a lock down. Our company internally encouraged everyone To work from home, if that was possible. And again, this this came as a little bit of surprise, of course, because there wasn’t like a two week heads up that that this was going to happen. So initially like the first week was or other first 10 days or so we’re, we’re we’re challenging simply because
Kaushal 1:00:28
for a few reasons like number one being
Kaushal 1:00:32
in the office, I asked, you know, the designer or some some of my other colleagues they would, they would work on like multiple screens, they would have bigger screens to work with. And because all of a sudden we were working from home. It was and not everyone had like the like home desk, or home office, where we will have the luxury of a largest screen so today I like getting used to a smaller screen getting used to your own laptop was was a little bit of a challenge in the first few days. beyond that. I guess as as people who work in the technology space, working remotely is not a big issue like ever since we had outsourcing ever since there was this concept of outsourcing. You know, engineers have been working remotely so that has been like for a couple of decades at least. So yeah, like having having meetings or having calls over the internet is not a problem at all. But sometimes he has like the, you know, when you’re in the office and when when you have some of your colleagues sitting just across the across the hall. It’s quite easy to, to engage them in spontaneous conversations about work and You know, like you You have the luxury of using a notepad or a whiteboard to explain you know your question or your query and have a discussion around around that diagram or or whiteboard presentation that you’ve made. But yeah, if any are behind the screen when you’re when you’re working remotely, you you don’t have that luxury. And yes, you have, you know, tools like Miro and whatnot to create, like, online whiteboards or, or, or virtual workshops and whatnot. But again, you need to set them up, right? You need to you need to schedule them in people’s diary. You need to give people a heads up that you want to engage, engage them in a conversation like that. So there are some natural hurdles to having spontaneous conversations which which does take
Kaushal 1:03:00
We which does impact your productivity to an extent
Kaushal 1:03:05
but you know rightly or wrongly we can’t change we don’t have a have an any other option right we we have to get used to this new way of working at least for a few months, if not more. So I guess
Kaushal 1:03:25
at least my team has taken well to it
Kaushal 1:03:28
you know, our conversations over slack or or our video meetings or zoom or or any other tool that we’ve been using the the they’re, they’re going just fine. People do miss having spontaneous conversations around work or you know, even beyond work. We do miss going out for a drink after work or or having lunches together in the office. We sometimes have like virtual coffee sessions with with my team Where we just talk about what’s new on Netflix, and we talk about all sorts of things over there. So yeah, we are trying to find ways in which we can engage more spontaneously and talk about things outside of work. It is not the same as being in the same office is certainly different. But I think I think we’ve learned how to get around them. And I think it has become the new normal now, at least for my team, or at least for me. And, like, sometimes, I think, how it might be like getting back to, to the office. So So yeah, like, those are some of my my thoughts around how how the current crisis has affected day to day and like the work that I do.
Vlad G 1:04:55
I see. Thank you that that is interesting. We’re welcome. And I’ve been working from home for the past two years outside of just outside of the time that I am on engagement where I have to be face to face with the client. So I agree there’s nothing, not much difference for me. I was equipped even before that happened yet what we’re seeing is actually more of a impact when people are deliberately not setting themselves up to be to be able to work from home kind of making that mental compartmentalization working from home working versus being home where they’re not working. And once this delicate, and there are some cultural things where people not used to working from home not because they don’t want to because they’ve never done it before and you know, homeless for the home. True. But it’s interesting because again, as you said, I this is a recurring question I keep asking is all of my guests. I keep getting different answers. I love it. So you know, everybody
Kaushal 1:06:00
They like what you said they’d come up in one of our recent office surveys where we asked for people’s thoughts on on what’s working and what’s not working, when it comes to remote work, and there were some concerns about people scheduling teams, sorry, people scheduling meetings with their teams, and outside of office hours. And we later found out that these were people who are outside of tech, like who are not familiar to the idea of remote working. So so I’m sure you know, like for for people who, as you said, it’s a cultural thing for I think tech teams are used to this culture of remote working and sort of compartmentalizing their work and life, whereas some other departments are not. So yeah, I hear you like sometimes it does happen that
Kaushal 1:06:54
people outside of your
Kaushal 1:06:57
team may not be sensitive towards How working from home might work for you versus for them.
Vlad G 1:07:04
Yep. All right. Cool. Thank you. That was interesting. Last last thing on my list is the the turn turning of the tables if you have any questions for me, again, hopefully around product management. This is this is the chance that if you don’t have any questions, that’s fine, too. It’s, it’s up to you if you want to take this opportunity.
Kaushal 1:07:25
Yeah. Sure. Like so as
Kaushal 1:07:31
how do you think of this podcast as your product?
Kaushal 1:07:37
You know, if you put on your product manager hat rather than the head of the host, what, what what problem are you solving out there for the user and like, what what is your goal with the podcast?
Vlad G 1:07:53
That is a really interesting question as definitely a new one. Haven’t heard that before. So You’re right. And I do approach this as a product rather than I’m a host your guests, let’s talk about things. because inevitably I have to because of the nature of my own work. It’s a occupational hazard, if you will. Sure. I, I have a couple of businesses before and my major responsibility in my current role is go to market for the products that I’m working with. It’s not necessarily developing of the products is going to market was either the current versions of the prototype or the MVP and then based on how market responds, continuing the product, discover continue the product development. So having said that, as the product manager of my own podcast, I am trying to go to market, my current problem the if you’re familiar with one metric that matters. My current metric that I care about is adoption. I need more people to listen to it so that’s that’s what I’m doing. I’m trying to build up on two things I’m trying to build up on the content having more content because one thing with podcasts is it’s not live translate it transmit it’s not live broadcasts You don’t have to be in front of your TV or in front of your radio with a specific our crew and everybody can listen to any episode they can they can they don’t have to start with episode one. They don’t have to start with the latest episode. They can start with episode number five and then go to 12 and then go to one so every episode is it’s a little different from episodes in your favorite sitcom or your favorite TV series. Every episode has to stand on its own on its own two legs. Interesting and and and so that’s the content front it you know expanding on content, having interesting episodes by themselves is important then the second part is expanding. into as many platforms as possible. Unfortunately, I can’t do live videos, I can’t do videos, you know, with my poking hat and a guest talking head, because not everybody is equipped and people don’t necessarily want to be seen. So it’s a challenge I sometimes I talk to people who don’t want to be seen. Sometimes they talk to people who do want to be seen, but they don’t have necessary capabilities. Even you know, if even just recording the audio stream is challenging, think about recording the video stream. So I’m trying to kind of sidestep those things and still expand into video platforms like YouTube and others, but mainly trying to get to YouTube right now. So I started the channel on YouTube, I started posting episodes, there was just you know, playing visualizations, but at least now you can listen to these podcasts on YouTube as well. So, again, since this is not my full time job I only have so many hours I can dedicate to producing, getting the guests on having the actual interview than post production, producing the episode of creating all the necessary meta work around it and then posting it all over the place. So, you know, with I’m working with what I have, I, I don’t think I’m doing everything I should be doing it just because I don’t I’ll lack enough time and knowledge but as I keep working through this, either iterative approach to product development. Sure. I’m sure I’ll get there. Yes, I like the topic. I like doing what I’m doing. I like product management as a as both science and art. I keep saying this, the product management as much science as it is art. So you can’t just go and get an MBA and become a product manager and become a solid product manager. Yes, you do need education. Yes, you do need to learn as much as you can, but you also need have real world experience making things happen in whatever branch of, you know, responsibilities before you can really become a good product manager. So, yeah, that’s that’s, thank you for the question. That was good. And that’s that’s the answer. Brilliant.
Kaushal 1:12:18
Thank you for for for sharing your answer.
Vlad G 1:12:22
All right, thank you so much. We’re slightly over time. I don’t think it’s a problem. Thank you very much for being guest such an awesome guest on the show.
Kaushal 1:12:32
Thank you for having me. My pleasure.
Vlad G 1:12:34
Absolutely. It’s a pleasure. Thank you very much and see you soon. See you. Bye. You’ve been listening to the real world product management and I’ll be your host Vlad Grubman. Until next time,