As a Product Manager, are you constantly asked "When will it be done?" before even knowing what "it" is?
Learn why this simple question is so problematic and how to handle it effectively. Learn strategies for educating stakeholders, collaborating on roadmaps, and focusing on delivering real value instead of arbitrary deadlines.
Don't let deadline pressure derail your product strategy. Listen now for practical tips on having better conversations about timelines and priorities.
#ProductManagement #AgileMethodology #ProductStrategy #SoftwareDevelopment #LeadershipSkills
= = = = = = = = = = = =
YouTube
= = = = = = = = = = = =
Subscribe on YouTube
Apple
https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596
Spotify
https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3
Amazon
https://music.amazon.com/podcasts/ee3506fc-38f2-46d1-a301-79681c55ed82/Agile-Podcast
= = = = = = = = = = = =
Toronto Is My Beat (Music Sample)
By Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)
CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)
welcome to the Arguing Agile Podcast, where Enterprise Business Agility Coach Om Patel and Product Manager Brian Orlando argue about product management, leadership, and business agility, so you don't have to. I'm glad that you're here at the podcast today. I just wanted to point that out. Just want to say it out loud. All right. Just thanks for being here. I want to express frustration and it's this, okay. As a product manager, I like upset stakeholders. No problem. Like investors that want to inquire about their pet features. No problem. Stakeholders that are crying about things that they wanted in the application. No problem, salespeople that think that we need to implement certain things. No problem. There is one single thing that gets under my skin. And one thing alone. And that is the following question. You ready for this question? I'm ready. I'm sitting down. The question is When's that going to be done? Ha ha. Oh, that's priceless. So who, I'm wondering, who, is there anybody who hasn't heard that question? Right? At work. When's it going to be done? It comes in various guises, right? In the software world, it's typically, What are we going live? So yeah, this, it's a great topic. When is it going to be done? So, there's a movie, What's the name of it, Rain Man? I don't know. Dustin Hoffman's being drilled in his Olivier, who keeps asking the same question, Is it safe? And the guy's like, Blah, blah. And he's drilling more, Is it safe? The guy has no clue what it is. Well, if you watch the movie, you'll see more, but anyway, so this is equally as painful if you like your teeth are being drilled into every time when you get asked that question, when is it going to be done? I thought that was the end of Brazil when he had the thing on his head . It might be. I don't know. Anyway, when's it going to be done? And so when people ask you that, put yourself in their shoes and say. Do they know what they're asking? When is what going to be done? Do they know what they're asking for? Ask them that. What do you mean by it? First of all, I'll be them, quote them in this conversation, and the answer is no, and I don't care. the reason this question upsets me so much is because it demonstrates a fundamental misunderstanding of the product development process. Now people will hear that and say, Brian, you are ridiculous. Why are you even in my house? How did you even get in here? Like, listen, all good questions, but also the modern product development process, like if we're going to walk through the Marty Cagan four illity categories of feasibility, , usability, desirability, custom and viability, If we're going to walk through every single one of those categories, in order to preface the feature, making it into active development and into the product, and you're telling me. I slipped in the shower. I hit my head on the toilet and came up with the idea for the flux capacitor. When's it going to be done? Like I haven't even examined. the fundamental underpinnings of the business viability. Yeah. If we can even charge and accept money for that from the business. Yeah. So I hadn't even started. So if you're bringing that to me to say, viable in the operating model for the business to bring money into the business. I'm more than happy to delegate the pieces of all the four Marty Cagan risks. And even in the Marty Cagan, even in different pieces that can be delegated. Oh, the technical feasibility, it can be delegated off to your tech lead. And the usability, can customers actually figure out how to use it, can be delegated off to your UIUX person. The other ones that the product manager has to own, but maybe there's a way to delegate those. But when Gary from sales, I came up with this idea. How come you aren't doing whatever, when's it going to be done? It drives me crazy. It is a trigger question. I agree. it is one of those things when you hear it, you just go, right. But we have to deal with it. That this is reality and then so people when they ask you that I always ask them. Why do you care? What's behind the question? I don't mean to be arrogant like why literally why do you care when it's gonna be done? Let me understand. What you're really asking me, right? Because if you just want a date or a day I'll give you a very wide range if you want to guarantee, first of all, you want to guarantee by a toaster. I think that was Clint Eastwood. But pick a day and then throw it in the bathtub. Pick a day ending in Y and that's the day we will go live. they're asking this question because they think they have a great idea. Before we pivot off of this subject so one other tactic, trying to be kind of useful here. One of the one of the tactics you could use is simply make up two dates and say, what would it mean to you? Right. This is you addressing the question. If we went live in March of 2025, okay, versus we went live in August 2025. What you're trying to do is to really get to the answer of the previous question, which is, what does it mean to you? Why are you asking me this? Right. I know you're looking for a date or something like that, but why what's really driving the question? Is it a budgetary concern? is it because you're concerned about a product launch date or some other event on the horizon? Like a convention happening where you want to present something, whatever it is. Let me understand that first. And then we can have a conversation of what we can deliver. We can talk about the scope and things like that. Well, again, make up two dates and say, what would it mean to you if we went live by date A or date B and let them talk to you. But again, you can't hold cards to your chest when we're all on the same team come to me as a product manager My put the milestone on my roadmap. Yeah dare to put my so like this is an interesting This is interesting because we don't think about roadmaps this way is like other people external milestones They just dropped them on there, which would be cool to see in a tool. Actually, if you think about it why don't we let other people drop milestones onto my roadmap and put notes of what the milestone is. And then I will tell you what we can do to get something to you by that milestone. We don't do roadmaps that way. The tools that we have don't really work that way. Alex, if you're listening. solid, absolute gold, and because, the external milestones that are happening, they are just happening anyway. And even in the case where your leadership team says like, Oh, we want version two to be launched on December, 2025, if you're listening. To this many years later, like it's currently it's December, 2024. So July, 2025, boom, we drop a milestone. We want to have a big marketing push and whatever. So like that's their milestone. You know that you want to have a big marketing push. You haven't a big like a Figma config 2025 or something like that. You have a big conference, Apple conference 2025, a big conference or something. Well, that's a milestone you have to work forward to in the future, but treat me like I'm a partner here in this and bring me in and say, this is the timeline that we have. What can we do by that timeline? And then I'm ready to wheel and deal are bringing a whole development team in. So we're all on the same page. No misalignment here. We'll bring as much of the company as we can in and we'll be on the same page But we can hit any milestone you drop on my road map. We did a whole podcast where we said We can do milestones left and right all day long. Absolutely. So that collaboration that you mentioned is the ideal way to go, right? Absolutely. That is the best way to proceed forward because everybody can understand what they have to do. Yeah. So the direction that people are heading in is clear. Right? But it doesn't happen always, unfortunately. So when you do have this sneak up on you , you have to have some things that you can use to deal with it, right? And at the end of the day, you can deliver to any date. It's just, what do you deliver? What are you delivering in terms of scope? How good is it? Is it refined? You know, does it stand upright even? Or is it just a figma screen you're delivering? I don't know. But conversation is key, right? That collaboration has to happen as early as possible before the milestone. In some of the planning frameworks where you have scaled environments, you do talk about milestones at the beginning. Planning events. So you can see, even though time horizon is only three months or so, roughly, you say, these are the milestones we have to hit as a program. So here are all the teams in order to do this. What are all the dependencies? You do that. That still isn't the same as you're saying, which is, Let's predate all of this and have a discussion and say, we're about to launch on this journey. We need these milestones and put them on the roadmap, right? Then everything else can be shuffled around that with respect to shaping what's in the scope for each of those milestones. So we talked about the, the, bypassing the essential product validation steps, like the Marty Cagan ilities Coming up with a hypothesis, Testing it, creating prototypes, gathering user feedback, refining, whatever the solution is , like building on it over time the reason why, when will it be done irks me, is because it skips all these phases, when will it be done, well, do you know What the critical barrier is to pass the number of features for your users to flip over and change their behavior to what they're doing now to using our product I feel this issue here of like I just shortcut like when will it be done? Meaning like I want to sell a contract when will it be done because I want to tell people hey You said you wouldn't buy the contract or wouldn't spend the money or whatever until X, Y, Z functionalities are available. It's all available. My dev team did all the work. Now, are you going to sign on the dotted line? No, you're not. Which is the normal thing that most people probably listening to this go through, right? Sales pressures you, you create a bunch of features that nobody's using and now nobody's going to use them because they didn't sign the contract and they weren't serious in the first place or whatever. Okay. so the critical validation steps of like Hey, if I were to implement feature X, would you sign on to the waiting list? If I were to implement feature Y, would you change your current behavior to use our product? If our product became more valuable because I created these features. Yeah. The flip side of it might be, well, Gary from sales can say the prospect, what feature do you need in order for you to. Sign on the started line, right? And now you're starting to get that feedback up, but that's not validated feedback. That's just hearsay still, but it's better than nothing.. It's better than nothing. If you have no other validation process in play. So like it's, it's, that's a tough one to call out. Like you're bypassing user validation, the funny thing about this is it would be less of an issue for me. In this conversation, if I've been almost at zero companies, like it's been one team through the whole career that when you implement features on the software development, Kanban board of implementing features, no matter what process you use, right. It's to do doing done through development, but rap to do doing done. Meaning vetting a hypothesis is a good thing to work on. It comes before to do, and then after done is validating that we actually solve the problem. So wrap your normal development to do doing done in a, is this the right problem to solve? Question mark lane, right? Column and then on the right side, another column that says validate with the customer that this actually did hit the mark. If you started working for a Jira and you forced the default plan. Of all their boards to have those two columns. Oh boy. Like you would create a storm in the market. Yeah, absolutely. Word. I think those bookends you mentioned to your development process are critical and sometimes they don't happen at all. And sometimes they happen minimally. Like I would say that they, they, I would say they never happened. First of all, if you had to pin me down and say, Brian pick pinning me down makes me see you don't like me pinned down. Not a good wrestling move. I don't like it. I don't like it at all let me say this. Before the first, if you skip the first step and you build something, you're taking gamble. Because maybe what you built Isn't worth building Maybe there isn't a market for it, or maybe there's a limited market. So you haven't validated the need You started talking about validating hypothesis If you don't do that You could potentially be in for a lot of hurt because after all that time and effort money spent on building something There is no market or the market shifts during that time Right, so that has to be done up front absolutely think you're going down the route of asking about metrics. And that's valid too. Looking at the wrong metrics. What where where I was going with this was to talk about the discovery process the question when will it be done skips over the whole discovery process so like What customers will this be valuable to let me MVP the solution and take it to these different customers and customer pools or whatever. Ideal customer profiles. Like it skips over all of that. Yeah. And that's where a lot of learning happens. So if you're skipping over all of that, imagine the risk you're taking, right? Where the question sounds innocuous. When, when's it going to be done? Let's say, okay, wait, we haven't done all of this stuff up front to begin with. If the question was, rephrased more of a sort of aspirational planning milestone. Like let's try and get this done by Q1, 2026 that's different. That's, that's not a bad question. We then need to still dig further so you could say, well we want to land on Saturn by Q1 2026. Can we do that? That meme, the meme I put up for land on Saturday, it was completely from a, I should go find the podcast or I should at least find the SRT. for you because it was so funny. I kept most of our laughing about that example in the podcast about letting us, and I was like, I saw the, I saw the meme. It was spot on and we didn't plan any of that. So yeah, looking at it a milestone as aspirational completion for a project. That's fine. You can do that. Just know that you're basically skipping rocks in the river. just know that you're skipping the opportunity to deeply understand the customer's issue or the market opportunity in the case that you're operating more broadly or whatever, like you're skipping over that. The thing that can tie you to deep product market fit. You're skipping over that. Just do this thing and Move on or whatever just tell me when it's gonna be done yeah and even if we don't dig into the deep like You know, the, the, the, we talked about it on a previous podcast about like a, the, the fear based culture of like if you don't, I'm going to tell you when it should be done if you don't meet that deadline, Oh, you're in big trouble or whatever, and we don't dig into like, Picking dates out of the air, like the games that are played in this, Kind of scenario like we could dig into a lot of things on this podcast, but I'm trying to keep it at a helpful Sure level right, but it's like a lot of nonsense that I just as a product manager I just don't deal with on a normal basis because I know they're like you didn't do any customer discovery So like your idea out of the air Or in the shower or your shower thought or whatever is, I mean, it's dime a dozen And oftentimes when you're dealing with the mindset where people are just looking for a date to put on a Gantt chart and say, you said it would be done by the state, right? Well, if you're looking for that if you're dealing in that kind of an environment, just know that they, whatever date you put out there, isn't the date they want, they want something sooner, typically. Well, let's talk about. Something that people might be thinking about and maybe like I was thinking about early on We started like within the first two minutes of starting this podcast I was thinking about but I couldn't quite put into words and up until now I couldn't think of a way to put it into words, but it reveals a waterfall mindset Under the guise of agile. Waterfall in agile form. I'll come up with all the requirements that you need to do, and then I'll give that to the team and they'll take two weeks and they have their little agile waterfall within two weeks. You know what I mean? You can't change what I gave you as the quote sprint goal, but the sprint goal is just like a, Series of stories that are just requirements the real damage the emotional damage of this category is it's a super slippery slope in a lot of different directions, One of which is like, oh, I told you don't dig into when's it going to be done? Meaning I already know the scope of what needs to be done. Meaning there's an unwritten or maybe it really is written requirements of what I think you should be implementing. And now you have to do what I say. You're force fitting often, right? So you'll have things like PRDs and TRDs and FRDs around and you're going to have to then force fit to that milestone. Right. And Almost inevitably, what happens when you try and do that? Quality goes down the toilet, right? Because you're focused on meeting the date. So, everything's wrong about this way of working. But it starts with that question, right? And sometimes it's not even a question, it's a statement. It's going to be done by August 29th. Right, they just pick a date because it's convenient for them. Yeah. Yeah, and it like again like a waterfall side like the the product manager if you have a Designer a tech lead if you have partners like the the Marty Cagan the holy trilogy or holy Trinity. you can do a lot to offset this. Sure. Because you have several people that can go with you on this and be like, Hey, why? Like, why are we pushing this thing? Why have we not, you know figure out the business viability and the, and the usability. You know why have we not figured this thing out? Yeah. Why haven't we not dug into these other categories? And you can do a lot, but there is an underlying issue here. that we haven't talked about, which is that you have people pushing you. They're stakeholders. I don't know what role they're in as stakeholders. C-level executives, managers. There could be users I've been in organizations where end user users can put in feature requests and stuff like that and send it into the backlog, where they are signaling things that they want to have done by a certain date and those requests, a lot of backlog items are completely disconnected from the validated value creation. Yeah. Yeah, that's a good way to put it. Validated value creation, as opposed to meeting dates which, almost, again, almost in all cases, these are arbitrary dates they're not based on anything, there's no basis for the dates. Just that it's convenient for someone to use those dates. Yeah, I mean, and that is the basis of like project management and I also like it depends on what industry you're in as well for sure You know again the other reason that this like irks me is probably because understand when someone asks like oh, I dreamt I dreamt this thing up in the middle of night When's it gonna be done? Yeah Right? The higher up in the organization are, the more you, you're going to irk me when you ask me this question, but it does irk me regardless, because when you're asking me that question, when, when is it going to be done? You, you have no, Understanding of technical feasibility. You don't know if what you asked for technically requires the team to develop the solution that the team will have to be constantly playing Jenga with taking things out of the, you could be asking for something that requires that the team now builds a system that hangs on by a string every time it runs. And basically you have no idea of how feasible it is to build for the first time. Cause anybody could build something one time, but you're asking the team to take it on. Build it and then maintain it. Cause again, welcome to the podcast. Brian believes you build it, you own it forever. Absolutely. So you're asking the team to build it and then own it forever and keep it running. 24 seven. 365 99. 99, whatever uptime.. So you're actually, while you're doing that, the team's building more stuff that they have to own and run and whatever. So this is not sustainable. First of all, right. I mean, pretty much any team cannot keep doing that. And also like, when's it going to be done? Like, Oh, well, when's it going to be done so a million consecutive users can use it? We haven't talked about, we haven't negotiated anything. Correct. And you're asking me the sad part about this too, that we haven't talked about until this point is, I've been coupled with some tech leads, product managers, CTOs. They'll answer the question. Of course. They'll say, oh, we can have that by the end of the week. Some will even stand up and say, look, I can answer that question faithfully because I'm looking back at how we've delivered over the last few sprints but they're missing the point that we haven't done all of those things that we talked about earlier again Go look if this goes up after our podcast after the previous podcast. Fractional. Yeah, if this goes up after the podcast about fractional, the concept of like, How is it going to be built? Like, who's going to maintain it? You know, that's like somebody else's job. If you're in leadership, like that's not. You can't pass off that conversation. That's not cool. Okay, I like I don't appreciate that as a team member working on the development team before I ever moved in the product management. I don't appreciate that. We're up in the middle of night. Exactly, but you know, sometimes they just don't care I mean Pay me the money. Yeah, I'll take the money. So like let, let's talk about, well, you don't care about how technically feasible the situation is. So you're just going to pay more money to develop the scenario, to develop the product feature, to keep it running in production, to just pay your team, to be up in the middle of the night or whatever, or not when you lose people, right. So on that, on that, on that concept of like stripping away the EQ. From running your teams like let's talk about like not like not caring about When when someone's like when they when can that be done? It's like you're not bringing in your development team a lot of times when this question is asked what you should say is I'm not sure I'm a CXO CPO yeah Right fractional part timer consultant product manager sure. Let me get my team lead in. We'll maybe we'll create some stories. We'll give you a timeline, but the pressures of working in the organization and depending on who's asking you, because sometimes I've seen C level executives will say, when's it going to be done? Yeah. And then you feel pressured and then you give a date or if you're smart enough, you'll give a date range, right? But a better answer is why don't I give me some time? Let me get with my team. Let's break it down and figure out where the real value in this is. And then we'll give you a timeline of like, explore the value, validate that that actually is a value, build a solution, figure it out. We'll give you a timeline. I think that's sage advice. I mean, the timeline you're thinking about there really culminates in the time when this, is in the customer's hands that's typically how people think about it, right? So we're not just dev complete or QA complete. It's actually released out in the wild. Even if it's a restricted audience, it doesn't matter. It's released to actual users. If you're looking at that as a date, my advice is this. Add a bit of time to that because you're gonna have fallout from that experience that the user has. So give yourself some time to deal with that. If there's none, great. But if there is some, you have some time there. There's never not none. Especially in those cultures where you have to pressure by dates pressure aside, I think the thing that we talked about in this podcast that has not been brought up, because it's probably not in our agenda, is like, any strategy that hits the real life battlefield you're gonna See some stuff in the logs or you're gonna talk to users and they're gonna tell you some things and then you're gonna say, oh We didn't realize yeah that you really use it that way if you ever watch any of those the YouTube or tik tok videos with that they're putting everything through the square hole because everything fits through the square hole Yeah, it's that thing It's like well Why don't we just design a bigger square hole and then everything fits through like we don't need we don't need a bunch of different You know Size holes in the application. It's the same thing. It's like well We didn't realize until we started talking to the customer that they use it this way and maybe this super easy solution Would solve the problem. So like they're Leaving room for innovation to happen at the team level team to customer level , it's maddening, honestly, from a product manager perspective, where I know that like the real innovation happens when the developers are implementing things and saying like, well, maybe if we just did this one extra thing ? Like it's that level of like, maybe if this cool thing happened and then the real innovation happens? Yeah. Or the user saying. On screen using the app for the first time walking through with the developer on the call saying, Oh, I didn't expect it to do that. Yeah. Maybe if it did this instead, that would be cool. Like those little breakthroughs. That's the innovation that your company. Well, your team, right? And then your company is looking for. Yeah, unfortunately, in a lot of I'll say old school type of cultures that's seen as the customer missed. Or change requirements. Now they're saying they want this instead. So then people jump up and down and wave the change request card, right? Pace more money. And that's a lose, lose all around. The customer is not happy. Your organization's not happy. You're probably not going to collect that last payment milestone. I mean, all of that is just downward spiral. So yeah, absolutely. If you're pressured for a date, think through what your client is Providing, think about how the product's going to land and then add a bit of time to do this, the bit that we just talked about the innovation, or even if it's just addressing issues, whatever it might be, well, some of this is at the team level, like between the team and the users and if you do like sprints, you would use like a sprint demo, like a sprint review with users, but there are some things that are. Like when we seek to implement a feature and you're saying, well, when will this feature be done or whatever? Like, yeah, that's, that's okay. When it will be done, your executive, we have to give you a range because we have to say something, but there are other questions like, well, what. Customer problems are solved by implementing this feature and then rolling that up the problem I'm not not just asking that question because I'm a product manager and I'm a huge pain anyway, right? I'm trying to roll that customer pain point back up to a strategy that comes above the product roadmap above the feature level Yeah, so I'm trying to say like well this is Strategy that all these road map items come from, that's where we can quantify that's where we can put it. Does it align with a broad product strategy and are there metrics that we can use to measure this, the usage of this feature or the way this feature is used or whatever? Are there metrics that we can use that indicate success? So the part of what it says is like, when you have your to do doing done of the development team, can you put a column in front that says validating that is a good idea and a column at the end that says validating the customer actually uses to solve the problem and then bookend your to do doing done development process. And if you're doing that, first of all, you're knocking down so many assumptions. Yeah, that I feel you're ready to compete in nearly any market and beat all your competitors because I've been at a single digit and I'm talking like low, like on one hand with two fingers missing single digit number of organizations that actually have a implemented that sort of like process around the way they do work because they have so few people to do the work. They have to absolutely make sure that everything they do is maximum impact. Yeah. I think you're going to a place where the organization, there's some organizations that will just go a little bit further on the precipice and start to impose metrics like utilization and say, the team must be doing these things. You know, and so when we have a date, they're going to say, I hate it too. I hate it too, because let's face it. If utilization was important and it was critical, like they say it is, we would have to set the whole town on fire and for our firefighters to be busy all the time, burn it down, burn it down. Okay. Where does that leave us? That's it. I mean, that's it. So the most effective product managers and organizations understand the question is not, when will it be done? But rather, are we building the right thing for the right people in the right way? It's actually several questions is, is it the right thing to build? is it the right thing to build for our customers? And are we building it the correct way , it's a whole lot of questions that you like in order to ask and answer, it requires more process. And a lot of people might be very impatient. That's a reason for like that This is like the whole reason to have product management at your organization is to lay down these good Practices so you're not wasting all this time and I like it and also if you want to retain Top development talent like the guys out there that are like I watch a lot of development channels and stuff online who are like, oh just like I don't need a bunch of processes or whatever just let me write good code on cool things like yes do you really want to be the guy that writes good code on cool things that makes no business nobody uses Is that really what, right. So I feel like it's downstream. The effects will be felt every step of the way of like, Oh, well, I'm creating this thing and nobody's using it. And like. Wow, that's a real that's a real gut punch that nobody uses this thing. Yeah, I agree. Those questions are much better than that simplistic question. I think that there may even be another level of questions below the the ones we just said Are we building the right thing or is that the right thing to build now? Is this the right time for it? Are we going to deliver it into the right market geographically or however you're segmenting it? So there's a bunch of questions there. But yes, oftentimes people don't ask those. They simply ask, when's it going to be done? So hopefully now you've picked up a couple of things. I hope that would be helpful in that scenario. And yeah, let us know what you think of this and subscribe and like I like that topic I haven't seen that being addressed anywhere