There is a common conundrum faced by technology companies as they transition from the design phase to the actual build phase. It's summed up by the engineers in what has become a Silicon Valley aphorism:
"Fast, good, or cheap--pick two."
The software developers' point is that there are three basic variables the build team can adjust, but they can only guarantee two of them. When the CEO suggests a deadline, the engineers say sure, we can meet that--if you sacrifice some quality, or toss out some features.
At The Giant Pixel Corporation, we strive to break this law of software development and achieve all three: quality products, built quickly, that don't break the bank.
Making it quickly
A key part of our design phase involves cutting features until we get down to a minimal first release that still promises to be a compelling product. This how-to-minimize discussion continues through the build phase. We are continually figuring out what is necessary in the initial version, and what can be omitted (for now).
Our build phase is very iterative. We scramble to get a prototype into colleagues' hands, and use their feedback to make adjustments. To move quickly, we have to be willing to throw things out.
The first Sobo prototype looked nothing like the first public release. Its interface aped the record-play-pause buttons on an old tape recorder. Early testers complained that too many taps were required to record a six-second sound bite. We quickly trashed that interface and replaced it with a one-button design.
Another important tactic in quickly building the first version of new software is to keep the team size small. We use teams of three people to start new projects. A typical team may include one designer, one programmer, and one product manager/marketer. Small teams are more nimble and have less communication overhead.
Making it good enough
The "good" variable is the toughest in a lot of ways, because perfectionists can go on improving a product forever. When you are knee deep in building something, you fixate on every little bug and all the features on your wish list that you haven't built yet. It's difficult to view your own creation from the perspective of a prospective customer.
At Giant Pixel, we manage this problem by ruthlessly prioritizing our to-do lists repeatedly. That way, we don't get sidetracked working on non-essential features. Some features will have to wait until the next release. And some bugs will go unfixed for the time being.
With Sobo, we found a corner case where two sound bites might erroneously play at the same time. We let the product ship with that bug and fixed it in a follow-up release.
(At our company, we use a little friendly internal competition to keep quality top-of-mind. After all, we are attempting to start three companies at the same time.)
Making it cheaply
Earlier in my career, I had no choice but to make products cheaply. I bootstrapped a startup with one other co-founder, and we ran our company for two years on a shoestring budget. We purchased some used computers and office furniture from the estates of dead dot-com-boom companies, and used my business partner's apartment as our office.
Today, we curb spending on Sobo by devoting only half a team to the project. An engineer and designer working on Sobo are also committed to other software projects. We also refuse to spend much on marketing until user engagement metrics reach sustainable levels.
- "Fast" is the easiest variable to let slip. Make a company-wide public commitment to a deadline, so coworkers help hold you to it.
- When you are knee-deep in building a product, you lose sight of when it is good enough to release. Get an outside opinion.
- The perceived seriousness of a product doesn't necessarily correlate with the resources required to build it.