Usually, when people think about building and launching a startup, they plan it out a few weeks in advance. In my experience doing software consulting, I’ve seen and worked on some projects where the founders take 2 - 3 months to launch the first version of their product. That’s too much time and effort sunk into a project that may not work.
Why you need to get your Minimum Viable Product out ASAP
The problem is that most people are not comfortable with launching a minimum viable product. Founders are often creative people who love to explore and dive into “wouldn’t it be cool if”s. This habit can result in a continuous loop of adding features, even before the first version of your product is released.
Perfectionism can often get in the way of execution, and I’ve fallen for this trap many times. My first product (SideQuest) took me four months to build and launch. To continue developing an untested product is, to put it bluntly, arrogant. Here’s why: it assumes that what you are making is vital for your customer. It assumes that you know what’s best for your user. You don’t.
No founder knows until they launch their startup and get feedback from people. Your first version is likely going to suck; it might even miss the mark or be utterly irrelevant to the market. You need to get any negative and positive signals from your target market as soon as possible.
That was what we tried to do with MeetButter. Everyone on our team has had experience getting burnt by wasting time, runway, effort, and emotion building products or features that were inconsequential in the larger picture.
Here’s the story of how we managed to build and ship MeetButter in three weeks.
Step 1 - Identification
The first spark for MeetButter was a Slack thread discussing the pains teachers and educators were dealing with transitioning their classrooms from offline to online. We found that there was a very human problem with online video conferencing - they only allowed the focus to one speaker at a time. It was awkward interrupting the speaker, and this caused some participants to feel reluctant to engage. The discussion thread grew, with more anecdotes and feedback from our friends and family.
Identifying the problem is the first step. It’s crucial to figure out the groups of people that are facing the same issues and gathering feedback from them.
Step 2 - Investigation
We decided to take this asynchronous discussion and organize a synchronous brainstorm session. During this particular session, we discussed three significant problems that we had identified and were interested in solving. On the list was the aforementioned “video conferencing” - which eventually became MeetButter.
Some significant points were brought up by everyone on the team, and we found that these were problems that each one of us had faced while doing online video conferencing:
- It’s difficult to indicate an interest in speaking, reply to the current conversation, or add to the discussion without feeling like you’re interrupting the current speaker.
- It’s impossible to transition smoothly between one speaker to the next. Sometimes mid-sentence pauses are met with several speakers trying to enter into the conversation at once. Combined with lag, this can get quite awkward.
- The avoidance of awkwardness causes some people to remain quiet.
- The loudest voice in the room problem - some people naturally dominated discussions.
- Social cues are almost non-existent when your entire team gets boxed into tiny windows on-screen and are only visible from their shoulder up.
The purpose of this brainstorm was not to narrow down into solutions, but it was to dive deep into the problems.
Step 3 - Sketching
After the brainstorm session, we discussed some ideas on how to tackle the problem. Solutions can seem pretty vague, and usually, what happens is that several keywords get thrown around. For us, it was “queue,” “overlay,” and “polls.” It’s good to note that people often visualize keywords differently and form very different concepts in their heads.
A picture is worth a thousand words. Sketching is an essential skill to learn for any founder, as it’s the best medium to transfer your ideas with a low signal-noise ratio. People often misunderstand your words. If you’re not good at drawing, it’s good to learn how to sketch out a prototype digitally using free tools like Figma. I have even used Google Slides to build a low fidelity prototype for a client once! Sometimes I even screenshot parts of other apps and combine them into a Frankenstein of an image - anything to help bridge the gap between your vision and their imagination.
Based on the feedback and ideas from the team, this was the very first sketch for MeetButter that I built using Figma. After sharing it on our team Slack, we held a meeting to discuss the steps moving forward. We decided to cut out some features and instead focus on the queuing functionality as we were able to test it internally during our daily standup calls.
Step 4 - Prototyping
I won’t go into too much detail about how we built the prototype. This step will be different for every team: some teams will opt to do a no-code prototype using tools like AirTable and Google Forms; some will choose to do a “simulated” prototype using Figma or Zeplin; some will opt to build a fully functioning albeit minimal prototype using code. We decided to do the latter as it was the fastest for me to code something quickly.
The purpose of our prototype was to test:
If the core hypothesis works. In this case, we wanted to test if allowing participants to queue would help meetings flow better.
If we could build the tech. Founders often underestimate the technical work that goes into creating their vision. Building a prototype allows you to do a mini feasibility test.
Step 5 - Testing and Feedback
Once you have your prototype, you need to get it in front of some test users. Finding test users can be tricky. Ideally, the test users should be from within your team; this was the case for us with MeetButter. It meant that we were building a product for ourselves, that we were part of our target market. Building a product to solve your problems has some apparent benefits:
- It creates a shorter and more efficient feedback loop.
- It’s easier to innovate on issues you face
- It somewhat validates your market.
If you are building a product that’s not for yourself, I’d suggest finding at least ten people within your networks who can become your loyal test users.
MeetButter was also super easy to integrate into our daily workflow. All we had to do was open up the web app during our regular standup calls. It’s essential to build some sort of feedback loop. I sent a Google Form to the participants of the meeting to gather initial feedback as soon as the meeting ended - it’s best to strike while the iron is hot. We also had several Slack threads discussing additional ideas that came up as we continued testing.
Step 6 - Reiteration
After testing our prototype, we collected the feedback and went back to the drawing board. At this point, you have to make a clear decision with your prototype - do you continue to reiterate, or do you kill the project? We found that our prototype worked quite well, and although we were skeptical, there was a sense that we were onto something. We started using the prototype in every meeting, so it was hard to deny that our team internally found it useful.
We repeated the process of designing, reiterating, and receiving feedback several times. Our testing group grew from our internal team of five people out to our friends within our social circles.
Final Step - Launch
After a few rounds of iterations, our prototype slowly shed its pieces and morphed into something resembling a product. As soon as we exhausted our immediate networks, we knew that the next step was to launch MeetButter beyond internal test users.
I began to lay the groundwork for a codebase that could grow into a scalable project. Our tech stack ended up being the following:
- Frontend - NextJS with Redux and GraphQL
- Backend - A mix of Firebase and an Express server that’s powered by Apollo GraphQL and Sequelize
- Infrastructure - We used Netlify and AWS to deployment
Several factors allowed us to build and ship MeetButter quickly.
Firstly, we were fortunate to have had the experience and the skills to execute quickly. We didn’t run into many technical limitations, as each one of us had filled the significant roles that were needed. These roles include design/UI UX, software development, and marketing/networking.
Secondly, we tried to follow the best practices for idea generation. The brainstorm that led to MeetButter wasn’t the first one that we had together. It was probably our fifth brainstorm session after getting together as a team as Project Phoenix. With a lot of practice, we were able to build a set of best practices to have productive brainstorm sessions, get feedback, and reiterate.
Thirdly, we were close to our target market, which allowed us to test fast and slowly expand our test userbase.
Fourth, we threw perfection out the window. Our prototype didn’t work 100% of the time, had a bunch of bugs, and built with the bare minimum UI. Despite this, we still used it every single day for our video calls. It was good enough for testing the functionality, which is the base level of effort you should aim at for your prototype.
So that’s the story of how we built and shipped MeetButter in only three weeks!
Curious about MeetButter?
MeetButter is an app that helps you with coordinating meetings, such as daily standups, or significant conference calls of more than eight people. We just launched video functionality powered by Jitsi! Try it out at meetbutter.io and let me know what you really think.