A Product You Can Build in a Day That You Shouldn't Build in a Day

I had an idea.

I let the idea sit for a week or so, then I had made up my mind. I was going to build a web application in one day.

I tried. I failed.

And I've since lost motivation to work on the product, and it now sits, half done, on a dusty server.

Why did I fail?

Well, the truth is, I stopped working on it intentionally after about 6 hours, because I came up with another idea.

Actually, this one was more of a hypothesis:

A minimum viable product should be a product that one person can build in a day (24 total team hours), and they shouldn't build it in a day.

This is my suggestion for putting constraints on the MVP you create, and it's why I stopped working on my app that day.

Testing the Hypothesis

Here are the details on how I believe this hypothesis can be tested:

Step 1: Plan

I don't aim to put restraints on planing. It's certainly going to differ depending on the product.

I want to caution you on over-planning, but it's difficult to know when you are crossing that line. I would say you begin to over-plan when you change your mind about any one thing more than once. To question your first idea and think of a better way to do it is fine. To question it again is putting in too much time and effort. Probably one of your first two ideas was good enough to ship within an MVP.

For example, let's say I want posts to be limited to 400 characters. Later, I add features to the MVP plan that make me think I should allow 500 characters. But, then I wonder if it would be better if posts only have 200 characters. All three of those numbers are arbitrary because you have zero knowledge of whether they are going to work or not. Pick one of the first two and move on.

You are best positioned for the build phase if you come out of the planning phase with:

• A feature set, and a general idea of how each feature will work
• A design that is fleshed out enough to provide ample support for implementation

Steps 2-4: Build

Now you're ready. You are Jack Bauer. You have 24 hours.

But wait! You noticed this is three steps of the MVP process, right? That's because you should not spend your 24 hours at one time. I think the sweet spot is building the product in at least three sessions.

I've found that you always encounter items you didn't think about when you start to build (even if the product is simple). It's good to stop every once in awhile. Otherwise you run the risk of spending part of the 24 hours over-thinking arbitrary ideas.

On the other hand, if you turn this into 12 2-hour sessions you might run out of inspiration and motivation before you're ready to ship. Inspiration can be short-lived. Run with it now.

And, most importantly, don't feel the need to use the 24 hours up. If you can do it in 8, or 20, or 12, awesome! Commit, tag and ship.

Step 5: Ship (Measure)

You don't need to publicize at this point. You don't need marketing dollars. You probably don't need investment (depending what the product is). You need direct feedback, and you need it fast.

Grab friends, colleagues, cousins, or anyone you believe would see value in using your product. Ask them to be your beta testers. Don't charge them if you're building a premium product, and don't get caught up in any formalities. Just ask them to use it and tell you specifically what they think.

Step 6: Learn & Recycle

And look at that! You've probably spent less than a week's worth of time (we'll call it 40 hours) on a product and you already have real user feedback and you're ready to hit the Build-Measure-Learn cycle for a second time.

In fact, I'd say you can repeat this process over and over. Never spend more than 24 hours building an iteration. That way you never waste more than a day of your life building something people won't use.

Exceptions & Alternative Methods

There are always exceptions to any ideal scenario, and I tend to enjoy exploring them to make it easier for you to relate to what I'm saying.

It's Impossible

Yeah, okay. There are certainly some products that just can't be built in a day. Even as an MVP. In this case, I think of more physical products. FitBit, iPod, or even an eBike. Products like these should still be originally built with the minimum viable product approach. But it's unlikely they could physically be built in 24 hours (or maybe I'm wrong).

Or, think of a product like Dropbox. Even the first iteration on Dropbox is a really big idea. 24 hours is just not enough time to realize that.

But, not being able to build a product in 24 hours is not an excuse for taking longer than 24 hours. Whatever your first iteration is, it must be done in 24 hours.

So, what?

So, get creative. You came up with the idea in the first place, right? So, now come up with an idea to create something that can earn you real feedback, something you can build in 24 hours.

For example, Dropbox did not build anything. Instead, they created a video and pretended that they had a working product. They used the feedback from people watching the video to build excitement, and more importantly, funding, to build the complicated 1.0.

Many other companies and individuals follow this approach using forums like KickStarter or IndieGoGo to earn funding. In both of those spaces, you still need something real to present to your backers.

Don't use complexity as an excuse for breaking your constraints. Constraints are there for a reason.

Avoiding Over-Planing

I mentioned this briefly, and I didn't put any specific constraints on avoiding over-planning, other than don't rethink any single idea more than once.

But how do you stop yourself, or anyone else, from this. How do you prevent over-planning?

If it's getting out of control, then put a time constraint on this. If our overall goal is 40 hours, and we want to spend 4 hours measuring and gathering feedback, then that leaves us with 12 total team hours during the planning phase.

That should be enough to plan an MVP.

My Experience

I called this a hypothesis for a reason. I've experienced failure by not following these steps, and I came up with the idea as a result. I haven't yet found success implementing this strategy directly, although I've likely done it in the past without paying specific attention to my bounds.

However, I will certainly provide an update and an example when I first put this to the test (which seems like it may happen within a month).

Thanks for reading! Have you tried this and have feedback? Let's talk about it.