A software development journal - The MVP (Part 2)

In the last part of this series I mentioned that our team had decided to build a small community focused app that allows users to issue requests for services or help out other people in their local community.

At this point, during our meetings, we kept going back and forth with different ideas and features that we wanted to implement. We were thinking about adding user rankings, neighborhood rankings, searching Neighborhoods based on user location, etc.

At the same time, a lot of questions arose. We knew that the core of our app consists of users being able to issue requests and respond to requests within a specific neighborhood. Here is an example of users interacting with the app:

User A is a member of Palm Springs Residential.

User B is also a member of Palm Springs Residential.

User A writes a request on the Palm Springs Residential main dashboard, saying that he needs help setting up his new washing machine.

User B sees User A’s request on the main dashboard and writes a response, saying that he is will to help out.

User A accepts User B’s help offer on the app and a communication channel is opened between them.

That is the core loop of the app. A user creates a request and a user issues a response. Sounds very simple right? And in essence it is, but as usual in software development, an apparently simple problem can hide quite a lot of complexity behind it. Currently we have 4 entities involved in this: Neighborhood, Request, Response and User. Now, here is a sample of questions that came up:

1. Should Users that haven’t joined a Neighborhood be able to see the requests within that Neighborhood?
2. When a User accepts a Response, does that automatically close the Request?
3. Should a User manually close a Request after it was finished?
4. Should we differentiate between a Request that was closed because it was solved or because it was not needed anymore?
5. How will User A and User B talk to each other after help was offered?
6. What happens to a Request or a Response if the user who created them leaves the neighborhood?

This is just a small part of all the questions we came up with. It’s not exhaustive, but I wanted to showcase the amount of depth even a small, apparently simple feature can present.

We also had to think about how a user joins a neighborhood? Who is the gatekeeper? Should we have a form of identity check?

After a few rounds of discussions, we amassed an impressive list of the potential features. Actually we had so many features that in my opinion it would of taken us too much time to implement all of them. We needed to establish an MVP (Minimum Viable Product) in order work efficiently and have a product ready for market as soon as possible.

Coming up with ideas is easy once you get into a flow state, but having to select only the essentials is though. We had to do it though, so we started cutting mercilessly left and right until we were left with the core features. I will not post all of the MVP’s requirements here since that will take up too much space in this article, but I can say that we’ve removed all of the superfluous features and instead decided to stick to the essentials, and that is to allow users to join/leave ‘neighborhoods’ and allow them to create requests and respond to requests within the same neighborhood.

One of the features that I had a hard time parting with, was linking ‘neighborhoods’ to real-world locations. I still consider this feature to be essential for the app, but for the MVP we decided that it would be best to make sure that the whole ‘Join/Leave Neighborhood | Create Request | Respond to Request’ loop is solid, before adding location based services.

After we had a list of MVP features we would like to add, we then further split it into categories based on the entities we’ve identified. Here’s a part of the features for the MVP:

MVP Features for Users and Neighborhoods

We were getting very excited. We had a product and a list of features for the MVP, but we didn’t write any code yet and I still didn’t know how we would organize ourselves and work as a team.

I forgot to mention that me and Antonina are based in Europe and are on the same timezone, while Bob and Shwetank are in the US, and are on a completely different timezone. This made collaboration a bit more difficult, but we saw that as just another challenge that needs to be overcome. As a consequence, we knew we needed to cover a lot of ground in our weekly meetings, so as to not waste the precious time that we had (I forgot to mention that we were all working on this project in our own free time, outside of our jobs or other obligations). This is how we organized our meetings for maximum efficiency:

1. During the week before the meeting I would share a document in which we would all write the topics or questions we wanted to discuss during our next meeting.
2. Since everyone had access to that document, we could all see what the others were asking or thinking about and we could research the problem before the meeting.
3. During the meeting, we recorded in writing the answers to all of the topics of interest.
4. After the meeting was over, one member of the team would take the list and transform it into an actionable plan or task list.

This very simple structures that was added to our meetings saved us a lot of time and allowed us to be focused on our priorities.

I know that I still haven’t talked about code yet, and I promise I will dive more into the technical aspects in the next article, but I want to emphasis that working on a project isn’t all about coding; a lot of time is dedicated to simply exchanging ideas, researching and discussing features and implementation.

In the next article I will breakdown and explain the architecture that we went for, the programming language that we chose to work with and the tools involved. I will also dive into the way we structured a workflow for working with Git and Github as a team.