Posted by Michael Alfaro on April 17, 2011

10 (Additional) Things Every Software Architect Should Know: Make Products, not Projects

Inspired by O’Reilly’s 97 Things Every Software Architect Should Know, I am adding my own few things (10, to be specific, and not all at once).

The second one: Make Products, not Projects

What is a project? Let’s not go to Webster’s dictionary…How is a project different than a product?

Rather than go into great detail (I’ll leave that to others..), I want to convey a simple thought. There’s more at stake if you frame what you are building as a product rather than a project. Why is this? A project is an experiment: something where the end goal might be loosely defined (e.g. ‘I’m working on a 3d project’). A product is something that butts up against the marketplace, and seeks validation not through it’s completion, but through the successful adoption by consumers (there are other cases, but the most general is something that is released to the public).

Why is it so hard to define great projects vs great products? I can think of at least 20 amazing products I enjoy on an everyday basis: drip coffee, my Nixon brand watch, my iPhone, iTunes, Unity 3d, my Wacom tablet, my microwave, etc. Great projects? Maybe Andy Warhol’s Factory. (And even that I’m not so sure of, because I wasn’t there to see it). The point is, it is so much easier to think of great products than great projects.

When you define something as a product, immediately there is more at stake. Once you have gone through the ideation phase and settled on an idea, give you and your team a definable goal of building (and releasing) a product. Below is a great video featuring Brandon Schauer and David Yerba from Adaptive Path that touches on many of these points, and a lot of the process and thinking behind product launches in general.