Tag Archives: product management

Real World Product Management – Episode 07

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

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

Real World Product Management – Episode 06

In this episode, I am talking to Fouzan Alam – a product manager in a life sciences startup about things that are straight out of science fiction. Even though he’s working on things from the future, the problems he is tackling are from the present.

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, everybody, this is lat. And this is another episode of the real world product management. I have Fouzan on the line. Please introduce yourself and tell us a bit more who you are and what you do. And what is your connection with product management.

Fouzan 0:30
Hi there, Vlad. Thank you. First of all for having me on, I guess a little bit about me. I got into product management entirely by accident stumbling into the role at a startup where I started like advocating for the user in like extremely early design phase. And I’ve had to learn on the go and sort of teach myself so I probably have a different perspective than most PMS. I guess a little bit about me. I studied engineering in undergrad And then having a research background in like sensor design, and lithography, but then I went to medical school and got interested in biotech startups. And that’s kind of where I found myself. And where this story begins.

Vlad G 1:15
you saying you got there by entirely by accident and by advocating for a customer? Was there no one else to speak on their behalf? Was there like no one else to say, Hey, this is what customers wanted? What was what was the process really?

Fouzan 1:32
Well, so we started out in a lab where we were just researching a new type of brain imaging modality. And when we understood that this might be something that would be useful to clinicians, I looked around and everyone else on the staff was an academic, and I was someone who is training to be a clinician and had been working with clinicians, physicians, I guess you could say for quite Some time and I realized that if I didn’t say anything now I would end up with a lot of the same frustrations I had with devices that I’ve had to use at the bedside with patients and that sort of thing. So it was almost a forced thing. I didn’t really want to do this and found myself there. Okay,

Vlad G 2:20
okay that I mean that’s interesting. I spent some time in life sciences let’s let’s put a broader perspective on that. Especially if I’m working for companies in in healthcare. I don’t remember them being specifically against the kind of the users against the A we know better but it’s interesting perspective. How I mean the way the way you presented cinches perspective how no one really cared. Especially given that there is a frustration.

Fouzan 2:53
Yeah, and I think you did pick up on the on the frustration there for me. What really happened i think is In the last, I would say, five to 10 years, the way that tools for physicians have been made seem to throw out any empathy for the user. And I find that a very annoying and really grating thing, because, you know, you see, like, I think the best thing I can point to is electronic medical records. We’ve seen those sort of come into the market over the last decade, and they still seem to have almost hostile user interfaces, and I’ve never met a doctor that liked using them.

Vlad G 3:37
I like I like that. That comparison. As a matter of fact, I owe some of my previous jobs. I was actually working on EMR systems. And I agree with you. Yes, I agree with you by the hostile user interface. But I think again, since I was I was both the developer and I’m coming From a social development background, since I was a developer, I was a manager of development resources. And I was a product manager on EMRs, or something wider. But so consider the EMR. There’s a lot of emphasis on making sure that the right data is coming through and making sure that the data is actually is coming through and making sure that the data makes sense. So by the by the, by the time that you make sure all that happened, you almost have no time, no resources to worry about the user interface. And I remember the pushback that I got when I was working on the you can call it a clinical viewer, right, the the viewer of the clinical shirt. And I remember when I introduced the idea of why don’t we have mobile interface, I mean, look at our doctors, not everybody wants to carry around six pound laptop, maybe they want to carry around tablets easier. And people look to me like, put tablets. What do you mean? doctors don’t want to carry around a laptop? What What are you talking about? Why are you Why are you on? Why are you talking like that? Yeah, I can relate to that pain. That’s what I’m saying.

Fouzan 5:16
Yeah, no, I I can already say Vlad, I think you and I are going to be friends because I think you you recognized and understood well before many of the others at your company did. And I really appreciate that. Even if it didn’t make it all the way to the production, I guess.

Vlad G 5:34
I don’t know I I have this weird thing about staying in the same place for too long. So I moved out, I moved on to another actually moved on to a completely different machine. But let’s let’s talk more about you. So you’re in the product management role. What is it that you do?

Fouzan 5:52
So most of what I do now is advisory. So I’ve actually I’ve stayed at the company in an advisory role. But I now manage other product managers there and manage some of the other teams still. But I do that remotely. So that’s kind of an interesting thing. And I’ve moved on to do some product consulting and other places and tried to kind of branch off from there. And I don’t think I’ll be returning to practicing medicine anytime soon.

Vlad G 6:21
That’s interesting. Again, from from my experience working, you know, my last role at a healthcare. We had a lot of what was the word? I can’t remember. I can’t remember the term that we’ve used. But we had a lot of MDS and our ns. I’m sorry, for those who are not familiar with American nomenclature. It’s doctors and nurses. Yeah. And we had a lot of people with degrees and sometimes advanced degrees in the roles of business analysts in the roles of business owners or product owners or kind of sort of product managers, even though it was not, it wasn’t a call the product manager was something else. But we had a lot of people in the it with with the medical degrees. And now that you’ve saying, you kind of picking up the same path, I wonder why what’s what’s so hard about being a product manager, or person with medical degrees that you guys want to save lives and stuff?

Fouzan 7:26
I think we do. But I think that a lot of us go into medicine expecting to be able to make a larger impact, maybe on a greater scale than is possible in actual clinical practice, and that sounds weird for me to say, but the truth is that you can only work on a few patients at a time. And I think that if you go into the biotech side, or at least what attracted me to that side is that your solutions can scale and so if you if you create a life saving or life changing product or help guide the development of something like that. It can often impact more people positively than you could with your own hands in medicine. And, like, for me, that’s something that I’m really attracted to. I want to maximize my positive impact on society, more so than just practice a field that I really care about.

Vlad G 8:24
Wow, that’s that. Thank you. That’s, that’s really interesting perspective. It’s kind of like part of my story when I was talking about usually on the interviews or whenever there’s a question about my career. And I tell the story that I worked for healthcare and I worked on this product that was displaying clinical data for clinicians, especially around the ER when you need to make fast decisions. And you need to make sure that you have all the information about the patient, make sure they do not prescribe something that’s going to kill them. I said, but there’s really, you know, we the only the only thing that we were worried about, it was patients lives so no pressure on developing the right things the right features in our product. And I usually I use it in the more like cell fire any sense that guess that happened. But I mean, the way you put it in perspective, it’s now it sounds like I’m bragging, so I should probably

Fouzan 9:17
no, no, I don’t think it’s necessarily bragging. And and I think that what you did there was really interesting and important. And I, I can agree after using EMR systems that they do display very relevant data. So

if you had a hand in that, I have to say thank you.

Vlad G 9:37
I wish but maybe, I don’t know. Potentially, maybe. Alright, let’s, let’s move on. onto your what products have you worked on? Or are you working on? What is it that that you do currently?

Fouzan 9:53
So currently, I do product consulting with local small businesses. This is sort of a I started on the side when I was transitioning to an advisory role. And essentially, I work with local businesses because I think that they don’t have the advantages of talking to product people. And I’m a relatively new and relatively young Product Manager. So I think that if there are any of you out out there listening that want to jumpstart your career, this is a really good way to do it is approach local small businesses, try to improve, streamline or adapt their products better to the correct type of consumer. And also tried to solve things like user retention and user turnover and some other things. And I think that it’s a really interesting arena to work in, because those people don’t usually have the same types of resources. But you can set it up in a way that incentivizes both of you to work well together and to sort of come up with solutions. And if you do it well, you’ll see quite a bit of growth, because that’s the other nice positive of small businesses is that there’s usually a lot of room to grow.

Vlad G 11:10
Okay, now I just have to ask as a person who both worked with small businesses and owned small businesses before, what kind of products specifically you guys are working on.

Fouzan 11:23
So we do some food stuff, which is actually really, really interesting. We do some local services, so a lot of printing and a lot of like graphic design related service type stuff, where it’s like, there’s opportunities for business to business growth, as well as business to consumer growth. And then there’s also like, I’ve worked with local business to business businesses and try to help them optimize their own products. Part of which is like I was lucky enough to have some mix. Trying to pitch ideas to other businesses. And so sometimes it’s Oh, let’s go in and I’ll optimize this business and try to get it purchased by someone else or or those types of things. And so, yeah, it’s a very, very different world, but I really enjoy what I do. And it’s fun doing it part time.

Vlad G 12:20
Okay. Interesting. You talked to you said that

Fouzan 12:26
you had a hand in biotech and startups, is that another part of your daily routine? Or is that something completely different? That’s the so that’s part of the advisory role that I have right now. And then I consult for a couple of other biotech companies. And that’s a totally different area of like what I like to do. And so, I guess I could say if you want to some of my career, it’s that I don’t like traditional nine to five and I found it much more interesting to consult for a bunch of different people all at once. And in different arenas. Oh, wow.

Vlad G 13:03
Okay. I mean, I’ve done that before. But lately I like do, I still like going into 15 different directions at the same time. But I also like deep diving into thanks and right, I found it hard to consult four or five different five different products, for example, that are each in a different in different arena or different vertical. So kudos to you. That’s, that’s really interesting.

Fouzan 13:35
It’s still waiting, I guess you could say and definitely, yes, just you know, it’s a different kind of thing. And if I would, like, I understand what you mean by a need to deep dive, and if I would say there’s one area where I like to deep dive, it’s the biotech side, so.

Vlad G 13:52
Okay, so do you want do you want to talk more about the biotech products that you worked on?

Fouzan 13:58
Yeah, so I’ve done that. A lot of stuff on brain imaging, which is really, really interesting. There’s some weird considerations you run into there. I’ve worked on some surgical devices, which are really, really fascinating. I was briefly product owner at a company that did resorbable polymers for surgical like replacement of bone. So they could like let’s say that you had like a multiple fracture somewhere. You could go in and excise the bone that was destroyed. 3d print a polymer that you could actually built into the bone exactly where it was, and the bone would grow back. Replacing the polymer and your body would actually recycle that polymer over time. Completely by a safe resorbable fascinating material. And another one that I helped shape was a nerve regrowing material. And that company is still relatively young. So I can’t speak too much about that. But I can say that there are now some pretty interesting products they have that allow you to essentially stitch two nerves together that have been severed. And the scaffolding and matrix that have been put into place like allow you to then regrow the nerve in a span of a couple of months with 90 plus percent recovery rates, which is significantly better than we’ve had before.

Vlad G 15:31
Okay, before before I say what I think about this, what was the success rate before

Fouzan 15:38
without any type of scaffolding, it’s less than 10%.

Vlad G 15:44
So you went from less than 10% to over 90%.

Fouzan 15:48
Yeah, that was okay. It was I mean, we should

Vlad G 15:53
just be clear to me, this sounds like you just recited a couple of episodes of altered carbon

Unknown Speaker 16:00
This is

Vlad G 16:02
to me this sounds like a complete the sounds from science fiction just told me that Oh, you know what, you know, time travel is possible.

Fouzan 16:10
I mean, I’ve heard, I’ve heard of things. I’ve heard of things when you can fix the bone by using some kind of an item put in there but the whole process overgrown the bowl regrown, the bone itself is pretty fantastic. And now you’re saying this, you know, more wounds can sit like for growing bone is really interesting because they will grow on their own, and they will stitch back together. But when you have shattered bone, like the, the interface between different pieces is very disruptive and can be hard to get it to grow correctly. And so by removing those fragments, you actually help the healing process and then the implant that goes in. Like cells will follow signaling molecules and so if you have the right signaling model kills in the implant. And they’re arranged correctly, which is possible to do if you’re 3d printing. And you know, with each piece you work with the physicians to design the implant. Wow. And then it’s, you know, shipped to them. So it’s very, you know, JT manufacturing, I guess you could say. And, you know, it goes into the patient, and it’s really satisfying to know that a you’ve worked on something that’s going into someone, and it’s actually directly going to help them.

Vlad G 17:31
Wow, as a person with a couple of broken bones. I can appreciate that. Probably more than some other people but yeah, I definitely. I definitely can appreciate that. I wish I wish this was available when I was a kid and I had those bones broken. Right. So So and I’m going to use the your, your outline that that you presented so we can get to it. topics that are that are are interested to both of us. I did you did you do this all by yourself? Or did you have some kind of a team helping you.

Fouzan 18:11
So the this sort of stuff was done with a relatively small team, limited resources, so a couple of academic labs, and a team of about 30 people. And it was really, really fun because the teams were very small. And so there was a lot more that each person had to understand and cover and think about, and it made my job a little bit easier because there were smaller groups of people to influence in the right ways to help them you know, find the right answers to some of the problems we’re facing.

Unknown Speaker 18:49

Vlad G 18:50
So, what was that about the limited resources? How do you guys deal with that? It’s always a fun question. Because everybody you It deals with limited resources of their own very certain, I’m sorry, in their own very specific way. So I wonder, I wonder what you guys that.

Fouzan 19:11
So with, like when we were building this team, you know when we understood, okay, we have this brain imaging modality. And we have two options we can like we can patent it right now, and the university will help pay for the patent and we could probably find a buyer and then it would sit on the shelf somewhere until someone decided to do something with it. Or we could build a product out of it and, you know, form a company around it, incorporate in everything and get everyone together and try and create something that someone would be willing to fund. After thinking about, like the possible impacts of this tech, we decided that it would be better to build a product because I think that there was like we saw direct clinical relevance. We saw You know, potential for positive impact. And we saw that the lead time was going to be long. And there’s a very high likelihood that someone who buys up the patents would just sit on them, because it’s very, very expensive to get something through the FDA. And it’s also like a 10 year process. And so you’re thinking about all of that. And sitting around with the team, we just said, Okay, we’re going to push for a company. And then we said, okay, well, we want to start something, but we have very limited resources. We have a couple of research grants, and some personal money from some people involved in this and that’s it. Okay. And so,

Vlad G 20:43
that is that is very similar to other startups, at least. Again, I’m not a startup person I somehow happened to avoid practically. For the whole of my career, I’ve avoided working for startups if the one that I did work for was a spinoff from a pharmaceutical company, I can’t even call that a, you know, fully legit startup. But it’s really interesting how I mean, I am familiar with startups in or around the key products or services. I’m completely unfamiliar with the startups around biotech because to me the, the sound expensive and seemed like you’re, you’re confirming that suspicion.

Fouzan 21:21
Yeah, so like the the process of a 510 K is like multiple millions of dollars. And there’s like so much paperwork, and it’s quite, you know, it’s just very, very, very involved. And there’s a lot of clinical research that has to go into it before you can really say okay, yes, we are truly ready to do this thing. And before the FDA will say, okay, yes, you are allowed to sell this. So, the first challenge is, well, if you if you don’t have a product you can actually sell then you don’t have any sort of revenue or cash flow? And as a product manager that makes your life very difficult.

Unknown Speaker 22:07
Oh, yeah. Okay.

Vlad G 22:09
And it sounds like, again, I don’t know how this works in biotech, but I rarely see anybody with a few million dollars laying around the house just like yeah, sure, take that, you know, scissors for something good by yourself something funny.

Fouzan 22:27
But we did have a couple of advantages. We had a couple of physicians interested in the technology. So we had been doing some experiments in the lab. And because some of our friends who are neurologists, we’d be like, hey, come over here, like check this out. And so we had some people who were like, Okay, this is pretty neat. And it turns out that physicians have a decent amount of recurring revenue. And if you get enough of them together, it like, helps along the process of addressing Like resources. The other thing we had was, we had academics and academia is full of very interesting people who are really, really good at going extremely deep into a topic and exploring it to its fullest and then learning to optimize little pieces of it. If you combine these things together, you sort of start to see the, I guess, a cloudy picture of what you might consider, you know, the beginnings of a team. And then it just comes down to like, defining your actual needs versus the resources you have at your disposal. And for us, like what really started to kind of come together out of this was a discussion we had about product need versus company need.

Vlad G 23:46
From my perspective, the way the story goes, you form the company around yourself to build a specific product or a specific set of products. So how do you see that those needs being different?

Fouzan 23:59
So I was actually not the original founder of the company. So there was my research supervisor was the person that I’d been working on this project under, was one of the original founders. And he was the one that sort of started to push us all in the direction of, okay, we need a company and I was very much in agreement with him. Well, a lot of other people disagreed. And between us, we started like thinking about, you know, where we need to go with this. And it became very clear that the company itself would need a different set of departments and operational branches, I guess you could say in the org chart. Then what we were going to build first because what we needed really was a team to get our product to a point where we could get the funding to build the other team.

Vlad G 24:54
It can you can you unpack that a little like what teams or what sequence of building teams did you have in mind because that sounds sounds rings true. So let me let me clarify that it rings true. It sounds like waste all the startups work, right? So you have one guy who does marketing calls, calls potential investors and sets up an appointment with I don’t know, with with investors and sets up an appointment for CEO at the same time he goes and buys coffee. So what is what are the what are the and then you know, when you once you expand, you hire a separate person to bring in coffee and only put this guy in the marketing or only put this guy on sales calls depending on his performance. So it’s normal. But I’m still curious. Because biotech is just the different from, I don’t know, people building a startup around an app or a software.

Fouzan 25:53
Yeah, so it differs from apps and software. Because when you’re building a biotech product that’s supposed to perform a function and get past like, say, clinical trials. The goal really is early on is you want good data quality, you want to be able to prove that it’s safe and efficacious. And, you know, it has the effect you want, or it does what you say it Does, does it consistently and actually gives clinicians actionable data. And researchers already inherently understand, like academics, I mean, you know, inherently understand good research data and good data collection. And so that side of it was almost entirely filled by academics. But the thing is, if you’re going to start something with limited resources, and you plan to build a company, you need to be very careful to make sure that you’re also meeting the needs of the VCs that will eventually invest in you. And that’s very tricky, because When VCs just see a science experiment that needs to be pushed through the FDA, they get reluctant. And it’s and so having this product vision early on, was extremely important in saying, okay, like, we need to make sure that we meet both sides of this. And this is what I mean by product need versus company need to product need is what we need to do to get through the FDA to have an actual product to sell. Company need is what do we need to do to satisfy the VCs so that we can actually form the company to take the rest of those steps forward? Because after that, it becomes a resource and data collection game. That’s why I switched to an advisory role later on in the process, right. So so for example, I guess, like let’s maybe dig into some specifics, because I think you’ve been talking about this in a very like top level.

Vlad G 27:58
Yes, I was going to ask

Fouzan 28:02
Yeah. So like, okay, from a company standpoint, like you probably want, you know, a design department, an engineering department, a software team, a hardware team, human interfaces team, a sort of medical director, and a couple of the other pieces around that, right, you need a business department and a few other things. But that’s none of our like, most of that is not extremely relevant to the product needs of getting it through regulatory. So what we tried to focus on was okay, we’re going to build a product vision. So we need hardware, software, design, and human interfaces. But we don’t need the business arm. We don’t need marketing, and we don’t need sort of the other side of things until we’re at a point where Ready to pitch. And then we can sort of build those out. At the same time, we sat down and looked around and said, Okay, we’re all people here who are relatively capable of learning and doing things, and delegating things and deciding the right balance of which to do in what departments is how we kept resources. Very, very, I would say, like very focused on just the product need, and tried to minimize the resources spent on company need, until we were ready to pitch. So until we had a working prototype, we weren’t going to do a lot of the other stuff.

Vlad G 29:41
And I think that what you’re looking for is lean, lean startup, right, you’re early, you’re focused on your goal. And you keep pushing for it with whatever all the resources basically focusing on getting that one goal and once you reach to the walls, you start approaching it that’s when you started looking at other things. So that makes perfect To me,

Fouzan 30:01
yeah. And the other thing we realized is there’s so much that you could teach yourselves and do. And then like, for certain types of manpower, bringing on a software team was easier done if you tapped academia, where you had people who specialized in the particular kind of software we needed. You know, who wrote papers on brain imaging software and, like worked with that and would love an opportunity to work on that as a project and be brought on board as partners later in the process. And then also, other researchers and other labs that were interested in sort of joining this project and working together. And so I think I would say like, if you’re building a team, like my best advice is actually tap academia for product teams specifically. Because they tend to have this understanding of research and data gathering. They tend to come into it with very few assumptions.

They know their academics. And so

they’re less willing to sort of just jump on preconceived notions and move forward. And they’re more willing to ask questions and explore and sometimes ask the right questions. And they’re also more receptive to a product manager responding with, I’m not sure but we can figure this out with the right type of testing or studying or data gathering. Because they, they inherently understand the importance of that.

Vlad G 31:35
The last part one to make one make me want me to go into biotech even more, especially when people are accepting of they will figure it out later responses. That’s not what I’ve seen. So from the from the end, let me let me ask you a couple of questions here because these situations situation that you’re describing is somewhat different, although Don’t get me wrong. There’s a, there’s a lot of enthusiasm. There’s a lot of ways you can build a team around an idea and even sometimes make them work for peanuts or for little incentive, just because the topic is interesting. And frankly, some of our guys in the company I work for right now, some of our guys do that as, as a part of their, in this paradigm, they, they experiment, they build things, that they later become a really cool, interesting offerings. I’m trying not to call them products because they’re not necessarily products but they’re pieces of functionality or software. That is that then company uses or sometimes not, but it’s fun to have them. Sometimes it sits on the shelf for five years. But what is the incentive for those people to join you? I mean, you don’t have any cash flow. You don’t have even a You don’t even have a Initial financing from VCs you were building towards that. So what is their incentive? Is that? How do you how do you how do you make them work for you? That’s I guess that’s my question. So

Fouzan 33:13
that’s a really good question because we actually really struggled with that problem first. And then we realized two things. And one was, academics love papers, and publications. And they have, they already have an incentive to publish. And if you give them a slice of something to work on that you can then allow them to publish at a future date. Some of them will absolutely be okay with that. And the other part of that is, academics do like to be able to patent technologies and to build new things or like work at the very edge of their field. And if you incentivize them with certain contracts, As well as some pay, and say, Okay, so we’re going to build this thing. And if it turns out to be novel enough, and we can get it patented, or when this company is up and running, and we have some funding, we will turn around and buy those patents from you and the university you work under. And that’s a really good incentive for them, because it puts them in the good graces of the university they’re working with, as well as gives them a sort of another type of publication. Academics don’t mind at all writing, or like creating new tech and patenting it and selling it to companies because that also gives them future revenue. And so if they believed in our vision, and they were interested in the kinds of things we were doing, and thought they could do something novel in that, and we showed them some of our demos, we brought them into the lab and sort of explained what we were working on. And they saw it and believed in it. We extended them that offer. And so it was a I know we don’t have Lunch right now. And we were very upfront with that, because it’s, it’s not good. If you try to trick people in those situations, it’s much better to be very upfront of that, and then offer them a but in the future, if we do, and if you believe in this, and you think this will actually be a significant, you know, a significant change to the way that neurology is practiced, or the way that we do brain medicine, then maybe this is worth working on. And maybe it’s just that you can give us some of your spare time. But we will promise to return the favor in the future and come back with money and patents and things that we can allow you to publish.

Vlad G 35:43
So they’re okay with nonzero probability that it would not it’s not it’s not gonna work out, right. I mean, they still get something out of it, like their research papers and potentially the paper patents that they that they

Fouzan 35:57
get. Exactly. And the way that was structured is If the company doesn’t work out, too, then those papers are allowed to be released or published, you know, basically saying, yes, the company didn’t work out financially or whatever else. But you now own this piece of IP, and maybe some of the research that went into that. And maybe someone else will be interested in the future. But you still have a tangible publication out of it, that’s good for you. And if the company does work out, then we turn around and we have those released as white papers or, in the case of patents, we purchase the patents from you. And that can be potentially very lucrative. So

Vlad G 36:37
it was the win win scenario,

Fouzan 36:37
whether our startup did well or not. And I think that’s the only way to do it.

Vlad G 36:45
Interesting, that still leaves out the question of, so you brought them in, and I understand that not now. Thank you for explaining it because it’s somewhat different in my world, but I understand the incentive for them to come over Use the incentive then what is the incentive for them to stay?

Unknown Speaker 37:05

Fouzan 37:08
the thing we’re working on and I guess

so, are you sort of familiar with like the MRI or

you know, those types of brain imaging. So

Vlad G 37:20
as much as anybody who was in that def def machine, not death,

Fouzan 37:26
but the very loud that makes uncomfortable noises.

Vlad G 37:31
I actually managed to fall asleep once so, ya

Fouzan 37:36
know, it’s a, it can be kind of soothing because you have like nothing to do and your brain just kind of gets bored after a while and just shuts off.

Vlad G 37:42
Yep, exactly.

Fouzan 37:45
So there’s a type of MRI imaging called functional MRI. And what it does is it looks at the sugar uptake in your brain over a certain time slice, right? And it’s about it Generally an average of 10 to 20 minutes. But essentially, the image you get at the end like that the deliverable that the machine prints out for you, I guess you could say, is a picture of your brain with varying degrees of bright lights over the regions that we’re most engaged during the last 20 minutes. So that’s an existing technology, it’s available for, you know, at most major hospitals. And it can be used in different kinds of studies, right? So it’s like which parts of the brain were active based on their sugar uptake.

And you know, which parts lead up Most Great.

The problem is the time slice is really large. And so for finer tuned brain stuff that’s not really workable. The technology that we were working on, allows you to get that time down to milliseconds. And so what you could do is You could do any sort of study and watch the brain light up almost immediately. And not only that, but instead of presenting you with the physical image, we were presenting you with a network map of the brain. And so our imaging modality wasn’t visual, or spatial, but it was information. So which areas the brain laid up? Where is the data going? What are the nodes? And you know, what’s the crosstalk like, and where does all the information go? And that has is just amazing. potential in so many different areas. For one, we could measure and quantify consciousness, which is just a crazy idea if you think about it, and

Vlad G 39:50
I read a lot of science fiction, so that’s not that’s not that crazy, but please, this does sound like science fiction. So please continue. I love this episode of So if I show

Fouzan 40:01
oh my gosh, so

so so when you bring someone in and show them this and say, do you want to work on this thing that has the potential to maybe like have a major impact in the way we treat brain injuries and comas and locked in syndrome and all these other terrible brain diseases were like we just were conditioned, I guess you could say, where we don’t really know what’s going on. And we have very limited tools and figuring it out. Right? It’s like to do want to build the next best hammer for figuring out how brains are working and what’s going on there. Most people are pretty interested in giving it a shot because they immediately saw the potential. I mean, there’s, you know, many clinical scenarios and other scenarios based around this and many research opportunities if you start using the tech and that’s the other side of the incentive coin. So how we made them stay was

you can run studies with prototypes and

Early versions of this tech and released them once the tech is in the market.

Unknown Speaker 41:05
Okay. Wow. I mean, yeah.

Fouzan 41:08
And the other side of that is, of course, it gave us a user base, right? Where you could actually like test things and and so there’s there’s two sides of that right, a give and take a positive mutual benefit for everybody involved.

Unknown Speaker 41:24

Vlad G 41:27
That is that as I said, this does sound like science fiction. So I’m having a hard time, disconnecting from the notion that I just watched another episode of I mentioned altered carbon is part of this problem with 10th dimension. I don’t know, Stargate

Fouzan 41:47
defects because 10 years out at least.

Vlad G 41:51
Okay, so let’s get back to to where we’re started. And the question here is then so what would make a product in the product management sense of the word. What would make a product? In this case? Would that be software that maps out the brain brain activity or or software that builds up? specific? I don’t know, assistance for brain surgeon or and forgive me if I’m using the rewards?

Fouzan 42:20
That’s okay. Um, that’s a really good question. And the way we sort of thought of it is we want to build a tool. And that tool should be the product and it should be this sort of all in one package, right. So you want the software that actually does all the analysis with the the hardware that includes like the computer hardware that does all the number crunching as well as the actual hardware that you know that the brain scanner itself is and then the design and packaging and everything and we wanted just one deliverable because sort of a tool that any scientist or To search for pickup and again, like a good example of this would be something like an MRI machine. There are different models, of course, but the general like idea of an MRI machine is you put someone in the tube and you can look at their brain, right? And different people have found different ways to use that in various fields, right? You have researchers that use it. For psychiatry research for psychology research, you have neurosurgeons who will take MRIs before and after a surgery, and so on and so forth. And so our idea was build the tool building very, very good tool, and sort of give that to various fields that would take advantage of it.


Vlad G 43:46
I’m sorry, maybe that’s a that’s a fly job, but I just have to ask it the way you imagined packaging your product for general use, do you would you include a brain to practice on or is that The class. So

Fouzan 44:06
I would want to make it so that the, the thing was safe enough that anyone could put on the device and use their own brain. Like it’s I guess you could say like, brains are included. They’re yours.

Vlad G 44:23
Stick your own brain and see how that works. I mean, yeah, by my work.

Fouzan 44:27
I mean, it’s only like a really weird electrical device like, what’s the worst that could happen? Right?

Vlad G 44:33
You short circuit your brain and you know, I don’t know which one of the superheroes got that. I don’t remember all of them. I only remember a few. You get flash or I don’t know. I mean, no one else

Fouzan 44:50
knows that. It’s a it’s such an interesting like, you know, like the the idea was that when we started out and we saw what we had, we said, okay, we need to turn this into something and it should be something usable for a wide variety of people. And so we started sort of narrowing down like, okay, what’s our actual product vision here, right? So we want something that was wearable, in pretty much any orientation. Because you know, sometimes patients are laying down sometimes they’re sitting up and sitting on the table. And sometimes you’re just, you know, in the living room with your friends and decide that zapping your brain might be something fun to try. And so something portable, something very, very simple to use. Very quickly, we learned that, you know, from the physicians we talked to, as we tried putting various sketches of the device in front of them, we realized that the less complicated it looked the like happier they were with it. And so really like being being careful to be empathetic towards the primary user, which is a physician or a researcher. Okay, well, what do we do to lower your cognitive load so that when you’re using this device, you can be thinking about other things and still get consistent results that are, you know, trustworthy and usable. And that was a really important requirement. The third requirement was that it had to be portable and self contained. Now part of the simplicity thing is you don’t want a cart with a bunch of stuff on it, that you have to wheel around from room to room, because that’s just more difficult to use. Inherently portable, and smaller is better because you can use it in more environments. And so those are kind of the the big requirements for a product. So

Vlad G 46:41
Wow, I mean, it does sound like product requirements. It absolutely does to me like if you design an iPhone has to be portable, you know, should not bend when you sit on it. Right? And if you know what I mean, and yes, it’s very product of it. Again, I apologize, but I just have to ask given this portable given that I brought up altered carbon a couple of times already. So how far are we from? carrying a device that records your brain and then can play back? Or at least give me an idea? What the hell was I thinking five minutes ago?

Fouzan 47:22
Very far away just because of the last part that you said. So the, what was I thinking five minutes ago is incredibly difficult like that the signal complexity of like, what comes out of your brain is just insane on a level that is hard to get into without like really spitting off another podcast because it’s a it’s a PhD level topic, actually, well beyond that. And I’m not even qualified to kind of go there and really tease all that out because it’s just so far beyond like, what I could possibly even begin to talk about.

Vlad G 47:54
Okay, no, I’m not pretending I’m smart enough I know is as a consumer of that technology. You know, I put my keys somewhere and I can find them. I’m really curious, since within get our flying cars but by, you know, your thousand, the least the least our scientists can do is like Tell me where the keys are because right, you know play back my last five minutes of thought,

Fouzan 48:16
excellent poster just the least i scientists could do is tell me where my keys are. That’s a really funny one I like that

Vlad G 48:24
by all means I can help you with product packaging. I have plenty of crazy ideas. Okay, so we’ve touched upon and thank you This is amazing. This is completely different from what I’m doing or what I’m even even what I’m involved in. My specialty is more b2b b2b b2c software, right? So I get to see a lot of enterprise things but I don’t get to see things or that are connected to academia and things are connected to the research. So my interest Standing is, as you work on the value prop of this product, I can see it even, you know, with my limited scope of knowledge what what are the challenges? And I would imagine, again, as I said, this is very different world that you are in, compared to what I deal with. What are the regular challenges like what is your day day to day life look like? And and building this amazing product?

Fouzan 49:28
So quite, I guess, let’s see. So from a design perspective, one of the main challenges was how do we make this comfortable for the user and the person who’s wearing it because that’s actually not the user. And so when you have a product that interacts with two different people directly in such a such a way that like, when we set out to actually design it, we had to really think about Okay, like the person wearing this, like, how will they feel will it look friendly to them. And I’ll get back to why we did that. I think later Later in the outline, you’ll see like exactly why that mattered very early on, because it sounds like almost, you know, at the end of product development consideration, but and so in the design phase, it was like, Okay, this is relatively heavy electronics on there’s some, you know, computer hardware in there, you’ve got to cool that down. The fan shouldn’t be louder, scary, because being in a hospital is frustrating and can be scary for the patient. And so it’s like, will a child be able to comfortably wear this and then it’s like, Okay, well, we need to distribute weight to the shoulders in the back because you don’t want to put all that weight on someone’s head because after about 10 pounds, like your neck gets very tired.

And you have to wear this thing for about 10 minutes for the scan.

And so there was that part of it. On the other side, it was the physician side. It’s like okay, what are the printouts look like? Like, what are the You know, what are the considerations there? Like? How do you lower cognitive load, we settled on a put on patient, press one button, wait for scan to complete, because there was like the simplest possible, you know, design that we could come up with that was like, still had some relatively usable things. Pressing the button again, would immediately cancel the scan, if there was ever a problem, like physicians should be able to know that, you know, there’s an easy way to cancel it, whatever. And so, that was like a really important part of it. From the actual technology and r&d stuff, it becomes crazy because on one hand, like we’re combining multiple existing brain imaging modalities and doing a lot of like the special stuff in software. And so you need a ton of computing resources, which is difficult and tricky when you’re doing something local and portable and self contained. And then you also need some really good software and the actual electronics and the hardware needs its own set of controllers and other things. And because you’re delivering, you know, magnetic fields in like very close to the MRI level of magnetic fields, there’s a lot of safety considerations. And so, over there, the challenges became, you know, how do we make this really, really, really safe? And how do we make sure that it’s absolutely not going to injure someone? And then on the materials perspective, we actually had two alloys, some relatively unusual materials to handle the thermal considerations of like, essentially, like, okay, maybe this doesn’t make sense. So, let me step back and redo this. So. Okay, from the material side, we had to think about You’re running a really, really powerful electric current through a metal coil. And that coil is going to heat up. And if you’re running relatively powerful currents at the level of an MRI machine, then you either need to cool it with liquid helium, which is very cold and very not portable. Or you need to find a way to cool it down or find new material that can handle that kind of heat. And then it’s also in very close proximity to the user. So you need to make sure that that’s not going to hurt them.

And so that whole problem was

Vlad G 53:36
Miss makes makes it very challenging, I guess.

Fouzan 53:40
Yeah. And we, our goal was to get this ready to pitch in about nine months, so not a lot of time. Okay.

Vlad G 53:52
Wow. I mean, this sounds like sounds like ball. If that Rocket Science then pretty close to anything our mere mortals can relate. I mean this in a very friendly respectful way, you guys, you guys seem to work more literally work magic. real work here, we’re the device that’s gonna read your brain and that’s right at the same time. So here’s

Fouzan 54:22
some here’s some like really practical advice for working magic, right?

When you’re working on really, really crazy stuff

there’s there’s a saying that my supervisor hadn’t it’s always that there’s always someone crazier than you are. And he’s been right multiple times because it’s like we we would present him with a with the requirements like okay, we were like I would be talking to them say okay, our team needs to do this or find this. And almost always after he looked at me and said that and told me to go do so. really deep digging, it turned out that someone somewhere had a similar need. And that you could almost always find the material. So we are actually able to find the material and adapt it within about two weeks.

And and it turned out that

when people were building real guns, they realize that you have really powerful magnets and that you can pulse really, really high current through them. And fire projectiles at you know, multiple times the speed of sound. But those metal coils would melt if they were made of ordinary alloys. And so we looked at some of the work that other people had done related to that, and sort of came up with our own alloying requirements and found someone who would quickly fabricate something relatively close to what we needed. And then ran some tests on it and it turned out that if you post it at a certain like at a low enough frequency, you Wouldn’t overheat the coil, see wouldn’t damage anything. And this is sort of, I guess a really good lesson in take an approach that is really practical and not an approach. That is exactly what you envision. So MRI machines are constantly running current through massive magnets and this like need huge amounts of cooling. It’s like, does your product really need that? Or can you do the same thing with pulsed magnetic fields? And how short Can you make the pulses without degrading your data? Right? So it’s like, what are the trade offs there? And so running small studies around that, and understanding Oh, like we can have relatively short pulses, and our data quality doesn’t really degrade very much. And we suddenly can just throw out the entire liquid helium cooling loop that would basically invalidate our product idea. Okay.

Vlad G 56:58
I can’t really On their experimentation level, but this is really amazing. This is really an amazing story. Thank you

Fouzan 57:05
for sharing. No, this is, you know, it’s my pleasure. It’s really fun to kind of talk about some of this stuff, because the conditions are just insane. And it’s really fun to like, see how like the teams came up with various ways to sort of work around that. The other thing is that when you’re solving a problem, too, I mean, okay, you’ve done you’ve done some project management as well. Right? So if you think about, like, a lot of the project management stuff is built around

sort of these choke points, or like, you know,

I guess efficiency limitations in like, how you waterfall a project or something like that. Right?

Unknown Speaker 57:49

Fouzan 57:50
Yeah. So one of the things we found is that it’s almost always better to build those around major problems you’re trying to solve And then the most efficient use of resources is to have each team solve that problem in their realm independently, as if they’re the only team working on it. And then you aggregate those results, and you often get a result, that’s an order of magnitude better at solving that problem. So rather than like minimizing the problem by 20, or 30%, the problem disappears overnight. And so when we started looking at thermal considerations, and, you know, pulsing electronic currents through through all the circuitry, we looked at the software team and said, you know, can you design a regime? That, or can you code a regime where it’s like, there’s an algorithm that looks at how heated our circuits are, and decides like, how to pulse things. And we looked at the electrical engineering team and said, Hey, which was like, you know, then each of these teams is like two or three people. So it’s like, hey, like, can you to come up with that? An idea for keeping these components cool in a way that doesn’t stress the circuits, but also still, like doesn’t degrade any of the data quality. And then we looked at the design team and said, okay, like you’re doing the physical design for this packaging of this device, can you build it in such a way that we have more airflow through the body where all the components are held, and so on and so forth. And by not having each team solve the problems created by another team, or like, like you never want software to be solving a hardware problem. You want software to be solving a problem, and you want hardware to be solving a problem and you want each of them doing it in a way that does it best. When you combine all those solutions, you get something that runs relatively cool. Cool enough that like despite house having a coil that we were running like three Tesla magnetic fields, through With like three Tesla’s on par with MRI scanner, it’s like if you even took anything metal in the same room as an MRI scanner, it would just suck it right in. Which is insane if you think about like the strength of the magnetic fields, but despite us running similar magnetic fields through that coil, the way we did it, you could touch the coil right afterwards with your bare hands, and it wouldn’t burn out. And so it’s like, if you want to eliminate a problem, let each team solve it in their domain.

Vlad G 1:00:36
Okay, makes sense. I mean, this is more simply the autonomy that we kind of all advocate in the product management mindset. I’m happy to see that it still works even if you’re not doing just about the social products but as a if you’re still if you’re talking about software and hardware together, and this is specifically hardware alone is still works and still delivers amazing Results.

Fouzan 1:01:00
Yeah. And so I would say it, we would credit that for probably most of our cost savings, because you can quickly see how like certain problems spiral out of control if you had everyone trying to solve it in an inefficient way, because of just like all the efficiencies stack up to solve the problem, all the inefficiencies would stack up, to drive up cost and like consume resources and take a lot more time. And so I think that it’s a really, really good approach. And it’s, it’s funny to have read that in a book, tried it and had it work is a very humbling moment for me because I, I, you know, at this point, I was like, trying to figure out how to lead this team that I’d thrown together. And, you know, unrealistic timeline, it’s like part of the the funny part is, when you don’t know that that’s an unrealistic timeline. And you think that that’s reasonable. It kind of changes your approach. Right? You go into it with the assumption that it can be done. And I think that my ignorance helped me more than like, If I’d known what I was being asked to do, I think that I would have collapsed in despair.

Vlad G 1:02:14
As a matter of fact, it’s a it’s a known fact that it’s that’s the way it works. I remember when I was a kid, I, as I said, I love science fiction. And since we are talking about science fiction, I think it’s wrong. To bring this up, there was a story I can’t remember because I read it in the legislative forum. There was a story about a couple of scientists and a military general inventing or or discovering somehow anti gravity, but having a hard time convincing anybody that it isn’t like the gravity, the it is actually real. Everybody thinks it’s a joke. Nobody takes them seriously. So what they did was They came up with a very specific toy where you put a toy on the on the string on you pull a string and it’s kind of like a Lucas magic, you know, this helicopter was flying and you whenever somebody wants to buy a toy, you show them the trick you show them that you’re actually presenting this with a black thread against the black background. So nobody can actually see that this is as you say, they think it’s, you know, magic you you wave your hands and the helicopter flies. But the real trick behind the trick was that the thickness of the thread was specifically calibrated so that if you don’t turn on that anti gravity device, the thread would break it would it would tear apart and the air. The helicopter would not fly. And they sold. I think his story goes that they sold about 20 or 30 prototypes and the specifically targeted people with scientific background and people who were curious enough so that when they tried to show this to their kids and they would think I mean come on it’s in line right it’s on his hands on the line so I don’t have to turn on the the the power on the toy to make it fly. It will break and they will start asking questions. Wait a second if that’s the trick, if I had just have to pull on the line on the on the thread and it will fly, why does it break when I don’t turn on the toy, but that’s the break when I do turn on the door and that curiosity moment should kind of sparkle the their discussion or their you know, investigation and so what what is going on with this story, this is not right. And it’s kind of it’s kind of how things work in life. You You get to curious and Get things get things. Yes, complex things get complicated. All right. Yeah. Is there anything else? Is there another episode of this has fiction that we need to talk and I’m, I’m looking at the time and your timeline. So if there’s anything you want to do anything else you want to share, by all means,

Fouzan 1:05:23
I would say, let’s talk a little bit about like the pitching side of it, right? Because we did something really, really unusual in that. We walked into a room of investors that we’d sort of gathered for a little conference. And we’ve done our homework. So we’ve chosen some people that we knew were interested in brain things right. So that historically had either expressed interest in interviews or in some of the companies that they had previously funded and so on and so forth. Right. But what what’s really unusual is that we managed to fund the company fully for next decade on our first try, and that doesn’t happen, like that doesn’t happen. I’ve been told multiple times that that’s a statistical anomaly and liked by other VCs. And by some very, very, very amazingly talented people in the field. They’re just like, how did you do it? And

I want to maybe talk about why and how. Because maybe people will find that valuable. I don’t know. So, I think that one of the biggest things is that it stems from like, my love of Steve Jobs as like a younger kid. I am an apple fan. I’m sorry if anyone isn’t. But like,

Vlad G 1:06:49
that’s okay. I told you. We’ve already agreed to disagree. I’m actually not a biggest fan of Apple I am interested in I have a single Apple device in my house.

Fouzan 1:07:00
I’m surrounded by them right now, actually.

Vlad G 1:07:03
But that’s okay.

Fouzan 1:07:05
You know, that’s the traits part of part of this is disagreeing. Yep, absolutely. And I think one of the things that I found really interesting about the way that Steve Jobs presented products is that he would demo things and try and delight the people in the audience. And this is what I mean. But like when I say give the outline, like, Don’t show and tell, like demo and delight, right. And that’s really the key here is that all the stuff that we did on the early end, the things I was talking about making the design friendly and usable, and sort of compressing what was like a tangle of wires on a workbench and a bunch of circuit boards, into like a relatively compact product and friendly looking design. Now, it was also that we could do live demos with the VCs. And that’s a crazy thing to do. Because Usually you don’t want to do live demos, and you don’t want to do it in a really risky environment, like it’s better to show results, or it’s better to like, talk about a things show some videos, and that’s kind of what they were expecting when we walked into the room.

What they weren’t expecting is us like Skyping in some of our engineers, like in the middle of our product talk, and we had about an hour to pitch to them, and it was myself and the founder. And some of our team is remote. And we like, you know, open these cases and pulled out these helmets and I said, Does anyone want to give it a try? And I got a lot of stares and a lot of people looking around at each other. And so I said, It’s okay, I’ll go first and sat down and you know, my, my colleague, CEO and boss put it on me and we started playing around with that. I was able to show them that it was like really comfortable and that I wasn’t in pain and I could like talk through like to them throughout that, like 10 minute scan. And so I was like presenting slides and everything. And at the end of it, we like, switched over. And our engineers like pulled up the data. And we Skyped him in and we said, Hey, like, this is what my brain looks like, when I’m pitching something. And Do any of you want to find out what your brains look like right now. And we can maybe make some predictions about what you what you were doing. And so we had a couple volunteers. And I’ll never forget, like when I was able to turn to one of them. And I said, from the data, it looks like you meditated this morning. And they just kind of gave me this look like Wait, what? And what they didn’t know is that while we’ve been working with all these researchers in the background with like demo versions of the device, they’d started exploring, like, what does your brain actually look like? When you meditate after a while, and when you like have a lot of coffee or when you’re exhausted and Like what pathways are more and more or less prominent, we’d started, like we started as a team to like, put together that you can actually, like, clean some of this information. And so, the like, we freaked people out because we were able to tell them things about their day or like the state of their brain that they didn’t think we could, we could glean.

Vlad G 1:10:22
So I’m sorry to interrupt. So is that does that if that sounds like you guys have sort of a library of patterns? Yes, we did. You bus you. Okay. All right. So there’s a lot of patterns. Okay. Make sense? I’m sorry. Please go on.

Fouzan 1:10:36
No. And so. And yes, it’s really important to have libraries, because like, when you do research, you want to build like standard sets of data. So we took a bunch of healthy brains and had people like doing these scans. And we were, you know, using that feedback to tweak the product and make it better in some ways. But interestingly, or more interestingly, was like, those standards helped us then pitch because it’s like Here’s a product, here’s its potential, we’re using it, you can actually see the technology at work. But we need money to get it through the FDA process to use it medically, because it has all these other uses and potentials

for good and they understood like they inherently understood, okay, this is a thing that’s valuable, and, you know, has a market and a use case. And it might take a long time to get there, because that process is long and expensive, but that it might be worth taking a chance on because like, VCs are a type of customer and their product is a semi ready idea with a strong likelihood of good ROI. And that’s what they want. They want potential and ROI.

And so that’s how,

yeah, that’s my advice for pitching from someone who has pitched a couple times and has helped fund things. I

Vlad G 1:12:00
totally agree with you. And in my defense, I don’t like Apple products. I do like Apple’s presentations I as a matter of fact, I did a few presentations on. We launched a couple of products in my last company. It’s an enterprise software. So we launched the product that I was managing. Before I started going on assignments. We launched it first time in 2018. And we launched to be 2019. So I was there in three or four conferences. I can remember exactly how many there were doing the presentation, doing live demos, and talking to people about a product about the value proposition. Not investors, but people who actually have the power to either influence or make the decision to buy Of course and I completely agree with them when delight Especially when I just started actively doing it. One thing I’ve immediately learned is don’t don’t talk show a dog show. Don’t Don’t talk and tell, show and tell. And if you can make it look like magic, it’s even better. And this is what you guys did. And I love it. About the way you demo delight. Unfortunately, not every product looks like science fiction. But you can throw in a little magic here and there. Right, right. And that’s, yeah, that’s, that’s that’s the approach I’m trying to take. And this approach, I’m trying to coach and whenever whenever I talk about product management, some of the things you don’t have to talk them talk a lot about your product you have to show, hey, this is this is what this is what the magic happens. This is what it look like. And it’s absolutely it sweeps people off their feet. So that’s that that that is great. I’m glad we’re on the same page there.

Fouzan 1:14:01
Yeah, absolutely. And it’s like, you know, it’s a human thing, like humans like stories and they like surprise, and they like to engage with more than one sense. And that’s really what it comes down to. Right? Like, it’s totally different to like look at a slide and see a video of a thing. And to like, put it on your head, and like have someone tell you something about yourself that you didn’t expect them to know because he just

Vlad G 1:14:27
funny you mentioned that you need this story. So someone asked me this question earlier today. And I want to turn this around and ask you as as a person in the product management role, but your role seem to be completely different, different from I’m sorry, maybe not completely different, but significantly different from product management as we see it on a regular software product. What do you say are the top three qualities of a good product man

Fouzan 1:15:02
That’s an interesting question. So, top three qualities I would say. One is being really, really adaptive and willing to understand that what you’re doing is you’re not standing on a surface but on like shifting and waving sand. And that you need to learn to pivot immediately, when things don’t seem to be going the way they are. Or to understand that sometimes when the sand is shifting, the direction you’re going is the correct one. And despite the forces that might try to sway you, you have to be willing to move forward in the direction that you think is correct. And that there is a real art to balancing those two sides. I would say your second trait should be trusting your teams. A lot of the problems that we were able to solve so quickly and so cheaply is because I trusted The teams that I was working with, where it was like, I know that you’re an engineer, and you do electrical stuff. And if you tell me this is good, and I asked a couple of questions and understand the problem, I should trust you. And we should move forward with that. And that it’s better to do that than to introduce tension. Because if it doesn’t work, or if the person working on that solution thinks it doesn’t work, as long as you leave room for them to turn around and tell you, Hey, I don’t think this is working, we should change things up. If that trust is still there, you will be on board with that as well. Like that they can understand and figure out when things don’t go their way. And I would say number three, you have to really have empathy for everyone around you, whether it’s the teams, you’re leading the teams that you’re working with the VCs you’re pitching to. Now I really, really see empathy. As a professional tool, I think humans are emotional creatures. And we respond to that. emotion. And it’s like one of the things that we did when we were choosing people to pitch to is that we specifically did our research on what they invested in. But also, we tried to watch as much footage of them interacting with other people to try and gauge who they were emotionally, and picked ones that we specifically would really vibe with. And that would vibe with each other. And so when we put everyone in a room together, now we minimize the awkwardness and just really like it, it felt like a bunch of people who were celebrating and enjoying this whole process, and they were all interested in the same things or they at least had some things in common. And that really changes the game. Because what you don’t want is to be there with a board or upset or just annoyed person who’s like, you know, this is like the sixth pitch. And of the day, and this is like the slide set that they’re seeing that they’ve seen five times over. And what they’re seeing is holes in the business plan and holes in like the product or the process or this is exactly what they’ve seen before. And I think that it’s really important to understand the emotional spectrum of every person that you work with. Because it really helps people connect and work with each other and that like whether that’s internally or externally. And so yeah, does that. Well,

Vlad G 1:18:42
thank you. First of all, that’s amazing. That that’s a great pitch for, for empathy. I. This is a new way I think. I’m going to start collecting these and probably publish it as a separate episode, all the qualities that people Think that product manager has to have for so far, we’ve had three or four answers to that. Adaptive or flexible or responsive seemed to be the trend. So that’s kind of on top of everybody’s list. Everything else. Everybody has has their own. Everybody has something else that they feel. Yeah. So we’re almost at a time actually, we’re out of time. But we need to wrap up somehow. And believe me, I don’t want to switch off this. This sci fi show I want more. So hopefully it will have you will have you one more time on this episode on on this podcast. Maybe even with my co host, she’ll, she’ll be able to pull more stuff out of you. So let me let me turn the tables a little bit, as promised, and ask you if you have any questions for me in the hallway I can answer them today without going and so, you know, 20 minutes of of deliberation. I’m sure. I’m

Fouzan 1:20:08
actually curious. So you talked a little bit about the EMR stuff that you worked on. And I want to know, like, when you were in that role, what were some of the like early challenges, especially with, I guess, I would say, like upper management and how you were able to like, handle some of the demands of the business side of things and the insurance side of things because, I mean, I’m sure that when you were pitching EMR software, you’re pitching it to hospitals and insurance companies and sort of all together in that realm.

Vlad G 1:20:46
Let me start from the from the end and work backwards. The times that I was working with EMR software, I was not working on the with the independent team. It’s It was a part of that The initiative within within the company. So it was internal software. It was several different companies. So we didn’t pitch it to anyone. We had internal customers who had a specific need. And we developed software based on the needs that we’ve identified in almost all the cases, except for one, it was refactoring or building the legacy software in one way or another. To two cases, or it was a one time it was the acquisition and we just replaced the existing software that was extremely clunky, extremely horrible, with something that looked and feel that felt better. And in other case, the way way up. This isn’t was made to replace a whole stack of applications with a single system single data store, single analytics suite and That thing that I keep calling clinical viewer as an EMR that allows you to see, it kind of transcended the boundaries that existed before between the inpatient outpatient data, things that are coming in from outside labs and feeds, and kind of presented everything in a single point of view, single point of reference. So, and the reason for that was because there’s too many data sources, it was unrealistic to keep incorporating them. The the health system, the healthcare system that I was working for, they kept acquiring, merging, splitting, re merging with other hospitals, and having customization work done on each of the systems to bring them all together. didn’t make any sense. So the decision was made pretty high up to kind of let’s build this one data store that’s going to feed off of everything that we ever going to have. So now you you’re replacing the problem of customizing everything to work together with an already solved problem, how do we feed the data from the system that we just got into into the existing data store? So it became the problem of data normalization rather than data acquisition.

Fouzan 1:23:17
That’s fascinating. So essentially, you you turn the problem around completely and said, okay, no, no, we will just put the data centrally, and anyone who needs it can access it, and display it in a way that they need to and standardize that sort of process of accessing.

Vlad G 1:23:34
Correct The only correction is it was not it was not me who made that decision. But yes, that was that’s what I don’t want to take credit for, for this genius move. I just want to make sure we’re clear on that. But yeah, that’s that’s what happened and my responsibility was building the actual front end, the customer facing front end for those systems. That’s fascinating.

Fouzan 1:23:55
So when you were working on I guess, the the front end of that or the customer facing side of that. How did you sort of factor in physicians needs and nurses needs? And like some of that other stuff like what? What led to like what did your data acquisition or I guess like customer intelligence looked like, I don’t know if that’s the right term.

Vlad G 1:24:23
That this the right term is just the the time when and and the environment that I was in, was not that data heavy as it was not, you know, 2019 to 2020. When we make data driven decisions and data first and do things later. A lot of this was driven by what we call product management, Gods feeling based on things and this is this is kind of my ideology. When you don’t have the data, you still need some kind of Truth, some kind of a source to base your decisions on, you can’t just come in and say, Okay, we’re doing this because I said, so just you know, I’m the captain of the ship make it so. And the reason I’m saying that is because I’ve seen those issues and decisions made by people who have been in the industry for 2025 years, and 90% of their decisions were wrong. Yeah, and it was a huge waste. So it was still worth with subject matter experts. We still worked with whoever was willing to talk to us. And the the operational framework was, talk to as many people as possible, get those people’s best gut feeling of what is right. And start experimenting, start building things. So you can test drive them as soon as possible. And this was one of those things when we’ve introduced rapid application development for work. So we’re not even quoting things. We’re kind of using a website builder. Think of it this way, like, and we’ve, yeah. And we built a system of one system, another system, another system using that Brad solution, so that we can bounce them off of real users as see what their feedback is. Luckily for us, the feedback was positive, but not always, and in many cases, cubicles neutral. As Then, why are you wasting time when this rain was good? It was good before. But it’s kind of like one of my most favorite things to relate to. Everybody’s talking about data driven decisions, because we can collect a lot of data now, and there’s a way to do that. But with the enterprise software with b2b clients with cases like this, that’s not that bad. data, there’s not that there’s not enough data to make you feel very slow strongly about the decision that you’re making. And that’s where you need to be, I guess be smart about it.

Fouzan 1:27:11
Yeah, no, that’s it’s interesting. You bring that up, because it’s one thing that I’ve sort of seen as I’ve jumped into other pm roles at other companies and just sort of like thought about how to handle some of the problems they’re having is that people seem to have this obsession with data, more than they do with asking the right questions or testing in the right manner. And it comes down to I think, quantity and quality problem, where it’s like, all the data in the world doesn’t help you if it’s the wrong kind of data. And

Vlad G 1:27:39
yes, I agree with that. Thank you.

Fouzan 1:27:43
And I just like, you know, maybe I find that really wasteful that people spend so many resources on acquiring data without even like thinking about the questions and the experimental design. And I would encourage people to like if you’re a PM, and those types of roles like maybe consider pulling in a couple of academics. Maybe they’re interns that work for you for a semester or two. But have them design experiments because they’re in an environment that encourages good experimental design. And if they have a research background, like they’ll have a better idea of like the right questions to ask sometimes.

Vlad G 1:28:24
Interesting, I didn’t think about the academia, because in the world that I live in, we’re probably very disconnected from from the academia, at least the way I remember, though, the way I think about it.

Fouzan 1:28:39
It’s, it’s quite common, right? Like businesses generally disconnected from academia. I mean, they’re seen as polar opposites. But I think that there’s like with any thing that’s very different. There’s usually some overlap and some difference in opinion and experience that can be valuable if applied correctly. Cool.

Vlad G 1:29:00
Thank you that that’s, that is interesting. That’s something for me too. as a as a product manager with a lot of experience in different fields that are not connected to academia it maybe it’s time for me to start rethinking that and start arguing that hey, you know, this is something where we can use people with academia background, maybe there’s, there’s value in that.

Fouzan 1:29:24
So thank you. That’s, that’s useful. Thank you. This has been incredibly fun. I really enjoyed being able to sit here and like talk to you about this and really just kind of get through this blizzard of different topics and touch on a bunch of different things. And I hope we get to do this again.

Vlad G 1:29:41
Oh, yeah, definitely. I definitely hope I’ll I’ll see the sequel to this amazing science fiction show. I am I am very thrilled. I am trying to stay up to date with current trends and discoveries and things that are happening all across different industries, but This is this is way too cool for that. Thank you for being my guest and thank you for being so thorough with your story. I definitely hope we’ll we’ll hear more from you and I think it’s worth bringing you back in a while and see how you guys progressed and maybe there’s some new stories that you can share with us.

Fouzan 1:30:23
Absolutely. Glad it’s been. It’s been a pleasure. Thank you.

Vlad G 1:30:26
All right. Thank you. It was on. Take care. You’ve been listening to Real World Product Management and I’ll be your host blood Grubman. Until next time!

Real World Product Management – Episode 05

In this episode, Irina and I are talking with Kyma – a seasoned Business Analyst who has a lot of interesting insight into BA’s world and how BAs are interacting with Product Managers. Additionally, Kyma brings a lot of questions that most BAs are asking but are having a hard time finding answers about product management. 

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 two people on the line with me right now. I have Irina and Kim. Can you ladies please introduce yourself? Irina, why don’t you go first?

Iryna M 0:29
Sure. Welcome back. I’m happy to be with you. Once again. We’re going to have quite an interesting topic today, where I’m going to represent product management era mostly and passing the word to Kim, who will be talking from beside today.

Kima 0:44
Hi, everyone. My name is Kima. I’m promote Mati and I’ve been in business analysis for the past eight years, quite a long time. And so yeah, I’ll be happy to talk about my experience in business analysis.

Vlad G 0:57
Just for those for those folks who are not thinking was the former Soviet Union geography? Can you please tell us where do Mati is?

Kima 1:05
Sure, um, what is former capital of Kazakhstan? And for those of you who don’t know, Kazakhstan, it’s between Russia and China does like it’s a big country.

Iryna M 1:16
Yeah. So Kima is closer to me than to Vlad, I guess. I’m located in Minsk Belarus.

Vlad G 1:23
Yeah. Awesome. Thank you, ladies. Alright, so as we’ve just heard, we are doing BA versus product management. And first obvious question that I would like to put on the table is what are the differences between a BA in product management and for the record, I did not have any ba background. They never played a role of ba ever. I was a software developer that I went through project management that was that felt very much like product management because of stuff I ended up doing and I became a product manager. So I know Irina has a A lot of the background I know Kima has a lot of BA background. And now that we’re all here, let’s talk about the differences between what BA is doing versus with product managers doing

Kima 2:10
Yeah, so um, maybe I can start with the definition of business analysis and I’m sure Irina will well saw at Thompson here. So business analyst in the like, previous when I was starting was definition was like the bridge between the customer and the team. And if you look at the BA book, business body of knowledge definition, the last version, it’s more defined like business analyst is a catalyst for change enables a change in the organization by defining the needs and bring the value to the customer. So this is pretty much it. Basically, business analyst is the person who supports the change and the person who communicates both with a product development or project development team and the customer.

Iryna M 2:55
And if we’re just go straight towards by Wikipedia and Product Management definition there were there, you would see that usually project managers are the ones who are responsible or at least orchestrating product development as the process together with the business business justification planning for requesting any kind of verification validation and users can actions. Sometimes it’s also involved pricing financial aspects of product development part. And of course for managers are the ones who are supports an anti orchestrated product launch as well as a new type of marketing activities, important sales activities and also sometimes helping to establish support model for the product. So this is what you would see for product management. I was saying that from their perspective over the past experience, product managers tend to be more on the business side and and business analysts. tend to be more between business and technology side technology side, but I would say that BAs and usually much more technology savvy, technology aware people comparing to product managers.

Vlad G 4:15
Funny, you brought that up because my my experience and that’s why I love having people with different approaches and different mindsets. Part of my experience was introducing change to organizations. So I was as a product manager, I was the agent of change, not not be a CPAs were more of to tell us what to do and we’ll figure out the requirements for it. And a lot of things a lot of times as a product manager, I not I was technically savvy, I was sometimes even more technically savvy than vas and I was able to get into nitty gritty details of software systems by being more technically savvy, and then explaining to them what the what the thing is. And the last part to again, back to what you were saying began as a product manager, I was the connection between the business and delivery, I was the exactly in the place where you’re putting the BA in, in this in this layout. So it’s funny how they overlap, how the positions overlap, or how the roles overlap and different organizations. Yeah, I think there’s I think there’s a conflict in there somewhere.

Kima 5:33
Yeah, you know, I think it’s, as they say, it all depends. But once I’ve heard this interesting thought, that product manager is more outward or externally bound looking. While business analyst is more inward looking, what it means. It means that product manager is involved with marketing research, who is I know users analyses and so forth, like benchmarking While business analysts might do this work, business analysts is more concentrated on the internal processes within the organization. So it might be one of the differences, but I do agree there might be some overlap between the two.

Iryna M 6:15
Yeah, and probably you know, that’s very true. That depends because if we go to the market right now and take a look who’s been called as a business analyst, you definitely would see that such role and such title exists in many other areas outside of software development, and the meaning for that would be different. So that probably, you know the first reason one of the reasons why conflict race. I actually quite aligned was keema mentioned about being extremely fees for product managers who versus being internally faced for business and Elise, and but I think coming back to your example, probably you’re just paying most of the roles. You’re just never in You got here we’re doing these, which has actually happened in quite a lot. Because many people who are looking for product managers to D, they actually put quite a number of their responsibilities in the worker description, the position description, that actually should be part of the responsibilities. The reality is, though, that not every company has a business, at least our business analysts a billable hour or separate competence, who has a separate department or whatever is needed. And still, someone has to work with the requirements. Someone has to be a bridge between delivery and business side. And if you don’t have such people as these assemblies, there’s nothing else to do except to have Product Manager to, uh, to ask a product manager to be such person. So yeah, that’s actually happening quite a lot. And I think more conflicts coming into play right now with product owner role being added because now You can have a setup where you have Product Manager, product owner, sometimes even proxy product owner, and business analyst. So that becomes even more tricky, I would say. Yeah.

Kima 8:15
That’s gonna be a lot of fun. And now, you know, I want us to think about this case when, okay, well, I’ll say I’m saying and I think that you disagree and we have started in discussion right. Product Manager is again more concentrated on the product, like how this product is placed on the market, how this product brings a value and so forth. While product owner is again, operates within the company, Product Manager might not be necessarily thinking about the company itself while the focus is on the product. While product owner is like at least in my you know, my perspective, from my perspective is a person who operates from the Company interests. What do you think?

Vlad G 9:04
I Yes, you were right I would disagree. I think product managers very concerned and this is very company focused, because the goal of each product and I keep stressing this and pretty much any dialogue I have around product management competency or product product mindset, overall, the idea is that product is not does not exist in a vacuum product is not built just because we can product is built to answer and result and solve for customers needs. So, there’s a customer problem customer issue and the product is being built as a response to that there for sure. Yeah, right. And therefore, product or product manager is very concerned with the internal view because that solves a customer problem for the company for this particular companies will use working with Additionally, there are there are aspects variables, Part of the responsibilities of their part of the scope of Product Manager, for example, connecting with delivery connecting with or setting up support model, even legal, then all these all these parts, all these items are internally facing. So yes, absolutely. As a product manager, I am responsible for taking the product to the market, but it’s one of one of those one of those nightmares of keep haunting me. These imagine, I don’t know 17th and 18th century army, and you have a general on the, you know, on the white horse in front of the army and he goes less attack he goes forward, but nobody follows. He’s just all alone. In front of in front of the enemy army, and everybody’s like, okay, dude, the guy decided to take a walk, that’s fine. So that’s, that’s kind of this kind of a picture that you paid for on a successful product manager. So you need to make sure Or your team, the company behind you is following you. And that’s why you still have to be company faced as well.

Iryna M 11:07
Just to, just to add to what Vlad mentioned, actually, I saw several cases when compensation and bonuses and all of that, for product managers is highly tied to the results of the products that they’re leading. So with that you actually has to be a company for Christmas as well, and especially with business and business goals, focus and business focus person. You know, I think what you mentioned about being extraordinarily Paul close to me, versus internally focused, that’s not exactly tied to the area or for specific VCs or which goals you’re trying to achieve, but they’re mostly tied to the activities that are fulfilling Gordy and in my mind The main difference between all these various roles would be the percentage of the time that you’re spending on one type of activities versus others. Because I actually did seen that quite a number of cases when product owners were part of the marketing activities as well or part of the sales features. And the same is very true for business analysts, especially if you would like to grow this these people into the product managers later on. I think that the question is, how much time should you dedicate to do the sales features or how much time business analysts should DK to help marketing department with the materials development and so on? So again, to me, the main difference who would be not only the focus but also percentage of the time that you’re spending on each of these various areas and activities?

Kima 12:51
And you know, then, like, I’m interested to hear Vlad’s opinion on the product owner versus product manager role. What is the difference then? From your prospecive?

Vlad G 13:03
That’s one of my favorite topics.

Iryna M 13:06

Kima 13:08
Let’s start.

Vlad G 13:10
Yes, there’s a there’s a canned definition I always provide, but it’s mostly for people who are not involved in product development. And that is it sounds something like product owners are is a role within agile team they sit in the team and they are teams external interface the product owner is the person or or a cook conductor that connects the team to the outside world because one of the responsibilities of the product owner is to shield the team from all the external things and make them focus on actual development and they are responsible for bringing in the new requirements are new once and asks then making sure team understands them and provides things back to the outside world. Whereas the product manager is someone in the more strategic level, who sees a big picture who sees the whole product or product portfolio. And effectively he tells product owners what needs to be done. And and the lingo here is pretty important. We’re this product manager, we’re not telling them how to do things. We’re not telling them what we want to do. We tell me what needs to be done. And then the rest is up to them how they want to figure it out.

Iryna M 14:31
Yeah, so I kind of would like to mirror what Vlad was saying about product owner and product management. And the reason for that is because we predict management usually that’s supposed to be a career path, you all can become a senior product manager or director product management. But for product owner, we don’t have such saying as Senior Product Owner, and that sounds obvious for most of us, and that’s actually happening especially because you We treat product owner just as a role. So, yeah, you can be titled even as a software engineer or Scrum Master whatever. And at the same time to be oriented, business oriented person and drive the team in the role of product holder. So disregarded the fact that you actually can hire a product owner in person for such title to de steal, most of us would see that just as a role. And partially that’s coming from that reason in that this came from Scrum where a product owner was just as a role that can be played by anybody similar to Scrum Master. So what I wanted to share here that when we were trying to find this border between Product Manager and product owner, so, you know, what’s this period of time was the flag or criteria that would let you know that you Not on the product or owner any longer, but you are now ready to become a product manager. Right? So we were looking at these and realized that one of such criteria A can be the timescale on which you will work in. Yeah, and on which you’re looking at your product. So usually product owner is the one who really defines how you’re doing how you’re going to achieve a particular goal as well as mentioned, but you’re doing that on a shorter timescale. So usually you have like a release or couple of releases in front of you, which kind of defined goals for those who you know what you’re trying to achieve. And most probably, you’re looking for the next three, six, probably nine months. You know, sometimes it can be up to 12 months, but I would say really rarely happening. And as a product owner, you have those goals kind of given to you. You don’t have the exact path Through these forests, how you’re going to achieve those goals, but you know what you need to do. And you have expected timeline for these. And again, this is something that’s a little bit more tactical, because if these goals were set for you, as a project manager, you actually the one who is working on more strategic level. So you are trying to define those goals for the next 12 months and longer in the role of Product Manager. And with that, you have to do all this external feast activities that we discussed before. And product owners just the one who’s helping you to achieve certain goals that were set by your so you’re the older of those goals, that laser are being communicated to product owners that lead to being the cheat by the entire team. So this is how we would treat that. And this is how we would do this limitation or separation between protocol and their product manager. It’s the scale and The timeframe and of course, percentage, as I said, time that you’re spending, dealing with markets and sales support and so on.

Vlad G 18:10
Make sense, I just want to throw in a bit of a curveball here. And you will see this in the marketplace people are hiring product owners. And by product owners, they mean portfolio product portfolio managers, portfolio managers or liat product line managers. So they’re really high level senior position and they understand ownership in the direct not a product owner not as an agile role or not a scrum role, but more of real ownership, you all you will own this product line or this product portfolio. And you will make all the decisions and you will be responsible for financial results. Basically, back back to what I was saying, where performance is tied into the product performance or portfolio performance. That’s exactly what they meant. So and that’s that That’s kind of a thing that I keep seeing. I see this last. Now, not these days, but I’ve seen this pretty often. So I think it’s so relevant. And whenever you talk about product ownership, you need to be very careful, because not every organization is on the same maturity level. And some organizations are pretty new and they are adopting good things. Some organizations are, again, not very mature, pretty new to the whole product mindset, but they’re not adopting the right methodologies or right approach. And they would call like, anybody who does anything with a product. Oh, there are the owners, so the product owners, right. It throws more monkey wrenches into the whole understanding. But I think what Irina said makes sense, in most of the cases, most of the scenarios,

Kima 19:49
okay, yeah, that’s interesting.

Iryna M 19:51
So, yeah, so now with that, Kimbat, Kima, a question to you, from your experience, who Don’t think you or actually it should show me putters in different way. Who would you prefer to have on your team isn’t a product manager product owner? And why?

Kima 20:11
I would say that, in the ideal scenario, based on the decision you provided, we would have both. Because again, if it’s an agile team, it’s of course, we need to have product owner, and then the product manager who’s looking like the, you know, as we said, outbound. So I wouldn’t say that it’s kind of if there is no if there’s no choice if and if I had to choose. I think the product manager role is important, because in some cases, business analysts can perform the role of the product owner.

But given the choice, I would prefer to have both

Iryna M 20:51
sounds great, unfortunately, this is no it was happier. The real live vigorous, not every company has a budget for all these roles, and not every company has tend to buy into the deck many people and you know what the wart all this people going to be doing? But yeah, I would agree with you that it’s great when you have ever wanted and you have clear in detail over their responsibilities.

Kima 21:15
Yeah. And and you know

yes sorry, it just I have a question to you guys. So we have business analyst, product owner and Product Manager right and what do you think would be the career path for business analyst to go further so is it more like again I understand that there might be a choice and business analyst might choose, but where you are because you guys have this product manager perspective right. And maybe you have this view where business analyst can grow where he would fit better is it product management or product ownership?

Iryna M 21:59
You Now I would say that it can be both and not only those who are of course, saying that as a business analyst you can easily grow into product manager that would be straightforward and easy answer here. The reality is though, I saw different cases happening in life and sometimes business analysts realizing that they would like to be more on the technology side and a little bit more process oriented. So they’re not that business oriented, but rather process oriented. Again, they feel really comfortable in administrating the protests, orchestrating all of that, and with that, they are sometimes switch into their role of Delivery Manager. That’s, I would say, like, probably not happening a lot. But sometimes I saw that, especially if you live to be the you know, this kind of the manager who is working with the team and kind of managing the team, that staff have in the past so that you can take as a business So is in nazzer, Korea past that’s happened in a much more often is, is tapped over to consultancy and be in a business consultant. If you’re a great business analyst, you most probably have enough of knowledge in a particular domain in the particular sphere. And if you’re developing yourself, our inter the next step in Korea, whatever it is, it might not be decided at that point. But you’re ready to work your region looking outside of only one company that you’re working with. And with that, your understanding the word is happening on the market, what what are the actual trends, what actually can happen with their with your competitors in the near future. So you’re getting more and more insights from the from the market side and at certain point of time, you can realize that this is information that you can sell together with your experience and your impulse to business consultancy and product management of course, this is a possibility to grow there. I would say you know coming back to your question between the product owner shape and product management the way how are usually the position that is actually see as a business analyst in terms of the career paths, but try to take on a role of product owner and that’s kind of coming back to our previous conversation that product ownership is mostly a role not like a career paths right. So, you can, you can try that you can be you can quite easily take yourself into the position of proxy for the folder and then product or that is usually, again, fairly quickly and easily doable for a nice skilled business analyst. And then if you feel like this is the right path, if you feel like this is the job that you would like to do you know, deal with all this paratis and business conflicts and deal with the business objectives and so on, then you’re definitely moving to the next stage in your career reaches product management. So I would say product ownership is a great step between business analysis and business analysis and product management. So this is how I would position that.

Kima 25:18
Okay, that’s interesting. Thank you. And the question to Vlad, it’s a bit maybe controversial question. But still, do you think that product manager can it’s the other way around when Product Manager becomes a business analyst?

Vlad G 25:34
I haven’t seen that happening. And I think I know why. Uh huh. first product managers unless this is not a career path, unless this is a retirement path. Product Managers deal with a lot of a lot more than ba does, at least from my perspective, I’m yet to see a single VA taking product to the market. product managers do this all the time. may have seen the A’s helping with marketing, legal interfacing with delivery, but they’re not the orchestrator. They are not the responsible of the responsible party for all of these activities. And I don’t think Unless Unless there’s a there’s a, you know, the person who spent 1015 years in product management role and then they decided, you know what, this is overwhelming. I want to focus on just one part of this, just figuring things out. I actually can see myself doing it. Okay. In 510 years, you know, what I really don’t enjoy talking to legal anymore, which is not true. I do. But, you know, 1015 years, you know, it’s the same thing all over, standing up, support organizations, the same thing all over again to marketing. It’s the same thing all over. I am bored. Let me go and do something really exciting. And that is that exciting part is figuring things out as a business analyst, or producing going down into nitty gritty details of systems and given the experience that I would have by that and given the expertise that we have, by that it’s probably would be a pretty interesting, pretty interesting role and pretty interesting position to be in. So theoretically, you know, as as, as we all know, theoretically nothing has nothing has zero probability. And so small chance and it’s probably will happen eventually some of the people, but not as a general rule, not as a career development, kind of like a change of a career or, you know, path on the retirement. It’s just, you know, I just want to do things for fun.

Kima 27:43
Yeah, sure.

Iryna M 27:43
And Kima kinda to be on the same topic. You know, with all these new roles, product ownership, being that and being all over the place like to the more and more companies are asking for a product owner to be a part of the team arizer for business and ways to be a part of this team. Do you think that will ever get to the point when business analysts is not needed any longer? So there is a product owner, Product Manager, and basically all of the activities that be doing today, between those two. So what do you think is the future for business? Always?

Kima 28:18
Yeah, that’s a good question. And you know, here, I think there are several things. The first thing is that business analyst has this specific activity. And as let’s say, this is quite, you know, I would say deep and focused on kind of analyzing the requirements and understanding the business need, focusing on the business value. So this is quite, you know, focused activity. So, I think in this activity, at least from my perspective, it will never be extinct. You know, while product management is indeed is has wider, things like wider scope of things. I believe that product manager will always need support a business analyst how Unless there is a kind of, I don’t know, maybe to some small product and product manager can perform both things like business analysis and Product Manager. But I do believe that product management, business analysis will always be needed. And as you said, Actually, I agree with you that again, I, I didn’t know is it the world changing or is just in my career, I’m changing my perspective. But what I see that when I was a middle business analyst or junior business analyst, I was more focused on the lower level of, you know, requirements. So I was more into functional requirements, analyzing the details, being really the breach with between the customer and the team, and just, you know, kind of handing over their requirements with right now, I do see the role changing, but I think it’s more to do with my career path, that I have more perspective and now it’s more focused on the business value, which would bring. So right now I think business analysis might be indeed, heading towards consulting, when you can really see when you’re, you know, when you’re deep down into the domain, and you understand the business processes within the company within the customer, and you can indeed consult what would be the more efficient again, this is the second thing, which would, I would say, prevent of business analysis to be extinct. So answering your question, no, I don’t think that business analysis might be you know, just fully disappear after all.

Iryna M 30:38
I hope that it will not do though I I truly believe that there was enough before is for enough a word for all of these roles. Yeah. So I guess now we’re, we are getting to the point in the conversation, where we can start talking a little bit about the remote work, you know, in our world today. When we have number of offshore teams and pretty, every pretty everyone, the company has an offshore team. Always it’s a question of budgets, but it’s also a question of visibility. Which role would you have? Would you prefer to have on site being together with the client together with the business side together with the entire company, versus which role can see offshore and be closer to the offshore delivery team? So came up a perspective from your side on that. Where do you think the separation should be and if it should be at all?

Kima 31:45
Yeah, it’s a very good question. And actually, for the past four years, I to have this either side, I was working on site on the customer side on the customer premises, and two of the past years, I was working offshore so I can compare him Guess the news was working on site, of course is created, you always have the, you know, access to the stakeholders. You can basically if you build a good enough relationship

Iryna M 32:11
with somebody, yeah. Likely,

Kima 32:14
you can just walk into the room say, Hey, you know, what could you please clarify just need your five minutes and you know, it’s more opportunity, first of all to build their relationship with the customer to make them trust because I think it’s even from the psychological perspective when you see person every single day, you kind of trust him more, I guess. And second thing, see, of course, you can, you know, yeah, you can always go into any of the doors and ask anything. With the Having said that, I think there is there are disadvantages, for example, being always on site gives you always this, more of the business site. You know, you’re all Working on the business need business requirement business solution like you’re taking one perspective, while being offshore makes you more Caesar deliver Tim perspective probably I do know that there might be of course balance and you can find that. But working on site can be quiet. I wouldn’t say stressful, but you know, it makes you put on the spots. You’re always there. And well, well you when you’re short. Okay, I’m going to talk about the second part here. When you’re working remotely of site. Sometimes if you’re working the different time zones, you have only certain hours overlapping, right. And during those hours, you can work with a client and when you’re they are not there when the kind of stakeholders are, you know, they are sleeping or something they’re in different timezone. You have your time to focus on concentrate, and I think it is very important for business analysts not only to communicate with the stakeholders or with the team It’s very important for him to have his own time to do the analysis. That’s why they’re always called business analysis, you know, to understand the business, the main the business person is where the problem lies, what would be the best solution, understanding the business and so forth. So you do need that time. It all depends, of course. But all I’m saying that if you’re working on site, you might not need enough. You might not get enough of that time on your own while remote work can allow that. But I think there are a few important things working remote which might seem like little things, but they’re critical actually. First thing is constant communication. Because when you are working off site, you kind of again, you might focus more on the delivery team, on working on your analysis thing and so forth. While you might get you might lose, you know, focus on the customer. That’s why I always make sure that we have enough communication points with a client with a customer Sometimes, you know, your clients might say, Hey, you know what, I think it’s too often maybe we don’t need to talk that often so forth. But eventually, in my experience, all clients did agree at the end that it was good. So communication never hurts. So you need to actually put that communication point in your, in your agenda in your calendar. And then second thing is that, please do put your camera on, it might seem like a little thing. But I think that, you know, seeing the actual person instead of just static image might change the attitude. And of course, there are more tips, but this is what I found.

Vlad G 35:36
Interesting. I know I know things about camera and I’m not disagreeing about stuff coming from. Let’s put it this way. from past experience. Having a video chat is not always the most ideal situation, because people tend to do things When they especially when they’re deep into thinking or they’re kind of like go with a flow, they doing things that you may not want to see or, you know, you as a person may be doing things that you don’t want others to see. And it gets, it gets distracting. It gets very so instead of thinking of what you’re saying, I watch how you scratch your head every 15 15.5 seconds. And that’s, that’s distracting because I’m not focusing on the conversation. I’m focusing on things I’m looking at, through the camera. And in my past experience, I actually found myself preferring not to watch the video and if I’m on the call where people use video and I see live people I try to tune that out or overlap it with no one knows where to take my notes, so I don’t see their faces. Instead, I am focusing on what they’re saying. And focusing on taking notes of what important for me. That’s interesting.

Kima 37:01
Yeah, I get Yeah, it’s interesting, Vlad. And I think it depends on the which at which stage of the relationship you are with this client. Because I do agree that we know when you’ve seen this person for I don’t know, every single day for the past couple of years and probably don’t need to build this trust, and you can of course, switch of the video, although I do not do so even now. But on the other hand, if you’re at some early stages, you might want to switch on the video because, you know, it makes you more human. As you said, there might be some things which are not ideal and so forth, but it Yeah, it’s, it makes you vulnerable, and at the same time, it makes other person trust you at least Yeah, it’s, it’s my opinion.

Iryna M 37:44
I actually would fully agree with Kim over here, I would say that it heavily depends whether you know how the particular person looks on the vault. And from the past experience, you know, we have going to be company We’re here and we’re talking to many, many people. But then once we had that, like conference or in person event where you meet all of these people in person, all of the sudden, the tone of your messengers, even the tone of your emails, which might sound a little bit crazy, but really the tone of your email messages changes, once you know how this person looks. And once you know how this person behaves just then in real life, and even his creation of fees, it still changes how you would talk to this person.

Vlad G 38:38
Okay? I mean, it’s possible I I’m not disagreeing I’m offering a slightly different perspective on this. And I do agree that it helps. I’m just thinking, you know, sometimes it can get distracting.

Iryna M 38:53
You know, it’s probably a good topic for our next session. How would you make sure that there is enough attention Communication but at the same time not to be overburdened with the returns in your calendar and have time to work to do the actual work right? And then how would you have that many meters during the day with video but still have a break and still have still have this feeling that you’re not very tired of sitting straight forward in your chair all the days or all the meats has left your house? So problem that can be part of the next conversation

Vlad G 39:31
I mean, we definitely need to explore we definitely need to explore and given the current situation we definitely need to explore Yeah, how people think feel and how they manage this remote work with the cameras on and I I’ve seen a few stories different guy that want to go in deep into this but I’ve seen a few stories about remote work being tracked how you do their most remote work. Yeah, and not not all of them are pretty so full, full. Definitely. Nice to Florida.

Iryna M 40:01
Okay, so So coming back to the usual topic, Vlad, what’s what’s your perspective about remote work? You know, Kima was saying that yeah, you have advantages and disadvantages of being business analysts and being on site versus offshore. What do you think about product manager is possible at all to be a product manager and to be remote.

Vlad G 40:27
That’s a good question. Yes, I’ve been doing this for the past two years, full time and I’ve been doing this previous five ish seven ish years, part time, which is which means I have been a product manager with teams partially or completely remote or I was working from home or I was working from a remote location. So technically, I was remote and the team was on on the premise. It’s possible Ideally, yes, I want to see my clients, the people I work with. Not not us, but not necessarily the team I’m working with, not necessarily the delivery or legal or marketing. But I, in the ideal world, we’re all in the same place. But you know, we’re not in the ideal world ever. So it’s possible. It’s doable, it takes longer for my experience. And it takes longer to make things happen. Because first of all, because of this, casuals you only stick to the schedule, so you can’t have a conversation in the court or you can have a conversation, somebody else’s office. Hey, are you available? I have a couple of questions for you. You can however, have conversations over, I don’t know slack teams, whatever you guys are using. And that helps. Again, the problem is it’s not instantaneous. You have a crazy idea. You want to boss it off by someone but everybody’s in the meeting. And you pick a couple of people they’re not responding. So the your interest kind of dies. down, you switch over to other activities and by the time they respond, either you don’t remember what you want to ask or you don’t really care much about it anymore. And it’s like yeah, probably was not a good idea, nevermind and you lose momentum you lose traction. So, some things are definitely getting lost in translation. There are certain personal like, just like hearing that, just like you said, there are certain personal connection that you make with people and there are certain personal feeling that you get once you’ve acquainted with the person in real life. That is that is missing if you’re constantly remote. At the same time, maybe because you’re more formal. Maybe because your communications are easier easily tracked, as in you have emails, you have chat, you have notes, you have recordings of meetings, so it’s easier to go back to the conversation and see if you’ve missed anything. A lot of times in interpersonal you probably in somebody’s office, you want to discuss something, you get things done faster, but it’s hard to track them. And in my previous life that happened to me a lot, where I would occasionally pop into somebody else’s office, we discuss something, we resolve things in 15 minutes instead of three hours of meetings. And then I send out meeting notes. If I’m, if I remember to do that. And if I don’t, no one’s aware that this is what we’ve decided. And I’ve seen I’ve seen actually companies actually struggling because of that. They have conversations in place. They have certain decisions made in place and then they forget or maybe not to distribute, though there is also those conversations. So to me, it’s a blessing and the curse. The Blessing is that everything is easier tracked. The curse is that you don’t get that personal dodge. You may not even pick up certain letters language that is easier to understand for the other parties. So yeah, I think again, it’s a double edged sword.

Iryna M 44:10
Now from my perspective, I would say that the best case scenario would be for a team and have a product manager. So actually now from the requests that we’ve been processing so far, in most of the cases, it’s kind of requested that product manager would stay on side to gather with the business and closer to the clients versus product owner and business analysts to be closer to the delivery team beakers and fishes, the guys that to whom they should interact on a daily basis. And my personal best scenario would be for my team where they’re really close tied and personal connection between product owner and Product Manager. And you can jump with in your deer in these communication between them. These two guys and the importance of time, so you’re actually not losing these great idea that just came to your mind while you were in the shower, for example. And at the same time, you have a product manager who can popping into someone’s room and into someone’s office and just talk briefly about that really quickly. And then feel all this tension and political scenes and you know, all these little emotional details which are going on the sides. And then as a product owner, you’re kind of doing the same for the offer team, and for everyone who is actually seeing offshore and then you have this whole chain between your two how we’re doing in both of the sides, but that requires really close and really trusted relationships between these two guys. But to me, this is a path to success when you have remote and remote team and on site team. Yeah

Vlad G 46:01
Now that you mentioned it, I’m sorry, I just have to bring this up the story about my past experience, I had a distributed team, where we have people all over the United States, literally any place in the United States, we had a person we had seven or eight people team. And we had a person, each and every part of United States. And one of the people on my team was very serious, very uptight, very professional. I’m not even sure which other words to use to describe this person. Very official, everything down to the point, nothing special, nothing, you know, nothing outside of work. And at some point we have we were having a scrum trust, Scrum related conversation or something. And one of us, not me some other key member use the phrase from a very popular Saturday. shop and everybody related to that almost instantaneously. Everybody said, Oh, yes, I know what you mean. And it was very funny when that person very uptight person very serious, very professional. Nothing outside of the boundaries of work immediately became very relatable and Oh, yes, since you’ve seen this show, I’ve seen this show will we can connect another level that in my head at least broke some some of the walls around that person breaker raised? Yeah, yeah. Yeah. Well, the whole world would not have any Nice.

Iryna M 47:37
Yeah, that’s actually a great story. Okay. Um, so I guess we’re kind of a slight movement to, to that. Yeah. to that organization to the so. So Kmart, I guess was MSL for most of the product management side today and, you know, kind of been sharing our experience from that from that side. Then you’re the one who was hearing your parents from the business analysis perspective. So other any questions that you would ever ask to product managers be there or business analyst? Yeah,

Kima 48:13
I have a few actually in two of them I guess relate to the product management and one are like general questions so I will start with a product management questions. So um, why do you think is that that it’s been recently that the product management role is becoming popular so as you guys said earlier, if you like to look at the market, probably more more and more there’s a product management role which is needed. So why do you think is becoming popular now?

Iryna M 48:43
I probably count step in over here and then Vlad would add

you know, my experience mostly comments from the enterprise world, and why my answer prices are seeking for product managers today. It’s not on the current state. would like to have such roll, it most happening occurs, they would like to have more product oriented mindset and product oriented approach. And now in my world product around that approach means result oriented approach. This is how I treat this personally. And these big enterprises, they actually used to behave in certain way using certain frameworks and patterns. And it’s worse, it used to be more project oriented when you have a timeline, when you have a budget that’s being allocated to a particular department. And this budget is allocated on the year in the Beasley is and whether you’re on this found that overspend that you’re in the bad situation. So you, you trying to be exactly all the number. So you’re most worried about these budgets and your plans for the next year in here. And yes, of course you do care About the business side and business objectives, but this is not exactly what’s driving what you’re doing within the department. And these days to be more competitive to be more aligned with your customers, with your clients with ant users, you can behave as he used to be with these budget allocation, you know, and plans and really being project oriented. You need to switch to the product mindset where you’re trying where you’re experimenting where your junior reads and amberly Deaton hypothesis when you’re trying to innovate. And basically, you’re trying to change Arison if not on daily or weekly basis than at least a monthly basis. And of course, that completely changes the framework and the way how you used to work. And when big organizations, big enterprises so looking at all of that they Oh yeah. So this time Basically this week, that means like a gentleman says mindset and product mindset. And in order to implement and support that product mindset, you always need product managers. And here where demand is coming from, from the market for such roles, and also where demand is coming from, for me AWS roles that are related to product development and production implementation. So, I would say product management is just the part that we see over here in terms of the growing demand, but really, it’s more requests for the transformation and it’s more more and more requests for these product lines had to be implemented to be adopted within a particular company.

Kima 51:54
So basically, the world is becoming more and more dynamic, of course, and more and more things are coming in. So basically, we need to To change your mindset to be more flexible in a way, right?

Iryna M 52:03
Absolutely and and so probably the main point to stay as close as we can be to the end users and to clients and to listen to their feedback and the work off that. This is probably thing number one to be successful today.

Vlad G 52:23
I agree with this. I agree with pretty much everything Iryna said, I’m not sure if I caught that that part. The product mindset approach is generally considered cheaper. And that’s why a lot of companies are looking at it and trying to implement it not cheaper, as in McDonald’s versus expensive restaurants, but cheaper in a way that you can get same amount of work for less or you can get more bang for your buck. So and that is actually true. It’s not something that you know, we pulled out of thin air, we actually seeing these types of successes, you know are in with our clients and the organizations I’ve used I’ve worked for before. There’s, there’s a definitely a benefit of product management approach, because of flexibility, because of the data driven decisions, or at least an attempt to make data driven decisions. Because of the new mentality or mindset, as we call it. How you approach solving the problem, you don’t just, you know, rush into the project. With a fixed budget, you’re you’re trying to spend money smarter, because there’s a pretty understandable lifecycle of a product, you send it up a product when it’s needed, how it’s needed, and then you continue supporting it as needed. So it’s all focused on business outcomes, not just, well, you know, we have $6 million, we need to spend it.

Kima 53:56

Vlad G 53:56
So there’s there’s that other aspect

Kima 53:59
interesting. Okay, thank you. Um, my next question is, what do you think are the three qualities for the good product manager?

Iryna M 54:11
It’s a good one

Vlad G 54:11
It’s interesting

Kima 54:13
I think there won’t be any people actually.

Unknown Speaker 54:18
Yeah, so you know, I don’t have a prepared for over here. I would say that good product managers do need to work quite a lot to unself skills, like communication skills, being flexible be to be able to serve as a servant leadership, be able to find to come to an agreement easily to with any person with any department and so on. So it actually comes back to the communication skills, and partial I know that it’s not usually treated as a soft skill, but you definitely need to be a good presenter or so together with their great speech that you are conducting union To be able to support that with nice images and presentations and tax, whatever is needed while you’re talking, so I would say, you know, there are a number of hard skills that you would need, but this is definitely important. And without that you will be successful product manager. Together with that, I was saying my next point, kind of connected, you need to be flexible. You’re really need to be able to listen to the people and understand their position, their opinion. And what’s even more important. If you feel if you hear something reasonable. And if you feel like this is the right thing, be able to change your opinion, your approach your mindset, whatever, based on the feedback and the input that you’re hurt. So really not to talk to you on the one right way because usually when you’re doing product development, there was no right way you’re and you’re just inventing ever since. And together we are in the bounce in since you need to be flexible. So I would say that’s, that’s point number two. And Point Number Number three, I would say that you still need to be educated in product management era and still have all of these known that you experience in hard skills and understanding what what is required from your role because, unfortunately, or from cases that we see over here, number of people have just been assigned with the role of product owner or being assigned to the position of Product Manager. But they really don’t know that they, for example, supposed to work with marketing. So still being educated in the field. I would say that that’s important as well. So this this, this is my verses that I just thought about right this moment.

Kima 56:59
Thank you. Yeah. Interesting. Okay, Vlad, anything?

Vlad G 57:01
That’s, that’s really cool because I have I think we only overlap on one.

Kima 57:08
Interesting, okay.

Vlad G 57:09
And this is good. This is good because because I don’t disagree with Irina’s perspective I may have, I may be calling things, similar things with different words. So let’s see how this how this will go. First and foremost, I, the one that overlaps with Irina, I just call it with a different word. I call it a storytelling. So it’s being a great communicator. Same way that Irina said is being able to get your point across and tell a good story is that whether it’s a story of a future product that you want to develop, and you need to convince your stakeholders or It’s a story of your success, or it’s a story of your failure, one of the most important parts of being a product manager is being a good storyteller because people aren’t going to listen to you. If you just keep telling them about, you know, this new brand new JavaScript framework that is absolutely amazing or this brand new AI algorithm that is just just going to solve the world hunger, nobody’s nobody’s that patient. But if you’re able to wrap it in a good story that immediately brings people to attention, and it immediately makes them interested in whatever it is you’re trying to do. And I think one of the major things that product managers do is they they’re champions of new products, or the champions of their existing products. And one of the goals is to increase adoption of your product. And that’s, that’s how you do it. You tell those stories. Now, the part where we start deviating a little bit. The next the next qualities that I think is really important is Product Manager is humble. And I keep regurgitating this thought that product management is a thankless job. If you did it. It’s a it’s a team effort. If you didn’t make it then it’s your personal fault. And that is where you know that Product Managers humble comes in. Yes, it is a team effort. You didn’t do it alone. And I’ve out of my career, I’ve never done anything alone. I always had help. From delivery from software developers from business analysts or subject matter experts. It’s never it’s never a solo game. It’s always a team effort. So it’s still true. And product manager needs to be humble in a way that they recognize and they they give credit, and they praise team members that help them achieve their goals. So in that sense, again, I think one of the most important parts of being Product Manager is being humble. Because if if you take away people’s credit, they’re not going to help you next time around. And it is it’s really real. If you’re not, if you’re not saying Hey, Kevin arena helped me record this podcast coming up that may never come back to me and I may never participate in another episode of this podcast. So there’s that And the third thing Which where we completely probably 90% away from the naming the same thing is product manager has to be curious and not educated, not necessarily educated, but curious to learn more and maybe it’s being the generalist of what is which is what I am in terms of product management, speaking but Product Manager always tries to learn new things as an example, again, I use personal examples because I can’t relate to them it’s easier. I I’ve studied 15 different things in the past week. They They range from a legal case management systems to pharmaceutical systems to logistic systems to oil and gas systems. Why because I think they’re these items. These knowledge points are the this information is relevant to understanding the current problems with the market. To help me do my job better, but also because I am, by nature curious, I want to know more about things that define the current world. And so when I come in and bring my expertise and experience to the company I work for or to a client of my company, they understand that I am actually bringing quality and a lot of expertise to the table. So in that says, my three items, being good communicator and storyteller, being humble and being curious. Yeah, those are my three.

Kima 1:01:34
Yeah, thanks a lot. That’s interesting. And, you know, while you guys were telling this, I was drawing a parallel was a business analyst. And I think that again, in terms of business analysis and product management, there might be differences, but of course, there are similarities and especially in the term in terms of, of the good ba qualities, they do believe that communication of course, is crucial. presentation skills, storytelling, yes. Sometimes you do need to, you know, to tell Stories. Don’t have curiosity as well. I do think that being has to be curious. And humble. I think that you have a lot. It’s interesting that you mentioned that because I think that BA is a serving role, right? Because you’re serving the customer, you’re serving the team. And this is a thing where overlap happens. So I think in general, yeah, thank you, guys. For these examples. It’s very interesting. I think that it’s has a lot in common with BA qualities.

Okay, I do have the last question, but I’m not sure if we have time for that.

Vlad G 1:02:30
Let’s, let’s do a lightning round. Let’s do let’s try to answer it really fast.

Kima 1:02:34
Okay. Irina, at some point of our conversation, you mentioned that it’s kind of the question is, when do you understand that it’s enough of communication, because for ba the communication is important. And sometimes you know, you want to have you want to make sure that it’s a lot of communication, but on the other hand, you do need time for your own things. So how do you understand that the the communication is sufficient that it’s enough

Iryna M 1:03:01
That’s actually a good question that I didn’t have a straight answer for. I feel like I think that it should be driven by your feeling only. And until you see that people are open to communicate with you more. And as long as you feel that you’re aligned with your stakeholders with business objectives, and you don’t have this feeling Oh, yeah, that conversation happened without me. So I’m liking the information. That should be enough. But you know, there’s no silver bullets, like two hours pretty good. I don’t think that there’s measure like that. I would say that on the productivity side, you definitely need to measure the number of sessions and communications of meetings that you’re participating in. versus if it’s eight hours a day, every day, that’s that that’s really going to be too much and most probably you’re going to be really tired. was a really short period of time. So enough is enough, as long as it does not stop you from doing your work. And as long as you feel aligned with all the people whom you’re talking to.

Kima 1:04:12
Thank you, Vlad. Anything to add here?

Vlad G 1:04:15
Yeah, I’m gonna try the lightning way. So it’s all in the schedule for me. And if if I need no, I need to get work done. And I’m being overwhelmed by meetings. It’s all about time management. So I’m going to try to schedule the work, I’m going to block my schedule to do the work. And this will naturally expand, it will naturally spread away spread out the meetings. So I don’t have eight meetings a day, which I had before in my previous life, and I didn’t have any time to work. And that’s how I learned the hard way to do this. So I was just I would just block out time on my calendar and make sure nobody puts a meetings there. And if if somebody tries to schedule over I will decline and said hey, I can’t I’m working on something or I have another meeting find another time. I i’m not i’m not a slave to your schedule. I am I am a manager of my own schedule. So that was for me. And that that basically, right you have to you have to be able to say no in any position is that, you know, not just product management thing, which we’ll probably explore in the next episode is is the ability to say no, but yeah, that’s that’s the way I do it.

Iryna M 1:05:26
Yeah, that’s a good one. You know, sometimes we go one of the managers so give me the advice. Don’t let people book your schedule, book, your schedule yourself with the people. But I think you need to be very real at the very high position in order to be able to do that and for product managers, unfortunately. So it’s not always working like that, especially in my case, but probably you guys.

Kima 1:05:51

Vlad G 1:05:52
scheduling is very important. discussion, definitely worth discussion because, yeah, this is a big topic time management as a whole. How to senior roles versum a middle level role. Yeah.

Kima 1:06:04
Yeah, thank you guys. Alright.

Vlad G 1:06:07
I think I think we’re out of time. Thank you both. This I think this went extremely well and this is really interesting. I hope it’ll reconnect and cover topics that we’ve missed. Yeah. Thank you. Kima Thank you. Reena. It was a pleasure having you on this episode.

Kima 1:06:22
Thank you guys.

Iryna M 1:06:24
They have the same here. Thank you for inviting me and hope to talk to her again.

Kima 1:06:30
Yeah, see, stay safe, take care.

Iryna M 1:06:32
Work remotely!

Vlad G 1:06:41
You’ve been listening to the real world’s product management and I’ll be your host Vlad Grubman. Until next time,

Transcribed by https://otter.ai

Real World Product Management – Episode 04

I am talking to Peter Dwyer, a product manager from Nielsen. Their approach, product structure, and product lifecycles are somewhat different from your regular software products. We explore that non-standard approach and things Peter and his team do in their context.

As always, if you have any questions or want to subscribe to our podcast – ask a question here

Transcript of the episode 4 (courtesy of otter.ai)

Vlad G 0:07
This is Real World Product Management.

Hello, and welcome to the next episode of the real world product management. My guest today is Peter Dwyer. Peter. Hi, how are you? I’m well

Peter D 0:25
I’m good. Thanks, Vlad. And how are you doing?

Vlad G 0:27
Thank you. I’m great. Hopefully we’re all staying healthy and sane in this new reality and new world. So can you please tell us more about you and your product management experience? What is it that you do when how you do it?

Peter D 0:40
Yeah. So my name is Peter Dwyer. I’m a product manager at Nielsen. So working in there. I’ve been a in product leadership for about three years now. But I’ve been a product manager for a little over a year. I kind of entered the role kind of worked my way through. I think everyone who listens here who is on Got a background in product management knows from experience that sometimes the product management role can kind of be a product of circumstance, if you will, I don’t know that many people naturally find themselves in the product management track, I don’t think there is a real well defined one it kind of finds you and to a certain extent. So I started as an analyst at Nielsen in what’s called the Nielsen bases division or the innovation practice, which kind of helps manufacturers around the world, evaluate new product ideas and bring them to market and kind of make some volumetric impact assessments or sales forecasting for these new innovations I go to market. So I started as an analyst work my way through into a sales operation role. So bidding and scoping one off projects. That’s what kind of what our business model was based on is individual projects, with deliverables and defined deliverables that are delivered to clients. And then I transition to product leadership and began as more of a business analyst role Before assuming more of a junior product management role about two and a half years ago, and then saving that role through the launch of a solution and service and kind of maintaining support. Getting a lot more know how and experience from the Support Portal or the help desk. I kind of felt like I was ready to make a move into product management kind of got elevated into the product manager role of that service. A little over a year ago, as I said,

Vlad G 2:28
Great, by the way, since you mentioned you that you participate in a lot of product ownership ceremonies, participate in sprint planning, and so on, as well as solving some high level problems leveraging delicious without the teams working on strategy. That’s more of a product manager rather than product owner responsibilities. In my mind, product owner, Product Manager completely different roles on two different levels. I understand that in your case, there’s some sort of symbiosis. You guys kind of merge them somewhere. Together, maybe you could elaborate a little bit on this for us.

Peter D 3:05
Yeah, that’s a that’s a great point to add. We’re pretty lean organization. So as I was speaking to, we were talking about earlier, our role, product manager role is a little different than probably what other people in the industry are used to, in my role as a product manager, not only am I responsible for the backlog in the roadmap of a product that we’re doing, that we’re working on, or that we’re assigned to or that we kind of pitch and get assignment towards, or do we win the resource battle. We also do maintain, we run stand ups. We also run through the grooming. So I’m actively writing stories, writing requirements, and at the same time, I’m going through and grooming them with my engineers to understand exactly what that they’re going through that size and estimate tagging for release tagging into sprint and managing the queue managing the Agile board with my team directly one to one while also being responsible for product health metrics and being able to assign or assign identified needs in the roadmap, so kind of keeping in touch with my commercial stakeholders in a regular cadence to understand what needs there are in the solution or in the platform, in my case, a little bit more on my my recent assignment. So it really is kind of touching go a little bit all over the place May, adding a little bit more challenge to the mix is that we’re in a global business. So kind of accustomed to the early mornings with Europe or Russia in some cases, when we got to be a little bit more Russia specific or less him. So working around a lot of time zones to manage that relationship, in addition to to everything else, so And lastly, kind of going hand in hand with the commercial relationship is also working closely with product marketing to align on like, something that we can do to get communication out, get the word out, bring new news to clients, when we have new features available. ton of working to establish that sales playbook or pitch deck when we need to as well understanding those market segments, we have a direct role on that. Almost like a vertically integrated role for the entire product experience a scrum manager, or Scrum Master product owner and Product Manager kind of all wrapped up in one roll. Again, we’re we’re pretty limited when it comes to that, and very similar to a lot of other organizations out there. But it’s just makes it a little bit more rewarding. I think it lacks

Vlad G 5:31
definitely makes it more challenging. So you saying you were watching product metrics? obvious question is what are the metrics that you’re watching? But before we dive deeper into that, what are the products that you’re working on? So we can understand why those metrics Make sense? So let’s break it down into two the four questions. What are the products that you’re working on? And which metrics are you watching and why they make sense?

Peter D 5:55
Yeah, so what do you do here? That’s the question. What work. So our business unit within Nielsen has a discrete offering of a multitude of market research products, or solutions as we’ve kind of packaged them up. So it’s a survey based research methodology with numerous applications. So we have discrete offerings, where there’s one format here and other format there. They have very specific individualized deliverables for that solution. And then they’re kind of sold as a project. One off basis. It’s not like not like a lot of typical SAS out there, where it’s based on licensing fees. These are kind of more of commodity that are sold or condition, their project engagements that are commissioned by the clients, and then they’re run, leveraging the platform that we kind of managing where we host these services and solutions. So that can be anything from qualifying a new, soft drink idea to a new bath wash, to helping clients understand the shelf dynamics in terms of like managing and integration pipelines. Let’s say you’ve got Multiple flavors of a soft drink, you need to define or decide which one is the best. We have a we have an offering in the platform that allows you to do that and kind of understand the revenue trade off for having an optimal line. And understanding what’s going to happen in the market when you swap out a new stock keeping unit or askew in what price points how to maximize volume, what what which price points maximize revenue, as well. So that’s, that’s a little bit more of what we do. So when it comes to product metrics, or product health metrics. Personally, myself, I’m pretty commercial oriented when it comes to that. So I’m really looking at unit volume, price per unit and total revenue or total revenue generated for the for the solution that we’re managing are under management at the time

Vlad G 7:50
going through throughout, but I just have to ask for my own sanity sake. What is the unit here is that a single survey is that a contract is that something else?

Peter D 7:59
You can think of it as a Single proposal for a project. So single project standalone as project manager, I’m looking at support burden. So we doesn’t matter if we’re generating a lot of revenue, if we have a lot of helpdesk tickets we’re looking at, that’s a support burden. We need to kind of reassess what the solutions got or what what what’s holding back the platform from delivering that without support burden. because it adds up means that it’s more man hours spent, we’re we’re pretty lean team. So if we’re getting pulled into tickets, a lot to kind of helping guide the conversation, and troubleshooting or trying to find a resolution for something. It’s less time spent on other work that we would like to ideally spend our time on.

Vlad G 8:42
So you effectively have dollar value or other direct dollar cost per ticket.

Peter D 8:49
Yeah, I mean, you can, you can pretty much come back to that if you do simple math a little bit like just assuming that no standard ticket for a project. It was going to be four hours of labor from our team. Maybe a little bit less than that kind of depends on where you kind of put the baby in the middle, so to speak, or draw the line. And then kind of averaging that out, you know, each project, kind of applying that equation that like, we got 500 tickets this month, we sold 250. That means we had two tickets for projects. that’s a that’s a sport, right. And it has a tangible monetary value that we could have. We could be doing with our we shouldn’t be working to reduce. So it’s just as important almost because a lot of the largest user base we have within our organization is internal. That’s not necessarily the clients that are executing these projects. We sell them the vision of having results within the within the platform for these projects, the commission, but the execution is mostly internal. So when we run into user issues a lot that means when we have internal associates that can’t use the tool correctly, or they struggle to use the tool or maybe the feature just isn’t there, which you know, to be honest with We’ve all I think you’ve kind of run into that issue where you define a feature, you kind of go through that discovery process, you ship. And turns out you miss a requirement. And depending on how important that requirement was, the blast radius can be pretty significant. And it can result in a pretty huge support, but and unintentionally. So we do keep an eye on that from, from our perspective, for from my perspective, at least. So kind of hand in hand, making sure we have operational excellence internally, but also making sure we got commercial excellence to when it comes to the product being in market or, you know, commercial viability, rather sorry. Making sure that we are where we kind of want to be from, from a commercial point of view.

Vlad G 10:46
Right, making sure you’re hitting certain financial KPIs.

Peter D 10:49

Vlad G 10:51
I like the commercial excellence as a term. I think I’m gonna use it in my conversations moving forward. Thank you. That was interesting. So you mentioned discovery and collecting the requirements process. So let’s, let’s look at this from a slightly different angle. As a matter of fact, let’s get to a higher point of view. And there’s probably a discovery process across the whole product lifecycle, you’re collecting requirements, and then do analysis and do other stuff. So what is this process? What are the challenges? Or what are your war stories around each step of this discovery? Or what are you guys dealing with? As the discovery progresses across different points in the product lifecycle?

Peter D 11:34
Yeah, that sounds good. Um, so So in our framework, for our software development lifecycle, we usually kind of work within discovery, development deployment, and that was kind of break out into a few different things, which I’ll kind of go into a bit more detail there. But another thing to note about our business unit is it’s kind of in transition So we’ve got this software application that we use to kind of service a lot of these solutions. But we’re also, we have a lot of legacy technology that we’re doing. Or we are replac, forming a lot of services that were kind of standalone consulting engagements without being like a specific product. We have to kind of draw the line and minimize variation and identify those minimal requirements to re platform that solution as an actual software offering. So we have to understand what is the survey variation? And what are the deliverables that are usually expected with that service and where the reporting needs. I mean, for anyone that’s kind of working in a business area or kind of a commercial services or consulting services, everything’s about a PowerPoint report. So we have to kind of have that in the back of their mind at all times when we’re forming these services. How do we get this down to a PowerPoint? Or what’s the expected delivery mechanism to the client So that’s something we have to consider. So we have to our discovery process is almost forensic. In that we have to understand the legacy application, the legacy processes, the legacy tools and teams that are that are leveraged throughout the execution and in the old world. And then we kind of have to size to fit into this new application that leverages the automation. So we think about a survey being programmed in a legacy world that would be programmed by a team or a vendor, and it would be published, it would go live in a production instance and collect the data. And then afterwards, we would have another team manage the tabulation of that data by hand. In the New World, what we would do is we would say, Okay, here’s the minimum survey requirements. We’ve defined these as what they’re going to be. We’re going to automate the survey creation and then we’re going to automate the tabulation of the data itself. But we have to kind of figure that out. A lot of ways where we have to kind of get down To the most granular level of the lowest possible level, the highest level of detail, the lowest common denominator, understand every process that’s going on in these legacy tools in teams. And then we use that to guide a little bit more of the software development, at least for the minimum viable product.

Vlad G 14:19
And that’s kind of like a race against the clock in our book.

Peter D 14:24
When it comes to defining the MVP, you kind of break it up into two platforms of discovery, I guess you got for your MVP discovery, like, just trying to like cut Jews and kind of picking, picking and choosing who’s gonna live who’s gonna die in terms of features. Now, and then that second part is okay, this didn’t make the initial cut. Why? Okay, I understand why. Now we’re going to put it in the backlog. We need a little bit more time to figure out what the actual value to the user for this. Okay, we got a value for the user. Is there a monetary value to me? Can we upsell for delivery or inclusion of this feature? Yes or no? Or is this an operational efficiency? Is this a margin play? Or is this just simply the cost of entry like something that we’re going to have to eat the time in terms of dev in terms of time and resources is it just going to be that minimum cost of entry and get our foot in the door to get our clients to adopt this new solution, because it kind of goes back a little bit more to our business. Like we’re business that’s in transition. So when we are replac, forming these services, it’s as much as winning over our internal users as it is our external clients. So we’ve got the name of the game does become a little bit of conversion. So it’s kind of our discovery processes. I wouldn’t say tainted, but it’s definitely informed a lot by that goal of conversion of adoption, away from a legacy service.

Vlad G 15:50
Interesting. And looks like you guys are doing great job given how small the team is. And listen, while listening to all of this. I still have this one question and this may sound like a interview. But please don’t treat it as such. It’s just the Curiosity because every organization kind of has it defined in a different way. So what is how do you define the MVP? What is an MVP for you?

Peter D 16:18
I think for us it becomes it’s kind of trying to harmonize what we think is the the MVP and what commercial stakeholders think is the MVP. And it’s just trying to get to a compromise somewhere in the middle where it’s, it’s commercially acceptable for what we want to push out to market. And that that’s always where the challenge comes in. Like you always have to manage those commercial expectations. And you have to you have to have a valid reason and you almost make it into a trade off situation. You try to give them enough of the carrot to say hey, this is what we think we can get done in we can get X amount of deliverables out and y amount of time the the z over Hear that’s that’s gonna have to come a little bit after, is that palatable? Or is that something that like, we need to spend an additional three to four months of dev work to get out the door? So it kind of comes down to getting getting the right stakeholders in the room to understand, Hey, can you get this in front of a client? Could you close the sale with just this in the spec of what this solution is offering? Now, it’s easier said than done. But sometimes it kind of comes down to it really is as much as like, do you think you can sell this? Okay, why not? If you have this in this or this, would you be able to sell it then. But it’s really, we have like, we kind of have a cheat sheet I guess in our organization since right now. We’re still on the transition of re platforming and transitioning a lot of this business to a product, focus mindset or product oriented delivery where we kind of have Way good established service Rolodex, if you will to pull from where it makes that a little bit easier. But for newer solutions that we have that are like, kind of a bit of a ways out, but kind of like the next suite of solutions that we want to deliver, or get onto the platform, it’s kind of like, I don’t want to use the term but like virgin products, it’s just like completely new in the market stuff that we want to build. That is going to be a little bit tougher, and that’s a situation haven’t been in quite yet. But I know that like, from like an MVP standpoint, we have a little bit easier, but it’s definitely it can definitely like pulling teeth sometimes with commercial folks to get it in there in the kindest way possible.

Vlad G 18:42
It’s understandable, at least from my professional perspective, from our professional experience. Sometimes we this is how I can relate to this. Sometimes we would show the business and we generally call them to business, could be sales, could be a PMO. could be anybody. We would show the business there. map and roadmaps are usually broken down into quarters so they can, they can deal with them easier. And everybody would get very excited. And we’ll we’ll show them the piece of nationalities that are coming down the road on the roadmap. And there’s always this one person, there’s always this one particular person that would look at the roadmap that was pointed to a single feature or capability or functionality on the roadmap somewhere in the fourth quarter, almost, at the end of a at the end of the roadmap, and it would say, get very excited about and said, this is this is the best seller, I can I can totally sell someone today, if we would have that feature. Can we have it now? Like what would it take to have it now. And by sheer luck, or I don’t know by an accident or, or or whatever? Yeah, that would be the only feature they requires this almost the waterfall sequence of events. So you have to make certain things happen. And that’s the only feature, that’s the only capability that actually requires four quarters of development. But that’s the only one they would care about. And that’s, that’s my next question. Really? How much? Sure, would you say your stakeholders are if they’re asking for this feature, this capability? How well do they understand that certain things have to happen in like, almost like a waterfall fashion? So, you know, they realize that there’s one thing that enables another enables another and that’s when the magic happens, or they they believe everything can be done by Friday?

Peter D 20:36
That’s a great question when, and it’s actually very prescient. So, five years ago, I don’t know if I would have been able to answer that question. Honestly. Just because it was a different setting. We hadn’t even launched the first real standalone solution. So the understanding at the time was very different from what it is today, whereas today we have the business unit Or president of the business that understands what the product focus is. And what it is even though they may not have exposure to this, the software development lifecycle, they at least understand it like, okay, there’s there’s trade offs to be made here. And it’s incredibly tight, like good timing on part of this podcast. But we been kind of on a full court press in 2020, from our organization to go out. And not just it’s not just the commercial stakeholders that need to be aware of the software development process. It’s it’s the users themselves that need to like, understand and internalize how how the sausage gets made, like everyone wants to make their client happy, and everyone wants to like their own private like mansion in terms of like what the software has offered for them. But you have to educate them a little bit more along the way in terms of what it is so we recently did an exercise. We kind of run this organization within the orange Are we kind of run this group of stakeholders within the organization we can refer to as our champions. They kind of disseminate some information via release notes or upcoming features we’ve got, you can never have too many points of contact with the org. So we just try to use them to facilitate that, that those channels as much as possible. But we recently walked them through a few features. And just like for compare and contrast, we walk them through a simple checkbox. Now what you or I would probably call like, a UI feature. But that UI feature that started out as three stories expanded scope into taking 16 stories and we kind of had to walk them through why that happened. And what that was and why that ended up being you know, something that would have taken a sprint to develop these three stories into why took four Sprint’s to develop it. Now, you know, Dev effort or dev approach is a completely different conversation, one that they don’t need to know about But under like making them aware of like, what the blast radius is of introducing something as simple as a checkbox into a UI that does something elsewhere, is pretty big. And then the second example we did was breaking down a recently released add on deliverable or a diagnostic add on that we we, we offer with a few products, kind of breaking that down and saying, Hey, this is like how a feature gets made, it starts out as one thing. So start from like, just generating a CSV file. And then from there, we work it up into 65 different other requirements that come together holistically to be generating a CSV file that is reflective of like, we produce a CSV file that’s read by this. It’s ingested by the platform, and it renders in a completely different fashion to kind of display the data that is produced for the client in this way. Kind of going from one to 65 and illustrating that journey has been huge. So I think now we’ve kind of also we’ve got the benefit of reaching that critical mass where the stakeholders, they’re bought into this, they they understand that software does come with a trade off, there is necessary tax to pay some time in terms of like, it’s better to bite the bullet now get, get something that’s acceptable to the client, and then wait for some of the better stuff to come along the way. Like it’s almost more important to prove to the client that we have a commitment to the software mindset than it is to deliver everything all at once and kind of that old school waterfall fashion.

Vlad G 24:38
You just think I love the part where you’re educating your users, your users or clients who you’re doing this for? Are your internal sales, right?

Peter D 24:46
Yeah, yeah. So we we call it we refer to them as champions. So it can be Client Services, operations, and sales and service are pretty closely aligned but operations is a is another pillar in the organization. Which kind of stands alone and kind of has their own priorities, similar like product leadership and sales and service?

Vlad G 25:06
This is pretty cool. I don’t hear about this pretty often. Usually, what I see in here is someone on the executive level saying things like, hey, I’ve been a developer 25 years ago, I know things down. You don’t need to teach me that. I don’t need to tell me that. So yeah, I am impressed. So okay, let’s move forward. You said that there are three steps that you guys are using in a delivery is a discovery, development deployment. And my understanding is, deployment includes the go to market activities. And again, if I understand your industry correctly, you’re developing things for specific engagements, then that’s when you give them to the customer, which is exactly what got the market is

Peter D 25:48
that that’s kind of right on the money. When we’re deploying something. We usually we know that the MVP for the service or at least the MVP for the add on that we want to make available. For the service, we’ve deemed market ready, and we deem it ready for client use and internal use at that point. So

Vlad G 26:07
let me ask you this and I understand that it’s a little fuzzy, this whole thing but for your deployment since you’re deploying solutions based on what you’ve been asked to do, rather than building things for the market, so there’s really not that much of trying to get to the market getting market share, you know, fighting for your place under the sun. I failed to capture that I failed to get the idea that you guys have a marketing strategy. Now we’re going to market strategy as a whole based on what a year based on what you guys doing, how you’re doing it.

Peter D 26:43
It’s it’s a bit of a dance. So I mean, in our in our portfolio, we’ve got a pretty expansive portfolio, but we’re kind of trying to streamline and standardize so when we have these software oriented solutions, they’re designed to kind of right now we’re kind of Tackling solutions are like the majority of our portfolio and then there’s like a pretty extensive long tail that we’ll need to address eventually. So when we’re doing these deployments, they’re kind of these these solutions that are designed to meet in at scale the needs of multiple clients on a global level, to answer one problem, or offer a suite of diagnostics to, to offer analytics for one problem. So thankfully, we’re kind of exempt from, you know, kind of building these one off pieces of software for clients. But when when it comes to deploying these new services to market, it becomes a bit of a full court press internally and externally. So we’re working with Product Marketing, to identify the account segments that we need to go after. So that’s kind of hand in hand with with the commercial stakeholders. We’ve got to develop a pitch deck, we go through an exercise with our sales organization to understand make sure you know how to sell it. So we kind of use this program that we we sit on and we help it and we kind of poke and prod when the sales team goes through it. We call it Pitch Perfect. It’s been something that’s been working pretty well within our organization. So we just coach them through 15 minutes or they get an opportunity to pitch for 15 minutes, we give them some pointers and kind of try to poke holes and see how well they actually know and understand what the solution capabilities are. We do a pretty big mailing or we do a pretty big communication Blitz in what product marketing is able to do, and leveraging them in that way. And then, on the internal side of things, were going through that, making sure that we’re doing end to end testing. With the internal users, we kind of do all day training sessions around the world for our associates that are getting trained up on how to execute these new solutions. So the client service users or operations, users weren’t really doing a full court press right off the bat for you know, up to a month until we go to market. That way when we turn the switch on. We’re ready to go. We have leads generated from the marketing blitz that kind of Pre precedes the internal training. So we get that critical mass we get the salespeople trained First they go out, they start pitching. By the time we finish up training with our internal organization, we’re ready to kind of go. And then we’re kind of in that deployment phase where we got a lot of round the clock production monitoring, make sure that nothing’s going wrong with a solution when it when it’s going to execution. And we’re also just making sure that we’re getting enough leads through the door that we got critical, like critical mass critical lion’s share of our internal teams to make sure that they, they’re, they’re doing their part what they can to make a commercial impact for it. And then that deployment kind of tapers off after we get through a certain amount of reps. Like there’s going to be that support spike. And then the user base kind of gets used to things and they get educated, they kind of learn from mistakes, or we kind of learn from our training mistakes. We make it a point to like re educate as needed. And then we kind of see that support burn and kind of taper off a little bit and then a little spike when we get a new hire class and or it’ll spike when we get a new market or a new methodology supported for some of the solutions. So the deployment can definitely be the most fun part, like discovery and deployment are definitely really enjoyable deployment, it’s so rewarding to get it out there. Because in organization, it’s just kind of like a big event. It’s like kind of a, you get to be the belle of the ball kind of traveling around you. Help people get excited about the product as much as you can. Gives us that’s kind of our role too. We we’ve got to be evangelists for what we what we’re working on, we can’t just be doom and gloom or kind of take our lumps a little bit in the back. So that’s a bit one bit of it. When it comes down to as far as deployment, it’s a lot of education, making sure documentation is up to snuff. or in our case, sometimes you have to develop internal tools or like an Excel document to kind of guide some things. Now that may be a little counterintuitive, what product management but when it’s engagement that runs all the time Mind, sometimes you have to make those sacrifices to ensure that like you’re delivering on time to a client, you got to develop a tool to make sure that your teams know what that timeline is put into a proposal. So it’s a lot of developing those like software tools that we we will use as well. And making sure those are up to snuff during the deployment phase.

Vlad G 31:19
Makes sense, and you said you have to do the door and you have to do some other stuff. Is that a part of your product management responsibilities, or is that something else

Peter D 31:28
I was reflecting on my past experience. So we we have a pretty unique structure again. But we have this role that we refer to as product operations. And they are kind of like Junior PM, but they’re doing a lot of this documentation, internal documentation, or they’re doing a lot of a little bit of the legwork to kind of help the pm out. So in my case, when I was a in product operations, my role was a little bit more oriented to preparing things for certainly automation as much as it was contributing to discovery Where I could, it’s doing a little bit of this, like pre wiring for the organization to be ready to go. That, but the product manager in my experience, when we’ve done trainings, I’ll definitely do a training here and there, it’s a great way to become more visible to the organization, again, like education is a huge priority for us in the past year or so. So being able to be visible to the org and making sure that they know that we have a product management team, and that they can, that you can they can kind of put a face to a name, so to speak, is invaluable too. So those training sessions are a really good vehicle to build that credibility within the organization.

Vlad G 32:42
And since we’re talking about responsibilities, and specifically about product management responsibilities, I wanted to ask you as it pertains to organization, about the product management role. I keep seeing it in almost every episode, that product manager is a thankless job. If the product is successful, then it was a team effort, but if the product is failed, that’s it. Your failure, your individual failure. So what does it look like from your organization? Well, where do you guys stand on that?

Peter D 33:08
uh, it’s a little bit different. I mean, part of the pitch that my managers kind of made is like you get, you kind of get a target on your back. So you like you. the good and the bad is that you become very visible in the organization very quickly. As much as it can be a painful, thankless task, like there’s definitely that there are definitely those days where you just feel like no one knows anything that you’re working on and you feel underappreciated. But more often than not, you do become the go to person for everything. So you when there’s a cset that comes through for your product, but people will forward that to you and be like, this is great. This is just what the client needed, like, like your work is invaluable. Kudos to you for working on this but when something goes wrong, conversely, you are also the first person you’re kind of Johnny on the spot to fix everything. So if you’ve got a production issue related to your product, you better be on call, you better be able to figure it out and you better be able to triage and get through this and come up with a solution and a resolution to move beyond that. And salvage the engagement if you if it comes to that those dire circumstances, but we do a lot of communication where I kind of work, we put our name on things so people know that when something goes well, they can reach out to us and they do reach out to us. Or when something goes wrong, they know exactly who to go to, to kind of chill out a little bit too. So you get as much as the glory you get all everything else that comes along with it to you become. I’m trying to think of the word to describe it, but I think I might have had a better app description for it but you get a lot of as much as the guts you get the glory too. So it’s kind of take it as it comes. It’ll kind of change day to day Interesting.

Vlad G 34:57
Interesting definitely has not been my experience of Least almost never. And I’m really happy you guys have it this way. I’m happy you guys have differently. I really am. And from, from what I’ve seen this one of the things that I’ve heard that scares people away from being a product manager, you know, it’s kind of like, what do you mean no one ever stops by and say thank you. Yep, that’s pretty much what it is. And that’s great that you guys have a habit this way. So I want to roll back a little. And you mentioned that there’s a, if there’s a mistake, there’s your education, and that you guys have been a big on education for the past year and change as the whole. So I wanted to ask this question. Whatever happens if you guys have deployed something, and it was a failure, and how you guys deal with it?

Peter D 35:43
Yeah, it’s happened. It’s happened. We can’t all have success stories. I wasn’t the product manager and I wasn’t able to contribute much but when one thing that comes to mind is we release application for general general availability a couple of years back. And the QA was a little bit different. It was a it was an It was a project that had changed ownership several times. This was this was about a two year project that took about five years spring to general availability release. So definitely a labor of love by the end of it. And there were just some very different practices on that team at the time. It was a very interesting team dynamic. So when it was released for general availability, the application which was mostly leveraged by internal users, was definitely just not ready for release. I can’t comment too much on the QA, but it was just done, not the right way to the point where the UI would be your responsive to a user’s action. So like there would be the UI was not talking to the Back in the backend was talking to the UI. So the application itself was not usable,

Vlad G 37:06
was that a design flaw was that the application not tested properly? What actually went wrong?

Peter D 37:14
It was definitely testing practices. And that was partially due to some of the relationships on that team. So it’s a little bit of a mix of vendor versus internal. So kind of lost in translation kind of thing going on there with with an organization that had really didn’t really, it was an inexperienced product organization. And we kind of inherited that coming from a more experienced organization. marginally more experienced, rather. And it was released kind of in triage mode for about a week to the point where it had to be rolled back to the previous application. Now this was supposed to replace and then it was pretty much two months of doing things the right way to get it back out. To release date, that’s how that that was pretty big. Personally, I have a few issues with a with the solution that I brought to market where you know, the Bucks got stopped somewhere. So in the case of like, pretty, not so great circumstances, going through raw data to kind of qualify some things or being able to be on the spot to help triage and engagement that’s going on in Japan. definitely been in there or being kind of boots on the ground for engagements in Europe in early morning hours to make sure that those operations personnel are able to do their job and learning from mistakes as quickly and as efficiently as you can to, to make sure you write down things. That’s definitely happened or I believe heavens knows that. You get a release out and you know, stuff happens And maybe it’s a missed requirement or it’s maybe a QA mess. Watching the nonce and this requirement from the pm side or the PEO side, depending on what your organization is like, and you identify the need for the hotfix. And you’ve got to, you got to manage that you got to go through the senior QA engineer to get clearance to get your hotfix deployed, you have to get grilled and

Vlad G 39:23
you said you got grilled on that? Is that like lessons learned? Why did that happen? Kind of a grill or?

Peter D 39:29
Yeah, you got to do that like SWAT meeting right afterward? Or, or it’s like in the go, No, go say, okay, hey, we got this branch ready to go. We identified the issue. It’s okay. So why didn’t you do this in the first release? It’s like, What? Oh,

Vlad G 39:45
right. And I’ll let me ask you this. Since you already mentioned that you have dollars tied to your support, therefore, you’re you can measure support calls directly. How do you guys handle support? What is what is your approach? How do you How do you do this?

Peter D 40:01
Yeah, typically we we leverage our product operations role to handle support. So what I mean, we’re lean organization and we put it in perspective, we, as an organization worldwide, we’re probably around 1000 users. So we’ve got about three to five people at any given point, sporting all that input, all that intake. Some of that some of those 1000 users still leverage a lot of legacy applications. So we would probably say about 50 to 60% of that critical volume coming through. But we typically leverage the product operations role as our support liaison, but in certain cases, kind of a little bit more strategic. We still get like tickets around like feedback or like, Hey, why don’t I have this feature that necessitates the need for the product manager to seven or in extenuating circumstances where I maybe have a bit more domain knowledge than the product operations person does at that point. So like, I may know a bit more about a service In the in the product or in the tech stack that they don’t, and I can know right away, like, oh, I’ve got to go out to this engineer who’s on our support team. We got to triage this right away, it should be like, I can kind of, kind of like, get to that point where like, it’s like a sizing exercise, like you understand just how big of an issue is by like looking at it and maybe talking to an engineer? Like, is it a small or is it a medium or it’s like this gonna take like two or three people plus DevOps to figure out, you kind of get like a feel for that, which also ties into support, we have a rotating system we refer to as l three, where a member of our onshore team will act as the kind of on call engineer, in addition to their other responsibilities, but like l three, their support burden kind of takes precedence. We rotate them through on a weekly basis for all of our teammates that are on tour.

Vlad G 41:53
And that’s pretty standard situation, at least in most of the delivery organizations. So let me ask you this. From the product standpoint, and that’s why I was asking about the support. So I would understand what feeds back into the product development. Since we’ve already talked about the MVPs. I understand you guys are developing your products after the initial release, you keep developing features after you’ve released the initial release, or the MVP. So you constantly supporting the product on the market. Once it’s been out there. What do you what is your product lifecycle how you define the product lifecycle? On average, what is the product’s lifespan? Is it months, years date decades? How do you decide then when it’s time to retire an existing product?

Peter D 42:38
Yeah, that’s a… wouldn’t say retire necessarily, but we definitely reached like a metric, like a maturation standpoint, and I think right now we’re kind of in a yearly cycle, or like a year as long cycle for this. So I’m the product that I’m kind of coming off of being the pm That has been my life for the past two and a half years. And it’s like an off that it’s now kind of reached a point of maturity, where it’s going to get kind of included into another team’s stack or in their product stack to kind of manage. And I’m going to be transitioning to a new project, the the flagship solution that we have in the platform that has been in market for about four years. And it’s probably just now reaching the point where we can say that that is, or maybe it was around the three year mark that it really started to reach maturity. Like we’re, we’re a little bit of an interesting business in that like, it really comes down to adoption. So once we reach that critical mass of adoption, that’s kind of where we draw the line of maturity to kind of move on and kind of go into maintenance mode as opposed to like feature mode. So right now, still on like a pretty big macrocycle for that, but in support. We’re actively taking feedback if we can And add on out, that’s not hitting the mark right away. Like, I think there’s that quote, like, if everyone loved your first release, you probably waited too long to get it out. So it’s kind of the way that I’ve approached like the feedback tickets in terms of God in the backlog. There are definitely some recurring themes, but we try to get like trying to have like a residual backlog review at least twice, if not four times a year, where we just kind of take a step back and be like, okay, here’s the ticket volume on this request. Is it worth the time? Or is it really client specific and it would kind of like handcuff stepwise do that. And then we’ll periodically have those conversations to kind of revisit or do we have like a back breaking bug somewhere that’s just been lurking that we’ve been ignoring like what are the ankle biters? Do we need to like spend a few Sprint’s and just tightening up everything that that will definitely that’s been a little bit of my focus as well, like, do we need guardrails to introduce based on or user errors that we’ve seen in the system? Like how do we address that? Can we solve that with a product rather than just excessive documentation? So that’s, that’s something that like, is a good support learning as well, from from my perspective?

Vlad G 45:14
Uh huh. And here comes the tricky question. There are different names for this. So we’re going to use features and capabilities. And let’s stick with features for simplicity sake. Have you ever had a feature of a product during the product development that you absolutely wanted to take to the market, but were unable to do so? And why?

Peter D 45:35
Yeah, got a few. There is one that comes immediately to mind is there was an add on. When I was elevated into the product manager role. There was an add on that was kind of in flight. And I wanted to take it to market we had done we had gotten heavy commercial signal that this was kind of like a make or break deliverable for several clients in our region. It was going to unlock that region to kind of a different user base that we hadn’t been And exposed to. And it got to the point where we were, we thought we were ready to commercialize, and we couldn’t come to agreement on price. And then the loudest voices in the room for the commercial stakeholders couldn’t align. They couldn’t agree that it was actually valuable anymore. So we’ve done the def work, we’ve got the feature flag on, we’re kind of waiting to go. And it’s kind of one of those things where it’s still there. We could still turn on tomorrow if we absolutely needed to, but we couldn’t get the signal validated. We kind of it was kind of one of those moments of where we acted in good faith with commercial. And maybe we should have done a little bit more homework to kind of offer that bit more. But we we acted on signal we did what we thought was the right decision in the moment. And right now, it’s just it’s just not the most necessary feature.

Vlad G 46:55
And this is interesting. How do you approach the validation is that some kind of data driven decision As a subject matter experts is that product managers gut feeling, how do you guys approach this?

Peter D 47:05
I would say, use the phrase data informed, because sometimes you don’t have you don’t have the data, like what do you do? This was one of those situations where we knew how the deliverable was configured, we could we could reverse engineer the legacy deliverable to to, to meet the needs of the product or the outcome that we wanted to develop. But it was in a pretty operational silo that we couldn’t get the information. So we had to rely on commercial commercial feedback to go ahead with development. It was something that we just, it was it’s just one of those situations where you, you got to make decision whether or not to deliver this feature. And the voices at the time were louder than what the data may be suggested or the lack of data suggested. And we kind of took a chance and we kind of learned the hard Wait for that. But it kind of goes back. I think we were talking before we went into the to the recording. But I’m like, What do you do when you don’t have data? You kind of have to ask why a couple times to commercial people. And sometimes, you know, commercials focus at the end of the day is to hit their number. And sometimes their feedback can be most influenced by what’s preventing them from hitting their number at the time. So you can kind of see these spikes where something is make or break, and then what by the time Deb is finished, it’s like on to the next object or onto the next target for the quarter. And that can be kind of tough to stomach and kind of let it silently go away knowing that like, dammit, I wish we could have done a little bit more to ensure that like had a little bit more valuable value to more users. And I wish we could have done a little bit things a little bit more differently in discovery to validate this before. Really Going through it. Or you kind of do the post mortem to understand like, Okay, why did this work? It was their data that we missed. Or like, how could we avoid this? No one wants to work on something that just never sees the light of day.

Vlad G 49:16
Wouldn’t you say it tremendously increases the waste. I mean, you’ve worked on this full time. And at the end of the day, after you have delivered it, the feature is there and you just never turn it on. I mean, it’s there, you just need to flick the switch. And that’s just no one letting you to flip that switch. So my question is, does it create huge amounts of waste. And maybe there are other ways you can you can work this out, maybe you can work through certain things and reduce that waste through experimentation, prototyping, market testing, got an A B testing in the market, a B testing of the features, anything really, that it would turn not only will decrease the waste and will also increase your chances of things being approved.

Peter D 50:00
Yeah, I mean, ultimately, this was a, this was a really commercially specific case where we, we went through that UI UX work stream, we got the deliverable in the way that it needed to look, we thought we addressed the user needs. And to your point, like, we’ve got, we’ve got code out there that just, we haven’t been able to turn on for a while. And you don’t want to do that from from a from a developer from like a team management point of view. You don’t want to necessarily communicate that to your teams all the time, or, or you need to like kind of walk line in terms of how you communicate that to your teams. But it really does call into question like, Okay, what could have made this a little bit more successful? Or like, how can we how can we revisit How can we like rethink getting us to market How can we have the acceptance criteria shifted, in terms of turning on that feature flag?

Vlad G 50:55
Interesting. In one of our previous episodes, we talked about experimentation and fails during the experiment. And we talk about the general notion of how experiments are usually negatively perceived by the upper management because they tend to fail and and to us, it’s normal. The experiment failure is good, because scientists tell us, there are no failed experiments, they are data rich experiments, and that we are naturally really learning from our failures. And it’s kind of understandable. If you’ve guessed all every step of the way, your experiments a success and you just moving on if it failed, you get to learn about new edge cases that may be useful later. You know, some things that you haven’t foreseen haven’t accounted for. So in general, you arrive at the end with a lot more information about your product, promote product development process. And in upper management, the experiments perceived negatively because it paints them in a negative light. Oh, you’re failing. Yeah, you’re failing. Yeah. That’s not good. And Overall, what you’re saying. And what I find genuinely interesting is that even though you have developed features that were wanted and needed by the customer, they never made it to the customer. And even though you’ve done the lessons learned postmortem, you have figured out, what could have done could have been done better. It doesn’t sound like you got any amount of negative flak from upper management saying you guys wasted the effort or wasted time and resources. And this interesting because in my previous experiment experience, and this is just the indicative story that I was developing prototype of a product that was parallel to our main core product offering. And I’ve heard literally from everyone except one single person who sponsored the r&d work that I was doing, you wasting time you should be focused on things that customers want today, instead of doing this, and when I was done, it became obvious that instead of focusing on the few customers who are giving us marginally better ROI, we’ve arrived at the product they gave us an additional 60 to 80% of revenue per year. And again, in your case, I’m happy that you didn’t get as much negative flack as I got, which is, you know, it’s a good thing. Your management is understanding. I’m just trying to understand what was the overall sentiment around the corner office if the corner office is still a thing? And how does it even work that you’ve developed something you never get released to the customer? And it’s okay.

Peter D 53:25
I think, you know, time with our macro cycles being pretty long, to to a certain extent. I think what first of all honesty goes a long way. My experience, so if you’re just upfront with the, with the right stakeholders, they can usually they’ll critique and they’ll probably take it up with the manager, or my manager or our unit leader, and kind of express their concerns, in a way but that’s happened before. Like when discovery goes awry. I’ll definitely get some flack for For the case, this is probably not what you should be doing. But this was a case where, you know, it was already in this deliverable and I think that should have been our first hint. To really question whether or not was the right decision to make. But I’m are already the second point going kind of pain in hand with Icos, like our organization has been remarkably patient. So the MVP for our flagship product compared to what it was four years ago to what it is now is is night and day different. And the organization has kind of come around to understanding that things come to those who wait like MVP is truly MVP sometimes, and we just have to iterate off of it. It maybe it’s a unique circumstance, like it sounds like it is I know that for this one that has that never saw the light of day. They’re equally frustrating things where there’s There are other products out there where people are definitely like pissed off. They’re like something that’s not out there or something just missed the mark completely. thing it’s talking to just like organizational patience and understanding that like we’re on a journey transitioning from a business that is anchored 10 years in the past and preparing it for being 10 years in the future. The You know, it was a one off circumstances does not happen. Usually, if something goes wrong, we will be the first to hear about like the the app that I was talking about yesterday or earlier. yesterday. You know, compare and contrast my one off little add on deliverable with this application and being just unacceptable for general ease. You had you know, the entire season like our call it C suite if we were an independent business, but the most senior stakeholders in the business unit we’re pretty much on the phone with our product leadership organization, just trying to understand what How happened here and why and this is unacceptable, you need to understand, like, there’s that negative failure, aversion to failure that comes out. And I think there was something that’s like still below the surface a little bit. But um, we’re in an incredibly client sensitive business where it’s like you only get one shot to make a first impression, and then the client may not want to talk to you for another 12 months. So there is like this aversion like, if it’s not ready for clients, that might just do what you have to do to make it client acceptable. And that will take it from

Vlad G 56:37
the so don’t release it until it’s ready.

Peter D 56:41
Exactly, and that’s kind of you know, that’s kind of influenced my approach as a pm like I make. I consider each bug that we kind of get through into our release, like, is this a blocker? Yes or no? Or is this edge case valid? It’s like, yeah, it’s valid, but like Or maybe it’s like a super edge case. But in this case, like, I want to avoid kind of shipping bad code. And I want you to avoid having bad code go out under your name. So let’s take the time let’s do the due diligence. And just make sure that like anything that goes into release is buttoned up top to bottom.

Vlad G 57:16
So we’re nearing the wrap up of this episode. And I want to ask a couple of standard questions that I have for each guest on my podcast. On first these obviously, what do you think about working from home working remotely? How does it affect you if it affects you, given our current situation?

Peter D 57:34
Well, you know, the afternoons have been a little bit different. Like, I’m used to like my day starting I used to do in the mornings from home with like stand ups at a beam, you know, usually split between onshore or offshore. So you’re going on India time or talking to Europe a little bit earlier in the morning, but the afternoons have been where it’s just like, I really feel like I should be in the office right now. I’m kind of going crazy working from home all the time non stop. I don’t I don’t even Like I don’t like not being able to walk down the hall or you know, my UI UX designer is kind of at the end of our bench seating, or my, my product leader is sitting next to me in the bench. So it’s just like not having those people there to kind of just bounce off random ideas and just like, gut check a decision or like, get a quick hit, or a quick read from someone in the office really sucks, or being able to talk to my lead. My lead and my QA lead are both in our office so it’s just like not not being able to go over and ask them like, hey, how’s testing going? Or like, Hey, is this like story makes sense? Does this like scope make sense or anything that’s in here that you want me to like? Like a certain thing we can do to improve this? Not having that it’s definitely coming through a little bit more. And that’s been challenging.

Vlad G 58:44
Yeah, that makes sense. I I personally had experience working from home anywhere from a single day to just a couple of days, to full time to having been being in the office full time and I get it. It’s hard to change your habits when you can have face to face. So the subject matter experts clients or key members, and slack or teams or whatever it is, if you don’t have right habits, and sometimes it’s just not. It’s just not that close or not that personal and you’re feel like you’re missing out on something. So yeah, I get it. This is challenging.

Peter D 59:19
Yeah, the biggest thing is also, like, missing out on users. I mean, just being able to walk and do like a quick gut, gut check what’s on like, internal. Okay, what do you think of this?

Vlad G 59:30
And yeah, if your users are sitting in the next room, or in the same building, at least, he’s definitely easier than trying to connect to them. If they’re thousands of miles away. in a different time zone. I can definitely relate to that.

Peter D 59:43
Yeah, I guess makes you appreciate the luxury that you have that makes you appreciate the little thing, but overall, it’s been like, kind of same old, same old.

Vlad G 59:52
Great. And the last question for today. Actually, last question for me, is, do you have any questions for me so let’s see. turn the tables and asked me anything. Let’s just not try to solve the world hunger just yet. Let’s try to limit ourselves to something that can be answered in a few minutes. Yeah.

Peter D 1:00:11
You know, in your vast experience, I guess, I mean, have you ever had to like ship, like a product that kind of blew up once it made its way into production or like in, in general really just missed the mark kind of going completely against the grain of everything and discovery? And if so, how did you kind of manage that situation?

Vlad G 1:00:35
Thank you. That’s a great question. Yes, of course, obviously, you know, every product manager has failures has flops, has things that didn’t work out. This one in particular that I wanted to talk about. It was developed as a part of the concept of Endless Aisle. So I was working on the product that was a retail point of sale system. And it was popular thing back in the day to have an endless aisle. So if you order something online, you can get it to the store. If you order something in the store, it can be shipped to your home to your home. And it just the concept of Endless Aisle is that you order anywhere you receive anywhere. And part of mentality at the company I was working for was can we get it for free? Whatever that is, can we get it for free? Why do we have to pay for it? And I was looking for solutions that would allow us to do things inexpensively or for free or somewhere on a you know, shoestring budget. We were able to find a few solutions that worked for us. I developed that into a prototype. We’ve built it as a as an MVP. So we figured that these things are working. We started doing customer demos we started showing you to the real customers, we actually had a customer who wanted to buy it and he was willing to sign the contract for a year to start paying for it. And the whole thing came down crushing. When we figure it out, it is enabled to do certain things. And developing the required integrations would take a lot longer given the new idea that companies management had. So a basically literally in the middle of a road, we’ve decided to change wheels and everything kind of crashed. And it’s it wasn’t that that wasn’t that problematic. We were able to figure out what to do with a client. We were able to kind of gave them give them different incentives or different things to kind of please Him and alleviate the situation. Of course, as I’ve said, you know, if it’s a failure Yours, I failed to develop a product, which was a good thing because we figured out through the true experimentation in the market, we figured that this is not the the activities, this is not the product that we want to be in because it doesn’t really align with what a company wants to do. And at the same time, we were able to figure out that it wasn’t the product that was wrong. It was the market niche that we’ve attacked, that niche was wrong. We’re going after kind of low to mid level market, because we thought, but that’s where the numbers are. But given the complexity of the task, given the complexity of the problem that we’re trying to solve, it would actually make sense to go off their upper segment of the market and instead of having a product for as a software product, it makes sense to have it as a service. So we’ve instead of building a product and selling it to 5000 10,000 hundred thousand customers on the cookie cutter approach, we’ve dropped that that considered a failure. But we were able to transform that into a service offering. And through the service offering, we were able to make a lot more money. And we were able to get higher caliber customers. And we were able to stand up a whole new practice, which is, again, I would say it’s kind of one of those things where you have a failure that you turn into success. But from the product perspective as a failure from prototype, going to market, it’s it’s complete failure, because we did not achieve any of the goals. But as I was saying, every failure is a is an experiment reaching data. We were actually able to collect enough information to make things right to turn things around, make things right There was not a product it was not even you know, was not a my game my part of the town anymore. But we were able to use the information that we’ve collected and get something useful out of it. So Did that answer your question?

Peter D 1:05:16
Yeah, yeah, actually, do you have time for one more? Do we have

Vlad G 1:05:19
more? Absolutely. Like I said, we’re not limited. There’s no set limit to length of each episode, at least not yet.

Peter D 1:05:26
It seems like we got a pretty big experience across industries. But what would you use for a KPI for something that is not necessarily revenue generating? How would you gauge you know, what, what defines like a healthy product or a successful product? And in your experience when it’s when it’s come cases?

Vlad G 1:05:45
Well, that’s a great question. Thank you. So let me start by saying there’s a number of frameworks that you can use. As an example, there’s one metric that matters. There’s AARRR, or pirate metric. Then there’s Google HEART. But if I had to pick one, just one KPI instead of a framework or instead of number of metrics, I’d say it’s an adoption. And it’s pretty easy to understand that if the product doesn’t, doesn’t generate revenue. The only other way you can judge, judge if the product successful is if people are using it, if customers are using it. And that’s ultimately why you’re building a product, you’re building a product, not because you’re bored, although there are people like that you’re building the product because somebody needs a solution to a problem. And if your solution works, if people like it, then people are going to use it if your solution doesn’t work, that no matter how sophisticated complicated or elaborated your product is people not going to use it because it’s a bad product. The product is not successful. And I’ve seen this happen. Many times when people will force the use some sort of a solution they will force the use a specific Data Storage platform they were used to force the use a specific CRM and they hated it so much that they ended up using their own tools they were using Excel, or they ended up using on licensed or on, not allowed or prohibited methods of exchanging the data thus, endangering business continuity and security of the business. Because the product was not was not good enough, the product was not user friendly, because the product ultimately was not successful even when users are forced to use a specific product. So as I said, there’s a number of frameworks. There’s number rose weight and number of ways to measure it. But if I had to pick a single KPI, I would say it’s adoption.

Peter D 1:07:49
That’s, that’s really helpful. I’m transitioning to a project that’s a little bit more internal focus and not necessarily revenue generating more more geared towards usability and satisfaction. So it’s just helpful to get your point of view on there.

Vlad G 1:08:04
Glad this answer was useful. And that’s a wrap. That’s our episode. Thank you very much. Peter Dwyer.

Peter D 1:08:10
Yeah. Thanks for having me. Boy, this was fun.

Vlad G 1:08:12
Thank you for being such an amazing guest on our show. Hopefully we’ll hear you many more times. And I wish you luck in your career development and as always, feel free to get back to us with any questions. Any questions for Peter or myself can be sent to the email askvlad at VGrubman dot com or visit us on the web at https://vgrubman.com/podcast/

You’ve been listening to the real world project management and I’ve been your host Vlad Grubman – Until next time!

Real World Product Management – Episode 03

In this episode Irina and I are interviewing Vitaly – a delivery and design lead who works close to product enough to absorb many of the product management methodologies and approaches. We found it interesting to see delivery organizations adopt the product mindset – and we grilled Vitaly on it.
As always, if you have any questions or want to subscribe to our podcast – ask a question here

Episode transcript (courtesy of Otter.ai)

Vlad 0:00
Hello, everyone, this is Vlad and you’re about to listen to the third episode of the real world product management podcast. Unfortunately, as you’re about to hear, it was not recorded in the most ideal of the circumstances. So the quality somewhat suffers. We apologize for that and promise to the better next time.

Vlad 0:24
This is real world product management.

Vlad 0:33
Hello, everyone. This is third edition of real world product management podcast. We have Irina Irina. Hi.

Iryna M 0:40
Hi everyone.

Vlad 0:42
And our guest today is Vitali. Vitali, please introduce yourself.

Vitali 0:48
Hey guys, Hello, my name is Vitali. I am Associate Director of user experience design as you can. So briefly talking about myself over the last 15 years of experience As I gather a significant experience working with products and services, and I’m focused on the full user experience circle, starting from the early concepts to the final delivery. Today, we’re going to talk about a data driven approach and how we will implement it in our day to day work. Thank you, Vitaly, since you’ve already announced the topic, which is great. You said data driven approach to delivery right. So what is the problem? What is the problem? Why do we need yet another approach to delivery we’ve been delivering stuff we as you know, all the it in the world been delivering stuff pretty successfully for a number of years. what’s what’s up with the new data driven approach to it? That’s actually not very you and and the problem itself is not also very new. So basically, the problem that we faced with usually on any new project or product we have been requested to work with, or develop with is we are facing a lot with the pinyon Based thing So, many, many times we are facing the situation with somebody been told to deliver something to you not understand why you need to do this. Moreover, that sometimes you’re not agree and this is very often situation when people who are working a lot in the in the clients company so they are working for a long time, it’s hard for them to think out of the box. And they consider themselves as a subject matter expert with a huge amount of experience. And they think that they know the their users business users need is painful. And so basically everything about about the business. And here’s the service company, like where I work and please guide we have this number of ideas, this number of features, and please build it, build it for us. This is what we’re facing with like for every new project and what we wants to change here is that we started to ask him questions why So why we need to build this? And this? If we get the answer was the next question will be, Okay guys, we’ve built it. So how we will measure success? How it will identify that this feature, this specific feature that we built for you will work bulletproof for your customers life. That’s probably the answer. Okay. So if I understand you correctly, you’re trying to replace the opinion based solution was something that’s backed up by data?

Yeah, yeah.

Vlad 3:33
I have a question. As a person who came from a company, I myself came from company where product was built based on opinions and not data. I’m really curious to see how you guys solving the problem that I was faced back

Vitali 3:46
in the day.

Vlad 3:48
What do you do when there’s not enough data? And I imagine it’s not a new problem either. So what are you doing there’s not enough data to outweigh the opinion

Vitali 3:59
so First we try to get the data before build something. And in order to build something meaningful, something that will bring value, we need to understand what is the what is the problem. And basically, we need to come up with some problem statement or point of view. And to get to this problem statement, we need to put data in front and center to kind of data qualitative and quantitative data. So qualitative data, we are gathering by using the analytics. So we have digital analysts in our team for our health and loss. We give them this kind of data that will give you the understanding of how the current solution works in terms of analytics in terms of behavioral patterns. So basically, we get the answer what people do in your solution today, and quantitative data will give you the answer why? Why are they behaving like this? Sometimes? It’s very hard to answer this question. Using the quantitative data only after that we will give the 360 view on the problems that we have today. And we can compare it against the KPIs that we have in this particular business model of our client. And this is the foundation for any our hypothesis that we will work in the future. So then we build the hypothesis will probably eliminate the problems and improve the situation. So when we build the solution based on the hypothesis, we definitely will measure so we measure the success and we measure against KPIs KPIs is the core here and measuring the success will give you the understanding, if this feature is designed, worse or not, this is not like a shiny items or great look and feel. So this is not enough. Right What is enough is that you will get numbers numbers that this solution will work. Okay, that’s great. Thank you. Again, I’m just following up on certain things you said, you mentioned that you’re looking at behavioral patterns. And you’re looking at what people do. And to me, again, correct me if I’m wrong. To me that sounds like either applying user personas are your blind jobs to be done. Do you have any specific discerning ideas, but which one do you apply in which case or not really, we are shifting from personas, you know, to just to be down because we are working with a with huge companies, right? So they would have a lot of personas. And what we see in our wars of progress is our specific. This personas have so many overlapping, overlapping, let’s say jobs to be done, then the persona does not have a lot of sense to be considered. So what we can see there is more and shift or more is to just be done. format, which is very convenient for us to understand the users tasks and these users behavior. So it’s like working with the fungibility rights one of our clients, which is very huge company. One of the main tasks for their, for their customers is to find the right product in like very, very huge catalog like we’re having millions of products and fungibility is crucial there. And we cannot seek to any personas because they they need different products for different personas. But the they have become an issue on the ability. It’s like if I will give you an example so if we are waiting in the queue to buy a coffee, it doesn’t mean who am I it designer or a CEO of a rich company. We have the same jobs to be done – to buy a coffee. So that’s what we think is more efficient to work with than the persona.

Vlad 8:06
Yeah, I agree. And my experience was pretty much the same. We’ve used personas before. And that’s something that we realized that personas are not the way to go on this, but I just have to mention that if, if I’m co standing in line for coffee, I’m planning my day wrong.

Okay, no, that was that was. That was really good, insightful. Thank you. I wanted to bring up another. Another thing that you said.

Again, one of the things you mentioned before, you mentioned that analyzing why people behave like they behave, why people behave like this is a very complex and one of the biggest problems understanding why they do what they do. Can you from your point of view from your spirits, can you talk a bit more about how you guys tackle this problem? We Yes, we all agree is hard. Trust me, I’ve been there. I’ve been in your shoes as well. And I understand is hard. How do you guys tackle the problem? How do you What’s your approach? How do you even look at this? Like, where do we start?

Vitali 9:12
So basically, we talked to users. So you should consider user voice as one of the main source for your data. You can talk to users directly, you can talk to users read some variable themes from from the surveys from different surveys, if your client company has or you can, you can run this survey, or even what we what we also do, by the way, this is very interesting. Since the company that we we are working right now is it old white company, they are represented in many countries. It’s very, it’s very hard for us to go in every country and to get the voice of their users and to see the difference. What was the cultural differences probably or conscious Pacific Thanks. So what we did, by the way, is not only interviewing respondents and customers by ourselves, but we created and let’s call it the framework. So that including discussion guides and nology, to the people to clients, people who plan to plant employees, for representatives in these countries. And we gave them this framework in order to get the user voice. So they basically interviewed users using our discussion guides using all materials and send the raw materials to us. And then we were processing this materials and get the data from them. This is basically what we what we are working with this problem. Awesome. Thank you. Oh, by the way, this is from the list of questions that we have based on the webinar you did prior and which is what this discussion is based on. there any trends of using AI or ml for focus? Because we’re interviewing or in broad terms, are there any uses of AI and ml to process that broad data that you were receiving from your interviews? Yeah, we have this, you should see us. So they are in the very beginning. So actually, today, I had a call with our technical guys, how we can use it in our work. We offer some with some ideas, and we definitely will elaborate more on that, because there are a lot of perpetuities to work with it to use AI and machine learning work. But you know, I’m not technical guy to answer the question. Unfortunately, if you want me to connect with this guy.

Vlad 11:45
It’s more about it’s more about whether you have enough data or not. And then obviously, we’re not experts in everything. Obviously, we need to subject matter experts. It’s just the question of, are you guys getting enough data to even think about AI/ML. To give you an example, in one of my previous engagements, the team, the product management team, which the design was part of, was also tasked with doing the customers interviews. And some of our users asked if we can if we’re going to be using AI NML to analyze the data we’re getting. And we said, No, we can’t really use AI and ML to analyze the data, the data from the interviews we’re doing with you, as our users. However, since we’re are gathering data of your interactions with your customers, which is way more plentiful, where there’s a lot more data, and it’s voice data, so we can do voice to text and then process the decks for whatever sentiment analysis, natural language processing, all the all the cool buzzwords that we keep hearing over and over. We can do that to tell you more about your own customers. So whereas we can’t use it on you, guys We can use it for you that allow user but for our users, and that was an interesting pivot for them. And again, we’re not we’re not we don’t have to be experts in everything, but we need to know kind of what what’s in there, what’s not. Right. Thank you.

Vitali 13:14
Thank you.

Vlad 13:14
No, thank you. It’s It’s interesting. I was just wondering, just to wrap this one up, what amount of information were you guys processing? And how did you how did you even manage that? I mean, I just said it’s not a couple of questions. It should be pretty big number to give you a significant insight into what’s going on. Like, what how much data Did you guys have is it was that like, I’m just question has hundreds of surveys, thousands millions, what was just give us a ballpark?

Vitali 13:42
Yeah, it is thousands, if not millions, thousands, but we definitely use some internal tools to work with with the surveys. So we identify the most critical touch points. So basically, our most critical touch points are really identified. In the consultation, and what we try to do right now is to get let’s say from the from the surveys and surveys and surveys, by the way is also a touch to the specific dashboards and what we are trying to do is to get try to correlate this answers and still correlate this variability to the touch points that we have and basically focus on this first on the most critical first and then continue with it with others. I don’t know if I asked you a question but but this is what we are trying to do right now.

Vlad 14:37
Oh, yes, yes, you did.

Iryna M 14:39
So without your actually mention a couple of things you’re doing on one side he said that you are sharing these surveys and these will get in the real danger and and as inside you said that you’re doing the daily proposition Canvas, and it helps a lot. how those two things live together and what goes first. And it’s actually possible to feeling that way to position cameras when you’re remote and when we’re not talking to the end users, because most of the cases what most people are trying to do is actually to have a workshop, like face to face workshop to healing the cameras. So how did you overcome this challenge of being remote in your case?

Vitali 15:21
So, you know, unfortunately, we didn’t use the preposition carnivals in our work. So, for us, this activity was not very helpful. So it will give you some kind of understanding. But you know, we have a lot of other activities that we are using in our work. So they are very specific. We choose them based on the task that we are we’re going to solve but value proposition Canvas is too general and doesn’t didn’t help us a lot, unfortunately. So that’s why we we basically remove it From the list of activities that we usually do hold the client.

Vlad 16:05
Cool, that is interesting.

Iryna M 16:06
Okay, thank you

Vlad 16:07
though it was interesting, because, you know, in the classic product management, you do use those things. And so it was interesting to see a different experience. Thank you for sharing. I want to just go back a little in what you said because that we we had one of the questions from your webinar that also proposes and slightly different and I like different opinions. That’s why we have you guys on the podcast. The question says, I would actually argue the amount of research and time spent on research directly correlates to the level of uncertainty. In other words, way I read this, the more data you have and more time you spend on research, the more uncertain you are in layman’s terms. This means the more data you have, the less you know. Do you have any experience especially from latest products that you worked on, and latest engagements that would speak to that? To that the amount of sort of research and time spent on research really helped or did did it actually introduce some level of uncertainty.

Vitali 17:09
So, you know, we did different kinds of researches, and I more or less agree with this. So we spent almost the whole year on research. And I found myself thinking of it. Now, if we spent like, twice less time or even lay out a month on the research, it will be enough and we will get more or less the same amount of information to to build our hypothesis. I fully agree with this. We do not try to spend more than money on the discovery phase, even less, so we try to spend a lot more than two weeks. Of course, it depends on the problem. Of course, it depends on the problem that you are working with. But if we are talking about the I don’t know, like a feature in your application, not every feature, it’s not more just spent, like a month is of discovery, basically what we what I see from my experience you can do enough, not more.

Vlad 18:12
So let me throw a curveball here. You will you’re talking about is the law of diminishing returns, you figured something in three weeks. And in the next three weeks, you don’t really figure out anything new. So it doesn’t make sense to spend more time. That’s the Law of Diminishing Returns, so you’d not be getting anything. What this question asks really is, hey, we know a, b, and c today was started doing research now we’re not sure. Is it a A, B and C? Is it x, y, and z? Is it alpha, beta and gamma? You know, the more research we do, the more uncertain we are, the less we know. And that’s what yeah, it’s what the question asks. And it seems like you guys are tackling this by kind of doing this stuff and Okay, we know this Let’s stop here. And let’s build it. And that leads me into into the next question.

Vitali 19:07
Yeah, but you know, then it’s endless process, you know, you can do research forever. So you need to stop somewhere. And probably Yeah, you definitely will uncover some things that needs more investigation. Probably yes. But in this case, what we usually do is that Okay, guys, here we have a clarity here, we can proceed with some hypothesis. But here is more and more we need more investigation, and it will be like another talk. So we just need to split it into many different tasks. Otherwise, you will do research for for a year. I don’t know I must say.

Vlad 19:43
I actually agree with you. Thank you. But just just to follow up on this one, I agree with you. You need to break down the tasks to just get what do you stop breaking down? What level of product capabilities is that? The price or product level of the capabilities level at – I don’t know – a feature, epic, story, where do you guys place I research and which level of product detalization.

Vitali 20:12
Different level, it could be, it could be even the full task. It could be even an epic, or it could be an overall view on the applications. Basically what we did recently, we conducted thorough research for the entire application would require. And this this research was not the learning phase, but more like a measuring place. So this guy’s they delivered number of features, all of them were opinion based, because multiple stakeholders are involved, and everybody has an opinion about that. And what we did is that we evaluated this issues first. And then we believe that overall experience with application and with With this lines are the flavors. So what we find out is that first, this is work this features that can sense. So this is this was a long report. And another thing that probably guys, he needs more investigation on how we you will position your application. Because now what we understood during the research that for the customers, they did not understand why this application for there are so many features. So the official collateral is huge there. And they just not understand what this application for is the replacement for another platform for the website, or this application is augmenting this website. They just do not know.

Vlad 21:44
So the value proposition was not clear to them.

Vitali 21:47
Yeah, yeah. And this is a good example of probably to say that guys, look, here we go. This is our playback about these features, but what you need to investigate more deeply into the proposition, into the value proposition of your application about.

Vlad 22:05
Okay, thank you, then that makes perfect sense. Let’s move on. Because we keep going back to what would you said? Let’s keep moving forward. We’ve mostly talked about qualitative data, the qualitative data in terms of doing the product research and measuring products, success or product impact. What about quantitative? What can we talk a bit more? And he probably would make sense to spend a few minutes on talking about the specifics of this particular case that we’re talking about. What kind of product is that? Is that is that a web application? Is that a mobile application? So that we would understand what the quantitative data are we able to collect and what was collected in real life?

Vitali 22:51
It depends, you know, that every time we’re faced with the Winblad problem when we start working on the corner, Data data, we see the problem that the level of maturity in terms of regions and data in terms of toolset and all the things is not enough on client side. And first what we do is a kind of the firstly assessment assessment in this area and then we come up usually with with a number of improvements and only after that we start collecting data Otherwise, you will get the wrong data and based on the wrong data, you should be very careful here because based on the wrong data you will you can build the wrong hypothesis and this is not acceptable. So, firstly we do this. So, the next level next level is we work in on measurement plan. So, what is my what is a measurement plan? Is that how We measure success of growth product and that some specific feature related to so basically we are we are working with a KPIs that are level of levels of KPIs. Some of them are behavioral UX KPIs that are connected to the buttons to the call to action. So things like that. And other things are the lead in our business KPIs, we call them is the things that are related to the conversions. And then the next level. So the highest level is the main KPI. It’s different from from business models and business model, it could be revenue, it could be user base growth, it could be an NSS Why not? So what we do is that we try to connect all these KPIs and based on this, we create the measurement And every feature that we are working on and we are building, we connect to the measurement problem and the connect to the KPIs and look how effective and how efficient it is. I don’t know probably a little bit clumsy explanation without whiteboarding or having slides, but I hope you will get the idea.

Vlad 25:28
We get it. We get it, thank you and just to clarify, your hierarchy of KPIs is the on top of the most important ones are your financial or your your overall growth KPIs. Then you’ll have business KPIs, like conversion rates, probably daily average users, those kinds of things. And then you have behavioral level KPIs on the bottom, which are tied into individual control elements like Marco Island, then you know, Soho When people click this button or said button, and so on,

Vitali 26:02
okay, yeah, well, yeah, that makes sense.

Vlad 26:04
Yep. Thank you that that that is interesting. Thank you. Thank you for elaborating on this. So are you using KPIs for any kind of decision making, for prioritization, or using for anything else? or using KPIs for everything? This is a data driven approach to delivery what what what is the role of KPIs in all the other methodologies or all the other ways to prioritize and figure out what is it that we’re building?

Vitali 26:36
Yeah, so long story short, yes, KPIs are our priorities. So KPIs are connected to the business model and the clients are our business right. So they want their backlog they want their roadmap to be related to the business they are doing. What we are doing is that we are trying to bring value to the business with every feature that we are working on. And based on this, we are creating our roadmaps.

Vlad 27:12
So your your roadmaps are solely based on KPIs.

Vitali 27:15
Yeah. So they should be related to the KPIs.

Vlad 27:19
Okay. Okay.

Iryna M 27:21
So my question to you is about how would you align your KPIs. The vision and the strategy are that most probably was sat before you start your search, and then fees and gains and needs that you found that were identified during services during the research. So how, how can you align those three strings and how do they work together in order to build one roadmap? So we have KPIs, we have vision and strategy for a management team, and we have your search results right. So what goes first? What takes the priority?

Vitali 28:00
Okay, so I think it’s really, the answer is very easy. So the product vision, and KPIs should be not contradiction with each other, they serve the same, sort of the same goal, right. So if you have the product vision, then you definitely should have a business model. And the business models should definitely have KPIs to measure if this business successful or not. This is the first thing. And if you really are talking about the user needs, about the pain point the user have, what drives business is these user satisfaction. So if users are loyal to you, if they rotation tradition is very high, that drive the daily active users and more productive users TPS, for example, your user satisfaction is good is high, then it should judge your main KPIs like raving you or user base gross. So all Things are very, very connected and they are serving the same thing.

Iryna M 29:06
Okay, and who joins KPIs wholesale whole brings down the vision, each of the KPIs is if you and your team in thinking on on the client side. So how those are being created.

Vitali 29:19
We do this collaboratively with a client. We can probably come up with some ideas, then we discuss it together. And the final decision is collaborative decision.

Iryna M 29:31
I see, thank you. Thank you.

Vlad 29:32
So this is great. Yes, I had similar question in the list of questions that we got from your webinars. So thank you for answering those as well. I have another one that is sort of applied to most of the body of knowledge you’ve shared with us. So let’s step back a little from details and look at this a little bit holistically. One of the questions Here we have asked, was it challenging to explain to the customer The reason for time consuming research before actual build phase? And if I can expand on that, the real question here is how you justify research to the customers. Given that this this is effectively a consulting assignment. Most of these are, how do you explain to them that you need to do research and spend time money and resources on something that will effectively never be built? versus, Hey, I know what we need to do just go and build it. Like, what is the rationale? What is the approach? What is the take? And is there any data driven, material data driven? I don’t know decisions or data driven approach that can help you justify doing the research and finding more data versus Hey, you already have some kind of a data go and build stuff.

Vitali 30:57
This is this is an excellent question. By the way. What I can say that there is no like silver bullet of how to solve this problem depends on the culture of the company. So some of them are not ready to change, they have a fear of fail and fail is considered something that is very negative. A fear… how to say it…

Vlad 31:23
I see I see what you mean, it’s the fear of failure, not not as much as the actual failure, but the optics of it. How do you go there and tell them, oh, hey, we did the research. We had three hypotheses and all three failed, even though that is expected result, you didn’t expect to succeed all the time. Your upper management say like, why did they experiment? It’s they’re always failing.

Vitali 31:29
Go and do this, instead of experimenting.

Vlad 31:50
Right? Yeah. upper management will always have an opinion on what to do if you were failing constantly. I had a similar experience and it’s good that we do Talk about this, because a lot of stories that I hear on on all the product management talks are, hey, we came in, we were great, we solved this problem management loved us and built this amazing product. And what we don’t hear about is all these stories of failure and how management said, Guys, you keep failing all these experiments, why we keep doing this. And believe it or not, these are way more way more relevant. And they happen way more often it just just to relate. I had the same experience in one of my previous engagements where we would introduce the whole idea of product mindset, the whole idea of, Hey, guys, you need to run experiments, not all of them will be successful. And you need to make sure that you understand and management understands that some of these variants will fail and that’s a good thing, because it tells you what not to build what not to spend your money on. And that fear in the eyes of these people was absolutely stunning. So we would run an experiment and they would always report success to the upper management and said, Hey guys, you only built one prototype, you can’t really say you’re successful because you haven’t tried other things. And the response was no, we can’t try other things – we will fail, and then they will tell us that we’re not doing the right job.

Vitali 33:19
Yes, Yeah, I agree. So, a lot of stories that we are facing with. So then people are definitely feel like not very confident in this failures. And this is not supported by by their bosses. And yet another thing that I can say that some of them have already understood that they need to talk to users, they need to be data to be considered and they are okay with the failures. What they want to do is to understand how they can do this. And this is where we can help. Then you go Need to convince this guy, he probably needs to convince the details. But you don’t need to convince important the importance of research of discovery phase of getting the data. Of course, it’s easier to work with these guys. But there are different level of maturity. So some of them do like the baby steps in these directions. Some of them are more major, but it’s great to work with this guys. And if we go go back to the first kind of the client who had who have this to fail, you definitely can improve the situation. So you need to talk to them. You need to ask the right questions. This shouldn’t be a one on one crazy guy in your team who continue asking this question like boxcar mantas deserve, right? It should be a team it’s a team voice. So not only designer, not only BA, not only developer should ask these questions, but the team should ask those questions and then you might probably will be heard.

Vlad 35:07
Yeah. Yeah. That’s why we have this product manager role. And product management competency. and a product mindset. I keep repeating this and I, maybe it’s a self fulfilling prophecy. I keep saying that, the product manager is a thankless job if you fail is your fault. If you succeed, that is a team effort. So you rarely get the thanks. But yes, that’s the person not the only one. Like you said, not the crazy guy, but the product management is the person who will lead the effort, at least in my eyes, my opinion, as the person who leads the effort and talks to your executive tier about hey, this is what needs to be done. This is what its gonna look like this is you know, all the failures you guys gonna face, but it needs to be done. Speaking of which, I like to use another question that we have From from the list of questions we got from your webinar, that it’s really interesting because it kind of segues into the previous discussion. So you have enough data to convince people that this is this stuff needs to build that, that you kind of have enough data for data driven decision. And you kind of stepped over the part where you can identify whether the decisions have been opinion based or not. So opinion based decision is when just one person tells you, Hey, this is, you know, this is what you what I think needs to be done. And when you have a large enough body of data, you say, Hey, 80% of our customers want this feature. So I understand you’re an expert, but our customers want to do this thing. And there’s a valid you can argue that there’s a balance that proverbial Ford’s quote, If I asked my customers what they want, they’d won the faster horse they wouldn’t want a car. So so there’s a balance. It’s a balancing act between what customers want and what they really need. Maybe customers and I’ve been in that situation as well. I’ve been in situation with customers kept asking for a faster horse. That’s a really interesting question. What are the pitfalls? Or what are the disadvantages or what are the dangers, however you want to address this. Are there any precautions that you need to make when you’re doing a data driven project projects or when you’re building data driven products or using data driven insights, for prioritization? What could go wrong? If you’re using data driven approach?

Vitali 37:35
I will say that you should be very, very, very accurate in reading the data first, it’s very tricky and you can make a lot of mistakes here. What leads you to bad consequences. This is the first thing and another thing that you said very good thing that family opinion should be considered as well. So what we have, let’s call it not the date, let’s call it a dating forum closest to the cell. So, the term that sort of power that a lot of us use, right. So, the what what data gives you is just the data is just a probably when I talk to customer you get the opinion of this guy’s when you talk, when you look at the data, you look how this appears, where opinions are scalable here in your your solution product, but what you are what you what hypothesis that you are doing is basically your opinion is is what how you read in the data, and this is where we have where you should be very accurate and when you should be. You should be where where the pitfall is. So this is this is why what I think is the most dangerous place.

Vlad 38:57
So to summarize that you need to go Collect the right data and you need to be able to interpret the collected data correctly.

Vitali 39:05
Yeah, correctly.

Vlad 39:08
That we’ve seen that.

All right,

Vitali 39:12
it’s very easy. It’s very easy to manipulate with the data, you know.

Vlad 39:17
Oh, yes. And I think I’ve seen these this question come up, pretty recently, some of the product management discussions online. The question was, you know, what do you hate about being a product manager? And a lot of the reiterating answers was the ability to manipulate the data. So, you know, when when I’m showing something to my CEO, and he wants to see good picture, it’s really easy to do this because I can, I can give the data any which way I want. Yeah.

All right, guys, we’re almost out of time. I want to start wrapping this up. Vitaly, thank you for great answers. I really enjoyed the conversation. Here’s let me turn the tables over a little bit. Do you have any questions for Irina or myself? Wait, if you know if you weren’t there, you know, it’s not the other way around. Do you have anything you may want to ask? And given that Irina has vast experience in product management? And I have some as well?

Vitali 40:20
No, no, I don’t have any questions, guys. But I want to say thank you for having me here. So this is this was a very pro pleasure for me. And thanks a lot. I’m looking forward to see you again.

Vlad 40:33
Oh, absolutely. Thank you so much. Vitaly Irina, thank you so much for great questions. So thank you guys for being on our podcast and hopefully we’ll see you guys more will definitely want to hear more about data driven approach is specifically coming from the experience designer, not from the product managers.

Iryna M 40:53
Thank you guys, for having me here as well and Vitaly Special thanks to you for sharing your insights. I think the you you know, with your practical backgrounds and experience is, it might sound a little bit controversial, controversial, but that’s always great. And actually, you know, I think you’ve covered quite a number of topics without good cause some awesome discussions going forward. And thank you for doing that a lot.

Vitali 41:21
Oh, yeah, I’m counting. I’m counting for discussions. Thank you, Vitaly.

That’s great. Thanks again. Thank you guys.

Vlad 41:30
You’ve been listening to the real world product management and I’ll be your host, Vlad Grubman. Until next time!

Real World Product Management – Episode 02

Places to listed to the current episode:

In this episode I and my guest Irina Miranos – one of my colleagues – talk about what makes a product successful and how to measure success of a product, how to tell if an idea is viable, when to drop the development of a prototype to cut losses – and many other things.

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.

Vlad G 0:15
Hello, everybody. This is the second episode of product that is with podcast but already have first guests with me on on this podcast right now. Please introduce yourself.

Iryna M 0:26
Hi everyone my name is Iryna Miranos and today together as well as we’re going to go through a number of questions that we’ve got in regards to product management and hopefully that this will be something interesting not only for people in our company, but also for the outside world.

Vlad G 0:46
Thank you. Right. So first episode, I recorded the webinar that I did inside our company, I removed some of the proprietary notes and made it more generic. Still, we believe that questions that people were asking during that webinar would be interesting. Everyone. And as an extra, we’ve produced a bit that is specific to our company. And those people who work for a company will be able to hear it at the end of this episode. So let’s start rolling. First question that we have is, how have you measured success of the product? What is the ROI of the product for the client? And then I’m going to ask her some of these questions specific to the product that I described in the previous episode. I’ll go more generic and then Irina will add her own thoughts that are derived from her own vast experience of product management. So for generally for us, the ROI is one of the most important metrics of the product success and so is customer satisfaction. For data heavy for example, for b2c products, you can capture pure data like signups business funnels, through the website, heat maps and so on. And collect collect sufficient amount of data to be able to say Whether it’s product successful or not, generally a measure of the adoption for b2b products, it usually is not that easy, especially in the early stages, when you don’t have all the customers, you don’t even have all the customers exposed to the product, you’re releasing it to a very specific cohort of customers, just to see if it satisfies the need if it answers the specific needs of a customer. And in the case of this particular product, most of the data we’re collecting was qualitative rather than quantitative, which means we asked customers do you like it? does it solve your problem? The need something to be fixed? Do you want additional teachers? How well does it work for you? Those kind of things, so we did not have a specific ROI attached to it. We did not have any specific KPIs attached to it. It was just a generic. Yes, no. How well does it work? On top of that? This particular product that though I was describing the previous episode, relied on specific business process steps to be done in a very specific way. One of the benefits of exposing customers to this product or having these customers adopting this particular product is that their realization that those process business process steps were not done correctly. And certain specific data required for the product was not even collected to begin with. So it wasn’t it wasn’t a product KPI. But it was a way to validate if the current business process is correct. Once they saw it’s not they had to make changes in their own business processes first, or change things within their organization before they can even start using the product. You read. I know you have your own thoughts on this. So by all means, jump in.

Iryna M 3:44
Sure. So let me start by saying that b2b and b2c world those are quite different things. And in b2b world, you basically get a much longer period of adoption of her particular product, and it’s not always easy to conquer Alright, rights rights out there one since day one once you implemented the product. So with that, we only see that we measuring success of the product not only by rating you not only by fan finance numbers, but we also doing that by measuring some quantity two for metrics as you will have mentioned, and we said we often the looking for some kind of adoption metrics and adoption in the wide medium, because again, it can be measured in all the different ways you can go from a just a basic understanding the usage on daily, weekly, monthly basis, whatever it is, versus you can go through, you can go through any kind of the metrics that would indicate that people switch from the older system. So all the systems that are covering pretty much the same need and the same pain for user to your brand new product. So with that, again, you’re measuring adoption and that gives you a good insights into how popular your product is within their organization. Another metric that can be applied here is any kind of their optimization that is happening on the process side. So anything that you would see in the increased speed of processes in particular class, for example, or anywhere way where you can minimize resources needed to process certain aspects of the business that would give you good insights into what your product improved as well. And again, this is something that’s straightforward and much easier to measure. Start in week one or month one of your product implementation compared to finance numbers and financial aspects, that Samson that would come later in b2b world.

Vlad G 5:52
Cold arena. Thank you. Alright, let’s move on next. lashley next They’re questions that we received. They’re very similar nature. So I combine them both. One was for a full time frame from start to finish with the program. And the other one was how did your project last? When did you get your first real clients in production? So first thing, and I want to hand it over to reason here real quick, I want to make sure we understand the difference between projects, programs and product development, because those two are completely different things may be related on some level, but in the true sense of the word or not. And Irina, please chime in here on this topic.

Iryna M 6:39
Sure. So let me start by saying that within every product, you would see a project inside, you would never see a product that does not have a project sale, there’s always a project but then what’s the difference? Actually, project would have certain criteria how you recognize one really simple And straightforward. So first of all project has certain timeline in mind and milestones and deeds to which this project is tied to. It also has certain scope and budget. So there’s always certain limits for how long your project is going to take, how expensive it can be. Also, it has a team who is working on that product on hand side, this is something that’s very unlimited and that can leave for years and years and years and have multiple and multiple projects within it. We all know how for a number of products we are making different releases. So each of these releases can be treated as a separate project, but does mean that we are changing the product of course not. So all of that T’s within the particular product and some other aspects that again, would differentiate project and and product as how we are doing fine findings to be Basically your budget for the project is usually located on annual basis and it can be some other time range as well. For product. This is something that is continues with probably more frequent revisits. Usually it’s up to three months, every quarter when you’re doing some kind of the checkpoint and abilities and how you are with your resources and with your budgeting. And also, a big difference between project and project would be on metric side. Because again, for project what you’re measuring is making sure that you’re on time and on budget. Of course, visit certain quality and sound technical aspects measure rate. For product, what you’re measuring, its customer satisfaction eats any kinds of the profitability or success of the product. It also can include market share and the gain adoption rate and so on. So the metrics would be quite different between those two and I do know People quite often confuse the two that we should remember that project and product would require a different approach. How to do precision.

Vlad G 9:11
Thank you. Yep. Thank you from from my end. I’d like to add that I was part of the engagement recently that was, I was part of the engagement recently that was supposed to completely remove project and program level thinking from a teams that were involved in product development. In other words, that would be a milestone slash checkpoint, for the budgeting perspective for the budgeting aspect of it. So you guys need more funding? Do you guys need less funding? What is the current status and what else do you need to move forward? But the whole concept of projects that program would be completely removed from the product development and the only stream so to speak would that were there was to be left was a team based fine dancing. So think about it as the teacher team that is receiving steady stream of financing, and is developing feature capabilities or full products. And there’s no projects involved. There’s the programs involved. There’s just specific milestones or touch points every six and 12 months to adjust the budgeting for those teams, which is yet another way of doing things without any projects or programs, all for product development. And this is why we have different people on this podcast. This is the idea. So we can see different approaches and different aspects. So Irina, thank you very much for your perspective. I just want to add, since there was a question, when do we how long did this development process last? And when did we get our first real client in production? This particular product that was mentioned in the previous episode to nine months, roughly from When the idea was formulated when we literally spelled it out within the organization, to the launch date, it was roughly nine months. Within those nine months, we were able to validate that idea makes sense, it sounded solid, we were able to develop several prototypes, were able to engage with a champion customers. So we had production customers, even before product, keep the MVP phase. So we can really tell you, I can’t really tell you, we can really gauge

Vlad G 11:33
how long it took for us to get a first real client because we had real clients prior to MVP phase. Those were our champion customers that helped us shape the MVP shape the product and shape the products roadmap. So hopefully that answers that question succinctly. And let’s move forward. The next question we got based on previous episode is how do you decide when to park and initiative me After you have a working VP. So this is this is a really easy question, because the answer is obvious when it stops giving you proof, but it doesn’t give a value doesn’t present the value or it stops giving out the value. In other words, when it doesn’t work anymore, which means one of the things happened, we’re not able to generate profit or sustain a specific retention rate. Some of the products in the market are developed not to generate revenue, but to generate a specific retention rate. And I gave an example in the previous episode. It’s it’s the product that is not there to get new customers is because the product or feature of a product or capability of a product that is there to keep customers from moving away. And from a generic example it would be the whole story with Apple TV and iTunes. Yes, you may change, you may change the device you possibly can go to, I don’t know Android phones or Windows Phones when they we had them. But your library stays with the Oculus. So you’re effectively changed to the ecosystem that you had before. So that is the iTunes was there not to generate any profit, but to generate a specific retention, retention rate for the customers. Another. Another thing that may play into abandoning the initiative or abandoning a working product, is when you’re unable to scale when you can’t scale anymore. You have way too many clients or the clients started consuming too much or too much or too many of resources depending on how you measure the resources. And you can’t sustain that rate. Back in the day when Dropbox was a new thing. There was a lot of new startups that tried to do same thing. There’s a document sharing, you know, collaborative editing. And most of them died out because they weren’t able to scale. They had a product that was usable to extend they had product that was the customers were buying, but they didn’t have an ability or capability to scale. And one by one they died out. I was, I was working for a company that used one of those, we decided to use some donate product instead. Something else that was available from one of the major players. And eventually everybody stopped using it because it was slow. It didn’t sync documents correctly because a lot of customers overwhelmed the servers. And eventually we ended up using something generic. Another reason we’re not able to sustain the support similarly the similar capability to many clients using the system they have problems, but we can support them. We can scale the support organization or support capabilities to support all these customers and obviously customers are Happy this thought leaving leaving the organization to stop using product product dies out. And another thing after you have in the working MVP, and you decide to abandon it, you can’t sell it. And this is one of those things that really boggles your mind. Once you’ve if you’ve never done sailing, if you’ve never tried to sell the product to the market, is that you think you have a solution for a problem. He developed into a product and seemed like you validated and does solve the problem. But when you present it to the customers, customers say listen, yes, it’s a pain for us. But it’s not such a big pain that I’m willing to be to resolve it or I already have a process to resolve it. So I want to pay for it. And again, this another reference the previous previous episode, the industry that that product was developed in was a very thin margin industry. So this may be the reasons why you are unable to sell it not because your product is inherently bad. But because the cost of your product, or the price of the product is to is prohibitive to the current to the market that you’re selling it to got your customers are not willing to spend their money on solving this problem because they sending their money for something else. That would be another reason why you are unable to sell the product even though you haven’t been up dust over the solar problem. But hey, nobody wants to pay for it. Irina, you want to add anything to this or we moving on?

Iryna M 16:30
Let’s move on for now. Okay.

Vlad G 16:34
All right. Next question. In terms of prototyping, would you go by yourself here in the early stage, or would you suggest this to be a task for UX designer? What is what are your thoughts on that? I’ll start and then I’ll hand it over to Irina, because she has her own slightly different point of view, which is great. So we hear different different angles on this. Personally, I’d love to do everything by myself. So that I can project the vision, the product vision that I have directly to developers and tell them what I want to be done. But as my experience says, a lot of almost all my products always fared better. When there was a dedicated UX resource that designer or customer experience expert at hand, which means I’m not that great at design, I can and will project the vision, but it’s always better when the designer takes over and Russell’s out of my hands. During ideation prototyping stage, it’s fine to use some wireframes you know, just something you put quickly that quickly put together on the back of a napkin for you, I. But once you start showing this to other people, not just you, it’s always better to have someone call them better qualified in UI UX realm than you and again, maybe you are as a product manager. You’re coming from UX In that case, you probably would be would fare better than I did. But in general, it’s always better to have a UX person doing the UX personally, and and I learned this the hard way, by developing those products that I mentioned before. I’m a big fan of collaborating between people in teams, I always try to find people that would be would have proper skill set for the job. I learned the hard way not to be a UX designer and always engage someone who is an expert in that field. Irina, I know you have your own status. So please go ahead.

Iryna M 18:39
Sure. So I’m trying to keep us back, tied to b2b world and in most their examples, most of the companies that I see out here is basically we’re patient with the situation when they say x is done by specialists in this error, and sometimes it’s the whole separate department who is doing the work And dx and who is starting, doing any kind of the prototypes and team one together with the product team together with the daily routine, sometimes we see that this is people who are incorporated into product team because they have to stay in touch and close ties with product managers. Otherwise, you’re just not going to be successful. But still, it’s it’s passionately so dedicated people who are working with design. Of course, as a product manager, you can start doing some early prototype by yourself, especially when you need to sell an idea to business owners, for example, or to any kinds of other stakeholders. And the reason for that is the fact that it’s better much better to show one pager but just one image to them and then talk for an hour about your product and what you’re going to do about these, rather than to come with nothing show NASA and down to occur in that word. Believe me, people will seek to this image and the We’ll use it and reuse it many, many times after that. And of course, as a product manager, you do need to have a good chance for what good you access and what good UI is. But it still doesn’t mean that you need to do that on your own. It’s always great if you have such understanding what the good dx is about the curse was that it would be so much easier for you to validate any kind of the prototypes that are being done for you and then making the adjustments but it’s really hard to see up to date with all the transcend these era and, you know, it’s really hard to look at your product after you work them down for a month or two with fresh eyes and leash with fresh, understand and how it might look like so I do encourage you to have a separate, dedicated person or even department working on that. And as practice shows, this is what many many companies are doing They are quite successful in establishing the model when product team is collaborating with your actors. But you have served a CEO a separate service and they are doing drop based on their knowledge and experience. That’s

Vlad G 21:15
cool. Thank you. Yes, I so this is actually one of those topics where we are in complete agreement. My one of my recent engagements, actually had a UX expert as a part of the product management team. So, product management team was a team standing up on their own and it was consisted of a product manager and UX apart from a couple of other people. So they worked in collaboration and presented the unified vision of a product, including the user experience. Alright, moving on to the next question. The next question is to identify market and product needs. The proper market research is required. Did you do it yourself? Or do you use sources provided by the client or something else? This is a great question because I’m going to talk about experience. Within the smaller team. I know how it is in the larger companies, and I’ll let the arena speak to that. But I’ll focus on how small companies do this. And they don’t. The pain of being within a small company as as as much as it presents you with a lot of opportunities and a lot of flexibility. The pain is sometimes you can’t afford to pay for market analytics, or you can’t afford to engage with analysts from major companies. You can sometimes you can’t even afford a large enough marketing department to do this research for you. So what happened to me in this previous engagement, this specific vertical that I was working at, I had to work with subject matter experts either within their organization or from customers, which is what I briefly talked about the intersection of higher your customers. That was my marketing Research. That was what I ended up doing, going to people who worked in this industry for a while, who either had their own businesses or used to have their own businesses. And they have a vast amount of experience with specific things. And that is, it was the best that was available to me at the moment. And that’s what I used as a marketing research by had had to interview customers multiple times, either same customers multiple times or different customers, to keep probing to keep looking for those areas of opportunity for those pain points that customers didn’t realize they have because they got so used to the pain, they don’t really recognize that it’s the pain. And that would give me that will give me an idea of what the market needs, and how can we close that. So it was a interesting process because it opened up a lot of inner inner knowledge of the industry, but it also was are painful and not really efficient. Because there was a lot of repetition of things that were not interested. But people would just want to talk about it for a while. And that was really interesting in terms of how you extract the data that makes sense to you from all these interviews and all these interactions with subject matter expert within the company, and then clients. Now, I’ll let you take over and talk about the real way to do the market research in the b2b world right now, please.

Iryna M 24:32
Sure. So I probably should start by saying that there’s always ways how you can start doing market research in b2b world and in bigger setups, the right thing to do would be start looking at any kind of the analytics from Gartner, Forrester or any other such kind of organization that can give you a much clearer picture where you’re going to be in couple of years was the competition in this year. almost sure you actually can use such reports to understand how you’re doing on technology side and see and make sure that you’re actually choosing the right technology for a solution and where your competitors might be outdated in a couple of years. So just be curious, you know, the, the stack that’s in use bind them is going to be absolutely By that time, but was that realistic was saying when you’re a product manager, and when you’re in the market research stage, there are so many different activities that you would need to handle as a product manager and part of doing the external market research you also need to perform there in Toronto or storage or collect the information that you already have within your company. And that can come from your team who’s already been working on product for so long and can serve as a good source of information for you. And also as a product manager, you obviously like to talk to clients Coming back to this case that pleb mentioned that your current clients, your current customers, might have a pain that they so used to that they wouldn’t even realize that that’s a key. And this is something that can be fixed. So collecting with all such information might be really useful for you as a product manager to see how can you improve your future product or a new new version of the product or just a new product. So with doing all of these internal or internally piece and activities, you obviously will not have much time to get to go outside and to get access to these extraordinary markets. And with that, what we see happening in many, many enterprises is market department, marketing department helping product managers to do such market research. And that’s actually been up to you as a product manager not only in getting some free time for gain due to make To work and make happen, may come through some other teachers that you will have, but also that helps them to understand the market better. So later on in the game when marketing department will need to form a marketing strategy and go to market strategy, they will do rare to have a much better insights into what the market is out there was the competition was their target audience, what’s the market size and someone’s now collecting all this information upfront for you as a product manager would benefit this market and their department later on as well. So, with that, we actually do see that in many cases, there are some marketing department who is doing that also there is a role of markets and product manager who can take on such activities. It still doesn’t mean the product manager should not understand the competition and should not understand our The market out there is absolutely key. So the product manager should have really great insights into that. It’s just a matter of fact, that’s not exactly Product Manager by himself or herself, need to perform all of these activities and all of these actions. And you definitely can and true to use all the help that is available for you here in order to perform market research as quick as possible. Because other cases that we saw happening quite often as well, is the fact that market research on its own takes several months and probably by the end of this exercise, and by their time when you have results, some information that market research might be already obsolete and you’re ready several months later with your product. So this is something that you kind of help dads, you with us. might help you and might assist you in doing such market research mix and match apostrophe. But

Vlad G 29:07
thank you, I think we’ve a way of talking about this deep enough. So let’s move on to the next question. Do you please share how you create MVPs in the cheapest and the quickest way which tools for prototyping you use? Not sure if there’s a specific tools I would recommend, it really depends on a technology stack and the problem you had the problem you trying to solve. In this particular case, this product we’ve had a bunch of SQL servers will hold we had a whole Microsoft Office where Microsoft shop so we use Excel and SQL databases for processing some of the logic and presenting the results. For other VPS have used anything that is free and open source, WordPress, WooCommerce, auto, any Drupal any other open source components or systems we could find. This is not only for the previous For the product that I was describing, but for many enterprise worlds I had lived in before that, sometimes it would come down from really high level executives. Don’t bother with requesting specific resources, find what you can align, whatever is open source and free, show us how it would work and that we will use that prototype as a as a way to request the budget as a way to justify the spend that hey, we can use this for licensing reasons. So we have to build something like this on our own dollars. arena. If you have any other suggestions, please feel free to chime in.

Iryna M 30:39
Sure. So when they’re talking about prototype and you know there is no one right way how you can do that and how you can win the dq or D or upfront isobaric different key says froma going by a napkin exercise, you know when you’re meeting medium business owner, potential sponsor, and just Trying to draw to your product on the napkin in a restaurant. And sometimes it works. And also, on the other hand side, you can do really deep prototype bar your own using any kind of the tool that’s available to you, I probably should say that one of the most useful is still PowerPoint, and many people are still doing lots of prototypes and showing different flows within the PowerPoint. And this is something that everyone has available really great to share. And you know, no one’s going to question you why you’re using prototype, why you’re doing prototype in PowerPoint. So yeah, I do see that happening a lot. And sometimes it can have a level of complexity, whether you’re getting up to several thousands of different elements on one page or this slide. So you know, it might be really deep work through a prototype, even though it’s still pretty point out, of course, you can do that too by your own. So basically, the only seen, the only resource that requires is your time and your energy. If you’re in those pins and much money on that, as you can tell, if you’ve got some budget, you can hire some of their yaks or some of their front end developers or some of the UI representatives and developers and those people can help you to create a more realistic and clickable prototype. And this is always great when you can show Nolan the some pictures how the product will look like, but also kind of show some kind of the flow, how the data will go between different screens and so on. And that’s a real powerful tool as well and not to this level of details. It always great to share any kind of insights like that or any kinds of the early prototypes like that when you’re changing in kind of the conferences or any kinds of events where you can see your potential users And your potential clients. So when you have this level of details, it should be enough for them to understand what your product is about how it’s going to look like how it’s going to work. And in this is really powerful to how he can get in earlier feedback about your product. Although I would be cautious to go into saturated white would use, we use just black and white version done in PowerPoint because with that, you might cause even more confusion and many questions have been asked about your product. So when you’re getting out there with least the prototype, just be sure that itself explain that theory. And people can just clicks with that on this tab these without a bigger instructions or, you know, extortion around different elements and functionality that you would expect to have within your product later on. So again, product Typing can be an easy and cheap same. And you can spy, you can spend as much money as you as you will spend later on the product by doing the very detailed and extensive prototype. But that’s the matter of the question. And of the KPIs that you would have some time said, we’re spending money on doing number of detailed prototypes and then gotten to the point of when you have the right product to be built, rather than doing an early MVP or the project, spend some money there and then figure out that this is not Sampson, that won’t work. So no one right way no silver bullet played by the conditions employed by your budget.

Vlad G 34:46
What battery. Thank you. This was great. So keep moving on. Next question again. Which tools do you use for metrics tracking? And before I answer Before I answer this question, I just want to point out that it’s great that we’re focusing so much on tools. But in reality, most of the responsibilities of a product manager can be done with just with Excel or with pen and paper, as long as you have the right data in front of you. It’s less about tools. It’s more about what use those tools for and what kind of information you’re gathering. So for that particular product, we’ve used Google Excel with list of clients, their feedback answers and the issues they’ve experienced. Obviously, if you have a b2c product, and you’re collecting vast amounts of data, if it’s a web application, or if it’s an app, you can use Google Analytics or any other tool to collect the data points. But the end of at the end of the day, for stakeholder reports, you’re probably not going to have them log into Google Analytics or Adobe analytics or any other things. You probably collect those reports that put them into Excel against their other KPIs or other metrics that you’re tracking, or you just those screenshots. And it’s really not that important which tools you use, it’s more important how you present the results. And if you’re really tracking those metrics against the KPIs that you care about, I’ve seen many times where people were so obsessed with, oh, hey, we have bazillion visits to our website, guess what 90% of it is either bouncing or it’s bots. So you’re not really getting the actual customers or people who are really interested in your product. You’re just having a lot of parasite traffic to your website. So really, be careful about what you’re asking. You really care about the tools, you really care about what those tools are showing you there. Even if you have a short note, please feel free to add.

Iryna M 36:49
Yeah, so when we’re talking about metrics, one of the important aspects over here is to remember that you’re not measuring metrics just for the sake of measuring those. you’re measuring them for the sake of other understanding that up on the success pass if you’re doing things right or if not so much than to convert down to certain actions. So what I would recommend to do here is not to be that much focused on the tool. Of course, we can mention some of them, but just not to market a particular tools and software probably wouldn’t do that today. But rather emphasize the fact that you need to identify what are the key metrics for a product and measure those unconstant beezus. And make sure that you have certain very limited set of metrics on which are your report and remember that when you’re reporting beat, based on these metrics to your business owners, you shouldn’t use tons of numbers, they will never read through them and they will never understand that stick to probably three five metrics that you You probably not even measuring directly, but something that you are calculating based on the metrics that you see in your product, and then start reporting on them on weekly, bi weekly, monthly basis, whatever it feels right for a particular product. So with that, you definitely can use several tools. And this is actually what’s happening in most of the cases. But make sure that again, you’re not only looking at these metrics, you’re making them you’re converting them to certain actions. You’re trying to prove certain metrics, you have the key metrics as Samson that you constantly monitor probably on daily basis. And you have a minimal set of metrics, the Bleacher Report back to a business that would i would say as the most important aspects. Of course, in today’s world. When we are talking about desktop applications, Google Analytics would supply you quite a big amount of data about your product, although it’s not going to give you the full picture. And there are a number of tools available on the market that will help you to better understand what’s happening with the retention within your product, how you and dealing with the conversion of your customers, and so on. So, definitely look for Thompson additional to Google Analytics that would serve the need for a product and again, don’t be obsessed with numbers. Don’t be obsessed with number of this metrics, be obsessed with gatson success was your product went back to

Vlad G 39:42
thank you. Let’s move on. Next question really deep. Is it necessary to perform all these activities support? Or is it necessary to perform all these support activities by the product manager that all the time when are the times to grow your own product support team and as collide all these activities through them. And this isn’t the reference to the part of the story the previous episode when I talked about the responsibilities of a product manager and how Product Manager ends up doing a lot of things around sales support marketing, interfacing with developers, interfacing the legal team and literally everything there is to do as a business owner or a meanie CIO, the CEO of a product. And my take on this in allowing a small organization that I was a part of, you do end up doing all of that and it’s really amazing hands on experience, when you are responsible, literally responsible for all of that you are responsible to reach out to legal counsel and draft a contract. You are responsible for either producing a sales and marketing collateral, or having a very major stake, very major input on that down to individual items on that one. Or on that website, you It’s really amazing experience when you touch every single part of your product management responsibility scope. And it does give you a lot of new things to learn. Of course, nobody, nobody’s born with that knowledge. So it does give you a great learning experience and introduces a lot of humility to being a product manager. But if I was to isolate, at least one of the activities that I would absolutely recommend everyone would go through, it would be sales, I would absolutely encourage anyone who wants to be a product manager to sell at least one of their products, not just develop a control with the market and see what sticks, but actually go and sell it. If you’ve never done this before, it would really blow your mind because it presents you with absolutely different perspective on things. absolutely different view on how your customers perceive your product, especially if you’re coming from development of ba QA testing any other IT environment at any other key background? It absolutely, if you never own your own business, it will absolutely blow your mind. It’s one of those experience that you absolutely must have in order to be a successful product manager. I know Irina has a different take, which is why is great to have different point of view. So why don’t you talk about more enterprise and more of a b2b environment and expectations for product managers.

Iryna M 42:28
In today’s world, when you’re applying to your position of further manager, there are certain expectations from you as a person who is going to serve such a role within the organization that in most of their companies, you would see in that ask that product manager should at least work minimum serve as a subject matter expert about the product to all these departments like sales and marketing and support and content and the research department and so on. And with that you need to interact with all of these departments on some regular basis no matter what. So this is, I would say, the minimal ask that’s, that is out there. In most of the cases, though, it’s not again, to me just limited to the kind of the consultants about the product and service is subject matter expert, but to have a closer interaction with all of these departments. So with that full support team, you usually as a product manager, expect expected to provide a kind of the trainings and demos and any materials that would help them and user materials I mantle we’re here that would help to support team to promote certain feature or share more information with the anti users how that functionality can be used to how to use it, right. And all of this trainings are done. in various formats, but still, this is something that in most cases, you’re going to do, pretty much

Iryna M 44:09
every big release when you’re pushing out there some big functionality to some new, the capability within your product sale, again, at least trainings, full support team when they are talking about marketing, as we already mentioned earlier to the marketing department, and most of the cases is helping you to do the market just George. And with that, it would be really great for product manager to be involved to inter such activities. It’s not on the for the sake of extra help that you’re providing there, but also for the sake of product manager to better understand the market and we start to be able to interact with the end users and with the customers that are available in the market to better understand the market the way just about I understand what what are the pain points that all of these people have. And on that note, which really helps you to prioritize certain capabilities in your product, right, and then probably would help you to do the positioning right as well when you’re talking to your business because position and the external market the gain would be most most probably be done by the markets and department. So again, by involving into any kind of the marketing activities, you have much better understanding of your end users, their their pain points, and their needs, and and nazzer earrin and as a department that most probably are going to be tied with his sales. So for sales, these guys tend to ask you to sit in sales features, it doesn’t mean that product manager should conduct such sales features by himself or herself. In most of the cases, you’re just going to be there to listen to the requests from the potential buyers from the potential clients, and also to provide any kinds of needed assistance to the sales team answering questions that they might not exactly be aware of, especially that is tied to thats related to questions about any kind of strategic plans and overall vision for your product where it’s going to be developed in their new risto longer future. So PR sales, you also might be reviewing any kinds of the materials or at least providing the content for creating such materials because no one accepted the product manager would know better and would phrase it better, how particular capability what trustable what what can be least who’s going to be out They’re the next few months and then how we can market that and how why we Why did we decide to put data in the first place? So for sales department again, you’re helping these guys we send you kinds of the materials and contents of these materials and all sore tangent the sales features. This is there were general ask that you would see out there in the market and all of this is expected from Product Manager, at least to be either old and to sell or at max just Spencer in the capacity, certain percentage from time helping all of these departments and these are the support markets in the sales. They said the guys that all together Together with the product team would form the success of your product. So you do need to make sure that you work as one big team. But back to you.

Vlad G 47:53
Thank you Reena. This is great. This is a without the last question for this Sorry. That’s okay. We still have two more questions. So let’s do one short and one long response. short question. How do you decide whether it’s going to work or not the whole team? Or was it rather God’s feeling as a pm? And I’m gonna ask you, Rena, I’m going to ask myself to take this as in how do you decide at any stage of product development if it’s going to work, but the idea level at the prototype level, a team PvP level and past that? So my take on this is, it’s more of a collective conscious is usually it’s a group decision because you’re never work alone, you know, work in a vacuum. You have a lot of people, a lot of stakeholders, and you have a lot of input from all sides, from co CEO, to marketing to sales to development team, any team at any point in time they come back to you and say, Hey, this is no longer feasible to support your initiative to support That stage of product development that they were in, eventually you may develop a gut feeling. There’s a, if you read internets if you listen to other product managers there is this thing that’s called product managers gut feeling or product manager gut. It is the thing people have get to feel that it’s time to stop or even get to feel that it’s a good idea. But you really need to assess the 360 on the situation really need to understand every stakeholders vision, whether it’s sustainable to continue whether this idea whether this prototype whether this MVP or This product has reached the end of life and it needs to be phased out or needs to be canceled. It almost never in my experience, it has been never just a single person’s endeavor. It was always a collective feeling or collective decision. It was sometimes it was in together with a customer sometimes was within the company. What it was always an input from subject matter experts that Trigger certain decisions. arena if you have anything else, please add.

Iryna M 50:05
Yeah, so this gut feeling you know, this assumption that many people used to use and used to have a when you’re developing them bro that these these good product manager is a data driven Product Manager and the responsibility of the product manager is to collect enough data to me to actually remove this gut feeling to certain point and make certain decision. And they’ll be a scene sale with all the data that you have enhance, no one’s going to question your decision and that would make you unique and the great product manager into the world. So basically you need to be data driven. These guys healing This is something that you definitely will get once your guests and more experience, but that takes years and we say to you never can be wrong. So my advice to you the data driven as much as possible, and of course is going to be completely different data dependent on this teach on device lifecycle stage of your product and wearing you’re just doing present happen when you’re ready to monitoring a program that’s out there. It’s going to be data, different data points that you need to monitor and collect, but try to make it happen and then everyone will realize that there is no good or bad there was just that overseen that you need to do. Blood back to you.

Vlad G 51:37
Thank you. Okay, this is the last question and it probably will be one of the long answers. But let’s, let’s bear with us. What period do you build the roadmap for? It’s a really deep question, because there’s no right answer, at least in my book. Ideally, you build a road map, a road map, not an easy road map. For a period of up to 12 months, and again, in my book, you can only build a detailed roadmap this early in the game. And again, we’re talking about from inception to MVP. And the first first, you know, just just first stages first months of introducing product to the road to the market. You can only have a detailed roadmap for the first three months realistically, you can outline the features and capabilities that you plan to develop. By then each market will have their own say about things and you will need to adjust so doesn’t make sense to plan detailed roadmap further than the next three months. What you can do over the next three months is have a less detailed or so to speak, have broader strokes on the roadmap for about six months, past six months, they probably have very high level capabilities defined. I want my product to be able to do this and that’s as as detailed as you probably would go. Because again, as I said, market will have their say your stakeholders will reassess your situation, a lot of things may change in six months. So it probably doesn’t make sense to spend that much time and effort on detailed planning. Because no plan ever survives. Contact with reality. So it would probably in my book, if it makes sense could be very detailed, first three months, somewhat less detailed in the next three months, and the remaining six months to be very high level very capabilities and high level feature oriented arena, please chime in here because I know that’s a that’s deep topic for you.

Iryna M 53:38
Yeah, so there, there can be a really long, long answer from me on this question today, but I will try to cut it short. So I would say that their timeframe for a roadmap might be really different depending on the level of trust that your guts and you as a prototype is good when you would like to Have a little bit more certainty and when you have your business and your sponsors, making sure that you’re always doing great and you’re doing the right thing, the might be okay with you have an only roadmap for three months where you have more concrete scenes, you have clear priorities, and then you’re revisiting that on for example, monster uses. Realistically b2b world in most of the cases you would see request to have roadmap for 12 months. And why is it 12 months? It’s because we are still, even when we are building products, we’re still kind of tied back to this project mindset. And as we discussed, when we have projects, we have certain funding periods, and usually this hunting period is one year, so it’s 12 months and this is exactly for how long you would need to have your roadmap in order to be evil, at least somehow allocate in calculating budget that you would need for pro And of course, you know it, it’s really hard to predict what to go into be in your product and where you’re going to be working on in six months from now, even from six months from now. So with that these budget allocation and most of the cases is treated rather than just as a backup, it doesn’t mean that you’re committing to certain features that have put on your roadmap. It just gives you some boundaries, outside which it would be hard to go or if you’re going outside of these boundaries, you basically will need to have an extra ask and extra pronunciation with your business and your sponsors. So this is how you would treat that 12 month roadmap and again, this is what is happening in most of the cases and this is the majority of requests that you would have as a product manager in majority of companies. We still face in some cases when project manager sometimes sometimes has been asked for three or five years roadmap And realistically, like probably 1% of product managers have roadmap for such long periods of time. And the reason for such asks is coming from the cases when you are dealing with a potential huge client or when you’re talking to the, to the company who might become a partner, one of the vendors for your product with that, and these guys are usually asking for a longer term roadmap in order to make sure that your strategy and your vision for your product overall on the longer on the longer term is somehow in line with what they have in mind, just to make sure that you know, there are no one can predict in scenes and there are no things that actually completely not within their region and not within their roadmap. And for that you actually been asked to have some some longer term And as I said to mention here is actually the fight that you you, sometimes you need to have different versions of the roadmap, the one that you would expose internally to your delivery team, for example. And these guys will be happy with a shorter term roadmap and more concrete one that is more stable. And with that you can stick to three months roadmap only. You also want you to have a roadmap that can be externally shared, and that will be used by your sales team and potential your marketing. And that can be something, what can create but still not treated as a commitment and Emerson dad to you put him there, he will live to mature that game, it’s more or less stable. So it can be from six to nine to 12 months, in some cases. And then there’s there should be a vision there should be a strategy. There should be a roadmap that you’re sharing with your business owners and your sponsors. Of course, for these guys who kind of would like to show a longer term strategy, because you don’t want to come to these guys and say, here what we’re going to do in the next few months, and then we don’t know, we have no idea, you absolutely would like to convince them that you are in absolute control or dissertation. And we start, you know what you’re going to be doing with least you know, where you’re going to be looking which scene which strategy you’re going to be taken in, in a year from now. So from that perspective, you need to have this internally used roadmap for longer periods of time.

Iryna M 58:36
I saw cases when we were creating roadmaps for three in park years, I would say that the game it’s hard to do, most of us don’t do that. Most of us don’t have such roadmaps. But when such requests come in, be prepared that this is a good way of showing yourself as a strategic thinker, which is actually good, skillful, creditors right back to you.

Vlad G 59:03
Thank you Irina. I just wanted to add a one one note on the topic when you said the longer term roadmaps are used to align with strategic partners. In many cases that I’ve seen longer, longer term roadmaps are used as a bargaining chip, or your customers actually will have a chance to adjust your roadmap your longer term roadmap based on their their priorities or adjust their roadmaps based on your priorities. If you’re one of the strategic partners and your product is adopted as the National enterprise platform for a large enough company, they will have something to say about your priorities and things in your roadmap. At the same time, they will use it to prioritize their internal development efforts. And I’ve seen this happen more than once. Look at the partners roadmap, hey, this capability comes up q2 next year. So by that time, we need to develop something that will use that capability internally. So if you guys Sending by that promise, then we’ll blend certain activities around that. So it’s not just don’t don’t treat this as a you know, as a read only item, don’t treat this as your own thing. There will be cases definitely hundred percent there will be cases, where are the companies will depend on it, you know, college, the companies will try to convince you to change things around or will use it as their own internal guide on how to do things inside their own organizations. And of course, you can always, you know, trade things back and forth, hey, we’re gonna move this things around, but promise us you’re not going to ask us to do this thing, and so on. So that wraps up our episode that wraps up all the questions we had. Thank you very much arena for being here on the podcast.

Iryna M 1:00:47
Thank you for inviting me and having me over.

Vlad G 1:00:50
Always say absolutely a pleasure. And I can promise you, this is not the last time you’re here. Thanks, everybody for listening. If you have any questions, please email them to me at asked a lot at V Grubman calm, that’s dedicated email address that you can send these send the questions for this podcast. And if you have any questions for our speakers in this case is terina. Send an email to this address and I’ll absolutely share all the notes and all the feedback and all the questions with her and hopefully we’ll have her back. Next time to answer those questions. Again, the email is asked LOD at the grubman.com Thank you very much. It’s been a pleasure and let’s hope to hear each other again.

Iryna M 1:01:33
And by now

Vlad G 1:01:36
you’ve been listening to the real world product management and I’ve been your host Vlad Grubman. Until the next time

Real World Product Management – Episode 01

Episode 01: A Story Of A Product

Places to listen to the current episode and to subscribe to podcast:

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!

Today’s episode of product management podcast is about the in the life of a product, not Product Manager, a product, I’m going to take you on the journey from the idea, or actually a bunch of ideas to a single product that was taken to the market. First of all, let’s look at the product context. Let’s look at what is it that makes it a product in the context of this particular industry and Product Manager scope of responsibilities. This particular product was built for a wireless industry a few years ago. For those who are unfamiliar with wireless industry, this is the slide where you have your regular United States carriers, your AT&T, T Mobile, Verizon, or whoever else was there at the time. They provide services obviously, the cell phone services, they also dictate what kind of phones can be used and the procedures and how to actually Activate the phones how to which plans to use to owners of wireless stores. The owner of wireless stores can operate anywhere from one to 100 different wireless shops or stores where smartphones are usually sold where you can buy a phone upgrade the plan or sign up a new plan Adeline and so on and so on. They’re also warehouses the may or may not be associated with the companies that own wireless stores. In either case, wireless store owner pays the warehouse to ship the equipment to ship the phones and accessories to the stores. As customer goes into the store and buys a phone or upgrades the line or as a new line or buys a brand new service that earns the store owner a commission. That’s that commission is in most cases the only the only income or most of the income that Marla store owner has the income that comes from operating the shop the wireless store is insignificant compared to the Commission’s they still earn some kind of revenue based on sales of the accessories. However, cell phone usually does not bring in as much money as commission paid by the carrier to the wireless store owner for the purchase of the phone or a purchase of the new occupation of a new line or upgrade of the existing line. That’s pretty much as much as you need to know about this industry. As much as you need to know about the context to understand what the products and ideas were at the time and to kind of take get on with this journey. Additionally, when I look at parties that are involved, as I said, there’s carrier there is wireless store owner, the warehouses and the actual stores plus the customers who are buying this Interesting thing is this industry is the business with a small margin. What this means is there’s really little revenue generated by selling the phones or upgrading lines or any of the activities. So as the business with thin operating margin, these cut the these businesses store store operators are really price sensitive. You can’t really say hey, here’s another product that costs $10,000. Buy it and everybody jumps and buys it. It goes down to the point that people have switched vendors switch software vendors, if they see 510 dollar difference a month for subscription price. About 60% of this market is operated by mom and pop shops. What this means is about 60% of the market owned by store in Digital stores from one to three stores, businesses that operate no more than four stores. That’s about 60% of market. On the other side of the spectrum, about 20 25% of the market are large companies that own hundreds of stores. It’s kind of your premium segment, those companies can afford the expensive tools, those companies can afford expensive products. problem is there’s only 20 to 25% of the market operating, it was operated by those companies.

That’s most of what you need to know or all of that you need to know in regards to the business side of this industry. So let’s move on to what is product manager does what is it product managers responsibilities in scope of this particular product, when we’re going to talk about is someone who is operating their product as a business the person who’s responsible for all aspects of product success in a way although this term is somewhat from The fund a product managers emini CEO, he drives every aspect of the product, yet he does not get the CEO compensation. She as you can imagine, product managers involved in all sides of product from idea to development, to taking it to the market supporting interacting with customers, marketing, finance, legal, you name it. With that said, let’s embark on this journey. Let’s look at this journey of a bunch of ideas was sort of that to individual product to a single product that went to the market. First and foremost, what is the idea funnel? Obviously, you need to have a funnel, same as a sales funnel, if you will, where you have a bunch of ideas, you sort through them, you make sure that you pick only the right ideas and you get rid of wrong bad, dead in the water ideas really quickly, in our case in case of this particular product We started with about 35 ideas that we together generated that were addressing about how just 14 customers requests and by customer requests. I mean, our sales people went met with clients or had extensive conversations over the phone. And they collected all the asks all the ideas, all the requests in a pretty neat Excel spreadsheet. So everything was documented, everything was prioritized. Five people wanted this then people wanted that hundred companies asked for this. It was pretty robust list of as I said about how just 14 customer requests as we sorted and sifted through this list, we ended up with about 25 hot asks that generated about five prototypes. And those five prototypes eventually generated a single product addressing three high value points that we took to the market. So where ideas come from Since ideation is your period where a product manager goes and talks to a bunch of people, ideas can come from anyone. ideas can come from CEO CIO sales support, even marketing, the problem with CEO and CIO, they have way more weight to throw behind their ideas. So they tend to say, hey, let’s do this because I think it’s a great idea. Guess what? Not always, not always CIOs idea or CEOs idea are the best. In many cases, they’re usually loud because there’s the loudest person in the room being the C level executive. So, this is where a product manager comes in and tries to do their due diligence. This is where the product manager responsibility comes in. Where he says, You know what, let us collect all these ideas. Let us go through to analyze them and see which one hold water which ideas actually makes sense versus the idea. Is that just look cool? Sounds cool. But that feasible either from the market standpoint from an implementation standpoint, or just simply not interesting to the customer, and they are a solution looking for a problem. So what happens on the ideation stage? What happens at the stage where you generate all these ideas, and everybody’s excited, and CEO, runs around and asks, so when are we getting? What are we doing this? When can I look at this and see if it’s done? At this point, you ask yourself and you ask customers and you ask your subject matter experts? Would the actual customers be interested in doing this ideas would actually solve a real pain point for a customer? What is customer think about this idea? You can even mock up? We call it a fake demo. So you mock up a demo, when in the demo, you mock up a data or you mock up certain functionality, but you show something live at the idea stage, you can throw together a workflow or a couple of screenshots.

And you show the customer Hey, Mr. Customer, this is approximately what it would look like. Does that make sense to you or not really, you can discuss real ideas of the customer so you can prepare a serious pitch. As long as customer understands what you’re talking about, they should be able to understand and provide the feedback. So how does it work in the real life? We had an idea for a brand new messenger for alerts and updates. So we approach a customer and ask them Hey, would you be interested in getting these dedicated messenger that would not be that disruptive for with messages from your relatives, but not distract you from anything else, you will only get alerts and updates about specific transactions. For example, if customers come if customer comes back to the store and tries to return their phone, it’s the deal for a store. So a manager needs to be notified. If a customer comes back and wants to upgrade the phone to but downgrade the line, it’s a big deal for a store manager needs to be notified. If the store is running on a really popular phone store manager needs to be notified, maybe someone needs somebody above the store manager needs to be notified. So they can approve additional inventory purchase. All these things needs to happen in near real time. And we thought it would be a good idea to keep customer in the loop. Their response? Hell no. We’re being bombarded by text messages from our relatives. Men face Facebook messenger from friends Viber what’s up a bunch of others and you guys want us want to give us another messenger? Please don’t. So obviously after talking to a couple of customers, they said yeah was dead in the water. Again, this was mostly targeted to companies that owned a Hundreds 10s and 10s and hundreds of stores. Therefore the are limited amount of customers would be interested in in that service. Obviously, if just a few of them thought it was incredibly bad idea, we didn’t expect others to say yes, great. Give me give us more messages. next idea that we did a bit of a research nowhere near prototype just just kind of did our homework was real time emotional voice sentiment analysis, kind of put microphone right next to the point of sale, and try to analyze what the customer thinks what based on the tone of the conversation that they had. Obviously, it didn’t work out. Because these stores are enormously noisy environments. It would be very hard to capture specific customers voice. Customers tend to roam around the store trying different phones as they interact with a salesperson. So the idea was dead in the water because We could never guarantee that we’re going to capture long enough conversation to assess the sentiment. Another great idea that we thought we had was inventory trends. Obviously, apple, Samsung, other companies release their phones at a specific time. different models come out in different quarters, flagship phones always come out close to the end of the year to bad companies bottom lines. So there’s a certain seasonality to the data. And we thought we could analyze that. Apparently, it was way too hard to analyze. From a developer point of view, we didn’t have enough resources we didn’t have enough data and we company were wasn’t that invested into this idea. So the idea of analyzing and providing insights into the inventory trends sort of died out. Next cool idea on the on our list was employee schedule, in this industry, who process that transaction matters. Because the cell salespeople in the store are also commission based. So if john doe sells the phone to a customer, john doe earns $1. If he upgraded the customer to a more expensive plan, he earned $5. This needs to be recorded with together with a transaction as it happens. There’s also certain level of fraud going on with people a lot of transactions outside of their working hours. And people forget to log out of the transaction or log out of their workstation, and somebody else may process transaction erroneously. And it gets attributed to somebody else. So the idea of implementing an employee’s schedule was floated around, hey, if this guy’s only in the store from five to nine, or from nine to five, then he can only log in the transactions during that time. Obviously, we had

some kind of legacy functionality towards that. Obviously didn’t work. People wanted to business owners wanted to Create schedules on the mobile phones or from the convenience of the home, they didn’t want to be in the store to create schedules in the point of sale. And additionally, a lot of sales people travel between the stores. So even though your schedule may be from nine to five, store may be open for 1216 hours at a time and your first four hours could be in the morning at store a, then you would take a break and then your next four hours of your eight hour workday would be at the store be in the evening. This is usually popular with high performance sales people where they are being thrown into the stores to increase the store performance. So they will be thrown in at the peak times whenever that store experiences at peak time. So this was pretty interesting and very important problem. Very important asked from the customer. But a company that I worked for realized that we’re not in the business of creating software for employee schedules. We’re in the business of building point of sales. So first so the functionality of scheduling, creating work shifts and managing employees schedule was partnered out. I did the research as a product manager, I created list of recommendations. We interviewed a few companies and eventually picked one. And it was partnered as we created the third party integration, where schedules and work hours and all of that was kept in a separate system, but it was referenced in the transaction. So we always knew who processes to try the transaction and who earned that commission. Another interesting problem that we ideated and actually did go to early prototype stage was the Endless Aisle back and 2016 2015 it was really cool idea about Endless Aisle where you had a physical store and you wanted to connect it to the online e commerce store, where you can order things online and pick them up at the store, order things at the store. Pick them up online, wherever you are, it would create the seamless integration experience. We prototype pretty successfully, a ecommerce integration between the point of sale and e commerce store front end. At samples, we’ve realized that even though we were able to successfully build the prototype, we will not be able to scale this once a lot of customers get on board. So this is this was an interesting problem. And we were glad that we caught it early on. Can we build websites? Can we build ecommerce websites? Absolutely, it’s no brainer. It’s so problem we can we can do that. But scaling it and maintaining it for each individual clients with their individual rules with their individual problems with their individual inventories and creating that inventory. Integration was somewhat complicated. And again, this was not the business who were in we’re not in the business of building websites, or in the business of building point of sale. So that idea actually got spun off into a completely new line of business. We’ve created a separate division within the company, where people integrated our point of sale with online Rp. So that the RP system was not only taking care of ecommerce front end, but tracking, shipping and a lot of other things that were not in the initial prototype. It worked out pretty well. It was even in the first year when we went from a failed product prototype into a successful line of business. It’s earned almost a million dollar, almost a million dollars for a $50 million company, which is pretty successful line of business in my book, given that the prototype of a product failed. Another interesting thing that happened actually, from idea to a product was inventory integration with third party websites. One of the problems that our customers were facing was when they added accessories to their inventory. They had to order those accessories from several websites. Some of those websites are sanctioned, approved by the carrier so they must buy from those websites. And the rest not so approved, but there’s better pricing. So our customers store owners had the joggle kind of do a balancing act between purchasing from the stores that were sanctioned. And purchasing from the stores that didn’t really that we weren’t sanctioned but had a better pricing. Obviously, when you’re a wireless store with a bunch of customers, it’s not like you’re ordering a couple of covers for one or two phones, you’re ordering 10s hundreds, thousands, sometimes 10s of thousands items, we’re talking about hundreds of SKUs and 10s of thousands

items. Obviously, if you don’t have an integration with your inventory module, it’s a problem to import all this inventory. back into your system, how can you sell something if it’s not in the inventory, we were able to build an integration module pretty simple. That would just parse the receipt, parse the purchase order, or the parse the invoice whichever was submitted with the list of purchases will list of the accessories and generate a list of products SKUs and names and import them automatically into our point of sale system into the inventory module. Therefore, removing anywhere from 10 to 20 hours of work per month for almost every customer, completely removing and replacing it with three four clicks of a mouse on the specific web page. We gave that product away for free, it became our retention tool. In other words, yes, you can go and use another system you can go on to another point of sale provider, another point of sale vendor. But hey, if you leave us you won’t be able to use This tool. So now you have to hire that person back and have them spend those 1520 hours importing manually, all these all these accessories all this inventory, because you’re not using our product anymore. It worked like magic. And the end of the day, we found an idea that sort of generated interesting buzz had that fuzzy, warm feeling where we thought, hey, maybe this is an interesting thing. Maybe we should look into this. It was a commission reconciliation. As I mentioned earlier, most of this business sits on top of commissions that carriers that a business owners for selling phones and activating lines can use a carrier tells you how much you’ve you’ve earned. And you don’t really have much of the information to say, hey, maybe you’re wrong. Maybe you’re right. I don’t know. We found a way to reconcile what happens at the store, what actually which transactions were actually pretty That the store versus those that were recognized by the carrier, we figure there’s a big discrepancy. And our customers may be losing 10s maybe hundreds of thousands of dollars by not seeing these the these differences not seeing these discrepancies and not disputing them with the carrier. This idea kind of took on and that’s the idea we ran with. As I mentioned, there’s a lot of prototyping and this the prototyping is really magic phase. During the product development, this is the time when you can ideate and prototype and experiment. Hey, I like this idea. Let me try it. And this is the time when you can fail. And well I can say without repercussion. But the repercussions of failing at the prototyping stage is really, really minimal. Its product managers responsibility to decide which ideas are working They have a prototype. I talked briefly about how we validated some of the ideas early with the customers and with development team and with the industry itself. But at the prototype stage, you really need to be asking these questions consistently, constantly, every day, as you build your prototypes. Why are we building this prototype? What’s the value? What’s in it for me as a customer, that I’m going to need this? Can we actually build this? And this is this is one of those things when we were unable to build real time voice, way sentiment analysis can scale and this is where we failed with the idea of Endless Aisle and ecommerce integration. Yes, we can build it but we cannot scale it. This is work the way it’s supposed to work. This is the time when you as you prototype. You start doing internal demos, as you build these internal demos as you conduct these turtled demos, you need to find believers in your product inside each organization inside support inside sales inside development. Why? Because you’re going to need support of those people as you move along as you move further in your product developing activities. Most importantly, can this product be sold.

And this is probably one of those big eye openers for a product manager, especially if you haven’t taken the product to the market from point A to point z. There are a lot of times when you think this is a great solution for the problem the customer has, but at the end of the day customer says you know what, I don’t want to pay for this. If this was free, I would gladly use it. But I’ll save my money for something that’s more important. I’m okay with experiencing this miles pain, if I can keep my money and as I mentioned earlier that This is a thin margin market, people are really price conscious. So a lot of products, we were not able to sell, for example, the product that we gave away for free, it has huge benefits of being retention tool. So it had merit, it had somewhat of a of a revenue attached to it in the form of retaining the customers. But customers there was pretty, they were pretty loud about this, we don’t want to pay for this, we’re not going to be paying for this event, if it would cost $1 a month, we’re not going to pay for this. And as you prototype and as you go through this, you start building a product brief, you start building the actual product documentation that you will enhance and build on top of as you move forward. Your prototypes as you move forward with them not very early prototypes are the most important thing you’re going to use to sell for sales. Sales should be your biggest believer. If sales is not believing your product, they’re not going to be able to sell it. Even if they try, they will inevitably fail. Sale your sales organization there your sales people need to believe in your product the same way you do as a product manager. On top of that, obviously, before you commit resources of development team or the company, you need to prove you need to show that the product makes financial sense. Sales are the people who will help you make that financial sales. And as you do the demo as you having conversation with sales, you need to understand if they can sell this product if they want to sell this product so they know what they’re selling to they know how to sell this product. They are your apostles. They are your followers, advocates, ambassadors, and this is what happens in the real life as you continue to engagement, internal departments, you’re doing demos, you’re doing these prototypes, you’re having hot conversations, you’re recruiting subject matter experts from each department. You updating them on schedules, progress challenges, hey, I don’t think this is working, we need to do something else or help me figure out this part. You need to show progress, you need to show that you’re taking that feedback, however bad it is. And you need to show that you’re implementing this. And this is what happens in the life of this product that that we’re looking at. We had a VP of Sales who was extremely negative towards this particular product. His opinion was that we’re wasting time wasting effort wasting money on I something hypothetical, you know, a pie in the sky, where we should be dedicating all the effort into fixing problems with the existing product. What he failed to realize, or maybe he didn’t realize, but he didn’t really care about it. Was that we had a legacy product, that it was increasingly more and more expensive to fix problems with that product, instead of building a new one, and the new one was in the way was too far away, but didn’t really make sense to fix issues, minor, especially minor issues in the legacy product if we knew that the new ones on the way. And as I had these meetings, either official meetings or one on one conversations, whether it be of sales, he went ballistic, he went extremely negative on the product. He started pointing all the inadequacies, all the stupid things like he called them in the product. I deliberately didn’t say anything. I did not react. I just wrote down every single thing he noted. Two days, three days, five days later, I came back and I showed him and now the prototype that addressed half of those items. He’s still win all medieval me and still showed me Hey, this doesn’t work. This doesn’t make sense, you should get rid of this. And week later I showed him the next prototype that addressed some of

his concerns, major concerns. And as we went through this on and on and on continuously iteratively, he saw that I am not only taken aback by these negative feedback, I’m using his him being emotional and being passionate about why this product should fail to really uncover flaws in the product design, fix them and give him a new version, a better version to go on about this kind of fixing things that he wasn’t most upset with. And in about month and a half, two months timeline, it turned him from being the most vocal critic into most vocal supporters. I was able to demonstrate by eternity meeting and providing it taking his feedback and providing value and providing updates fast enough back to him that not only I am listening and acting on what I think is very valuable input from one of the most experienced subject matter experts in the field. As this was happening, I was able to start recruiting other sales people from his organization into ranks of folks who believed in the product who wanted to see it succeed. As I started talking to the salespeople, they started sleeping out to customers that hey, we’re working on this product is going to be really cool. I want to talk to you about it, but later when we have something to show you. And this allowed us to get to talk to subject matter experts from the customers, people who are actually in the field. We’re actually experiencing this, these pain points and who actually were able to help us Figure out the business process behind this commission reconciliation problem and build a product around that business process. As we had these ICT hoc meetings and conversations with multiple departments, we went from 25 product features to just five. Why? Because we wanted to simplify it. One of the things that I didn’t realize was as I was building this product, I became so knowledgeable about this problem, I figured it out to the depth and breadth that not all customers are able to understand. So the product was overcomplicated product was not bad. It was just so sophisticated that only I could use it. So we had to simplify it. So even our smallest customers, or people without too much time on their hands to learn new things, could understand what we’re trying to give them and use it within their own business processes. Hey, We’re doing this reconciliation, let’s look at this report. Great, understand everything that it says, Let’s take this as an action item and move on. And don’t forget, as you work on this product, you’re going to have a bunch of other activities. So you need to fit your other activities into this product, product building exercise. On top of that, you will have these disappointing conversations. When somebody like your CEO or customer or customers representative will ask you, Hey, this is great. But can your product do this? And you’ll be really puzzled if you just talked about them, hey, this product makes coffee. And a customer looks at it and says, This is amazing. But can it also drive me from New York to Boston? And you would look at this, like, how did this how does that even connect? And apparently it doesn’t, but customers like to ask those things. So you need to be prepared for those conversations. Once you build your prototype, To the extent of the MVP, it’s time to take your product to the market. And taking your product to the market is a great time to do this one activity that I absolutely love. And not everybody understands what it is. So I’m going to I’m going to focus on this a little bit higher your customers. Your customers are already with you, they already paying you money, they already interacting with you pretty regularly. This is more true to b2b segment rather than b2c segment. But this is also possible the b2c segments as well.

Have your customers as the subject matter experts, and they’re going to be the most vocal critics, they’re going to be the most the best subject matter experts, not because they know better, but because they don’t think in terms of is this product good. They think in terms of Can I use this product in my daily life? How do I apply this product to solve problems I am experiencing today. And customers will help you look at your product from a different angle from a different point of view. Can I use this in my business process within my business processes? Or can I use it in my daily life? Like I said, product got too sophisticated and too complex for people to use. So Can someone operate the product without knowledge and expertise as much knowledge and expertise of product management God, as he was building this prototype? Does it truly makes their lives easier? Or is it just again, a solution looking for a problem as you talk to them, and this is what happened with us. We were trying to hire these customers. We had a list of 10 what we call the champion customers. We got about three of them picking up phones and answering our inquiries to agreed to help us one of the customers after the extensive demo and asking questions. Literally laughed in our face and said, You know what? This is crazy idea. This is crazy talk. There’s another company that charges $1,000 a ticket thousand dollars a month for doing this. The I’m just giving you an approximate pricing point at this time. They they’re charging thousand dollars a month for this. And they know what they’re doing. You guys have no clue. I’m not interested, Don’t ever call me again with this crazy idea. And we only ended up with two customers who were willing to work with us. We created the cadence, hey, we’re going to let you use this. We’re going to give you all the data that we have. Give us an hour, two hours of your time a week or every two weeks. So we can walk through your data with you and understand what’s happening. And you will provide feedback to us so we can understand if the product makes sense to you. And we had these goals we had about four or five goals. We went through the data with the customer. This is our report, this is how we would look at it. This is your report, tell us what you think. Tell us if that if this makes sense to you. And as customers started realizing the value this as they started to realize that they’re getting a lot more value than they thought they would. People talk, people started talking. And in this industry, people know each other. And about a month and a half later, I have a salesperson approaching me and telling me Hey, remember that guy who we did the demo for? And he didn’t want to do it? I said, Yes, of course. He’s He’s really smart. He asked really smart questions, and I really would love to work with him. So yeah, he wants to he wants to, he wants you to show another della. He wants to see maybe you guys made some progress, and whatever else, and it immediately struck me as somebody thought somebody shared their feedback about our product, our building our product with him. And now he wants in again and again, since he’s one of our valuable customers who absolutely let him and we absolutely said yes, he was our champion customer number three. It was great relationship, he really helped us figure out a couple of issues. And as a part of it, we were able to build trust and build relationships. If at the beginning of this, they had no idea who I am, they never pick up the phone never returned my calls, never answered my emails. In a month and a half after doing these demos. They knew my phone number by heart. They called me themselves directly on my cell phone instead of a company number. They will always pick up my calls on the first or second ring. It was absolutely amazing and great relationship that I had with customers because they saw the value that I was providing to them. And they were really interested in seeing more and getting more And they were genuinely which surprised me. They were genuinely interested in success of this product.

Another thing as you’re building the MVP as you’re going between the prototype and MVP, and the launch stage, is your ability to iterate fast. And the only way this is possible, is when you expose your developers directly to customer feedback doesn’t mean all the developers have to hop on the call with a customer, but you should not shield them from the harsh reality of the feedback. If customer says, Hey, this is crap. It’s a crap new developers know it’s a crap. And sometimes it’s painful for everyone. Sometimes you iterate too fast at this stage, and it’s also painful to developers. This is how we actually lost one of our developers want to our first developer that we hired, we hired outside of the con Because our developers within the company didn’t have capacity, and the prototyping phase is way too fast for them, I was able to create four or five, seven versions of the prototype within the week. And if if i had i given this job to our development team, I would only be able to get one. And this this was not the speed I wanted to move with. And one of the first developers, the first developer that we hired for this for building the prototype, it was too fast for him as well. And he was not happy that we changed things so fast. It was like in the morning, he would give me the the new released a new update, I would go around, do the demos. And in the middle of the day, at the end of the day, I would go back to him and tell him Hey, let’s redo everything. This rebuild everything and start from the almost from the scratch because this doesn’t work. He wasn’t happy he quit at some point. He quit and the spot said I can’t deal with this anymore. I don’t want to do this. And we had to hire somebody else. Now it was a requirement to be able to keep up with us with a fast pace of change. As you work with your champion customers back to hiring them, they help you validate not just the existing prototype, not just the existing MVP, but the way you want to move forward. They help you validate your priorities and features. And as you move through, validate the existing prototype, they will voice a concern saying, Hey, we as we look at this piece of data, we really want to look at this. And if we’re answering these questions, we really cannot make a decision without this piece of data. And eventually, you build you build this idea in your head that hey, I need to know all of this together in order for my customer to have a specific answer as an example, As we started producing these reports, the product generated reports for our customers. Some of the customers were not processing transactions correctly at all. So a lot of fields that were supposed to be populated with the road data from the transaction were empty or blanks. Their system didn’t work. Obviously, the product didn’t work because there was no data to work with. But what the reports what the product demonstrated was not that, hey, your commissions are wrong, but your process your sales process at the store is wrong. So before you even go and challenge your carrier before you go and challenge your business partner, that should not pay me correctly. You need to fix a lot of problems in your own stores. You need to fix the problems with your salespeople. That was that was a revelation to them. We as we were building the product, we kind of expected that. But that was a pretty interesting turn of events for the customer. As they said, Hey, we didn’t know this was a problem. But now they do now they understand what’s going on. Again, same way, it worked with our VP of Sales when he saw how even harshest feedback that he provided was immediately taken into action. And product was fixed. The same way our customers were seeing that every time they will challenge us, or they will say, Hey, this is wrong, or this doesn’t work. In the in the few days in a week and a couple of weeks, they see an update, they will see the change, they’ll see that we took their feedback to heart and we addressed it. It created trust, he created this understanding between the customer and the product manager. And one of the things that I love to do for our customers is create magic. It’s when you show them hey, this is the problem and boom, this is the solution by bypassing the whole you know how we got their part. customers don’t really care how you solve the problem as long as you solve a problem for them.

They’re okay. They don’t really need to know they may be curious, but they don’t really need to know how you solve the problem for them. So by showing them hey, this is your problem. Let’s apply this magic potion. And boom, there’s a solution. They absolutely fascinated you love you even more. Everybody understands it’s a psychological trick customers probably most of all, but they still love it. They still see it as a Hey, he did the magic for us. And they love you for that. Now with the MVP launch, and everybody knows what the MVP minimum viable product in truth, meal viable product is not what makes products tender. So it’s what you can sell on the market as the minimum set of product capabilities that your class can tolerate, and they will pay money for. As we thought before, this is where full scope of Product Manager responsibilities kicks in. high gear You need to develop your value proposition, you need to develop your marketing strategy, how are you going to tell your customers that this product is out there? Right? You lucky if you have your marketing department but in that particular case within and I was the person tasked with developing marketing strategy from zero to two, whatever we did in the market, I was the person who created and conducted demos for customers for sales and develop sales collateral, one pagers, flyers, I had some help. I hired some help from the outside, but it was mostly on need to provide all the information to provide feedback, a circulate and make sure that everybody had what they need. All the tools all the collateral, all the demos operational, so that sales can sell customer support can answer questions, and everybody can work in unison. I had to work with legal making sure that We had all the contracts and agreements and MBAs in place. I had to work with customer support and training them how to support this product and how to make sure that they know how to answer questions, most popular questions or how to gather intelligence on what’s working for the customer, it’s not working for the customer, so they can give it back to me and I can process it and provide them with some kind of feedback, additional training or whatnot. I needed to conduct customer training. It’s not the business owner who’s going to be doing this who’s going to be one of the people in their company so I need to find that person and train them and understand their process of on this what is their process of reconciling the Commission’s and hey, this now you’re going to use us our product to enhance or rebuild or, you know, completely rehash or just a man to process however it applies. I was I had to it Establish a customer support organization, will we have customer support? I need to know have my experts. Everybody can answer generic questions, but I need to have a few people who could who could dive into details and really get to the nitty gritty details of what’s working for the customer. It’s not working for the customer, what’s missing and what needs to be that

as you launch the product, your MVP or whatever else was you launch the product. There’s a lot of things to happen internally, you need to hand over certain parts of your product to the other organizations, billing and finance they need to know how to charge you need to know how to process the contract, how to process subscription, support sales, operations, need to know when we start selling it, so when they can start answering questions when they can start telling customers about this new product. Then you need to measure everything in anything. You need to measure performance. Need to see what happens internally, and I’m talking about internal performance. Let’s say we just launched this new product, 5 million people signed up, and our support lines are choking because of that. So we should have, we should scale back. Or we should either increase our support organization or scaled back and only make available make products available to certain markets or certain cohorts of people. And that’s where Product Manager actually gets hands on with almost every aspect. Same thing externally as you earn, build trust within the relationships. You get as much feedback as you can from anyone and everyone. measure what you can measure. It’s really easy to measure things. When you’re doing b2c product, you can just throw in analytics, and at least that’s there. With b2b products. When you’re selling piecemeal one by one. It’s hard to measure performance or measure accrete analytics automatically. But you still can collect some kind of feedback either through sales or through support. You see the level of tickets being raised for this product, you see number of questions, you see which questions are the top 10. And at least on that level, you can understand where you at, right after the launch, you can measure sales performance. If you see a lot of, say a successful sales, that means you hit the spot, if you’re seeing a lot of inquiries, but not a lot of sales. That means either you’re not clear on the value proposition or your sales don’t know how to communicate product benefits. So you can go back and adjust, which in essence together makes up the overall product performance. And as we’ve launched as we kind of looked back on the whole process, the whole process took us about nine months from Roy idea when we just started charting first first sketches of this idea on the whiteboard to the moment when we sent off press release sent out old email communications and we had an official launch date, about nine months. Just a couple of lessons that we’ve learned. The only stable thing in product management is failure. And as a product manager, you will fail at every step of your product building journey. And when you run out of steps to fail, you will find new steps and new ways to fail. And this is probably the most exciting thing because

you learn so much from the failures. It’s a scientific thing, obviously, you learn so so much from failures that you won’t be able to learn as much from success. simplify everything. As I mentioned earlier, we went from 25 features to five and we actually got more successful in introducing our prototypes and VPS to customers customers and they’re still with the product does better and faster when we had 25 features, customers were all over the place this So does it do this? Does it do that? When we got them to the five feature point, they immediately grasp what they do the product is, oh, it solves this problem. Cool. Let’s run with it. It had to be dumbed down to customers level. But at the same time it made customers. It made it easy. It made it easier for customers to understand what the product does, because they don’t have all the time in the world listening to you talking about all the features. And guess what manuals is better than automation. When we just launched the product. We were sending out the product was basically generating reports. So instead of giving customers access to the product that was generating reports, we were manually sending these reports to the customers and then calling them with a follow up call and saying hey, we emailed you this report Monday. Today’s Wednesday, I’m pretty sure you haven’t had a chance to look at it. So let me take an hour of your time, two hours of your time walk you through the report, let’s analyze, let’s see what was going on that generated tremendously positive response. Because not only we were given them, giving the customers what they wanted, given the customers the value from the product, we also were proactively teaching them how to use it, and how to extract maximum value from that product. That was probably the most important and most valuable part of this conversation. Plus, we’ve got so much feedback by having these phone calls and face to face with customer that we would never got if we just automatically sent out those emails, and waited for customers to call us back.

That is it for today. Thank you for listening. Hopefully this was interesting, and I’m looking forward to creating more content for you. Check out my website: Vgrubman.com. My name is Vlad and this is my first podcast about product management. Thank you

Transcribed by https://otter.ai