Developers: Stop Building Your Own Products.

At some point in their career, pretty much every developer is struck with a case of idea-itus.

Ideaitus –

A mental condition where the sufferer is convinced they’ve stumbled on a business idea that is completely unique in the history of human civilisation, and that they could turn the idea into a run-away success if only they had the time to execute it perfectly

A tool that would make their (and others’) lives measurably easier, a plugin or extension they’d like to build, a ground-breaking startup they’d like to launch… and I personally believe the “ideaitus” sufferer should start working on the idea as soon as possible. But this comes with a caveat: they shouldn’t build the product themselves.

It seems counter-intuitive. As a practitioner (programmer, designer, etc), they have the technical experience to execute – so won’t they’ll save lots of money if they build it themselves?

This is one (completely valid) way of looking at it, and actually the perspective I myself subscribed to earlier in my career. But it’s something I consider to be an error of my youth. I think practitioners building their own products is one of the reasons so many self-started projects fail, mainly because of two reasons.

Reason 1: Spreading resources too thin

The first reason developers shouldn’t build their own product: it spreads them too thinly.

When you’re launching a startup, there are so many important activities competing for your time and attention. Product design, marketing and promotion, technical implementation…

As the technical founder of your start-up, you need to have a laser focus on one priority: designing a product that people want.

Everything else should be a secondary concern.

Especially if you’re trying to bootstrap and launch the product while juggling other obligations (a full-time job, a freelancing or consulting gig), you need to spend all your time and creative energy designing a good product. Anything that can be outsourced, should be – and I think technical implementation is one of those things.

Reason 2: Competing concerns

The second reason: coding and product design have competing concerns.

While you’re performing different roles (coder and product designer), you have different goals, and so try to optimise your outcome according to those goals. Unfortunately, your goals while writing software (creating maintainable, understandable code) and while designing a product (best-serving the use-cases of your customers) are often at odds with one another.

When you’re designing a good product, it needs to fit within engineering constraints, but those constraints should define the limits of what your project can do – they shouldn’t actively restrict the feature set or user experience.

But when you’re trying to do the two things at the same time, you can’t help but consider constraints from both angles. Unfortunately this means you’ll start making decisions based on what’s easier to implement, rather than what will provide the most valuable product to the end user.

The solution?

As the creator of a product, you should be the product designer, not the coder. You should be responsible for shaping the offering: choosing the target market, defining the feature-set, designing the user experience, marketing and selling the product…

And so you should hire someone to do all the other stuff, most notably technical implementation.

Making tradeoffs

Of course I don’t want to imply that coding your own product (especially the MVP) will never work… it can, and has worked for many people.

But if you can afford it, the better solution is to pay someone else to do everything that can possibly be done by another person.

You have limited time. You need to spend that limited time doing important stuff – stuff no one else can do. You can’t outsource market selection or product design. That’s the stuff you get paid for as a founder. That’s your sweet spot – that’s where you create the most value.

Everything else (within budget constraints) should be outsourced.