How This Product Manager Navigated Competing Priorities Under Pressure to Deliver Key Features

OK. And In probably the last 6 months to 12 months, um, we had competing priorities, um, so the, the situation was to do a feature that would help the administration administrator user or pull. Uh, uh, a release of the, uh, uh, a feature that was for every user in the system. So basically 1% or 99% of the users, and they both had different merits. Um, one was, uh, increased, uh, one was a feature to help populate, um, a system and the system was a, uh, staff celebration platform that needed, uh, that was provided to the SNP space and it needed a population for usage. It needed a community of users, where the other one, was, uh, helping existing clients and, um, ensuring that They had, uh, the main core use case had this feature, but it, there was a risk of that secondary feature being pulled, um, because both were competing priorities. So not to go down to competing priority piece. And the decision was made to investigate these 11 they were bugs that were established and see what the impact was. And by weighing up the new feature. We were able to understand that the, the new feature for population would still benefit our growth goals, but the, uh, deciding whether to pull and see, to pull the, the generic feature that would help all of the existing users. And that, that was, And Somewhat, uh, what's the word I'm looking for? It was somewhat, um, Deprioritize that as in it didn't get it, it wasn't a P1, it wasn't a severe issue. We essentially, um, found that we could do an internal workaround to still ship the feature, but we had to deal with a bit of a headache behind the scenes. So unbeknownst to the clients, they would still benefit from this. 99% of users will benefit from this feature, but they, uh, won't, which was a gallery tool, um, uh, for selecting media, um, They Yeah, they essentially, um, were able to still ship it, but we had to carry a headache for six months. Um, but at the end of the day, we still got, um, one feature out with a bit of a, you know, a bit of a skeleton in the closet and one that didn't have that. I hope that answers what you're looking for. Well,

Um, I, I, I always talk to the, the, the, the people that have the most information, so the, the, the, the QA's and the Dev that are involved in this, and I get it, I want to be as close to the problem as possible. So if they have any risk about, um, I think I'll fix it in this, or I can fix it in this amount of time, you weigh up what, what the, um. What the needs are for that versus the other. And then you weigh up the, the, the goals that you're trying to strive for with each of these releases. What was the original thing you were, uh, doing and I was doing, um, Solution A versus Solution B, and this is the pros and cons of adopting each. And then trying to find out if there was any wiggle room for a compromise. And the compromise is either going to be with the stakeholder, or it's going to be with the dev, or it's going to be with the user. Something's got to give. And, um, in this scenario. You know, we had to take on a bit of a headache, but we still got out some of the, uh, solutions that to meet some of those goals that we were going towards. But it it was really assessing the, the time to value for the customer, the, the effort and the weightings of these development tasks, and then also the impact, making sure that without the future, what would that experience be? And can we, can we suffer the headache for the period of time that we expect to suffer it for.

Um, once I explained that it was an internal, uh, headache to carry, um, it, it, it was digested quite well. Um, the, the alternative was, um, stopping something that would have affected lots of users and the other, um, let's say solution A, which was one for, which is a new feature, that one was untested as well, but we wanted to make headway in our growth goals. So it was explaining that you're going to get both, but we will suffer a little bit of headache time for a period, uh, that, that might affect the backlog going forward, but understanding and quantifying how much that's going to be. And, so we were able to speculate about the, the size of that headache and how long it's going to be and what, how many aspirin you're going to have to take over that period of time. And that helped the decision be a bit clearer for those stakeholders.

And was, let's see, the biggest obstacle to get approved. As it came to a kind of a happy medium with this scenario, um, the obstacle was more so, uh, reaching out ahead of time to the personnel that would be involved in, um, suffering this headache as I'm putting it, um, and if we didn't have an agreement that that was an acceptable amount of work, I would have just been passing the buck and throwing a problem over the wall, and I didn't want to do that, so I wanted to keep the relationships with the support team. Um, you know, to a high level, and I also wanted to make sure that the stakeholders knew that I had taken ownership of the problem and I was carrying this headache alongside with them, and I'm gonna make sure that it was going to be dealt with at the appropriate and earliest time without affecting their other more high priority goals for the, for the business and the the department.