Skip to content

How to plan for Product Development

This tutorial goes over the process a development team should take before writing code.

Posted on:July 11, 2021
10 minutes

Planning a feature for development is not exactly what you think. It’s not with the purpose of knowing every single line of code you want to write, or even figuring out everything that might block you during the process. Planning a development feature is a process to help you:

All three of those points are extremely important when it comes to knowing what you can deliver in a certain amount of time.

Regardless of how many experienced software developers and project planning says that timeline estimates are guesses (with which I fully agree), they all still ask you for an estimate on how long it’s going to take. So we might as well get better at our guesses.

In this tutorial we will go over the planning of a feature we (or you, if you want to contribute) need to implement in our BoxtOut application. The feature we are planning to build is “Location based results”. In a food delivery service it’s important to show the user only restaurants that are in their vicinity to ensure a speedy delivery of their food. We’ll go through each of the points above and do concrete planning for the feature in those steps.

Understanding your problem

It’s absolutely crucial that you understand the problem you are trying to solve. Problem sometimes has a negative connotation so we can also phrase it as “Understanding your feature”. There are different levels of information that you are privy too during the process leading up to this. At the point of development feature planning it’s only technical and the actual problem / feature that matters. It’s great if we know the business reasons and the impact it will have on our clients financials, but those problems were solved before we got to the technical development planning. Which is what this is.

The way that I break down a problem, which has been very successful, is by “walking through what we want to happen”. Before we can do that, lets give a single user story to the feature.

When a user opens the app they should see only restaurants close to them.

That is the feature we’re trying to build. At this point we can move on to the solutions portion.

Exploring Solutions

We’ll write down a minimum of 2 solutions. Beginners won’t have these solutions stashed away in their heads so there’s some research that’ll have to go into this. More experienced developers can combine different tools / solutions from their past experience and using their engineering knowledge can come up with viable solutions. I will choose two known solutions to this problem and we can explore pro’s and cons of them both.

Divide restaurants into regions and return results per region

With this solution we place the merchant within a specific region. This will be determined by the lat/lng they enter when filling in their restaurant information. When a user enters their address in the app for delivery we figure out what region they’re in and we’ll return only restaurants for that region to the home / browse view.



Return results based on a radius / minimum distance from the user

With this solution we don’t care about regions. Each restaurant still stores their lat/lng and we use the basic distace between lat/lng points algorithm to get an “estimate” of how far it is. This will be done on the backend and we’ll only return restaurants that are available to the user. The response from the backend will be amended and will contain the distance from the user’s selected address to the restaurant.



After laying our your two solutions it’s time to talk to the senior in the team or the architect if you have 1 at your disposal. In our case we’ll choose #1 . I think mentally it’s easier to handle and we don’t need a well defined, highly optimised algorithm to calculate the information we require. Now that we’ve determined our feature and have a solution to implement we need to come up with our development plan.

Exploring Selected Solution

In this step we need to ensure that EVERY question we have is answered. These questions will arise as we walk through the implementation and find points that are not entirely clear at a high level. It’s not to determine the implementation details. That will be done by the implementing developer. It’s specifically to determine at a product architecture level:

To make use of this functionality we know that the Merchants on the system has to be divided into regions. Here comes the first question: How do we determine which region a merchant belongs to? This question falls into the 3rd part above. What is the process to get this information

Determining the region a merchant belongs to

There are 3 options for this:

  1. Given that Merchant onboarding will be an operations task and will have on the ground sales representatives to onboard a merchant. They should know the area well enough to place restaurants in certain regions manually. This means that we don’t have to do any calculation or define region boundaries at this point.
  2. We use the lat / long information supplied when creating the merchant and using google geocoding we figure out which region the merchant belongs too.
  3. We use the city as the region

Out of the options above I choose #3. It’s the easiest to implement and the most straight forward at the moment.

How do we store the merchant on the backend? - This question holds a lot of merit on firestore. Lets go over the two options:

Storing under single merchants collection

With this option all merchants are stored in a single root merchants collection. Similar to our users.



Store merchants under region collections

In this option we have a root collection called regions under each region there will be a document with the id matching the region name. In side of that region collection we’ll have merchant documents.



With those laid out we’ll choose Store merchants under region collections.

This concludes our backend requirements from the perspective of the Merchant region management and we can move on to the feature from the perspective of the Users region management.

Determining the region a user belongs to

When the user saves their address we want to assign that address to a region. How will we determine a users region? Given the geocoding functionality that exists the easiest solution at this point is to use the city we’re in as the region. This will make is quite easy to map against addresses / coordinate points that already exist. This means when the user saves their address we will take the city and save it as the region. Later on we can go lower to the town level if we need that level of accuracy.

Create a Development Plan

At this point we 100% understand the solution for the functionality that we want. We’ve not talked about any code and if you understand basic parts of the product you should be able to read the above and get at least a vague idea of what needs to be done. At this point the development planning can start to ensure we have a plan that covers all the work required in addition to giving guidance to the QA team on what to test and how they should expect it to work. We’ll start with the non-client work.

Backend work

What do we need in code to make this functionality work? at this point nothing. We’ll insert the merchant with the information that we want and clients will query for a specific region. But for us to develop the region functionality in the client we need some data on the backend to test against. So there’s going to be 1 task for backend work which is.

Setup fake data for region merchant generation when running on emulator

Front End work

Here we’ll need quite a bit work to be done.

⬜ When selecting an address, if there’s no merchants for address show user the feedback

You should always be mindful of work spawned from work that’s being planned. Above we can see that we’ll need a design for the “Not serviced yet” UI. For now we can probably use the dialog that we have in the designs. Which still spawns a new client task

⬜ Build the Custom Dialog UI based on Design System

Custom Flutter Dialog UI

⬜ When we get to Home show user the merchants from their region

Flutter restaurant listing UI

Define the end goal

For the functionality “Show Location Based Results” we are complete. What we need to be able to do by the end of this feature is:

That’s it. We don’t need to build the merchant details view yet, that is all we need to complete our feature and that is all that we will develop. We have our acceptance criteria, we know how to test it, we have our development tasks and now we can start writing the code.

I hope this was helpful, making a tutorial about planning takes longer to go through because I have to actually plan the feature as well while writing it. But this will also be a guide we’ll use internally going forward.

If you want to get these in your inbox, for our newsletter.

Also check out