Saying “No” Sometimes Is the Best We Can Do: Prioritisation in Product Development

Raise your hand if you’ve ever received an “urgent” request from a stakeholder—something that was never discussed before, wasn’t included in any milestones, but suddenly seems like the most important feature in the world. Yes, that’s happened to most of us working in product teams.

Our teams have limited capacity in resources, people and time based on the available budget. When we start a project, we usually have a broad plan, clear goals, and a product vision that outlines the essentials for the product’s success.

This vision must be well defined to keep the team aligned, manage expectations on all sides, and establish boundaries for what will be delivered. But what happens if we don’t define this vision clearly from the beginning?

Sometimes, the core problem is a vague or insufficiently detailed product vision. A vision that’s too broad leaves room for frequent adjustments and changes, which makes it harder to decline new features later on—because we’ve left the door open to them since the beginning of the project.

As an example: I have joined a project that was already ongoing a few years ago. The basis of the product was already built, so the team was developing additional features to add value to the product. But since they didn’t have a PO from the beginning, we had almost no documentation regarding the product itself. What was the goal for it? What was the vision behind it? What need would it suppress?

In the beginning it felt like I needed to work harder to understand the entire logic behind it, but for some reason it never felt enough, something was always slipping through my fingers (thank you, ABBA, for this precious instant memory).

The team was demotivated, they didn’t understand why we were implementing certain features, it was not clear why they were needed there, nor the urgency of the requests that come up every single day. We had requests coming by email, on Slack, tickets directly created on the Jira board—it was a nightmare!

First, I started to document what was already done and what we were working on.

Afterwards, we created specific channels to communicate with each other. For example, bugs and improvement suggestions (or supposed bugs) could only be communicated through the Zendesk channel, and were addressed according to a priority established.

Then, we set up weekly calls with the stakeholders to discuss our ongoing work, their feedback regarding the features that went live, and align our next steps by managing expectations and understanding priorities.

And finally, we gave “view-only” access to the Jira board to the stakeholders.

This is just an example based on experience, but I believe we all have similar experiences, and we always learn something from them. When we are confronted by it sometimes it seems too overwhelming, we think we can’t move forward, we can’t change the habits that are implemented, but what we don’t realise is that sometimes the team is eager to have a fresh perspective on things, someone that will shake things up and bring a new approach.

We should not have resistance in proposing new approaches. If the old ways are not getting us to the place we want to be, why not change it?

Well, as we know, introducing significant changes mid-project can disrupt all the work done so far and also impact the team, not only because team members might feel lost or demotivated, but because it can create a sense of instability and erode overall focus.

Having a well-defined product vision, combined with an ongoing discovery phase, is crucial for achieving good outcomes and for providing solid justification when we choose not to pursue a new feature in the middle of development.

Building a strong relationship between a team and stakeholders takes time. Trust, alignment of work styles, and shared approaches are all critical for a project’s success—but sometimes it takes very little to damage that foundation.

This can be one of the reasons why product teams can feel hesitant to challenge stakeholders’ ideas. After investing so much time and effort in building rapport, we’re understandably reluctant to risk losing it over a single request that falls outside what was initially planned.

But should we truly consider this relationship so fragile that it could be destroyed by a single disagreement? The reality is, we need to read the room carefully and act professionally.

It’s not about refusing ideas arbitrarily—it’s about explaining our reasoning clearly, so stakeholders understand the impact of implementing the proposed change, not just in terms of delivery timelines, but also in relation to team motivation and productivity.

If all the relevant factors are transparent and well communicated to everyone involved, we shouldn’t fear losing our connection or relationship with stakeholders. Choosing not to pursue unexpected, last-minute changes is one way to ensure we deliver our work on time, with quality, and with genuine added value—and protect our team.

The key is to remain as transparent as possible: share with stakeholders the established product vision, the goals you’ve defined together, the committed timeline, and key milestones. When new requests arise, you can refer back to this shared understanding to support a decision not to proceed. Communication is always one of the most important tools we have!

There are several methods we can use for prioritisation, such as the RICE or MoSCoW methods. Let’s explore the MoSCoW method, as it’s one we frequently rely on.

The MoSCoW method is a technique used in product development, project management, and agile planning that helps teams focus on what truly matters for moving the project forward.

MoSCoW stands for:

Struggling with feature creep, misaligned priorities, or constant last-minute requests from stakeholders?

Our product team can help you define your product vision, streamline communication, and implement processes that protect your roadmap and your people.