In the episode 07, I am talking to Richard who works in San Francisco bug bounty company about his experience sharing product management responsibilities with other product managers, remote work and managing two roadmaps for one product.
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 the real world product management. And I have Richard on the call with me, Richard. Hi, can you please introduce yourself?
Richard 0:25
Hi. Yes, this is Richard.
Vlad G 0:26
Hey, Richard. Thank you. So first question and to kind of understand why we’re talking to you. Sure. Can you tell us more about who you are, what your role is, and what kind of organization you’re working with?
Richard 0:43
Yeah, of course. So, Richard, as well. I work out of San Francisco and here in the Bay Area. here in California. I work for a company called bug crowd as the product manager, bug bug crowd. We do crowdsource cyber secure We started as a initially as a bug bounty company a brief statement of what that is, is we connect hackers with companies and facilitate vulnerabilities and distributing that across the to the to user bases. So yeah
Vlad G 1:15
wow that’s that’s pretty cool. Yeah. You work with any big names or this is more of a small scale operations because from what I know a couple large companies like Facebook, Microsoft, they have their own bug bounty programs.
Richard 1:29
That’s right. So we work with actually quite quite a large enterprise customers on we can we work with Netgear, TripAdvisor, Netflix to just name a few enterprise but we work with the mid market as well, where a company doesn’t have the resources to have security team like a Google like a Facebook to run their own bug bounty. So we come in the middle and help help them out.
Vlad G 1:56
Wow, that’s that’s pretty cool. And by the way, thank you We all want to live in a more secure world, right? So talk me through your kind of start of your career as a product manager. How did you how did you end up being a product manager? And I seem, I seem to have a number of stories from different people share and not not to have the same. So I’m really interested in hearing What’s up with you.
Richard 2:23
Yeah, um, so I joined bug crowd a little over four years ago now. When I joined the company was relatively small. We had about 4540 individuals across the world, mostly based in San Francisco, and they didn’t have a head of support. Support is managed across multiple departments within the company. When I joined, it was collapsing all of them down into a single individual. And that was myself. When I joined, we were using intercom as a support channel. We were mainly email based and we supported both The researcher community, the customer base, internal stakeholders, and through my first three years of being in support, I built the team built in the different support metrics that was needed for leadership to see to have insight into what we could fix. through that experience, I learned a lot empathy. I heard this comment, empathy tank and the day when I would go home to my girlfriend, it would damp the tank would be exhausted. through three years of doing support tickets. It’s very transactional. And through that process, I came to know the platform quite well. I knew the ins and outs, I knew the faults. I knew where to not to talk about. So when three years came about roughly, I felt like this was not as fulfilling because I couldn’t really fixed the problem. I reached out to product engineering and had a pretty frank discussion about What can support do beyond just answering tickets and submitting requests into engineering to be a part of the backlog? So, product became the natural reaction, a lot of PMS or PMS at the time, recommend, Hey, why don’t you come on our team, you know, the platform? Well, you know, the stakeholders across the company, even our customers in certain cases, join product, you have now engineering resources backing you to alleviate some of the problems you saw in support. So that’s kind of my bridge into product management.
Vlad G 4:37
Wow, that’s, that’s interesting. We have a lot of people coming over from VA. world. I myself came in from software development project management world. Now we have somebody coming from support, which is cool. I think. Now that you said it, I actually think it’s one of the best ways to get into product a BA is probably the same. Yeah, because a BA stands In a place where you collect the information, and it kind of like input into the product, and as a support person, you stay at the output or kind of at the beginning of the feedback loop, which is also a pretty good place to be. So that’s pretty cool. Okay, so you actually made a transition and you join the product product team, how many product managers Did you guys have there?
Richard 5:27
When I joined, we had one product manager managing roughly 20 engineers at the time. So he was well overworked, completely inundated with all these requests, obviously unable to prioritize and fulfill and that was the second one coming up on board.
Vlad G 5:46
Was there any kind of structure around that? And by structure I mean, developers broken into teams are working on the specific appeal or especially as epics few Features individual products. How do they work?
Richard 6:03
Sure. The structure was we had a team in San Francisco. And we had another team in Australia and they would tackle different themes within the product. If they were if one team would focus more on the researcher side, another customer and another internal products, so it was divided in that sense.
Vlad G 6:23
So one product manager was overseeing everything.
Richard 6:26
Correct. A lot of work on his friend. Yeah.
Vlad G 6:30
Okay. So how do you guys structure the work once you’ve once you’ve joined and there’s there was two of you though.
Richard 6:38
Yeah. So that transition was interesting. It was during a holiday season, so he was off on holiday and I came in and kind of just took on what was the backlog at the time and what was already being worked on in epics and sprints for that quarter. Working on products or working on improvements within the product was really A lot more seamless for me because I knew what was going on. We didn’t have the idea of new products at the time, we were still working on a backlog to help create small fires to put out small fires. So when I joined, those are the first forefront of my mind, how can we alleviate the the short term pains that the customer and the user base are encountering? So that that’s kind of what I picked up right away? And I felt really accustomed to that. Yeah.
Vlad G 7:28
Okay. Interesting. So you started, you started to the more tactical level, which is understandable, and that had you kind of grow into doing more strategic stuff is under strain. Correct. Given that you’re still there, I’m assuming. In general, generally speaking, it went well, what do you think was the largest challenge or how we asked in the enterprise world What kept you up at night?
Richard 7:58
I think adoption was was really key and in the beginning, we, we were more consultative, I guess in, in a sense. They were people, customers, users, internal stakeholders would request things and expect a turnaround time with a deliverable. That’s not the emotion that our product leader wanted to the cadence that we wanted for certain requests. Sure, there’d be transactional, but certain ones that product managers should be driving products should be driving the themes and how we build out. So we noticed adoption, we would build a problem come in and we would build it in a sprint, and then it would sit on the wayside and not be actually utilized. So we saw that right away, like, were they using the feature? Were they using the chart that we built and spent engineering resources, actual currency money, and that became a sticking point early on.
Vlad G 8:55
Okay, since you’ve mentioned the real money, yeah. One of my previous Guests mentioned that based on their structure and their ways of doing things, they had an actual dollar value on the support ticket, a support ticket actually cost them real money. Would Was there anything like this in your case? Or was it just the resource use that cost you?
Richard 9:18
It was more of a broader resource. No one knew how much they were spending. It was a request and they were putting they were taking money out of the bank, but never putting any deposit anything back in. And we didn’t have a monetary idea. We didn’t have $1 in each feature, but I do like that idea. I guess. It does work in certain cases.
Vlad G 9:40
Yeah. And I loved I loved that idea because it translated directly to the products I am managing in my current company or rather managed until the last year in my current company, so it definitely makes sense. So when you were something you mentioned We said there’s there was no perception of monetary value on features. My understanding is there’s no ROI on any kind of development work. So how do you guys measure how successful the product was? What was the success metrics or framework? Maybe you’ve you, you’ve used the framework, maybe there was something that made sense to you at the time. What was the success measure as the whole.
Richard 10:28
I think over time, we did learn to use our allies and metrics to drive them and maybe I’m speaking in the short term window. Some requests would come in tactical with things that we had to do RFPs requests for enhancements for current customers, we would have to tackle those for the deal to continue to renew the deal. ROI we would base it on. It came to bond top align. We talked about top line a lot and how can we drive revenue How can we expand to adjacent marketplaces, and then those kind of funneled into our features and epics. And that’s kind of how we derived it early on. I think now we’re at a better place in the company in the teams. We talk about ROI and KPIs a little more, and it’s a lot more defined in today’s world.
Vlad G 11:19
Okay, so you’re not using any any specific thing. We’re just trying to tailor it to the monetary value, way understand your answer.
Richard 11:29
I mean, there’s there’s frameworks, right? We can we can talk about the different frameworks that exist on how to prioritize work. And we’ve used some of them. I think certain PMS in the company today, have that intrinsically in in how they look at a feature and a request. But there’s no standard across the teams to utilize a certain framework.
Vlad G 11:52
Interesting. Do you again, I don’t want to intrude too much, but ye Thank you. You guys don’t have a standard. Is that because you’re lacking some kind of a certain central product, the governance or is that because of the inherent nature of things that those product managers are managing? What’s, what’s the story there?
Richard 12:14
Yeah, I think it breaks down to what I focus on personally. And I think it goes towards the service engineering side, which is my team and we smoke we focus on shorter iteration, lower time to value versus other pianists that are working on new products. And their validation points are how what’s the adoption from the market from the security industry as a whole? So when I speak I’m probably speaking more in like my lens versus the other pm some, but the broader theme I think, that can be spoken about by leadership and I have intrinsically felt that in my own purview, yeah.
Vlad G 12:54
Okay. Make sense? Thank you for for the answer. Really appreciate it. So, so Talk to me about how you prioritize then and how you prioritize now or other, less even, you know, go a little higher. How do you guys manage your roadmap when you started versus how are you guys doing this now? What What was the transition? What? So basically tell doctor, talk me through what was back then how do you guys get to the current state? And what do you see as an ideal state? If If you get
Richard 13:26
sure of course. So previous state, um, we had a lot of fires, a lot of tickets that would come in and dva on the product roadmap. We had a sense of product roadmap on many years ago before I joined. But it was often deviated because of requests that have come in pretty pretty urgently. emails will be called urgent or critical or whatever it may be. To signal to engineers we should drop everything and focus on this. This oftentimes distracted engineers from working on the overarching idea of how to move the platform forward, when when service engineering was introduced by my manager, it was an idea that we would have two separate roadmaps, one platform, more product focused roadmap on where the vision of the platform will eventually go, and a service engineering roadmap or a service roadmap. The service roadmap would be inherently meant for more short term wins, iterations that don’t take months but days versus weeks. And that’s how it’s kind of deviated since. The team I work on work on is based out of Costa Rica, and they understand the platform from top to bottom and they do know the work that they’re getting is not a long gated in a quarter metric there. They do understand that the deliverables we have is smaller wins to make operations to make the customer to make the researcher feel that their requests are being heard and actually being actioned. So that has been the major shift in perception to the from the market and perception within the company.
Vlad G 15:13
Wow. I’m impressed having two separate roadmaps, one for support. Technically, that’s what it is. Yeah. So vos for support that was for feature development. That’s an interesting approach. Yeah. Okay. So that that is basically what it evolved into. You guys kind of started that. Almost intuitively, I guess. And then that’s what it’s evolved into. That’s what the current situation is. Yeah. So if you saying that your engineers would be getting all these urgent, super urgent and critical emails that was disrupting your natural flow. Let me first let me step back and ask Did you have any development software development process in place anything along the lines of Agile Scrum, any of that stuff?
Richard 15:58
did there was an agile built To the team, there was that notion. There was a scrum leader that managing the work that there was coming in. So we did have that idea. Yes.
Vlad G 16:09
The idea or was it actual Scrum or actual agile? Because from, from my experience, there’s a lot of frameworks. A lot. Sorry, a lot of governance that is called agile where it’s just what a time based waterfall. Okay, so we’re doing waterfall for two weeks now. So I just want to make sure I understand your situation.
Richard 16:31
Yeah, I guess I can’t really speak to it too much. I came in and was introduced to my team and we, I knew the feature teams were part of the agile and they were running with their their two week iterations. And then I was running. Not in the same parallel, though we did. We did do sprint reviews together. The work was not always the same.
Vlad G 16:59
Okay, okay. It makes sense because you guys are managing completely different types of work. Yeah. So to speak. So yeah, it’s totally understandable that you guys were not aligned, although I would argue and again, maybe it’s just my personal experience, I would argue that you still need some kind of a connect or some kind of sync between the teams because you guys were fixing what they were producing. Sure. Yeah. To me, they should be really nice. In the sense of sinking up.
Richard 17:34
Oh, yeah. I mean, that’s the width through the PR process, the peer review process of code review and code quality. All the engineers it was more round robin. So they didn’t know what we were producing and the engineers, the service engineers were focused on. So I think there was a back and forth appreciation for what the team in service was actually accomplishing and how They’re looking at it slightly different. So.
Vlad G 18:03
Okay, so let me ask you then a slightly different question. And this is a me. I used to be a developer many years ago, and I’m kind of, I’m kind of the person that likes doing new things or discover new things, which is why I ended up being a product manager. Sure. My I’m very, very heavily rooted in r&d and figuring things out. And as a developer, I was, I had same mentality. And whenever I was asked to fix other people’s code, other people’s problems, yeah, I would get, I wouldn’t be very negative, but I would get very defensive. And I’ve caught it’s not a good it’s not a good character trait. Right. But it was, it was it is it is what it is. I used to be like that. And yeah, I’m just curious. Aren’t your developers at least partially resentful, I’m not sure how to how to soft them that word. So I’m just gonna raise resentful for now. Yeah. I’d say at least bit resentful saying, Hey, we’re always fixing things whenever building new things. And we want to build new things. So let somebody else fix the bugs.
Richard 19:16
I think there will be so the tickets itself is we split into defects and then improvements and feature improvement. So the defect, sure, there there comes, I am sure if they get inundated. If their work was at 20, and 80% of it was defect, I bet there would be that resentment instilled over time, but the team does focus on feature enhancements as well. So I don’t know the percentage split today, but they do focus on once they see a defect and how can we improve it on the user experience? We do have that notion as well. So it’s just not fully focused on defects. And I see very similar parallels with security. Engineers, when you see a vulnerability, you have to Coinbase someone a secure engineer at Coinbase recently did a presentation at app sec, Cali. And his notion was, we cannot criticize our engineers for their for the vulnerabilities that come out, we have to be able to do better. It’s not a person that did it. It’s how can we create a system that just prevents them from from actually creating those vulnerabilities from the beginning? You can’t blame the individual for vulnerability that comes out. And actually is has million dollar affects the company. It’s how what kind of governance do we have in place to prevent that from happening? So yeah,
Vlad G 20:42
it makes sense. Okay. Thank you. So once you guys establish that, how do you start or where do you what do you guys ended up on managing their road map? I mean, from from What I hear it sounds like you are very focused on fighting fires, and it’s not a bad thing. If our, if our knowledge is any indication, we would argue that about 80% of any it is firefighting. Sure. And that’s, that’s basically, yeah, that’s where some of my products, the products I co manage, cuz that’s where that they are rooted in. So it’s normal thing is wondering, how do you guys push for moving your product forward? Or what was the situation when you realize, hey, we’re not really doing anything? You we just keep, you know, rehashing the existing thing without moving things ahead.
Richard 21:42
Yeah, I think that’s when we started introducing new product managers at the time. We had to and my counterpart was focused on how we can push the platform into another evolution another version. I was trailing behind Following any hit or any misses that they were unable to capture, we hired two more product managers to focus on that vision. Some more outward focusing, how can we improve payments to to researchers? How can we build out more sdlc API endpoints to help customers facilitate vulnerabilities into the developers hands? So we did have that concept of how can we evolve? We were just capacity constraint in that sense.
Vlad G 22:29
Since you mentioned the award, I feel like I’m obligated to ask you know, who owns the vision for your product we have now
Richard 22:40
I think all the PMS own a piece of it. We do have head of product that owns a vision. It comes from all versions, right? There’s the idea of bottom up product views where PMS and support will derive new ideas and bubble it up into the product. It could be top down leadership can say, hey, please do this. That and PMS go off and scrambling and developing it out for for the user base. I think it’s a it’s a mix of both. Who owns it, I think, end of the day, the customer and the users own a bit of it, and how we can improve it. But all the product managers own a piece.
Vlad G 23:21
Interesting. Almost like Co Op ownership by committee. Interesting, in many cases in the enterprise, at least, that’s what I’m seeing. Vision is a collaboration within the product management office or product manager or have a product. Sure. And the business in the business being whoever makes money off of product. Good. This is definitely not a profit organization. So that that’s where the vision kind of stems from, huh. It’s interesting that you’re saying that product management owns it. Literally like a co op everybody like shareholders, everybody is a bit. So it’s definitely not the way I would imagine I imagined that before this episode, so thank you for that. That’s interesting.
Richard 24:10
I think there is a governance we do have an idea of PRB product review board where all the PMS in any stakeholder within the company can present new ideas to the exact board to leadership. And there’ll be a voting process. I guess Co Op is is fun you mentioned that is very interesting idea and it might line up in parallels and certain use cases. The government governance we have is a meeting where any stakeholder myself all the PMS can present new ideas, new functionality that requires company buy in. When that actually happens. People can ask questions, leaders can question what if this tactic if this phasing makes sense? And then that kind of rise how the product starts moving?
Vlad G 24:58
Yeah. Okay, that’s interesting because I was I was actually sitting here thinking, How do I ask this question? And you literally led me to it. Okay, so I’m just gonna ask it a straight up this kind of a turtle sell a sales pitch that you guys are doing to stakeholders. How much How much do you do? How much do you utilize data driven approach? In other words, do you collect certain amount of data and then present it to the board? or however you guys call it? Yeah. And then say, hey, data points to this direction, let’s do this. Or are you experimenting? Let’s say we’ve built a couple of prototypes. And this is what we have. And we think this prototype loop makes more sense than this and this but we’re showing you all three, as an example, right? Or do you guys just go with a product manager gut feeling because it’s totally is a thing. I I started This in some of the previous episodes, and we agree that it’s a thing, Product Management gut feeling has absolutely has, has existed, especially people who’ve been in product management capacity for a long time. So we kind of feel when things are right or wrong. What do you use? And it’s okay if you use a combination of all of the above, but just walk me through how you guys deal with that?
Richard 26:28
Yeah, I think we do. I mean, we do have metrics. So you have analytical information on clicks and throughout the platform, I think that it helps inform our decision. When I was in college, one of my professors has mentioned it customers are always not always right. In the sense we do hear feedback from from customers, but are they right in the case that they’re requesting this functionality? So we do go into the metrics and start deriving that hey, what does Telling us does actually line up with what we’re seeing in the platform interaction that we’re seeing. So that side is that the metrics pulled being pulled out. The other side is a lot of PMS have that innate feeling already. They can feel like this is not going to go well. It can be changed. So we, myself being at the company for a couple years, I do have that. I do empathize with the users. I do understand that without actually peeling away and looking at the metrics. But yeah, so it’s a little bit of both. It’s mixed. Yeah.
Vlad G 27:35
Awesome. So let me it’s a tricky question. I’m warning right. Let me ask you this. How many times was there ever a case or how many times there was a case that you’re absolutely hundred percent sure. With your gut feeling that this is this is the right decision, and you’ve been proven wrong, and from my end, so you don’t feel bad? For my end? Yeah. That’s about it. Had I had less of them lately? Hmm. But when I was in, up until like seven years into the product management, I had that almost have to die if I didn’t have enough data to support my decision. And that would go with a gut feeling. It was almost 5050. So I, you know, it’s almost like I had no gut feeling at all. Sure. So what is it about you?
Richard 28:23
Yeah, I mean, it’s, it’s a scary thought you because you I mean, we we try to do well, I personally try to make sure all the features, the products that I roll out, is solidified with some kind of data. But I’ve personally have an opinion I that’s how I think about it. I have an opinion on a feature or some kind of request has come in, and I’m waiting for the stakeholder or for someone to push me off of it. And we can have a discussion. I have my own opinion, and it’s derived from data. It’s derived from experience within the platform, and Everything I’ve gathered in life, and I have the stakeholder whoever wants to come back that. Does that go right or wrong? Sometimes I opinion can be swayed. And I I’m not bagging up 100 I’m sure that I can. There’s been iterations. But I think one thing I’ve done recently is phasing that has lessen the impact of failure in my mind. If we have a problem in a feature rollout that could take three months, I talked to the stakeholder and explained to them, hey, we can phase this approach out and minimize the risk of failure. Let’s Let’s adopt this phase one. And I explained to them this accomplishes 80% of your requests. And phase two, we can iterate and build upon it, but phase one, do we all agree with this? process this rule out? And for the most part that has lessen the load on failure on my end? I don’t know what’s your thoughts on the phased approach?
Vlad G 30:00
I mean that that’s the only approach for me. Yeah. And yeah, I learned the hard way. I’ve learned the hard way that it’s a we call them stages, not phases, but it doesn’t really matter. Yeah. Yeah. And and that’s, that’s the kind of like part of it is you throw it behind the MVP, or some people use minimal marketable product, which is the bare bare minimum of features of market or your clients are willing to accept, and you build from there. And the beauty of it is, you build an add to the product in such a small iteration, such small amounts. So the small amounts of features that you can play with anytime you can always say a stop, let’s turn around and do this, or let’s turn around and do other things. And that allows you to and that’s kind of like what we argue, is a benefit of adopting the product mindset. Yeah, is because it costs less. You don’t have to, you know, have a vision of a future, you know, A year, two years, three years, God forbid five years down the road. You can you’re only good and that’s that’s what I that’s what I wanted to talk about how do you plan the roadmaps? And I’ll talk about it later. But that allows you to be very flexible. So face staged approach is definitely a way to go.
Richard 31:21
Oh, yeah. And that’s, that’s been helpful there to your broader question of how have I prevented that? And that’s, that’s how I think my team has mitigated any anything of huge failure and huge resources, commitment. I’m into it. So yeah.
Vlad G 31:37
All right. So let’s make a pause here, and we’ll return off there a short break. Sounds good. Hey, listeners, thank you for listening. This is a lot and I’d like to thank you for being a part of our audience. If you have any questions if you want to be a part of this podcast, or if you want to introduce someone for our broadcasts to be a part of it, feel free to contact me at Escalade at V robbing.com or big Robin comm slash podcast. Additionally, I’d really appreciate it if you guys promoted the podcast any which way you like, either specific episode or the whole show. Since we’re not asking you to donate anything, I’m not asking you to buy anything. It’s really, you know, free as a beer value. Hopefully it’s not, you know, whatever is free is worth what you pay for it. So, but everybody know, tell your mom, tell your friend, though you are the friend. And hopefully we’ll see more of you listening and providing feedback and having a dialogue around product management and all the other disciplines that touch product management in in the technology world. Thank you again and keep listening. Alright, this is part two, Richard pie again. Thanks for coming back. Hey, yep. And let’s, let’s move on. Let’s let’s talk about the next thing that is on my list and it’s something you’ve mentioned. Before the question that I wanted to pose was, how do you given that your developers that keep getting these panic emails, urgent, urgent, urgent? And if everything is urgent, nothing related? How do you keep your roadmap in check? How do you actually make things happen if they your developers are constantly interrupted by all these origin messages flashing their faces?
Richard 33:24
Sure, sure. Um, I can talk about where the beginning has when we started service engineering and how I work with the team to where it is now. When we first started it in a few quarters ago, the team, I would have a service manager service engineering roadmap, and that would usually I would commit things to that roadmap for 80% of our capacity, what resources I had out of the engineers and that would constantly bite me in the butt. I would have said, Hey, here’s the x features to the stakeholders. We will deliver by end of q1, for example. And when q1 rolled around, we would often hear those fire tickets that come in and we read deviating our own roadmap. And the purpose of the team was to accomplish and tackle those those fires that came in. So it defeated the purpose of what the team was initially created for. And as the quarters went along, q2, q3, I think myself and the engineering manager I worked with, we learned that we cannot commit double digit or 80% 100% of our capacity at the beginning of the quarter in the in that when we started developing the roadmap, we slowly realized we should commit to a quarter of what we’re capable of for that quarter and things would automatically essentially trickle in. Urgent emails and so forth would just trickle in and we would cover the hundred percent of resources that we had for that quarter. I think over time, that has become a better cadence for us for engineering. To understand, hey, here’s the amount of engineering resources we have. Here’s all the products and requests that come is coming down the pipe. let’s commit to 20%. And as the team grows, let’s commit a little more a little more little bigger scope. So yeah, that’s how it’s kind of derived over time.
Vlad G 35:17
Wow, you went from hundred percent to 20% 20%. Now, it’s a big shift. Yeah, well, it’s not not a positive, the big shift, not in the positive way, at least from from my perspective, but, you know, you can argue that it’s a normal thing, because you’ve tried to the things and then you realize you’re over committing. Yeah, it’s, it’s, it’s not that you’re not delivering enough. You’re over committing Yes. Because there are other things. So my understanding is, there’s there’s a way out of this, you guys are delivering more compared to what you used to. That’s correct. Okay, that makes sense. So how do you move forward? I kind of like this form of it. asking how do you move forward when your hands are full? So how do you move the product forward? When you Oh, you spend 80% of your time fixing bugs?
Richard 36:08
Yeah, I think that’s, I leave that for the platform, the platform PMS that focus on where the platform will move and iterate to, for from my team, and I guess I can speak directly for my, my team, we do focus on the shorter wins, the fires that come up and smaller phases. We do develop phase one PLCs. pointer concepts, ideas, and then we hand it off to the larger team, other PMS to actually tackle developing it out in the platform. A prime example was we did get received requests for something that could take a year or two for our whole company to invest engineering resources, people’s time. And that was a task that we picked up we said, Hey, we can do a PLC we can present something to the executor and say, Hey, should we actually commit a year of engineer resource develop this new product, this new idea. We took it on, developed it within a quarter in our quarterly roadmap. And we actually were able to save our company a year of engineering resources. And we tackle that. So beyond just tackling defects and small feature wins, we also are capable of doing or the team was developed to be more PLC focused on MVP focused as an essence. So I guess moving forward, how we we change and how we we actually accomplish more? I think it’s it’s a collaboration between the platform roadmap and service engineering, how can we work together to move the platform forward because we have a lot of insight. And engineers that I’ve worked with, they have insight and they’ve moved from service engineering over the platform engineering. So that’s how they level up internally in their career ladder, so forth, so they’re selling themselves For them to move, move and move on.
Vlad G 38:02
Yeah, I see. Okay, it makes sense. I mean, you grow with the product. And then once you figured out what the underlying problems were or what the fires were, that you had to put out, as easier for you to design. As you design the product, you keep in mind that hey, last time we tried something like that it generated, right, you know, this whole firefight that nobody wanted. Exactly, exactly. No, makes sense. So, as a as a whole, I think I understand. It’s not very typical, at least not in the way I’ve seen it happen. Although I do see from time to time, teams having similar breakdown when one team one engineering team is set up as a product support team or engineering support, and the other one is focused on national product development. It’s rare I mean, again, From my limited experience, I haven’t seen teams that are sent on the support side being called a product team. So I mean their product teams in Agile sense of the word, as in there, they’re utilizing agile and they utilizing some kind of a gel approach. But they’re not really product teams in the sense of developing the product. They’re firefighters, right? They’re not they’re not architects and house builders, they’re firefighters, they saving houses, they’re not building them. Sure. And in that sense, it’s it’s kind of interesting. This is an interesting symbiosis. And I keep seeing things like this popping up. Things like this meaning non classical approaches or some kind of a symbiotic relationship between teams that are kind of what’s what’s the word I’m looking for. marriage of convenience, I guess, would be a good one. Sure. Sure.
Richard 40:00
I think it’s necessary and like it’s necessary in this world, at least I see it. it’s beneficial. It’s, it calms the nerves of the execs. There’s a win win across the board. There’s architects that does focus on platform and product. And then they can actually influence how service engineering develops smaller wins or smaller defects. So I think it’s,
Vlad G 40:26
it’s beneficial from all the other PMS. I’ve talked to other smaller startups that are encountering this interesting. I’m not, again, I don’t know enough to say it’s better or not. Yeah, again, based on my experience, I’ve seen different things here. And one of the reasons why we have guests on this podcast is that you guys have different experience and the wolf come out, hopefully smarter, at least in some way out of this and I’m really happy that you guys find collaboration in In terms of you know, you’re, you’re not in kind of this situation when I don’t care about the quality of this, this other team, they’ll fix it. They’re smart enough, they’ll fix it. Now that I’m happy that you guys actually collaborating, and you see this as a mutually beneficial or Win Win relationship, when they can rely on you to pick up things that inevitably fall through the cracks. And you can rely rely on them. Knowing they will, they will design to the best of their abilities. So if something actually falls through the cracks, it’s not due to negligence or due to lack of attention is because it’s genuinely fall fell through the cracks.
Richard 41:42
Sure, sure.
Vlad G 41:44
Okay, moving on. I’d like to kind of bring back one of the things you mentioned, because it’s, it’s the area that is really interesting for us, people who host this show, and it’s special Interesting in these trying times when everybody’s working from home, I would like to bring back you mentioned that your remote team is Puerto Rico. Yeah, Costa Rica. Costa Rica apologize Costa Rica. Can you tell me what does your experience look like working with them? And my understanding is you’re 100% remote. How do you guys not about it’s not about tools. I don’t care if you use slack or Microsoft Teams or Skype. I care about the relationships. I care about the How do you work? How do you make things done? How does that whole thing work out for you being the remote product manager? The team that I don’t know thousand miles away?
Richard 42:44
Yeah, no. I think when we first introduced the idea of Costa Rica, luckily their timezone is central. It’s two hours ahead of, of San Francisco. Right now it’s I learned we’re only an hour away. With daylight savings time, so it shifts according to daylight savings. But it helped being that the engineering manager I work with is also based on Austin. They, they work closely together, there’s there’s no time change for him. And the team over there has is relatively young. They’re they’re still early in their career. They’re software engineers, they’re firms and then they kind of banded together. Costa Rica, what I’ve noticed the difference between the San Francisco engineers and and the engineers I’ve worked with, outside of a few handful, and they do evolve, become more self sufficient. The engineers I’ve worked with in Costa Rica have been more reliant on the PMI deriving with the view of what they’re developing is. They want to hear more of what technical solution will look like. Instead of engineers in San Francisco, they want to hear more of the problem and they’ll run off in Build it in and design it accordingly. For for me, it’s it’s an it’s a nice breath of fresh air and that sense that, hey, I’ve worked with the designer. Here’s the wireframe. Here’s the phasing that I see. Do you guys agree on do can we work together on this? But tooling lies it’s it’s really open whenever they have a question. Via Slack, I jump quickly on a zoom. It feels very close. We’re really closely knitted. I visited Costa Rica about a month ago. And when I saw them in person for realistically, the first time for over a year, it was really normal. We spoke so frequently on a day to day basis that when I saw them in person, it was like I knew them. It was it was that kind of relationship, even thousands of miles away. So yeah, it was a it was a fun, fun collaboration walking them through how I think in person
Vlad G 45:00
So yeah, I see. Interesting. So it’s interesting. I had a lot of experience working with remote teams back before it became a thing. I had my own company that basically the regular outsourcing thing Sure, would leave talked, I hired people all over the world, literally all over the world. And it was not even a voice communication back then it was problematic was just just that typing, a lot of typing and a lot of conversations. Through just written text than me, we moved on to voice communication. Now you have you can have video pretty much in any part of the world, so it gets easier with the time. Yeah. What would you say? The biggest challenge is if you’re talking about different geographical regions. And, and I if, if I can, if I may, I want you to think about it. not dissimilar. technical challenge, you know, they have slower internet thoughts. Yeah, more like a cultural thing. Like, you treat certain things differently from you and you’d see things differently from them.
Richard 46:11
Yeah, I think, timezone wise India has been slightly difficult in terms of go there. They’re hours, hours ahead of us. I think culture, culturally wise, the team there is their working hours, at least the ones that we work with the working hours might differ that they’re not at a nine to five, work business hour time type of path there for their engineers. They come online, they code, they do their daily stand ups, and then they go home eat. I feel like they have more of a blend between the business and social. So they’re more flexible. I took a call earlier today with a team in India and they were it was midnight, and they were happy and to both get on a call It seems to be the normal culture. I could be very wrong. But that’s my PR. That’s what I’ve seen so far. It’s interesting. They’ve kind of adapted to what the SF culture is like. They they adapted to our timezone, I guess is probably the better statement, at least for the people that work with.
Vlad G 47:23
Wow, that’s definitely interesting. definitely different from what I’ve seen and being myself being, you know, originally from Eastern Europe. Hmm. I, when I was starting back when I had my own business, I tended to hire people from Eastern Europe because we shared the same language, same legacy, same kind of, you know, history. Sure. It was funny that when I just started doing that, everybody was very eager to work. Whatever hours I needed to work, let’s say right, if I needed I needed them to work early morning hours, they were okay with that. If I needed them to work late nights. Shift there would be okay with that they will adjust. Right? Then sometime past that I didn’t have any exposure whatsoever to outsourcing or offshore development. I was working with everything where everything was inside in house teams. And I came back to it at a couple of companies. And this situation completely changed. No one ever cared about what my hours were. They had their nine to five. And that’s it. If I wanted to get their attention, I needed to get up at five o’clock in the morning. Get in there stand up. Yes. And get their stand up. I my boss CIO. At the time he was getting up at 435 in the morning, so he can make it to most of their activities. He was that was kind of a different story. Right? He was very much into micromanagement. So he would be on every daily stand up and the CIO of a company and every every little thing, every meeting everything he had to be there. And you know it kind of, you know, self fulfilling prophecy if you’re in the every meeting, then nobody makes any decisions unless you’re in the meeting. And now your presence is mandatory. But again, it’s it’s it’s a whole nother story. But the culture was completely different. Like we don’t care what your hours are hours are nine to five to six if you really ask for it. But then that says we’re going home and I was wondering if you have seen any, any shifts like that in your experience?
Richard 49:32
Not in my experience. I’ve seen more. The teams be flexible. It seems like their work life balance is more blended, at least the engineers that we work with in India and Costa Rica. We do have a team that’s Australia, and they do hold that strict timeframe you had mentioned in there. I don’t know if it’s more established or the leader that’s running. The Australia team is more stringent on work from from nine to five, and all the PM, the pm manager managing their workload, we’ll have to play around with their schedules and pick up calls then. So I don’t know, how does your team and with the CIO, were they based out of Eastern Europe as well?
Vlad G 50:20
Yeah. Okay. Interesting. Let me see, I was here in New York. I was here in New York, the def teams were all in Eastern Europe, right. And the problem was that there was only so many hours in a day, three, four hours in a day that you can have all these meetings, and they actually wanted to have some work done. Sure. And you basically that’s why things took way longer not and that’s kind of like your your remote work experience. Things took longer, not because the team was not productive. Tech, definitely not. Okay, wrong choice awards, not because the team was not productive on the technical aspects of things. It was because he was not productive and making their own decisions or was not enabled to make their own decisions. So everything had to be vetoed or approved by just a couple of people just okay. Look for phrase that just by a handful of people, it needs to be approved by a handful of people. Sure. And that was, that was kind of a bottleneck.
Richard 51:23
Yeah, it seems like how I mean that that’s interesting bottleneck. Yeah.
Vlad G 51:28
But that’s, I guess that’s more or more speaks more towards of the management style rather than, you know, teams, teams way of doing things. But it is what it is. So what are we talking about? While we’re staying on the topic of working remotely? Obviously, given that, you know, this is March 2020, or this episode probably gonna get out in April 2020.
Richard 51:55
Right.
Vlad G 51:57
What is your What are your thoughts on working from Home versus working from office where you can at least see some of your colleagues, some of your peers in the office, what are your thoughts on? Yeah, doing this completely in a complete isolation.
Richard 52:14
I think personally for me, I enjoy going into the office, seeing things change, talking to stakeholders here and just being in the ground floor. That has helped a lot with my growth, just being next to the sales team, seeing what they’re selling. Being close to the engineering groups, asking questions in an ad hoc kind of way. Being remote or being working from home, it’s it’s nice that I don’t have to travel or 30 minutes to go to the office, but there’s a slight difference. Personally, I enjoy being in office even though I’m sitting there and on headphones. I still feel comfortable around other people working but my whole team is remotes, so to say that’s it. necessary. I don’t think it’s essential for this team.
Vlad G 53:06
Okay, I was more I was more interested in, like your personal experience personal feeling. I understand it’s not necessarily for the team. It’s more of a, you know, how does that how does that make you feel? Yeah. So that’s just the question. Really, how does that make you feel when you’re not there?
Richard 53:23
Well, I guess feeling wise, I feel like there’s certain conversations that are happening right now in backdoor conversations in slack on slack channels, things that I’m not privy to. And I think it just the information is not there in the office. I can hear conversations happening here and there and I can chime in and help resolve it or chime in and clarify certain things. Those conversations are now completely gone and in ether in the air, either they’re not happening or they’re happening in a manner that’s that’s not Yeah, that’s my feeling. I feel like there’s, there’s a I’m missing out on something that’s I guess that’s what I’ve noticed. Um,
Vlad G 54:08
yeah, that’s actually it’s actually a thing. It’s, there’s there’s a word for it. I think FOMO fear of missing out, right? Yep. As a matter of fact, it’s interesting that you brought up these like small conversations. There’s there was this book I read, and I don’t mean to, to promote it. It’s just I kind of liked it. That’s, that’s why I’m talking about it. And I think if I’m not mistaken, it’s called the turn turning the ship around, turn the ship around something like that. The one of the one of the thoughts or one of the main methods of making things happen, right, right, was having these small conversations when you don’t have to call in a meeting to discuss something when you can just talk to a person or group of persons in the hallway and resolve it and and and then The book is actually about the nuclear submarine in US Navy. How they, technically speaking how they implemented agile methods and writing the submarine to simplify this, simplify this story. And one of the things that they praised really high was having these small off site conversations. And they do help by only a buck. Absolutely. They have Oh, yeah, yeah. We’re almost at the time of our second part, second segment. And I’d like to ask to give you an opportunity to ask me a question. If you have any men hopefully, again, hopefully, it’s a question that I can answer in a couple of minutes. And but as I keep saying, let’s not let’s let’s not solve the world hunger just yet, On this episode, but if there are any questions, if they’re a question or questions for me that you would like to ask by all means, this is this is your chance. This is your opportunity.
Richard 55:58
Yeah. I had a few I’m curious how since you’ve worked at many products, product rolls, there’s certain products that exist in the market. And if you own your own product and it eventually goes away expires, cannibalizing an old product and moving on with the new iteration or something completely different. How do you cannibalized old products? What’s the best roll out? What What, what models? Have you seen successful and fail and so forth? Have you seen that in your in your past?
Vlad G 56:30
Yeah, yes, definitely. And I wouldn’t call it cannibalizing because again, just because of the experience that I had. It’s the it’s the next the next version, next release or new product that kind of a, you know, descendant of the previous of the previous one. So it’s definitely not cannibalization. It’s more of a you know, generations watching Fast assessing and and new generation is taking over. Because the old generation is incapable of doing things that are new now. Sure. And I’ve seen this a couple of times. One was my own product, v1, so to say. And what happened was it was developed in a rapid application development tool. So there were a lot of limitations around how things were done, how things were built, and how things were deployed. And it was it worked as a prototyping and first iteration and, you know, basic VP type of a thing. But once we figured that this approach works, once we’ve figured that we’re in the right track, we’re doing everything right. We’ve we’ve succeeded in identifying the solution to the needs of a customer. The decision was made to expand the development team now we have a lot more resources. So we can Easily we had a capacity to build a more sustainable model code that’s easier, better managed and that is more sustainable moving forward because you can only in that particular rabbit application development environment that we were using at the time making changes was really cumbersome. So every time you needed to go from dev to stage to production, it was it was a hassle, probably worse than you would have in the in the regular pipelines, hey, CD pipeline. And eventually we came to, to the point when the risk of breaking something in production was far greater than a probability of deploying something successful. Okay. And, and, and, and, and we kind of saw that happening. And it was it was, it was a pretty close call at some point. So we figured if we know that this is true If we know that this is a scalar solution that we’re going to need for multiple use cases, why not start early invest early in a building a sustainable, scalable solution, so that we don’t have to resolve this later, when it’s going to cost us 10 1520 times more. And that’s, that’s, that’s what happened to that particular product. It was kind of phased out in exchange for something more robust and easier to maintain. Another example was a legacy product that was about 15 years old, okay. It’s a desktop application. And everybody wants to work on the phone or a tablet and no one really nobody wants to work on the desktop. And the other however, the problem was that there were so many legacy features. There were so many things that were built on top of another on top of another on top of another, so it’s kind of like that, you know, old building, if you start scaping off the paint of the Well, you start, you start finding old wallpapers under those wallpapers. You see some magazine pages for magazines, you see some newspapers from you know, last century, you keep digging, you keep uncovering more interesting stuff. But all of it is useless. All of it is, you know, is nice. All of it needs to go, you need to start from scratch. And that’s, that’s what company did. They started building a brand new thing, of course, not without their own set of failures, but at least it was more contemporary solution, at least that was working on mobile, at least it was working on contemporary hardware with more modern methodologies built in. So again, it was more like a generations passing and new generation taking over because it was more now it’s reached the maturity stage. And now it can safely take over what you know, your granddaddy did.
Richard 1:00:57
No, that’s good. That’s a good approach. That’s great to hear your experience through those processes. Yeah.
Vlad G 1:01:04
Okay. Glad. Glad I was able to do that. Any other Any other questions? Any Anything else?
Richard 1:01:11
Yeah, um, I spoke about during my my talk earlier about consumption adoption into a feature. What models? Have you seen work and fail? You’ve built the feature out and you have stakeholders and users that don’t actually consume that. Well, what models How can you force that maybe forces is a strong word, but how can you guide them to start using that functionality, though? They requested it months ago,
Vlad G 1:01:37
that that is a great quote. So for me, the problem is not adoption. The problem is delivery cycle is too long. And you need to you need to keep asking why? Why do they Why did they request that feature several months ago? What was the problem they were trying to solve? And hopefully, because you’ve already developed that feature, you should already have the structure. And then when you start approaching the delivery, technically you need to do the sync ops pretty pretty often. Oh, yeah. in in in my playbook. The one that I’m kind of developing and standing behind is at least monthly. So if you didn’t catch that, you mentioned several months, right. So if you haven’t caught that, in any of those monthly sync Ops, it means either nobody really cares about your monthly sync ups or something. just happened and that does happen like Coronavirus wrap, right? Things have changed.
Same thing. When
legalized marijuana was introduced. There was there was a surge in apps that allowed you to process transactions, right? And then the EU legislation came in and now you have to if you want to trade in that merchandize now you have to track literally everything if it was worse than HIPAA compliance. And it’s like, overnight, the market died. So there are certain things that can happen pretty rapidly, and you don’t have time to respond. And and and that happened. So that you, you again, you need to keep asking why? Why did they care about it six months ago, three months ago, why they don’t care about it now, what changed? What happened? And once you have those answers, it would be easier for you to understand how to guide them into using or or adopting this feature or this application, this capability. It could be that you know, it’s not relevant anymore, you late You took too long to develop. Unfortunately, these things still happen. And it’s a sad truth that, Oh, wait, you just wasted a whole bunch of resources and nothing. It could be that they perceive it as useless now, but there’s a way to change things and there was a way to reposition it. And it also does happened like I don’t have a good example off the top of my head, but I have something potentially relevant. In my mind. There certainly like I was developing a prototype of a solution that had 15 different capabilities. And everybody said you only need to a three, throw out everything else that was really upset to that turns out the amount of information that those still three capabilities were bringing in was overwhelming already. So if I, whether I had those 15 or not, nobody would be using them. Because of overload information overload, we needed to train our users to absorb the initial stage, the initial phase of the product, before we could move move forward. So in other words, market was not ready to use those features. And that’s kind of same thing so you, your market needs to be ready you can be the only person who can read your own handwriting. You have to have other people be able to figure it too? So why why why this the five why’s? And that should lend you somewhere around the solution somewhere in the vicinity of. Okay, I see what the problem is. So how do I tackle it? How do I approach it?
Richard 1:05:15
No, that’s a man. Yeah, that’s a great way to frame it. It’s it’s always chaotic, I guess. I don’t think there’s a one solution. And it’s situational based. So it’s, it’s fun to discuss tonight. Yeah,
Vlad G 1:05:30
I agree. Yep. All right. So hopefully that was useful for you as it was for me. Hearing about your your part of your side of story, and hearing about your very interesting symbiotic relationship between your product team. Thank you so much, Richard, I appreciate you being a guest on our show.
Richard 1:05:52
Yeah, thanks a lot for having me.
Vlad G 1:05:54
Thank you. Thank you very much. I hope this is not the last time
Richard 1:05:58
Oh yeah, definitely not.
Vlad G 1:06:03
You’ve been listening to the real world’s product management and I’ve been your host blood Grubman. Until next time