Defining Scope and Determining Necessary Features

When I first joined Echobind, I was introduced to a greenfield project which meant we were building an application from the ground up. This provided a lot of freedom such as choosing the most optimal technology and designing how the app will look.

Building this from the ground up meant there was an abundance of creative ideas being thrown around each of which was deemed as essential for launch. These ideas were going beyond the basic function of the product. With the deadline on my calendar, I knew all the items on this long list of requests wasn’t going to make it in.

As the project manager how was I to determine essential features while still making the client happy, staying within budget, and meeting deadlines?

Trimming the Fat

In software, there is something referred to as Minimum Viable Product (MVP). This is the first working version of a product and should have a sufficient amount of core features to validate an idea but no more. This was the key to building something that would still make the client happy and not go over budget.

Part of my job was to determine what would be part of the MVP. This meant collaborating with all stakeholders to ensure that we were building features that were relevant to validating the product.

The definition of an MVP is fairly easy to understand theoretically, but much more difficult to practice. Our CEO, Michael Yared gave me excellent advice when determining critical features for product validation:

• Is it absolutely critical? Yes or No?
• Can we simplify it? Yes or No?

Using those questions as a base I built a decision tree to help me answer my question around new features:

Is this feature necessary for this phase of work?

Referring to this tree has been helpful in determining whether a feature can be revisited in the future or if we have to absolutely build it now. If we’re building an app whose primary feature is to allow users to chat with each other then a feature for user profiles showing birthdays can be determined as a “nice to have” for the future.

If a feature is determined to be necessary and is large enough to begin affecting the budget and meeting the deadline I’ll reanalyze other requested features using this tree. We want to be ruthless and trim down to the core necessities for MVP.

Wait, Technical Debt?!

In the tree, I mention technical debt which is a concept that Robert Beene ensures we keep in mind for every project whether that be greenfield or not.

Before saying that a feature can be simplified it’s important to consider the ramifications of making that decision. Will simplifying it now cause us to work harder later? With three primary factors to consider for projects (budget, quality, and time) we may be saving on time now but pay in budget later to fix this technical debt.

Not Mushroom For Technical Debt

I want to talk about technical debt using a real-world scenario I encountered recently.

I’ve gotten into the hobby of growing gourmet mushrooms. As a side project, I wanted to build an app that would allow me to easily search all types of mushrooms and view certain information about them such as health benefits or if it’s even safe to eat.

I knew for my MVP build I wanted to have the mushroom name and its potential health benefits. Mushrooms can have more than one health benefit so my initial thought was to have an array to hold these. It’s simple to do and doesn’t take much time. Great! When I search for a mushroom I’ll be able to see its health benefits.

Well now I have a cold and I’ve decided to make a soup containing mushrooms. I know reishi mushrooms have immune-boosting benefits but unfortunately, I’m not growing those right now and the store is all out! To see what other mushrooms have the same benefit I want to filter for the mushrooms with that specific benefit. Given that I used an array to store all the benefits for the mushrooms each one has to be touched to see if their array contains the immune-boosting benefit.

If there’s only a handful of mushrooms in the database this may not seem like an issue. But what about if there are hundreds? If I’m trying to search for those with immune-boosting benefits, I now have to touch hundreds of individual mushrooms and check their arrays. This is a significant problem when it comes to efficiency, only I realized the issue too late after hundreds of mushrooms have been added to the database.

Now I have technical debt. I have to go back and implement a more efficient solution which costs extra time and runs the risk of losing data which would be even more time lost.

To improve this let’s look at what I know:

• A mushroom can have many types of health benefits
• A health benefit can belong to more than one type of mushroom

Have you guessed where this is going yet? That’s right, a many-to-many relationship! Using this relationship to our advantage we’ll now have a mushroom table, a health benefit table, and a join table. This join table will hold the association between the mushrooms and the health benefits.

With this new structure, I can ask the join table to show me all the mushrooms where the health benefit is that of immune-boosting without having to touch every single mushroom in the database. This makes the processing time for filtering those results much more efficient.

Using an array simplified the work and saved time at that moment but I didn’t consider the technical debt that it was causing.

Be Fearless

I said it before and I’ll say it again: be ruthless! As the project manager, it’s our job to guide the client to success which can require tough calls that you can’t be afraid to make.

You can narrow down the product to its core MVP features and still end up in a situation where the deadline doesn’t allow for the given work. It could be a dilemma of deciding between two features and the client is torn on which way to go.

Help guide them to the final choice using the decision tree. They may decide to cut a feature entirely or decide on trying to implement a simpler version.

Just remember, before you simplify a feature consider the technical debt! If it can’t be simplified, assure the client that waiting to implement it in the future may very well be the best decision they can make. They may even appreciate this attention to detail and feel you have their best interest at heart.

Sometimes all that the client needs is the reassurance that a successful product can be still be made even if we have to make some cuts here and there.

Until next time!