Share:

Can a small dev team launch a meaningful product using only their lunch hour one day a week to build it? After eight weeks (eight total hours of development), will they have a worthwhile product to launch? This is the experiment we’re currently running, and we invite you to follow along with our progress.

In this series of blog posts, you’ll learn about the decisions we make, how far we get, and what we learn along the way.

Lessons Learned from a Hackathon

A few years ago, our company ran a hackathon where our teams attempted to build a fully-functional SaaS product in three days. Our team’s goal was to launch something every day, use it at night to see how it works, and then work on it again the next day. But it took some mental gymnastics to get there.

Initially, our vision of what we wanted to accomplish in three days was going to be spectacular. We had a giant feature list and would knock out as much as we could.

The problem with the initial plan was that we wouldn’t have a working system until the end of the final day. If anything went wrong, there was a chance we wouldn’t have a functioning product in the end.

To be certain our product would be useable on the last day, we challenged ourselves to have something usable at the end of the first day. Even if we failed miserably at that, we had two more days to recover. We looked at all of our features and decided, as long as it does one thing, it would technically “work”. It wouldn’t work well or be enjoyable and was certainly missing many features we thought were essential, but it would work!

We created a backlog of the essential items that didn’t fit into day one and planned to do them on days two and three because they were obviously critical. Or so we thought.

We expected the product’s user experience to be lousy after the first day, and it was. But the functionality was also unhelpful in ways we never anticipated. 

Those unanticipated problems we discovered after using the product for the first time were actually more important than our entire high-priority backlog. We threw away all tasks for the next two days and came up with a new list of high-priorities.

If we blindly followed our original plan for three days, we would have finished with something that had major drawbacks. The resulting product might have been more feature rich, but it would have missed the key features that truly mattered.

We learned that launching something at the end of each day gave us a much better end result than we could have ever imagined. As an added bonus, we actually had a usable product by the end of the hackathon. We didn’t need to schedule time after the hackathon to get it ready for launch as other teams did.

If we didn’t launch before we thought we were ready, we would have wasted time on the wrong features.

Our New Experiment

Recently I decided to try a similar, but even more aggressive, experiment. I wanted to try to build a new app from scratch, working only one hour over lunch one day per week, with the goal of launching at the end of the hour. We’ll repeat this for eight weeks, therefore giving ourselves eight total hours to launch a meaningful product.

After I came up with the idea, I had three weeks to assemble a team and think about what we’d build.

Fortunately, building the team was extremely easy. I’m blessed to work with an office full of highly productive designers and developers. Each time I told someone what I was up to, their reply was, “can I join?” I had to stop talking about the project so the team didn’t get too big!

I wanted to build something that would improve the daily work for someone in our office. I asked around, but I didn’t find anything that excited me or would be a good fit for a diverse team (lots of things needed all front end or all back end skills). Then I realized, most of the developers in our company have a problem that needs solving and this also affected me as their Scrum Master — the organization of our daily team standup. Solving my own problem seemed like a perfect tool to build.

As soon as I figured out what I wanted to solve, new feature ideas kept coming to me. Within a few days, I had a mental picture of a complete SaaS ecosystem that would take at least six months to build. It was already like my baby and was hard to remove any feature; the complete picture looked so beautiful in my mind and I couldn’t fathom anything less.

I spent the next two and a half weeks forcing my thoughts to find a way to make it smaller. I figured out how to make it small, but it was still way bigger than one day of work.

My breakthrough came when a colleague suggested I pick a specific dev team to support as the “customer” of the app. A lot of my “bloat” came because each developer would want to solve the problem in a different way, so my app concept was trying to address all of these different needs. But, if I could pick a single team as my “customer,” that would remove a lot of work. I struggled for a few days trying to decide which team I would support; each had its pros and cons. Then I realized, why not build the app to support the team who is actually building it!

As soon as I decided on a very specific user (not a user group or persona, but a specific person), narrowing down the feature set became simple.

Narrowing Down Your Scope

If you start this journey, it’s easy to think of all the items you see in a typical app, and set that as your “minimum required features.” Typical features you see includes a front-end marketing website, login/registration, payments, live chat, and of course, the actual app.

Here’s an example of what I drew on a whiteboard to explain the app to the team.

Since we were building this for ourselves, it became very simple to start crossing out major features. We won’t need a marketing website to encourage ourselves to sign up for it. We won’t even need a registration screen (we’ll just hard code our users in the database).

Following that train of thought, we quickly crossed out everything we didn’t need to use the tool. We also narrowed down the most-critical feature for the app. As long as it does this one thing, we’re ok. Other features are important to have a commercially successful product but with the one critical feature, we can start using it right away.

Standup Tool Revised

Now that our scope is severely reduced and everyone is on the same page, we’re ready for our first hour of development.

If you’d like to follow along, jump to our next post to see what we accomplished in the first two hours.

Share:


Chris Burns is a Product Manager at 352 and a lifelong pragmatist and problem solver. He loves improving old products and creating new ones from scratch.