The key to side project success

Posted on: 31 October 2023

Most start-ups fail. Intuitively, they fail because they run out of money. But what’s the biggest reason for this? The Lean Startup, by Eric Ries, speculates it’s because too many companies build the wrong product for the wrong people. He goes on to extoll the value of the MVP (Minimal Viable Product). MVP is the basis for discovering what matters to your audience.

Most developers, myself included, can become jaded when it comes to the concept of an MVP. Often, the MVP is synonymous with low quality, subpar design or even shoddiness. Particularly when working at an agency for a client, the often lo-fi attribute of an MVP can be a hard sell. But it’s an incredibly useful and imperative tool for ultimately building something people want.

What is low quality or even cringeworthy to a developer or a designer can tick every box for a customer. If it helps them achieve their goal, the fact it may be a little unpolished is unimportant. Better yet, an MVP can tell you where to apply the polish.

Creators have a habit of thinking they know what their audience wants through intuition. They can spend hours on something they’re truly proud of, only for it to fall flat when put in front of real users. If real users didn’t ask for it, there’s a very real likelihood this can happen.

Customers don't care how much time something takes to make. They only care if it serves their needs.

In his book, Eric shares a wonderful story during the build of his first startup app, where a crucial feature in the app’s 3D avatar world was missing that users unanimously pointed out when using the prototype. The avatars were stuck in the top corner and couldn’t move about their environment. This was around the time The Sims came out, and the standard in the industry had been set when it came to avatars fluidly moving to their destination, efficiently avoiding obstacles on their way.

Eric’s team couldn’t justify the time spent to program this for an MVP. But the feedback was clear, users wanted to be able to move their avatars to a point on the screen.

Instead of picking one of the obvious 2 options: crudely implement the movement, or invest significant time and money into doing it right; the team picked a third option.

We used a simple hack, it felt like it was cheating

They altered the perceived requirement to allow “transportation” of the avatar to any point on the screen. No walking animation required, no obstacle avoidance programming. To their amazement, this was exactly what customers wanted. In feedback, most users described the problem in way of a solution “I want my avatar to move from A to B”. Whereas in reality, they simply wanted their avatar to be at point B.

In a fraction of the time, the team had satisfied their users’ needs, with minimal cost.

MVP’s aren’t about hackily cutting corners, they’re about making smart choices with the primary purpose of gathering data about what your customers want. Polish can come later.

The Lean Startup method is not opposed to building high-quality products, but only in service of the goal of winning over customers.

I’m only halfway through reading the Lean Startup, but the key takeaway is already clear to me. Don’t build what you think customers want, learn what they really do want. This is done through iterating quickly, and relentlessly gathering feedback as you go.

MVP in my work

I’m a big proponent of iterating quickly in code. I advocate for quick, small, focussed features that deliver value to users as quickly as possible. The much maligned waterfall technique of software development proposed requirements gathering was a process done entirely up front of design & build. We’ve since learned this just doesn’t work, and requirements are ever evolving and often poorly understood to begin with.

A Minimum Viable Product may satisfy just a single requirement for your users. Don’t build 10 features only to find 2 are actually useful to your end users. Build the first and let them guide you to the next most important feature through feedback and data gathering:

Remove any feature, process, or effort that does not contribute directly to the learning you seek.

The MVP gets buy-in from your users and avoids unnecessary work in the wrong direction. Often often it’s the case users don’t really know what they want until they see something that isn’t it.

An MVP allows you to hedge your bets. Try lots of little experiments and see what sticks. It’s much more valuable to a business to know what doesn’t work than to always be wondering. Failure is learning. Failure can steer the ship.

MVP in my side projects

An MVP has another very useful benefit when it comes to side projects: motivation. I’ve written recently about how motivation is overrated, but until you’ve built up that muscle of consistency, motivation can be all you’ve got.

This year I’ve struggled to gain any consistency with my side projects. An idea will burn bright for a week or so, I’ll make a load of progress, then get stuck in my head and it’ll fizzle out.

Focussing on building an MVP for your side project idea is the key to unlocking that consistency and enjoyment in a project.

With an MVP comes real feedback. When the idea is out in the open and being actually used, there’s greater opportunity for momentum to build. Aim to get from idea to prototype as quickly as possible and start bringing your ideas to reality, and seeing them through!