Real World Product Management – Episode 16

Picking up where I left off a year ago. New episode with just me talking about

  • what happened to the podcast
  • how to become a product manager
  • what to expect in product management interviews
  • tools vs process
  • PRDs are bad for business

You can now WATCH ME SAY THINGS! In the glorious HD. With sarcastic subtitles!

You can subscribe to podcast on your favorite platforms

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:08
This is real world product management.

Vlad G 0:17
Hello everyone, my name is Vlad, you probably watching this or listening to this, recording both the video and the audio separately. So it could be a podcast and a YouTube video. I am a host and the author of the real world product management podcast. I started it in March 2020. Right in the middle of a pandemic, sort of, technically, it’s a sort of cope with pandemic and the whole thing. And I the podcast was pretty had a pretty good run, we did 15 episodes, I almost always except for the first and last actually no scratch that acceptable one first episode, where I was doing things solo, I believe every single episode after that, had someone one or two people, as guests, this is me tried to restart the podcast, the trying to sort of restore and continue the work I was doing and other people were participating in almost exactly a year after I started after I stopped doing it. Last episode went out June 17. I’m recording this on June 7, exactly here after so we’ll see how that goes. As, like I said, I’m not just restarting it as if nothing happened. I’ve learned a lot I’ve seen a lot of things, know that a lot of feedback sub doing a lot of things differently, going to try a lot of new things, previous 15 episodes, let’s let’s go the season one I did mostly in the same Canvas, same approach, same, you know, hey, this is the guest, they had something to tell us. We’ll listen to the story that the guests is telling us and then we ask questions, kind of sort of like an interview, but not exactly. I’m going to try to do in different things from now, one, maybe make it shorter. I remember, some of the episodes ran for almost an hour and a half, I’m looking to record more episodes, but they potentially going to be shorter. So we’re looking at 20 3045 minute episodes. But maybe, you know, once a week, twice a week, sometimes we’ll see how it goes. No promises, but I’m gonna try to do different things. I’m going to try doing live videos, try leveraging community a lot more through the last year, the company I was I’m still working for by the way. We’ve built an amazing community of people have amazing community of product managers, a lot of them have tremendous amount of experience huge lists of things they were able to achieve and they were able to accomplish. So hopefully, I’ll be able to drag some of them kicking and screaming onto this podcast. I know some of them were interested, as Firstly, I was not available to continue the podcast. But hopefully now we’ll, we’ll be able to work on that. But additionally, the community on Reddit, which is what prompted me to start the podcast in the beginning, the community on Reddit began to be a lot more active. I’ve seen a lot of interesting people. I’ve seen a lot of interesting thoughts. One of the one of the cornerstones of this podcast was the guests should not agree with the host or host is not always agrees with the guests. And that’s what makes the conversation interesting. That’s what I’m seeing on in the community. So I’m hoping to drag in more people from Reddit product management subreddit, see if we can give them a platform to express their opinions. I’m actually if I’ll have time today, I’ll try to talk about one of those topics that were discussed that piqued my interest. Again, like I said, No promises. We’ll we’ll see how this how this is gonna go. And we’re still you know, in and we’re still in COVID pipe pandemic, I’m not sure if it’s called been called off or not, but people still cautious on moving away from New York to a whole different state. So being there physically may not be an option. So we’ll try to leverage online collaboration tools that

Vlad G 4:17
They’ve gotten… we don’t really remember but when I started working on the podcast again, I figured that Hey, remember how last year we were struggling with, you know, doing the recording or bringing several people in and getting with quality recording so we can post it as a podcast. I remember going through the WebEx going through teams Zen caster, zoom, we’ve tried a lot of things. And it’s surprisingly it’s gotten so easy now, just the year after a lot of online calibration became almost like a non issue. It used to be a lot harder for us. I remember that’s the backstory, why what happened and why we’re restarting the podcast, podcast, as you remember, cold real world product management, the goal still the same, bring in a real world perspective on things that people who are close to product management and maybe just starting in product management. They think that it’s some kind of glorified position where you just tell other people what to do when they just hop, hop to it and do it. We try to bring in the real world perspective on things. So having said that, one of the things that I always wanted to talk about is, and I know it sounds corny, but it is one of the things that I wanted to talk about, and I felt pretty strong about it, are the top asked questions. And we’ve done a number of online conferences, the company I work for. And there’s a there’s always a number of questions that come in. And they’re, they’re they basically divided into two parts. One is tactical, so specifically about the topic has been discussed or a question about something somebody said during the presentation. And then there is a whole set of strategic, kind of like strategic questions, and they all start with one single question. How do I become a product manager if I am a blah, blah, blah, and that blah, blah, blah, can be literally anybody. If I’m a software developer, if I’m a business consultant, if I’m a BA, if I’m a UX designer, if I’m experienced designer, if I’m a janitor, how do I become a product manager? I had a slightly different opinion year last year, and we talked about it on some of the some of the episodes, that opinion has changed, guess what people do change their opinion. I know, that’s not really, you know, cool thing to do. Everybody now has their opinion, and they’re sticking to it. I don’t, that’s kind of one of the things I bring to the table is I will make mistakes, I can make mistakes, I do make mistakes, and I try to fix them. And I try to if if my opinion was a mistake, or if I had to adjust my opinion based on facts that absolutely will do that. One of the things that we did discuss back in the early episodes was how do you become a product manager, most of our product managers back then came from Ba, this is no longer the case. We are hiring off market we are hiring from a lot of other sources. We do hire from experience design, UX design, business consultants, one trend that we’ve noticed, not in us in some other geographies is that people are coming from being in within the general management, sort of line of business manager, oh, bank, you know, CFO, Director of Operations, things of that nature. Apparently, one thing is it pays better I again, it’s not us. So situation is slightly different in other countries. And another thing is that experience that they had in those roles helps them become product managers around it for software products. And it helps them get things moving, get things through, because they have the business acumen or they have that understanding of how things work in the business or the in their in the enterprise. And it helps them get better at this job faster. If you compare someone who comes from ba background, they know very well how to write requirements how to how software works and how stuff has been built. But they have very little if any understanding of how business is conducted, what is

Vlad G 8:50
you know, me doing business? How does that whole thing work. And that’s that’s kind of the part where they struggle the most these people who are coming from other non it backgrounds, but they have a lot of business acumen, they’ll have a lot of business knowledge, they tend to be successful because they understand that overall big picture. And they get very well positioned in terms of Hey, I know how the business works, just tell me what I need to do to get from the you know, one step to another to another in order to make things happen at the business level. So people do get there successful if they come from non product or non it background. They come with a business background. So how do you become a product manager? You learn you, I recommend reading and taking classes I’ve conducted about hundreds of about 100 interviews and assessments in the last year. So that year that I was not producing episodes, I was very heavily interviewing people. I was very heavily participating in a product management assessments. So the difference between interview and assessment is when the company hires someone from outside from the market, it’s an interview. If we want to promote someone from within, and our company does that a lot, we run an assessment. So it’s kind of like an interview, but it’s internal interview is a different format, it’s a lot harder, believe it or not, it’s a lot easier to be interviewed and get an offer, if you’re on the market than it is to be to pass assessment and get promoted internally. So I’ve heard of cases when people leave, would leave the company for a couple of years, get a bit more experience, and then come in, sort of from the market and set up from within and get into the position, they were unsuccessful in getting internally dirty little secrets. So a little bit about the interviewing and assessments, I’m going to kind of bundle them together because ultimately, the goal of either interview or a set or an assessment is so understand your skill sets and their send your How does your mind work? Right? How do you think, and I use suitable for this position. And so that’s what hire for a specific position, sometimes we’ll hire, because when they’ll will, will get positions in the specific

Vlad G 11:23
areas specific knowledge, the main, very rarely, we stumble upon. Someone who’s a generalist, somebody who can be put into almost any role aside from very specialized give you an example. I’m not like a super perfect generalist. But with with my experience most my set of skills, I can put in general, finance, healthcare, retail Telecom, very general software, enterprise software, is a set of domains that I can fit because I’m a generalist, but if you want to me, if you want me to work on a very specific domain, for example, clinical trials within Life Sciences, I’m not sure guy because I don’t have sufficient depth of knowledge in that area. Or, for example, if you want me to work on something that’s very consumer oriented, that requires a lot of graphic design background or industrial design background, even though I may manage, but I’m not going to be a good fit, because I lack those specifically those design, industrial design or graphic design skills, that would be preferable than a candidate for the role like that. So like I said, it’s really rare that you get generalists off the market or internally, but they do exist. And we try to maintain kind of a healthy balance. So and the trick is interviewing a specialist, if there is a specialist is easier than interviewing a generalist, because with a specialist, you know, specific, their specific domain knowledge, couple of domains. And you can kind of either drill deeper into that area, or you can kick them out of that area really easy and kind of take them out of their comfort zone and make them think in terms of pure product management, pure product pathologies, without relying on existing experience with a generalist is harder because they’ve seen so many things. They’ve seen so many different things based on different domains, it’s hard to get them out of their comfort zone. I’ll talk a little bit more about that later. But I would generally break down the interviewing assessment, again, doesn’t really matter into two pieces. I probably want to talk more about the interviews, because generally public don’t get assessment general public gets interviews, when they tried to get into new work. And I have been on both sides of the table. I have been the interviewee and I an interviewer a lot. I have the I have gone to interview for for other roles. Because I want to understand what else is happening on the market and how people interview for this role. Obviously, early in the days during the pandemic, there were all kinds of things were going on. I haven’t interviewed for about a year, but I don’t think a lot of things change in terms of the interview mythologies, the acceptance rates have fallen, but the methodologies are most likely the same. I don’t think they’ve changed in the year. So there are two types of interviews a product manager will go through when they are applying for product manager role. And I want to make sure we’re talking about product managers, not product owners. There’s an interesting split in the product owner roles. This product owner as an agile role, which is a team member of the agile team. It could be senior lead ba developer or somebody who understands whole concept of thing or capability of feature whatever he was working on. And they represent the team in as they are a teams representative, they work with other teams and with the product management office, then there’s another meaning to the term product owner. And that is a very senior person kind of like a business owner and the sense, but they said, because they own the product, everybody tends to call them product owner. And they are senior, usually senior executive at the program or even higher level where they get tend to make business decisions about the product. And they could be senior executive director level, they also get to be called the product owner. We used to ask this question we still do sometimes. But we try and tried to phase it out. Because especially in the interviews in the assessments is different. But in the interviews, it’s really easy to fall into this trap of what is this specific companies calling a product owner or the calling product owner, a person who assists with the developers and gets the rights, their user stories? Or are they calling a product owner, a executive director of operations, who makes calls about a Hey, this product is going to do this in three years, boom, go. So that’s the trap. Like I was saying, there are two levels of the interview. One is the peer interviews where you get interviewed by Delivery Manager, project manager, Program Manager, and obviously, your fellow product managers who are tend to be on your level, maybe you know, a little higher, a little lower, but generally they’re your peers. And then there’s an executive interview, that’s where your senior product owner or, or your executive director of operations come in, and either review, and sometimes these occurred the same on the same day at same time, sometimes they’re different. Hope for your sake, they’re different. Because it would suck to have both on the same time. And what what are the questions, right, what are we expecting to see from fellow product managers? And what are we expecting to see from executives? What type of answers, but sometimes they ask the same question. I love it when it happens to me, because it allows me to leverage this understanding of the difference. But obviously, you don’t have to love it. You can hate it if you if that’s what you’re if that’s your thing. But sometimes we do ask questions like so how do you resolve the conflict? in whichever form that question is asked? How do you how do you approach building a roadmap? Again, there’s a number of ways to ask this question. What type of questions are coming from fellow product managers? And what kind of answers we expect to hear and ultimately, what we’re looking for in in the interviews? Well, the questions that are coming from product managers, I usually try to understand how much the you know, in terms of product mindset, in terms of product management technologies, in terms of building creating, and using product management artifacts. A lot of times we’re seeing a resume that looks like the person is next Bill Gates or net next Steve Jobs, the resume just screams

Vlad G 18:22
I’m a genius. And these usually make me very uneasy, because I know something’s up Believe it or not a perfect resume is not a recipe for success. It’s more of a recipe for a little bit more scrutiny, I guess. So what happens is I I probably should not talk about what other people are doing I should probably only talk about what things that I do not you know, my secrets are my secrets, their secrets, their secrets. So we when we interviewing usually as a one person was leading the interview and then others kind of supporting them. So if I’m the I’m the interview lead I do what I think is right other supporting me. If I’m not the lead, I look for clues from the either lead and support them and their questions. That’s usually how it works. So if I’m really if I’m asking the questions, I want the candidate to elaborate on some of the things that they’ve listed in the resume. Best thing here. Best thing I can ask is, what was your role or or more specifically you did on this, you know, working on this product. there sometimes people would say I did this either this either this either this, and there’s too many eyes. Although the three E’s the time to brag is when you absolutely must leverage your knowledge, your expertise, you should brag neither of us you tend to brag However, if you always say I I suspect that you have done absolutely nothing. by yourself. I Everything you do whatever you say I, you just wanted to say we and then, you know, consciously or subconsciously you just think, Oh, no, I can’t say we have to say AI and I’m gonna say AI. And you’re saying AI all the time. Ideally, you should say, hey, my team did this. And my part in it was this good example would probably be like he was working on this product. I sat down with a C CIO or CEO within the ideation, we came up with this idea. I did research, I took my developers, we came up with a PLC, the proof of concept developers build technical prototype, or UX designers, or UX folks, built this, you know, visual prototype, we looked at it, well liked it. I took it upon myself to create kind of like a high level roadmap, we dive, dive into it with the teams, we broke it down into blah, blah, blah, Bs or appeals or user stories and the rest of history. That’s the right thing to tell your story. But if you’re going to say I, that’s something I, I did hear it. So it’s not, it’s not unusual to hear I come up came up with this idea. The CEO told me to go and look into this. And I came up with this idea. I wrote requirements, I wrote all the user stories. I created wireframes. I did that I Nope, nope. No, you did? No, you didn’t? Nope. No, I’m sorry, I don’t believe just I just don’t. So another another thing that I’ve noticed a lot of companies started doing I do it myself. I know others are, is

Vlad G 21:36
giving you an example, a sample product? I’m sorry, that’s a simple product doesn’t here’s your sample product. If you were to build a Google Glass from the scratch, right, what would you do? How would you build it? How would you go differently? Or if you were to build the system that should track online usage of something something? How would you approach it? How would you do it? So those types of questions? Technically, they’re scenarios, right? You in good consciousness? And if somebody somebody who’s interviewing you expects you to answer these questions correctly, 100% of the time, they’re out of their mind, you should not be working for the company like that. Just my personal opinion. But you should not be hitting 100%, all of that you should be getting close. But don’t expect to be I saw I had a case, one fellow Product Manager interview, who was interviewing me was basically trying to find out if I can configure Google Ads platform for a specific client. I don’t know why. I don’t know, what was the purpose of it? I don’t know, how much did he learn about me, but it didn’t go well. Ultimately, a good interview should allow you as a product manager to demonstrate that you can operate within the product mindset, you should be able to do discovery, you should be able to do you know get from ideation through discovery, through you know, product vision, product strategy, product roadmap, define the MVP, define some kind of sort of preliminary plan, get to the point where you, were you able to demonstrate you don’t you’re not just Yeah, I know what the product lifecycle is. But you can navigate the product lifecycle, you know exactly what happens at each step of the way. Sometimes you may miss things, because you’re under pressure. Everybody understands that interviews are pressurized environments, but nobody in their right mind should be expecting you to hit the nail on the head 100% with them, ultimately, a good product manager should be able to leverage their existing experience. Where if you’re brand new product manager, their knowledge? And if you don’t know the answer to the question, that’s normal. I’d be very, very cautious about the person and we knew all the answers all the questions I’m asking, here’s a little dirty little secret. I don’t know the answers to those questions. And if you know them, then you should be interviewing me or you should own the company I work for if you know all the answers to all those questions, because the trick to it is not knowing the answers, but showing how you get to the answer. To me, it’s pretty obvious if I’m asking you, so you, you want to build a Google Glass, right? So I’m gonna use that example because I already mentioned it. So you want to build a Google Glass. So you know, who’s your Who’s your target audience? Who are you going to sell it to? I don’t know. I don’t know. But if you tell me Oh, that’s easy. You know, all the hipsters or you know, all the vlogger vloggers or bloggers or Instagram or Tik talkers. Well, maybe, I don’t know. Prove it. Show me how you get how you got there. Show me that these. These are the people who We’ll be able to pay for it, then we’ll have a conversation. But using this example, instead of telling me Oh, all the vloggers bloggers, THE youtuber stick Dockers, I want you to say things like, well, we’re going to do, I don’t know, pressure test a few hypotheses, like, let’s see if bloggers will like it. Let’s see, travel bloggers, food bloggers, whatever. Let’s see if military will like it. Let’s see if I don’t know if somebody else will like it. Doctors and clinicians, maybe there’s other niches, but I want you to demonstrate the process, I want to see the process, I don’t want to get a get a get an answer right away. Your answer means nothing. If it’s not supported by something, there’s a lot of talk about data driven decisions, that’s fine, you can you can do that. That’s basically, pressure testing hypotheses would be your data collected that you will use to inform the decisions. Sometimes you go by a hunch, sometimes you don’t have enough data in the enterprise world with enterprise software products specially are in early stages of enterprise software products, you just don’t get to have that data, you don’t know, you can make an educated guess you can estimate.

Vlad G 26:14
That’s what happened to me early in my career, or the company I work for I was working on the ipcress product, I was launching it first time ever bring it to the market, we had absolutely no idea how many companies there would be interested. We know each of our clients, each of the companies to a degree suffered from same problems that prompted my company, our company to create this product. But we didn’t realize how hard it would be to sell it. And it took us a few months to actually zeroing in on proper positioning on how do I talk about this product to my client? Just that part a long, few months? And it’s it’s really hard. So I if if if I’m asking questions like that, and you have an answer right away. So to summarize, what are the questions from product managers, what we’re looking for? What kind of answers we’re expecting, we’re expecting to see how you think we’re expecting to see how you would approach this problem? How would you try to solve it? What is the methodology? What are the tools? One of the ways of thinking? How do you how do you do this? Basically, I don’t really care what the answer is, as long as you walk me through getting to that answer to getting it. Here’s my process. Here’s how I approach this. I think I’m going to get x as a result. Okay. Let’s assume that that’s your resolve and move on to the interview. Right? But if you just tell me, oh, it’s going to be whatever I had, I had a person, we’re talking about developing mobile application for pretty wide audience, pretty large set of people, and the person just straight up told us Nope, we’re not doing Android, iPhone is the way Android is really insignificant share of the market. So we’re not going to waste our time building anything for Android in the first couple of years of this product, was just gonna go ahead and build iOS. And that was, for me, it was pretty indicative of the way the person thinks it’s the person has all the answers. They don’t have a methodology to get to those answers. They just know the answer by heart, and they’re giving it to you. So no, don’t do that. Second part of the interviewing and assessment, the executive interviews, we don’t do executive interviews as part of the assessment, at least, not that I’m aware of at not not at the level of product management, Senior Product Managers. Maybe higher, I don’t know, nobody told me. But executives are exactly the opposite. So which is why I said they really, really suck to have an executive and the product manager interviewer at the same time, you would be in a really bad position unless you listen to me and I tell you what to do. So executives want clarity. They exist in the world where things constantly break the things and I hear and I ask I get I get a chance to ask what keeps executives up at night. And it’s uncertainty. They’re there they leave and breathe by uncertainty they their whole Well, technically speaking, their their whole existence is to make money for the company they work for. But what that means in the real world is they are battling uncertainty. There is an uncertainty there’s a risk and they try to address it, the more certainty they have, the better they feel, the better their projections come through reality. The more uncertainty they have, the worse the off their projections, they’ll meet the reality. things go bad. So with that said, when the when the executive asks you questions, they don’t really want the process, at least not to the same extent as the product managers, when the executive asks you a question, so tell me about the roadmap. My answer to that is usually Well, I confer with the team I work with the team, I communicate across multiple teams, get their feedback, collected all together, put it all together, make make make a presentation for the whichever the forum whichever The meeting is to discuss it with the executives, and present my findings for present the risks present, how they would affect the outcomes, maybe a proposed couple of what if scenarios, to make sure everybody understands why certain decisions are better, why certain decisions are worse. What should you do

Vlad G 31:10
if things happen, so to kind of sort of paint the bigger picture for the executive, to help them make the informed decision you expect them to make. And I believe that’s the biggest difference, the executive does not want to know your process. When you’re thinking about executives always think about your customers, they are effectively the same in the way that customer does not want to buy a drill, they want to buy holes in the wall. Same as with executives, the executives don’t want your process they don’t want you to sell them product mindset. They don’t want you to sell them, you know, JIRA, JIRA versus other tools, or conference versus Aha, or whatever. They don’t care. give them what they want. They want information, they want clarity, they want to understand what are you doing today, and what’s gonna happen to the product in six months, 12 months, two years, three years, and so on. So that’s probably the biggest difference. And that’s probably the biggest disconnect, when people come in into the product management interview, and they start talking to HR, and they start talking to product management. And then they started talking to executives, they tend to tell the similar or the same, a similar story. And they tend to fail. And the reason why they fail is because you’re the product, and you’re presenting it to different audiences, you presenting your story to the users, and then you present the story to the buyers. And it’s always in product management. When you position your product, there are users and their buyers, there are people who pay for it, and there are people who use it. If you approach it from this perspective, you will immediately again, if you’re a product manager, you will immediately understand the difference, and you will immediately change a pitch. Hopefully that helps. All right. One of the last things I want to discuss today, we see in interviews in assessments, and in the real work in in the work that we’re doing for clients or in internal products. We see people either over leveraging or under using certain artifacts systems solutions. At one of the things I do want to talk about is sometimes people get obsessed with tools. I remember our company spending literally a month deliberating which system to use, should we use JIRA? Should we use Microsoft product? I forgot what’s called used to be TFS. Should we use Aha. And guess what? They ended up not using anything, they end up using Excel, but they spent the month talking about it. Why? Because they are obsessed with the tools instead of being obsessed with the process. I used to say this I don’t think it holds true anymore because of reward from home work remote and all that jazz. But it holds true in the way that you can use online tools to that extent, but I used to used to say that my job as a product manager can be done with pen and paper. I don’t need tools. I need the whiteboard. Obviously, it’s an exaggeration. But it’s a good exaggeration, because I don’t really need to use JIRA, I don’t really need to use. I don’t know, aha, I can draw. It would be very convoluted exercise and probably not really productive. But I can draw or write everything down on a piece of paper. I don’t really need to use any of these sophisticated tools. As long as my process is good.

Vlad G 34:51
As long as my process helps me move things through. If my process is broken, no matter which tools I’m going to use is not going to help it nothing get done. If my process is broken, I can use the most sophisticated the best tools in the market, Mind Maps, mind reading applications, whatever AI systems that will predict with predictive analytics, nothing will help if your process is broken. So one of the things that we’re seeing in the real world is people being obsessed with the tools, instead of our process, I would actually argue that a good product manager should be good process enabler. If you come into the existing product, to work in the existing product. Or if you’re just starting and building a new product, one of the most important things to do is set up the right process. Time and time again, I am seeing and my colleagues are seeing that if the process is wrong, no matter how good you are, no matter how talented you are developers, no matter how talented, they are designers, no matter how great everybody is, bad process will ruin everything. If you’re if you’re writing user stories, if you’re building technology before you even look at the product roadmap, or if you don’t have a roadmap, if you don’t have a process to review the roadmap because it’s a living, breathing document, those developers will get upset, they get frustrated, they will leave you in like three to six months tops. And you’ll end up with bad developers bad product roadmap, bad process, back to square one. One of the things that we’re seeing, and it’s a matter of fact, back to the interviewing, to kind of circle back and tie it up when we interview or when we do the assessments. One of the things we try to get for indirectly, because of this direct questions prompts the obvious direct response. So we’re trying to see if the candidate is actually thinking about it, is give us the plan of work. Let’s say sometimes it’s a plan how you plan to release the MVP, sometimes it’s a question of what is your personal plan for the next, you know, one to three months? But it’s always a question about what is your plan to do XY and Z for the product you’re building? And part of the expected answer is, I want to set up a process a product development process, there’s whatever the your process and whichever methodology you subscribe to, it doesn’t really matter, I’m not going to judge you or not. Nobody’s going to judge you unless they’re, they’re religious about a particular unless they’re religious about the particular framework or a particular approach. And then you know, anybody who’s not using x processes, you know, not our not our candidate, but you have to, you have to, you have to say the magic words, basically,

Vlad G 37:46
you have to say that, hey, I want to make sure my process works, I want to make sure that, you know, we’re doing whatever, if we’re doing agile, right? Then we have all the proper ceremonies for the product office to review the roadmap, break down my product of the capabilities and the features until epics, what however, your your your hierarchy works. And you do this and you review care, you review regularly, your business goals, your okrs, your whatever, again, depending on what your terminology is, what your concept is, what your methodology is, but give me something that will make me feel better about you having a process to build the product, actually, actually, which reminds me at one of the candidates ever interviewed that said something like, Hey, we’re going to spend for first 60 days, building your roadmap, then we’re going to fix it in time, right? All the documentation, right, all the product requirement documents, and we’re going to start building product. And I generally, like my candidates, they’re very smart people. It’s just they just stress and I asked the candidate. So what’s gonna happen if developers discover something that doesn’t really fit your roadmap or isn’t isn’t in the product. PRD is in the product requirement documents. And again, they responded, well, this shouldn’t have happened because we would figure out everything as we ride the pierogis. So this should be no, no surprises are very, very minimal risk. Because everything should be thought about up in events that didn’t go well. Which brings me as a final final note, brings me to the topic that I picked on Reddit, because I promised we’re gonna leverage Reddit and this whole podcast started off of me reading Reddit to somebody came up, hopefully you know who you are. And you leave me a comment or something. Somebody came up with the topic on Reddit about how it was a good template for a product requirement documents. I believe the my biggest problem with the right app was about 2010 to 20% of the document would be me talking about what the product is and about 80% 70 to 80% of the document is How to Build how we’re going to build the product all the architecture, design, wireframes technology, technological specifications, functional specifications, very, very detailed documentation from which then you can construct user stories. My my concern was hate history. So you just write this one document. And people just can just take them and write user stories off of that one document. The the author said something to extend it. Yes, this is, you know, a pretty self sufficient documentation, they doesn’t need anything aside from obviously design mock ups and UI UX component. So you do understand this is insane, right? You’re going to spend six months writing it, then it’s going to be obsolete probably for four months in person disagree with me, they had a little different vision, which is why I’m bringing this up. Because I do want to give voice to people who disagree with me or I disagree with them. And one of the main concerns that it’s actually happened to me more than one specifically was prepare their pre recorded pre written parodies, before the beginning of the work on the product, is that they’re obsolete The moment you start writing them. And here’s why. Because you have set a certain vision in your head of how things should work. Allegedly, you did some research you’ve done you did some user experience testing, I’m giving you the all the benefit of a doubt, right, you did, did do some discovery. The problem is, in the real world, building product is always going to be a continuous discovery, continuous evaluation, continuous reassessment of where we are what we doing, how are we solving? How are we solving an individual issue?

Vlad G 41:48
If I if I say, these parodies are written in June 2020, when I stop doing this podcast, and I am here today, in June 2021. It’s not the case, I’m giving you a hypothetical case, if I had a PRD, written in 2020. And I start development in I don’t know, October, September, October, November, something like that. And I am here today, one year after Not a single word of those parodies will still hold true. How do I know that because it happened to me more than once. There’s no way you can write anything. If you’re doing product development, if you’re not doing waterfall. If you’re actually doing genuine product development and following one of the product development methodologies, there’s no way in hell, you can do this and survive, either a product is that you’re most likely impurities in it. But either a product is there, or your teams are dead, or your product management team is there. But most likely your purities are dead. Because most of what happens usually happens in the real world, people tend not to read documents that are longer than a couple of pages. Someone actually we were working on the clients assignments. And we gave them a playbook product management playbook that was only 80 slides. It’s not in the book, it’s just slides. And each person had maybe 20 slides to look at. They didn’t even have to read the whole thing. They could have just like flip through. But their part was 15 to 20. slides, not like 20 2020. But there’s overlap. And but most each person used to read 20 slides and they told us straight through there to our faces. Nobody’s going to read the PowerPoint deck and 80 slides and we’re like, no, they will, because that’s your job. And if you’re writing and documentation to developers, if you’re a product manager who’s telling developers how to write code, if they’re good developers, they laugh in your face, and they leave and work in another product. If there are bad developers, they’re going to listen to you and you’re going to end up with a mess of a product if you’re going to get the product at all. And again, I’m not trying to offend anyone, I’m just speaking strictly from experience. I would never ever, ever imagine I would have to write a functional specification that tells the developers how to build something, I will tell them what I want built, I will never tell them how to do it. Because I’m smarter than developers in that particular niche where I understand what needs to be done. What is the problem? What is the solution, what the customers want? What the business owner wants, what business wants, right? And notice how I say what I always say what they want, what needs to be built, because I’m responsible as a product manager, I’m responsible for what? Now, when I hand it over to developers, they’re way smarter than me, or solution architects and developers and techniques. They’re way smarter than me in terms of how to achieve that. They know way more than I do. I have a very basic understanding of things because I need to, but if you asked me to write code, I wouldn’t end I want and I can’t. And that’s because they are the smart people in the room who are smarter than me. Who will tell me, hey, Vlad, we think we could approach it from this direction. But if if something goes off, we have an alternative way. And I said, Yeah, build a proof of concept, build something that will help you determine what’s the right way to approach it. And that’s how things work. I decide what needs to be built in conjunction with business in conjunction to with UX, then UX, and developers and solution, architects will go back to the drawing board and tell me how they’re going to build it. All I need to do is I need to look at their solute proposed solution, and see if it does the what if it solves the problem I came to them with? If I came to them, if I came into development with a problem, hey, I need I don’t know, I need to chat. And they come back to me and giving me I don’t know if flight simulator will probably not looking at same thing. But if I came to them, and told them, hey, I need a flight simulator. And they gave me a flight simulator that has one plane today, but they will be able to scale it next couple of years to add other planes. Awesome. That’s what I was looking for. So with that said a little bit about the

Vlad G 46:19
these are using, and the approach and obsession with tools. And some of the artifacts don’t do parodies. There are the abomination of product management world. Sometimes you have to for documentation purposes, sometimes you have to for what it’s legal and compliance purposes of seeing those things they do happen, but don’t expect to build anything. And don’t expect to to build the actual product off of a single peer review. I think it’s unreasonable, I think is bad for business. And it doesn’t make any it’s not gonna make anybody happy. He just waste of time, effort, money. And they mentioned waste of time. Yeah. So that is it for today. Hopefully, I’ll be able to continue doing this. Hopefully, there’s gonna be a video I’ll be able to edit this. I’ve never done this before. It’s going to be my first time. So at least there’s that there’s podcasts, there’s video. Let me know if there are any questions if there are any ideas. If there are any people you want me to bring in five of people, obviously you can’t bring a bill gates to talk about his marital problems. But we might be able to bring in people who work in a specific industry specific areas. We have a lot of talented people in the company. There’s a lot of talented people on Reddit, off Reddit on LinkedIn, so we’ll be able to talk to them and we’ll be able to bring them in and interview them same way we did before. So hopefully that’s it. Thank you all for watching, listening and to it.

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