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.

If you’re just joining us, you can read part 1 to learn how we reduced our scope as much as possible.

Kicking off hour 1

With our scope as narrow as possible, we were excited to begin.

I began the meeting with a drawing on the board to show what we wanted to accomplish for the day. Anything in black would be hardcoded, blue stuff would actually work with the database.

This was an extremely simple website by design. No logins or anything else that wasn’t pictured. If someone were to figure out the URL, they would also see our work. All we were building was an Add button that added things to a list. And Edit or Delete buttons to modify the things in the list. 

We probably didn’t spend more than 60 seconds talking about the day’s goal. Everyone felt confident that we could do it in one hour and it seemed pretty self-explanatory.

Today's goal

Launching the first hour of work

We wanted to launch something that could be used at the end of each hour. This included the first hour.

It’s a big stretch to make something useful in an hour and I would be lying if I hadn’t heard the doubts from other folks outside the team. But within the team, we felt good because we knew our scope was as small as we could get it. It was dead simple.

I’m pleased to say that at the end of the first hour, we launched something tangible. It was on the internet and could be used by people.

Unfortunately, it wasn’t as complete as we were hoping or had drawn above. 

At this point, you could type in your details, but nothing was saved to the database. After a page refresh, all of your work was gone. 

You could use this tool for your work, but it wouldn’t be pleasant. And keeping with our team’s mantra, at the end of the hour, before returning to our real jobs, we used our software to run a quick daily standup meeting. There was lots of laughing and our spirits were high. Although our tool was lousy, we actually had fun!

Overall, the first day was a great success, but that doesn’t mean it everything was perfect. Below we’ll cover what we learned or would change if we were to start over.

Lesson 1 – Our MVP wasn’t as minimal as we needed

We thought we had a really simple design and we were confident we could finish the job in an hour. 

The design I drew on the board had several form fields, and a few buttons. The buttons were supposed to send data to the database and the results would be reflected on the page.

Unfortunately, those interactions weren’t saving to the database at the end of the first hour. Although we had something we could use because you could type into your browser and it could be viewed on a shared screen, I think it’s fair to say didn’t meet the goal.

After work, one of the developers approached me and said, “wouldn’t it have been easier if we just did one giant textbox that covered the whole screen and you just write in it?” This would cut out all of the individual text boxes, several save buttons, and the need for edit or delete buttons (you’d just erase the line you want to delete).

EUREKA! Yes, it would have been easier. If we thought of that sooner and made that our goal, we probably could have completed our goal for the first hour.

Even when you think your plan is simple, keep running it by other people. Ask them to help you find simpler solutions.

Lesson 2 – Don’t be fancy

Remember the old days, when you’d click a button on a webpage, the page goes white for a few seconds, then the new page loads? 

Newer websites feel much more responsive because you don’t get that blank flash followed by the whole page reloading again. People in the industry call this as a “SPA”.

There are plenty of upsides to building a website with the SPA architecture, and that’s why it’s become the de facto architecture for most new projects. But one drawback is that it takes a little longer to get started.

When results are the name of our game, taking time to “wire up” all these different tools and libraries to give a wonderful front end experience is wasteful. 

So our big mistake was that we didn’t stop to ask ourselves, “Do we need to build it as a SPA?” 

If we hadn’t wasted time building it as a SPA, we definitely would have gotten farther.

We wasted time because we blindly followed the “industry standard.” We should have stopped to ask ourselves if the industry standard was appropriate here.

Lesson 3 – Just because it’s simple, don’t assume you’re on the same page

After the two mistakes from the first hour, we re-assembled for hour #2.

Learning from Lesson 1, I drew a new diagram on the board and explained that we’ll just have 1 giant textbox. Everyone nodded in agreement.

Learning from Lesson 2, I said, “No more SPA, we’re just using traditional page loads and form posts.” Everyone nodded in agreement.

We all agreed, the goal was to rebuild everything from Day 1 using traditional page loads and to rip out any of the SPA functionality. Let the coding begin.

Maybe 30 seconds in, I noticed two programmers already in vigorous debate. I thought they were talking about nerdy stuff, so I just kept focused on my task.

Then 2 minutes later, I noticed they were still going, and looking to me for an answer.

Turns out my “simple” diagram that I thought simply said, “Make a giant textbox,” could have been (and was) interpreted in other ways too. And if we were all on the same page with what I thought was my vision, it would have come up sooner that there was a technical problem with my idea. 

We spent the first 15 minutes understanding the technical problem with my idea and the best path forward. It was unfortunate to lose 25% of our coding time, but in the end, we still finished day two with more functionality than we had on day one.

Just because a feature is simple or seems self explanatory, don’t leave it to chance that someone could interpret it another way.

Check back for our next post in this series as our dev team continues to make progress.

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.