This Spring, a small team of Sparkbox developers built a Slack app that interfaces with the Forecast API. By keeping an MVP mindset while developing, we created a working app within just a few weeks. Because all the basic requirements were met already, we were easily able to move into a beta testing stage to start working on some “nice-to-have” additions we identified along the way. But how did we make these MVP decisions in the first place? Let’s dive in!
The Background
For several years, Sparkbox had a custom Slackbot that ran every Monday morning. The bot used the Forecast API to gather data and send everyone on the team a message letting them know what they are scheduled to be working on for the upcoming week. We’ve found it very helpful to ensure everyone is on the same page with scheduling.
Over time, people outside of Sparkbox have asked about using our Slackbot. Unfortunately, with it being built as an internal tool, it wasn’t able to be used by anyone outside of Sparkbox. And that’s exactly what we wanted to change. The rewrite would allow the app to be installed into any Slack team.
Over the course of rebuilding this app, one question kept coming up: “Do we need feature X right now?” We decided to set our initial goal on getting something out as soon as possible and then beta testing—ignoring edge cases and possible unknowns.
Decision-Making
We truly wanted to build the minimum valuable product, but we often had to remind ourselves that we are in MVP mode. It can be difficult to zoom out and see the forest when you’re in the trees.
One way we prioritized the MVP mindset throughout this process was by regularly asking ourselves questions like these:
What do we absolutely need to get this app in front of users?
Is this a refinement of a feature that is already working and valuable?
Is this valuable, or does it just sound fun to build?
Does not doing this create a security risk?
One thought that our team had was how having a product owner (or product champion) could really be helpful in making priority decisions. Since we did not have anyone to fill this role, we instead talked to some other Sparkboxers to help us gain perspectives on certain features and their necessity. For example, our VP of Delivery helped us gain the project manager’s perspectives on the timing for creating the messages while our President helped us determine decisions around “must-have” items and “nice-to-have” features.
Overall, getting this stakeholder feedback at such an early stage—without having built the whole thing—was highly valuable in leaning into the MVP mindset and ensuring we were focusing on MVP features.
Examples of Technical Decisions
Over the course of the project, we needed to maintain the MVP mindset while making numerous technical decisions. Here are a few examples of these decisions:
Handling Database Migrations
One thing that came up while working on this was whether or not we needed something in place to handle database migrations. Now is probably a good time to mention that we decided to write this app in Go. It’s a language that I have used a little and enjoyed, so this provided a great opportunity to explore it further. But it also meant I didn’t have a go-to tool for migrations.
We knew that as the needs of the app changed, we would need to adjust the schema of the database. Being able to include these changes (both adding and removing them) along with our code changes would make the process much simpler and keep everyone in sync with minimal effort.
After making the decision to move forward with a migration tool, we researched possible solutions and decided to use golang-migrate. It has a simple interface and took very little time to implement—which was a huge win for us and the MVP. By adding some scripts to incorporate it into our Docker network, we were all set.
This was definitely a case where something that seemed out of scope for an MVP was definitely worth the small amount of time to add in early because of the long-term projected time savings.
Accounting for Vacation Time
We hit another challenge when one of our developers was working on a feature to configure time off within the app. We wanted this to be called out differently than typical project assignments, so we needed to identify which project (if any) in Forecast was connected to time off.
Our first idea was to grab a list of projects from the API and display those to the user. Since our goal right now was to get this to beta testing, this was probably fine to just be a text input that the user could enter the name of that project. This allowed us to not put a lot of time into a feature that hadn’t been tested with users yet.
The outcome of this decision was getting a base feature in place with minimal effort. And seeing as this is a one-time configuration option for the users, we settled on this being the solution for the beta testing period until we knew more about what kinds of pain points this will reveal.
Allowing For Different Scheduling Needs
The initial plan was to run the app once every Monday morning at 1:00 ET, gathering all of the relevant data and scheduling the messages to go out later that morning based on individual time zones. During the first conversations about this app, we talked about how project managers sometimes make last-minute changes to Forecast. This meant that any changes that happened on Monday morning after 1:00 ET wouldn’t be reflected in the messages going out. We decided that it would make sense to move forward with what we saw as the easier solution and see how it played out with other users—really keeping in mind our MVP mindset.
In our very first conversation with a beta user, they described how their project managers adjust forecasting data on Monday mornings. This was also exactly what our VP of Delivery had brought up early on and wouldn’t work with the existing implementation. It was obvious to me that it was worth taking the time now to pivot on that decision. Even though we wanted to maintain the MVP visions, we needed a solution that would allow each account to determine when the messages would get created.
The outcome of this decision led to a change to our codebase that was a little more complicated, but worth the extra effort to meet what we were finding as a common user need. After a database migration to update the schema and a little rework on how we schedule messages, each account can now set the time that their messages are scheduled based on their own needs.
Conclusion
Overall, continually asking ourselves what needs to be in this MVP helped us to stay focused on our goal and deliver a valuable product quickly. However, leaning into the MVP mindset also means being able to pivot based on user and stakeholder feedback. Understanding who the users are and how they will use our products is invaluable information that we need to use to inform what we build and when we build it. Keeping things simple also meant that we were only building things that were needed, but we were trying not to build too much for cases that we thought might be needed in the future and letting the right feature set come out through the process.
