How to decide which feature you'll ship next

As part of the product department, your UX team is always looking ahead, researching needs and fleshing out concepts that should *hopefully* translate to new feature candidates.

At any given time, you likely have dozens of screenshots, messy diagrams, half-baked flows and unfinished designs sitting around in Figma drafts, waiting to be picked back up.

Not to mention the spreadsheets filled with user feedback from research, or the infamous Backlog™ of bugs and UI fixes.

So, how can you determine which feature ideas will make the cut? How do you prioritize the right candidates to develop?

Being on the team in charge of user experience gives you an advantage in leading this effort. You can weigh your product knowledge against the needs of both business and technical stakeholders and evaluate which ideas the organization is receptive to.

You want to move steadily and efficiently, but you can't do that without enough clarity. You need to find out what matters to everybody else before you start, or you might be blindsided when you're already halfway through.

The goal is to align with other teams and reach a shared decision that will be implemented in a few weeks.

Let's see how to do this.

Choose your features

Working with your team lead, design and writing colleagues, select 3–4 improvements or projects you've fleshed out the most.

When I say "fleshed out", I mean that you should try to come prepared with:

• The why and how
• Stakeholder buy-in
• A good grasp of the user flow

The why and how

You know which user problem your idea addresses and can describe how it will do so in simple terms.

Stakeholder buy-in

You've had conversations about your idea with different stakeholders, and they generally agree that implementing it would add value for the product and its users.

Perhaps it's something that has long been in the works, but you've never been able to make the case for it. Taking note of which teams are familiar with your proposals and may already be on your side can help you gain more leverage.

A good grasp of the user flow

You have a general understanding of the user flow, and perhaps even a lo-fi prototype to back it up. These are needed to help others outside the UX world visualize the process. They don't need to be final. In fact, they'll most likely change often as you progress.

Once you've made your pick, write down your feature ideas. In a couple of sentences, summarize what each feature aims to do and how. This will help bring everyone up to speed, especially those who are less involved with your line of work.

Evaluate your options

Now, set aside some time to go through these core aspects with the UX team:

• Business goals
• Product roadmap
• Technical feasibility
• Resources (people and time)

They'll help you understand how much value each feature may add.

For each feature idea, write 1-2 sentences to answer the questions below to the best of your knowledge.

Business goals

Question 1: Does the feature meet our audience's needs?

Your organization's customer-facing teams may have identified a demographic that's struggling or a segment that consistently drives more revenue. Or perhaps there's a new type of prospect the business is interested in pursuing.

Learn more about these users, then try to understand whether your feature ideas could meet their wants and needs.

Product roadmap

Question 2: Does the feature address a shortcoming or existing problem with the product?

Part of your organization's product roadmap will address legacy issues, long-standing tickets and strategic, user-reported bugs.

If you can connect one of your feature ideas to a critical task in the backlog pile, you likely have a candidate worth pursuing.

Technical feasibility

Question 3: Are we able to deliver on the technical requirements?

This ties back to my earlier point about setting the stage through conversations with other stakeholders. When you started exploring and researching your feature idea, you probably had a Q&A session with tech teams, or perhaps they shared a preliminary list of requirements and constraints with you.

Gather the technical information you've received so far, review your designs and see if you can prepare an MVP proposal that aligns with both sides of the story: UX and engineering.

Resources

Question 4: Are there enough people and time to deliver the feature in the coming sprint(s)?

This one is pretty self-explanatory. You may have a feeling about how busy other teams are and what their day-to-day looks like. Impressions can be misleading, so it's best to check regularly with leads and team members to see how they're doing and if everything is on track.

After answering the questions, you might end up with something like this:

As you'll have noticed, you won't always have all the answers right away. You can speak for the UX team and give an informed opinion from your perspective, but you'll need to check in with other stakeholders to get the full picture and figure out how to move forward.

That's what the next step is about.

Meet stakeholders

Now you know where you stand on your feature ideas and can confidently argue for or against prioritizing each one.

It's time to bring together other team representatives, hear what they think and make some decisions.

Organize a meeting with a few select leads from engineering and customer-facing roles. Think the usual suspects: front-end, back-end, security and data science (if your product requires it), but also sales, marketing, customer care and delivery.

When you're ready to introduce your feature ideas, bring out the visual aids you've prepared: the user flows, the prototypes, anything that can quickly bring everybody up to speed.

Then, follow your notes to explain why you think each idea should or shouldn't make it to the next step.

Once you finish the overview, ask everyone to express their opinion. You can even do an informal voting session to gauge the sentiment, like in a team retrospective.

As we saw before, you might have less information about technical feasibility and available resources. This is the right time to fill in the gaps with engineering leads and understand how they feel about implementation.

If you notice pushback, suggest focusing on what's feasible for the MVP to build momentum. You can always break down advanced requirements that need more research and save them for later increments.

By the end of the meeting, you should have a clearer idea of which features you all want to move forward with, and which ones will have to wait instead.

Record all results in a table to quickly see how the session went and make sharing easier.

Next steps

After this exercise, you'll be aligned with important stakeholders across departments. Thanks to the materials you prepared before the meeting, you'll also get a head start on planning the following UX activities and design sprints. You can time your tasks based on the other teams' bandwidth and build your rationale around business and user needs as you go.

At first, reaching a consensus on the direction might be hard. As frustrating as it sounds, someone else's opinion may end up having more weight than yours simply because of their title or seniority within the organization.

You'll probably have disagreements or feel like you're wasting time discussing the finer points and losing track of the bigger picture. Eventually, the group might approve a different course of action from what you had envisioned and hoped for.

What matters is not who wins the match, though. Your goal is to break down barriers and bring leadership together.

Structuring the discussion around criteria such as business goals, product roadmap, technical feasibility and resources shows you understand the variables that go into making complex decisions.

Your message is clear: We know your field has specific challenges, and we care.

You're introducing a good practice that will put your team on the map and increase your chances of being heard. When you show your cross-functional partners that you see them, they'll start seeing you too.

I’m Elisa, an Italian content designer with a background in localization and customer service. This is where I document my life in UX and writing.

Read more