If you search for “feature prioritization blog post” in Google, you would get about 72,900,000 results. So, why would we need another one? Truth to be told, we don`t. But, through my research, I`ve found that most of the articles go into one or other direction, either discussing the prioritization techniques or strategies. The aim of this article is to walk the reader through the process in a real-life situation, with emphasis on the client’s perspective. Why is feature prioritization so important, how to properly approach the process and what should be the outcomes?

In the last couple of years, I`ve been involved in the development of a couple of hundred different digital products. Almost half of them never got off the ground. An even lower percentage was able to monetize the idea and get profitable. Of course, there are many reasons why some digital products would fail and end up being a waste of time and resources. To name a few: poor market research – that type of product already exists and has commercial success; unreasonably optimistic timelines, especially when dealing with investors – usually leads to break of trust; lack of technical capabilities – more often than not, some great ideas are shut down because they`re not feasible at the given time; bad go-to-market strategy – even if your product is really good, you can’t expect commercial success if there is no one willing to pay for it

Majority of these challenges have a common denominator, and it revolves around features that are being built. That is the core of every product and it is necessary to understand the value and impact of every feature that is being developed.

There are many articles out there that focus on Strategy or Frameworks that can help you with feature prioritization. Some studies say that about 40 different techniques have been developed over the years, because it was agreed that it was not possible to fit one framework into every use case. Therefore, my focus here won’t be on the specific techniques but rather on the overall approach that someone who intends to invest in a product should have to maximize the chance for developing a successful product. I`ll be using one case study in order to showcase the concept in a real-life example.

The Problem

/We partnered with a mobile Covid testing laboratory that identified a problem back in 2020-2022. where you had to test yourself almost regularly in order to travel, participate in social events, have a wedding… Therefore, they`ve decided to build an app that would serve as a portal to their clients and send them notifications and results as soon as their test was processed, with that adding to their convenience and saving time./

Bread and Butter

After the problem has been identified, it is important to figure out how that problem will be solved. Every product needs to have its “bread and butter”. That main feature or set of features that will lead towards the resolution of the problem. The money maker. A couple of things are rather important in this phase, and they revolve around: 1) technical feasibility of the solution. How easy or difficult it is to develop a solution to the problem; 2) market research. Did anyone develop something similar in the past  and how did that go; 3) impact of the solution. What is the benefit that the end user is achieving and are they going to be willing to pay for that solution? Having a clear understanding on what is the solution you`re trying to propose, how easy or complex it is to implement, if someone else has done it in the past and if the solution gives proper benefit are prerequisites for proper decision making.

/In my personal opinion and experience, apps that are in the beginning focused on resolving one concrete problem have better chances of succeeding and being profitable than those that start big, trying to solve multiple problems at once. Following the case study from above, the solution was to build two secure portals, one where the nurses and technicians who process covid tests would fill in the test results for the patients, while on the patient portal, every individual patient would be able to see their previous and current covid test results./

Building Blocks

After the Product Vision (what problem we`re trying to solve) and Product Goal (what is the core of our solution) are set in place, it is time to focus on the building blocks of the Product itself. At this moment, a couple more decisions should be made, providing the foundation for further development. First question to be asked in this phase revolves around scale: are we aiming to build an MVP (minimum viable product) or we intend to build a full scale product? Think of an MVP as a sort of an unpolished, rough around the edges product that has only core functionalities. If I`m to use an analogy, compare a skateboard to an electric scooter.

Both will take you from A to B, just one will be more challenging to ride and steer. Second question is related to the architecture you`re going to pursue: your app can be modular or monolithic. This decision usually goes in hand with the previous one, because modular development enables you to build one set of features, encapsulate it in a module and have a simple, yet operational mini-app. Think of a bicycle as a module.

It is a functional means of transportation. If you develop a new module (battery), you can connect it to the bicycle and have an electric bicycle. Or if you add a new module (carriage), now you have Pedicab. In contrast, if you decide to build a monolithic type of an app, it is important to understand that the product won’t be operational until fully complete. You can look at it as the shell and chassis of a car, rather useless, until the engine is developed and inserted. At last, the third question revolves around the decision to build everything in-house versus integration of 3rd party solutions.

This is also a question of speed, resource availability, customizability and control. Following the examples from above, if we have built all of those vehicles to start ourselves a delivery agency, now the question would be if we want to build an in-house point-to-point navigation system or we would integrate a service such as Google Maps.

User-Centered Development

After the foundation of a product has been put in place, focus should shift to bells and whistles that support the core features. And here things get complicated, simply because there are so many avenues someone can take. Different stakeholders can advocate for the product to be built in different directions, yet, there is one stakeholder group that every product development team should listen to with utmost attention: end users.

Regardless of the type of the product and the problem it is meant to solve, the user experience is always the paramount objective, and feature prioritization should always go towards the better experience. In an ideal scenario, you might have done market research. And you might know how your users prefer to be onboarded on the product, what their expectations are (talking about experience) and how you would monetize from it. Unfortunately, sometimes, this is far easier said than done, usually while we`re still ideating about what should be built and in which order, without having any input from the end user.

In situations like that, the team is using best practices for a particular industry and product archetype, assuming that if something has worked before, it would still work today. This is the moment where feature prioritization falls into place.

/When we started building our Covid testing app, that specific use case was rather new and we did not have a proper user base to perform market research. So, we`ve tested a couple of assumptions: To achieve ease of use, the app had to be mobile and tablet friendly, so it could be used on the go, therefore the design had to be responsive. We expected that users most probably had experience with EMR patient portals in the past, and tried to mimic the onboarding experience. Still, we wanted to ensure the access is secure, so 2FA was mandatory. At the end, it was important that patients can see their results within the portal, but also to have the option to download them in a convenient way, and we opted for the PDF format./

Feature Prioritization

As stated in the beginning, there are so many techniques for feature prioritization. But, at the end, it all boils down to three questions. The first one is: how easy/complex it is to build this feature? (and this same question can be asked in a different manner: how expensive is this feature to implement?) The second question is: how quickly can we implement this feature?

And the last question you should ask is: does this feature bring value to the user? (again, this same question can be asked in a different way: can we monetize from the implementation of this feature?) I`m personally a big proponent of this approach, because it is in a way a never ending cost versus benefit analysis. Every feature is looked at through the prism of its value for the customer and then prioritized taking into account the complexity and time to delivery. In order for this flow to be achieved, different stakeholder groups have to be involved in the development strategy with a big emphasis on the business analysts that are the voice of the end users.

Also, this approach is well suited for the iterative delivery of small increments of working product. It allows for all hypotheses to be verified in real life conditions with end users. And a good team would ensure that valuable feedback from the field is collected and implemented in future iterations of the product. 

/After the first iteration of the Covid app was released, it served its intended purpose, users would be able to schedule testing, receive notifications when the test results are ready and to see and download their test results on the secure patient portal, and to do all that on their phone. On the side of the medical staff, it was possible to see the scheduled times for patient testing to onboard a patient and input test results. That was the bread-and-butter, solution to the said problem. It was only after months of usage that new features were implemented, such as the ability for a single user to schedule and manage multiple patients (used for sport teams, homes for the elderly etc.), to have different types of tests performed, to allow for nurses to bulk update test results or for administrators to pull analytics for every test performed. And all of those features were carefully considered and agreed upon, by asking the three questions from above./

Instead of a Conclusion

Our team is composed of subject matter experts in different fields, such as Business Analysis, Market Research, Design, Development, Lead Generation, with a proven track record and ability to walk you through the entire process of product development, from ideation, through development until monetization. Check out our portfolio and what we can do for you.