Are you caught in the haze of miscommunication, competing priorities, and lack of clarity in your organization?
Let's clear the fog together as we welcome Bijan Shahrokhi, an expert in the product management field. Bijan shares his intriguing journey into the product niche and underscores the importance of clarity within an organization. From personal anecdotes to discussions on the consequences of unclear communication, this episode is packed with insights and practical tips for anyone involved in product management.
Are you caught in the haze of miscommunication, competing priorities, and lack of clarity in your organization?
Let's clear the fog together as we welcome Bijan Shahrokhi, an expert in the product management field. Bijan shares his intriguing journey into the product niche and underscores the importance of clarity within an organization. From personal anecdotes to discussions on the consequences of unclear communication, this episode is packed with insights and practical tips for anyone involved in product management.
It's practically a trope, but it happens all the time—you say something to three people, and they'll hear three different things. And that's not so bad if that something is, "I'm going to grab coffee, anyone want anything?" But when you're building an MVP with ever-shortening runway, or trying to ship something on a strict deadline, that lack of clarity can be the kiss of death for a startup. Today's guest is Bijan Shahrokhi—he's the Founder of Product Management Exercises and Product Monkey AI. Bijan has spent the latter part of his career helping PMs become more productive and better at managing teams. And the ability to bring clarity and alignment to a product team is foundational to those skillsets. In a few minutes, Bijan will share an easy-to-replicate process that will cost you a bit of time upfront, but has the power to save a startup on the brink. Let's jump in. Welcome back, listeners. I'm joined today by Bijan Shahrokhi. He's the founder of ProductManagementExercises.com, and he's recently launched a productivity tool just for product managers called ProductMonkey.ai. Bijan, thank you so much for joining us today.
Bijan Shahrokhi:Thank you so much for having me.
Hannah Clark:Great. So we always kick off the same way. I'd love if you could tell us a little bit about your background and how you ended up where you are today.
Bijan Shahrokhi:Sure. I'm a product manager by heart. I've been a product manager for over 10 years totally accidental. I didn't even know what product management was until I had a startup that wasn't going very well. I was asking a friend what he thinks I should be doing next and he told me 'you should be a product manager'. I'm like, wait a second. Sounds very interesting, like product and managing the product. That's what I want to do. So from there on, I became a PM. I've done a few different things over the past 10 years. I worked for the first couple of years of my life in larger organizations, like in a bank as a product manager and then product strategist. After that, I was part of two startups. Both of them we launched it as I joined the company and one of them got acquired within a year and a half by a larger player in the ecosystem. And the other one actually was a successful project. It was worth multi billion dollars at its peak. It's still going, it's still going through a lot of growth. And then since then, I've been focusing mostly on Product Management Exercises over the past few years of my career. And recently, we've launched another product for the product management community called ProductMonkey.ai.
Hannah Clark:Amazing. So today we're going to be talking all about clarity in organizations, which is something that you're personally quite passionate about. And by clarity, I mean, just making sure that all the stakeholders are aligned and share the same version of what's going on, what's to be built. So what does that look like to you when an organization lacks a sense of clarity?
Bijan Shahrokhi:Great question. So I think the biggest sign that you can see, the most obvious sign that an organization lacks clarity is when you go across the organization and ask different people what they think are the success criteria for what needs to be kind of delivered as the next big milestone, and you start hearing different stories. So I'll give you an example. For example, let's say you're dealing with a very technical product that is going to be dealing with a lot of performance metrics, like, for example, latency, speed, number of transactions per second, or the volume of tasks that could be completed. If this is not clearly defined from a very technical person within the organization, they might try to build something that can resist extremely high volume of transactions, let's say. But if you ask maybe somebody more kind of business oriented and customer facing, they would ask, we just need to get something out the door so that we can start getting feedback from our customer. And you would know that there's lack of clarity once you start having conversations with people across the organization and you start hearing different numbers or they say, 'Oh, we never thought about it or we never discussed it'. And that's usually a pretty big alert for you as a PM to realize that, wait a second, it seems like there's lack of clarity here.
Hannah Clark:So it sounds like you've got a few firsthand experiences with that sort of without naming names, can you think of an anecdote?
Bijan Shahrokhi:Sure. Yeah. So actually the last project I was telling you about that became multi billion dollars invaluation was a company that was just like a few months away from running out of cash and they hadn't launched a project yet. It was just like, they thought that they were only a few months away from launching their product. And when I joined, I was initially told we're only three months away. Once I joined, I realized that what the founders, some of the founders had in their mind was maybe 5 to 10 years away from reality. And what some of the engineers thought that they were delivering was also a few months away. So there's like a huge gap between the two. And because of that, they were just in this cycle of developing for over three years, because engineering team kept presenting over ready. And some of the founders or business people will look and say, Oh, wait a second, you guys are not ready. This is not really meeting what we have in our mind. They would redefine what needs to be built. And Jane goes back to this building, feeling disappointed, feeling like they're not really being very valuable to the organization. And then the, what we did at that moment is I spent actually the first three months of my time as head of product to meet with a lot of stakeholders and really understand what are some of those attributes that have very strong different perspectives across the organization. For example, like I realized that, okay, this particular attribute after company or a few people within the organization, things that it needs to be part of the initial launch. The other half doesn't think so. And then what we did was we started kind of having a lot of conversations around those particular items and got clarity on whether or not they're going to be built. And it was a zero on one decision. Or it would be a decision like we're going to do a very, very light version of it. And here's exactly what we're going to do as part of it. And only after that, it took us about a year to actually build a light version of what was initially thought as, this is what we're going to launch within three months. Honestly, it just, like, took us a few months alone just to kind of get clarity on what's going to be built within a year. So, hopefully, that's an example of a situation where if you bring a lot of clarity, you're able to actually get something out the door. And then once you get it out the door you're able to kind of use the feedback from your users and the community and the whole ecosystem to figure out which of all those things that are in the pipeline need to be prioritized further as the next step.
Hannah Clark:Yeah, and that's a huge accomplishment too, to close a gap like that is a seemingly impossible task. So that's, it's pretty powerful to take that approach. So if we step back a little more, what would you say are some of the more broad implications when an organization hasn't baked processes for clarity into their culture at large, not just necessarily with the product team?
Bijan Shahrokhi:I mean, the biggest impact is they usually end up not shipping and this is a pretty big issue. So there are a lot of great projects that end up never making it into the wild because they run out of cash basically before they're able to start injecting cash into their company. So, and unfortunately, this is even a kind of a harsher reality when it comes to R&D based projects. Because the R&D based projects that are like kind of very science based and they're trying to really deliver some sort of a breakthrough are usually driven by founders that have strong academic backgrounds. And from people with strong academic backgrounds and, you know, no offense to them, like I also have a strong technical and academic background and I think that's a positive thing. But what happens when an organization is led by them is they look for perfection and because they look for perfection, they keep building, building, building, adding. They're always worried about the extreme scenarios that, to be honest, it's not even the end of the world if they happen in the incubation or early phases of a project. And then the outcome is, they never ship and the world never gets to actually see what they had as their vision for this new technology.
Hannah Clark:Yeah, that whole'done versus perfect' thing we always wrestle with that was a perfectionist versus the folks that just want to ship, right? So one area I think that actually speaking of which that I think we can agree that clarity is just so vitally important is, like you said, developing an MVP and I think it's just an area that's very ripe for a lot of missteps, a lot of miscommunications that can be pretty disastrous at the end of the day. So what are some of the common pitfalls that teams building MVPs should be mindful of, that might run into, and some remedies to avoid them?
Bijan Shahrokhi:Yeah, so I think the biggest mistake that I've seen startups make with the concept of MVP is mixing it with delivering a broken product that's not even usable, right? And I've seen this so many times. Without giving names, I'll give an example. So for example, investor in one particular product that is an enterprise on solution. I'm very, very passionate and excited about it. And from day one, the reason I was excited about it, it was something that I could see myself wanting to use it. And I could see my organization at Product Management Exercises wanting to use it on a daily basis. The biggest friction for us to actually adopting it has been that it's so buggy that it's so buggy to the point where we can't even use it. Right? So it's very important for us as product leaders to kind of pay attention to it and make sure that when we see an MVP, we're not talking about a buggy product that is not able to articulate the value proposition of the product. So you still have to make sure that core user experience or that core value product that you're trying to deliver to the user works very well, smoothly, end to end. You can de-scope a lot of things that are kind of like unnecessary, right, but you have to make sure that you can deliver that core product experience. And I think this is one of the biggest mistakes that I've seen companies make is they misunderstand what MVP means and they think that it means you can just like ship something that's kind of broken.
Hannah Clark:Yeah. So it's almost, you know, there's a camp that doesn't want to wait to ship until everything is perfect. And then there's the other side of the spectrum. Yeah. That makes sense. So you have quite an intensive process for seeking clarity within organizations. You kind of hinted at before. So, if folks listening wanted to say copy and paste that approach into their own workflow, what steps would you give them to make sure that they're getting aligned with everybody on the team?
Bijan Shahrokhi:Thanks for asking that. And it's interesting you ask this question because a lot of people at PM Exercises are very, they find this process very helpful. To be honest, it's actually pretty straightforward, and it really focuses on doing the hard work early on before you actually start a project. It's pretty step by step and I'll quickly walk you through it. But basically what you do is you spend a lot of time at first to bring alignment across the organization through a step by step process. And only then once you think that everybody is aligned, then you get started. What's interesting is this approach has been actually adopted in a lot of larger organizations, like, for example, financial institutions. But when we moved from Waterfall to Agile and Scrum methodology, we thought that what it means is that you don't need to have clarity on where you're going and all you need to know is just like think about what you're going to do for the next two weeks. No, that wasn't the intention of Agile. The intention of Agile was that you deliver something meaningful every two weeks while knowing clearly where you're trying to go within a few months. So how do you do that? The way I approach it is for example, when I'm leading a project or a product that I realized is like a lot of lack of clarity, the first thing I do is we're going to, I set up one-on-one meetings with the stakeholders, with my product. It has to be one-on-one. Not group environment, because what happens is 1% shares an opinion to sensitive topics. Somebody else jumps in and you as the Oracle of the product are not able to properly digest all the context as necessary. So you need to kind of get 1% in, make sure that you really understand their perspectives. Let's say you're dealing with a trade off. Should we build X or not build X? It's a binary decision, but this model really works for a lot of other things. So you meet them, you get their perspective on why it should be done and shouldn't be done. And you also ask them, what are some of the things that I have to pay attention to as I make this decision? And they'll probably give you, you know, four or five different things that's very important to them in their world. Especially in the world of R&D, this becomes even more important. So the more technical your product is, or the more technical dependencies it has with other tools within the organization, it becomes more important because there is subject matter expert. You go to the next person, next person, you meet everybody one on one. And as time goes by, what will happen is either your own opinion on what the trade off decision should be becomes stronger, or you start developing new opinions. Or your trade offs start changing and you realize there's certain things that you thought are harder than you initially thought or easier than you thought and you adjust them. But what you do along the way is as you gather more information on a one on one basis, you go back to some of those individuals and you say, you know, initially when I met with you, this is, you told me, these are like, 1,2,3 are your biggest concerns. From my conversation with others, I believe they shouldn't be a concern. Here's the argument. Tell me why I'm wrong or tell me if I'm right. And what will happen as you kind of go through this back and forth, which is time consuming, you end up realizing that a lot of the challenges that the team was facing was really lack of communication. Nobody was really spending time to clearly articulate all these different trade offs to different stakeholders within the organization, and a lot of things will get addressed. Now, what will happen is, as time goes by, you kind of get more and more clarity on all these different kind of trade offs that you have to pay attention to. This approach could also work on product priorities, by the way, we can talk a little bit about that later. But at some point you realize maybe there are a few items that still have, like, they bring different opinions to the table. Like, for example, half the team thinks this particular attribute is very important. Let's say security. And the other half, the thing is that security is not very important as an attribute. And they have their own reasons for it. This is when you actually organize a group meeting. This is when you actually say, okay, for us to make this decision, this is an attribute that's very relevant for us. There are two different perspectives. I would like us to have a conversation. And through that live conversation, you're usually able to arrive at a decision. Sometimes there's a couple action items, like let's go and investigate this further. Okay, great. Then you can organize the next meeting and come back and say, this was our initial goal. We did the research. Here's the new finding. What do we do? But you come up with a decision. Once you have very clearly on what all those tradeoffs are, it's much easier for you as a team to make a decision on whether it's, you go down a particular path from a trade off perspective, or it's about these are the product priorities. So that's when you can actually come in and say, okay, now we've decided that this is our priority and we're going to focus on it. So at a very high level, the way I think about it is step one, start with one-on-one meetings where you really understand each individual's perspective clearly. Step two, go back and forth between them if you need to, to make sure that all those kind of items where they have different opinions on with you at the end of the day are addressed. If not, mark them for group discussions. And then step three, you have the group discussions. Finally, this will result in a kind of a cohesive either product strategy or product spec or product priorities. And, you know, for each of these different scenarios, there might be an extra step in between. For example, for product priorities, you need to think more about what is the objective, right? Maybe you need to spend a little bit of time at the beginning saying, our objective is to get something out the door quickly and learn, right? And then you want to see whether or not anybody disagrees with you. And if they all agree, great, then you can actually move on and continue through this process.
Hannah Clark:Yeah, I'd like to talk a little bit more about product priorities in general. I think that that's something that even when we have a relatively close to a consensus or feel like we've agreed on objectives and what the success looks like, it can still be difficult to juggle some competing priorities. And of course there's a hundred different product feature prioritization frameworks, but what are some of the methods that you've used to that you found to be most successful and broadly applicable when working with some competing priorities within these contexts?
Bijan Shahrokhi:Yeah, I think one of the approaches is really for me is like kind of scoring them and thinking about it from a couple different lenses. One is the impact that I think this particular feature or product is going to have on my target audience or my target users. The second one is the probability of us being able to actually capture that impact. Because in many cases, you're not even sure whether or not you're going to actually be able to, like, whether or not your new product is actually going to resonate with the audience, right? In that case, then the probability is lower. And then the third one is ease of implementation. Right? So the formula that I kind of have in my head is"impact times the probability of the impact plus the ease of implementation". And then for the impact is one to five, five being the highest impact, one being the lowest impact. And also on the ease of implementation, the way I think about it is if it's a five, that means it's easy to implement. If it's a one means it's a lot of effort. And then from there you get a score. What I like about this approach is it's objective and you can have, through this process that I was just like telling you about one, two, three, you can also have similar conversations. You can go back to a team member and say, look, from my conversation with everybody, here's my table on what I think the different key projects are within the organization. Here's my view on how they score from impact and implementation effort perspective. And based on how I've scored them, here's the result on what the type five projects should be. Right? And then they can actually come back to you and say, look, first of all, I think you're missing these three projects that we're also working on. Or this one project that you've included, it should be broken into three, because it's much bigger than you imagine. Or they might come in and say they disagree with you on the impact or the ease of effort. But now, you're starting to have very objective conversations, right, like it's more about items. And what's interesting about this kind of scoring system is that because you're not trying to really estimate how long everything is going to take, and you're looking at it on a relative basis compared to other projects, it's much easier for you to quickly come up with some sort of a consensus on how much value it's going to deliver or how much effort it's going to take. And that will result in you having a set of clearly defined priorities that you would say, okay, these five are what we're going to focus on for the next quarter. And every time a new item comes in or somebody or a new staff member, or somebody even within the organization comes back to you and says, We should do this. You look at your priorities table and say, well, let's have a look. We discussed it. We decided right now it's not a priority for this reason, but once we finish these two or three, we're going to prioritize it. Now there's sometimes you realize that there's some additional things that need to be added. We can talk about how you can think about those scenarios as well. But this approach I think is more objective and makes it easier for you to kind of come up with some priorities.
Hannah Clark:Yeah, I appreciate that. I think we've talked on the Product Manager before about depersonalizing feedback and depersonalizing some of these prioritization conversations so that people don't feel that there's a personal reason why their pet project or their agenda has been deprioritized or placed in a different priority sequence than they think it should be used. So that's a very prescriptive method. I really appreciate that. Sorry, what did you say you wanted to come back to? So you, what you said we'll talk about that in a second, shortly, just a moment ago.
Bijan Shahrokhi:I said, we can also talk about how sometimes people will come in and say, this needs to be a priority. And then you actually realize that it needs to be a priority for whatever reason. How do you deal with that? And I was saying like, sometimes when that happens, you can kind of think about how to do it. It cannot be just added to the list of priorities. You have to either think about, okay, if we want to do it, we have to do it in a way that it doesn't impact the list of already high priority items, their speed of delivery. So you have a couple other approaches. One is you need to remove something from that list. It needs to be deprioritized. So then it gets replaced with that one through the scoring system. Another way is you have additional resources that will be working on this new priority item. So the principle that you're following is that the things that are in your priority list are not going to be slowed down just because you're adding another item to the list. And this is the job of a product manager, in my opinion, in some organizations it's not. And that's where you start running into an issue of things not being delivered. But I think a great PM will actually pay close attention to it and make sure that something else due to like new information coming to surface needs to be prioritized to think about how do I handle it. I either remove something from the list or I make sure that I get additional resources that are able to work on us without impacting my delivery speed on the other item.
Hannah Clark:Fascinating. I did want to switch gears a little bit while we're we're sort of coming to time because I wanted to speak a little bit, I wanted to talk a little bit about productivity, which is another thing that I know you're very passionate about and probably a main reason why you decided to found productmonkey.ai. So I was wondering if you had any products, just in general product, in general productivity tips for our audience and some information about Product Monkey AI that people might find interesting. It's a very cool tool.
Bijan Shahrokhi:Sure. So what I'm doing with Product Monkey AI is automating the one task that I think is very necessary for us as PMs and I don't like doing, which is spending a lot of time writing detailed requirements and acceptance criteria for the reasons I was mentioning to you. So what we do as Product Monkey AI is we try to obtain as much information as we can about the particular project that you're working on, about your organization, about the particular user flow that you're dealing with. And then with proper guidance from you using AI, we're able to actually give you detailed product requirements, acceptance criteria, testing scenarios, even events and metrics to pay attention to when you actually build the product. So that you can actually take it and start working on it and get a quick draft, which is like 80% of the work for your engineering pass tickets and PRDs prior to home and docs. And then spend your time doing the kind of the last 20% to make them. So I think one of the benefits that we could deliver as PMs, as I mentioned, is bringing clarity. And I think that Product Monkey AI can actually do that by reducing the time it takes for the PMs to bring clarity to engineering teams.
Hannah Clark:That's fantastic. And I'm sure that a ton of people listening will find a lot of value in that tool. Bijan, thank you so much for joining us today. Where can people keep up with you online if they want to see what else you're up to?
Bijan Shahrokhi:They can come to Twitter or X as we call it now. So my X handle is bijan_sha. You can find me there. You can also come to PM Exercises or Product Management Exercises. You can search for either of them. You'll come to our site and you'll be able to connect with me there as well.
Hannah Clark:Fantastic. Well, thanks so much for your time.
Bijan Shahrokhi:Thank you so much for having me.
Hannah Clark:Thanks for listening in. For more great insights, how-to guides, and tool reviews, subscribe to our newsletter at theproductmanager.com/subscribe. You can hear more conversations like this by subscribing to The Product Manager wherever you get your podcasts.