{{announcement.body}}
{{announcement.title}}

Effective Prioritization: In a Fast-Paced Startup Era

DZone 's Guide to

Effective Prioritization: In a Fast-Paced Startup Era

Get your startup on the right path.

· Agile Zone ·
Free Resource
Prioritize your success.
You may also like: 5 Project Prioritization Lessons We Learned the Hard Way

At a time when startups have flooded the market, sustainability is the key to success. Many of these startups are at loggerheads with each other and literally have the same product, in turn, giving each other severe competition.

Your tech team will be awesome at delivering technological stuff but when it comes to project-level details, and decision making, they will need direction. That is were people like project manager, product manager or scrum master pitch in. This direction will have an enormous impact on time to market and eventually sustainability.

It is very easy for the team to implement the projects using a sequential or linear approach. I am rather a proponent of the value-based development approach. Adopting this approach will turn out to be a boon in difficult times. Value-based approach prioritize your features based on the value it provides to the finished product. It tries to implement the most valued feature first.

During project initiation, the team might have a very good plan but they can run into bottlenecks and get slow. Sometimes scope creep puts the team in a bad spot. All this will either result in hiring more resources, in order to meet the timeline or delaying the product launch. In this era of cut-throat competition, a delay in the launch or a huge spike in cost can turn out to be highly detrimental. Prioritization comes to rescue here.

The Situation

Let’s take an example of how the value-based approach and effective prioritizing can be a lifesaver in such situations. Suppose your company is launching a Christmas Express train on Christmas Eve. Everyone is very excited and the best team has been assigned to this task. Your competitor announces the same after a few days. This puts you in a situation where missing the deadline is not an option. You later decide to include luxurious facilities and modern interiors for your passengers.

Your competitor too follows the same. There is a marketing war to bring in traction. Your marketing team will need your support but do you have the bandwidth? Suddenly the competitor announces aggressively closer launch date and renames it Thanks-Giving express. Can you handle this situation? It all depends on your approach and prioritization. Many projects tend to descope some complex and most valuable features to meet timelines.

The Path

Your competitor was using a value-based approach. They started working on the engine and a few bogies first; however, your team was busy refining the passenger facilities and beautification of the coaches. Your project manager was providing % based completion status (a common trend) and informed the organization that they are burning the midnight oil in order to succeed.

In reality, your team is running around like a headless chicken and there are burnouts and frictions. The organization was also informed that the product will be 75% complete i.e. out of seven bogies and an engine, six bogies will be ready by Thanksgiving. Your organization was celebrating because the competitor will only be 50% done. Below is how your and competitor’s trains look.

Value-based Vs % based models

The early bird has caught the worm

Your competitor worked on the Most Viable Product (MVP) and was better prepared for today’s fast-paced era than your team. Without adding extra resources, a workable product was built. MVP takes a value-based approach and prioritizes the features that add more value. If you are developing an online store, the app should prioritize ‘product listing’ and payments feature and these should be implemented (and probably released) first rather than working on a catchy sign in and login features.

Taking a look at flavorless Google’s or Facebook’s login and create account page, we can deduce that they focus on where it matters. The pre-release of the train example can be viewed as a pre-launch of software or a demo at an important conference. Moving further, there are numerous ways to decide what to implement first, when you break down your features or epics into a granular level. In this article, I will refrain from going into those microscopic details.

Take Away

As mentioned earlier, without direction, the team tends to follow a sequential approach. The sequence that is often used, may be based on common user actions or wireframes. As an example, while developing an online store application, there is a tendency to work on ‘creating an account’ and login sections first. Normally, the teams spend more time with the functionalities that they are developing first. They may like to fine-tune or make things fancier.

Later when the team realizes, that time is not on their side, they play catch up with the most important functionalities. Either the team will have a buggy implementation of an important feature like payments or it will be descoped from the initial version. Consequently, the product loses the first impression game. In order to descope any feature, they may keep complexity as the deciding factor.

This can have adverse effects. Rather, using a value-based approach could have been a smooth sail. Going by the same example, ‘listing of products’ and payments should always be at the top of your priority list and should never be a candidate for descoping.

Remember, if you know you are going to run out of electricity soon for your oven, it’s better to have a well-baked smaller cake rather than a half baked big one.


Further Reading

In Sprint Planning, How Do You Prioritize the Requirements in the Backlog?

A Simple Rule of Thumb for Priorities

The MoSCoW Prioritization

Topics:
agile methodology ,product management ,scrum (development) ,scrum master ,product owner ,product manager ,project management ,startup ,project manager ,prioritization

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}