Prioritizing Features

Prioritizing Features


Today is feature prioritization day at company x that sells a service to people. This means developers, product owners, and team members along with other departments in the company convene to ‘hash-out’ every final detail before rolling out a new feature that will land in the pockets of millions of digital global users.

The new feature is shipped out in the world, and in the following three weeks it becomes obvious that this added feature that everyone agreed was a great idea failed and now is very low priority to the customers turning this feature to a low business metric and no benefits.

Prioritizing features is about realigning your daily product goals by asking repetitive questions that lead you to optimize after feeling frustrated towards what went wrong.

The client is not seeing numbers. Customers aren’t even noticing these new changes on the platform, no one is using this new feature. A big budget went into this project, everyone thought that a design overhaul to give the product a fresh look is the solution to why users aren’t doing what the product owners anticipated. The project failed since real customers were never included at the core of the product development conversation.

Ask your customers before building solutions if they will notice these changes.

For mobile app developers, don’t take away features that people use or need with no explanation or rationale behind the decision to change.

Ask yourself before building:
Why does the user think the new feature is useless?
What went wrong when product designers decided to iterate the product?

Nothing went wrong, it’s just that research was never conducted thoroughly. When researchers are not part of the conversation, accuracy becomes non existent.

Designers took steps that were mostly based on the objectivity of designs. Developers and researchers must build a bridge to connect with what the other goes through.

By having common grounds we can formulate neutral biases backed up by data points to the product’s benefit. While there is truly no one to blame, everyone is to blame because we all want to do our job with maximum efficiency and zero loss.

The real question is: how many times do we have to run into hurdles to uncover software problems and truly conduct research for the benefit of the business and customers? 

We usually fall into a vicious cycle of creating self doubt with our original ideas due to fear and miscommunication with teams. Being in a creative field requires a whole lot of mental strength by being firm with yourself, your team, and your clients but open for interpretation and flexible to update ideas by letting go. As designers, we want to expand on our ideas but we find ourselves caught up in the trap of negative self feedback.

It’s a crazy loop, we want to create and expand but we’re terrified of failure.

We tend to lean back on familiarity, missing out on opportunity, stopping bright and scary ideas.
Taking risks always requires us to step out of our comfort zone.

The trick is to know when to catch yourself and realize that fear of failure is an emotion that can be controlled.

It takes a ton of personal steps to recreate your dream and turn it into a tangible reality.

This situation or a similar one may have happened to you; your company’s global team meeting.

Everyone is ready in the conference room waiting for departments to share updates in the meeting. Some people are chit-chatting, others are on their phone.

The team is waiting and the rest who are leading the meeting on the main screen scramble to connect their laptops to kick off the presentation.

Messiness is different every time. Everyone settles in for the meeting to start.

People feel often confused by how to make things work in their favor.

The next time you’re in a meeting with decision makers trying to understand what didn’t work or why, just ask humans and follow your instincts, you already know the answers.

A Day in the Life of a Product Strategist

A Day in the Life of a Product Strategist

We Are More Than Data Points

We Are More Than Data Points