PhatNoise: From concept to launch

I have been meaning to write several posts about my first company, PhatNoise, but haven’t had the chance to finish one off.  Well, after seeing an update on the Techcrunch tablet project over the weekend — especially the sentiment expressed in the comments – I decided to put something together.

There is a lot I want to write about PhatNoise, since there is a lot that happened.  Literally a garage startup, PhatNoise ended up running for over six years, with half a dozen automotive deals, and finally a successful sale to Harman International.  Whatever I write, however, I would like these notes to be considered both a post mortem and a straight historical accounting of what went down.

PhatNoise began as a question I asked myself: could I put a little computer full of mp3s in my car by replacing (and mimicking) a regular old CD-Changer?  Only one way to find out – reverse engineer the communication path in the car, build the hardware to interface it to a PC, and off we go!
Our home base was a crappy apartment in west LA, which happened to be just up the street from the infamous DEN.  Here’s Dan Lau, my roommate at the time, where it all started:

What we had hobbled together wasn’t much, and it would frequently break down in a plume of smoke, but it was enough to convince us that having thousands of songs in your car was damn cool.

Keep in mind this is late 1998.  It was about six months before the original Napster was released, and about three years before the first iPod.  I would often joke that the first half of any meeting we would have with an investor or hardware vendor was devoted to explaining what mp3s were and why anyone would care.  But this demo was enough for us to realize the potential, and we thus set out to build a dedicated solution to replace the jungle of wires pictured above.  My buddy Dan and I finished up our Master’s degrees at UCLA, and founded the company in July of 1999.

Pizza and Ikea

The company was largely conducted out of our living room.  Most of our hires were friends of ours at school, many of whom had not graduated yet.  The operation was run on Ikea furniture (the first job of any new hire was to build the desk they would call their home), and lots of pizza dinners.  Folks would head over to our pad (the “PhatPad”, the first in a long line of Phat* names), and bang out various aspects of the concept.  There wasn’t much of a plan, nor did anyone have any relevant experience beyond being smart engineers.

Creating a small Linux computer to interface with cars was the main idea, but a bunch of other problems needed to be solved along the way.  The biggest was moving music from the PC to the car.  Our original concept was for computer to house a hard disk drive full of music, and you would shuttle the whole computer to and from the car.  At the time, though, USB-bulk storage devices were *just* coming out on the market.  Using painfully slow first generation USB, these were designed to accommodate external hard drive enclosures.  Our idea as a bit more ambitious – house just the drive in a small cartridge that could easily slide into bays or docks.  Here’s what very early sketches looked like:

The computer itself (the “PhatBox”) was originally thought to look not much different from CD-changers, such as this sketch below:

This idea was ditched when our contract manufacturer convinced us that using a single piece of extruded aluminum was cheap to tool, and looked way cooler.  With our concept firmly in hand, we were able to raise enough venture money to actually pay people and to move the operation out of our apartment.


Speaking of which, this is probably the biggest lesson in building a new hardware product: get really comfy with the contract manufacturer.  You gotta choose them as if you were going on a long, dangerous, and ill-planned camping trip together.  This partner will need to take on a lot of risk if you are going to do this on the cheap, and yet they will need to be capable enough of really running the show.  Fortunately, we did have a great partner that believed in our vision, and part of what this partner did was create manufacturable 3D models of our sketches and quick-turn SLA prototypes.  Here they are:

Pretty damn close, wouldn’t you say?  Here’s how the cartridge fit in the cradle, with a giant CRT monitor for scale:

The cartridge never did quite perfectly fit in the dock, considering there was a 40-pin connector there and all.  Rigorous mechanical engineering is one of those things that you just gotta pay a lot for.  If this looks familiar, well let’s just say we inspired a few folks:

Iomega, really, we’re flattered!

Enough about plastic, though, onto electronics!  Our idea was always a small computer, capable of playing back thousands of mp3s, interfacing to a variety of automotive networks, and easily software upgradable.  In order to fit our cost and mechanical constraints though (more on that later), it meant finding a processor “just good enough”.  It also meant pretty much designing and building it from scratch.

The just good enough processor turned out to be an ARM7 running at a whopping 74MHz from Cirrus Logic.  And just as important as being cozy with your manufacturer is to be really chummy with your major chip vendors.  Processors are complicated beasts — even little ones like this — and you’ll need all the help you can get.  Cirrus was always a great vendor for us.

Software was done all in house: a stripped down Linux kernel, software audio decoders, and daemons to manage everything.  A smart decision we made was to include a second, smaller microcontroller on the board to handle interfacing with the vehicle, power management, and in-system updates.  It acted like a bridge between the PCB and the Linux OS.

I want to make the point that this was all very fancy stuff for a music player.  Every other device on the market used a dedicated IC for decoding MP3s and doing everything else on the device.  We were the first to employ a full OS and software decoders in such a product, and we got press simply for that fact.

The boards took quite a long time to get working properly, but this basic design would last us for years.  Here’s a shot of an early PCB:

Along the way, the company crammed as much as possible into the space and time we had.  That’s me on the right – hey at least we had a view!

Although one downside is that at 4am it gets quite cold in an office building with no heat on, even in Los Angeles:

Notice all the crap in the back – oy!

We wouldn’t have had much of a music system if there wasn’t a tool to effectively rip CDs and manage all that stuff.  As if there wasn’t enough to do, we made that as well.

It was not the first music management tool, but one of the only built around a database to manage thousands of tracks, and with a dedicated interface to sync it to the portable drive.  And since all the cool apps had funky skins, ours did too.  One of our early users called it “garish”, and the name stuck!

The Big Show

After about 15 months from inception, we were ready for our first big show: the MP3 Summit, sponsored by the then huge  Most of the companies were either software services (luminaries such as Scour and moodlogic), or large hardware companies such as Philips and Thomson.  And then us.  We had a barely working system, held together with tape and with a soldering iron always nearby.  One of us was permanently on duty to reset crashed demos.  But none of it mattered, since the crowd was in awe:

We were easily the most popular booth at the show, because people saw something for the first time in the flesh: thousands of songs, accessible by the stereo they may already have in their car; a portable harddrive with USB connectivity, and a database driven music management software for the PC.

Was it worth it?  Well, we won best of show.  The company went on to strike deals with most major automotive suppliers, and to develop several variants of the system, including a home version and a multimedia version for General Motors.  We have PhatNoise alums at both Apple and Google.  Our main competitor (and major source of inspiration) went on to become the hardware chief of the Apple iPhone.  Here’s Hugo and myself at that summit:

About six months later, when rumors were swirling around a totally new product line from Apple (a week before the iPod was announced), a Wired reporter asked me for a quote.  I didn’t think Apple was doing anything directed at cars, and to this day most interfaces for iPods are pretty lame.  But Apple did take what they knew was a game-changing technology (MP3s), and spent the money to cross the chasm to the masses (more on that another day!).  I’d like to say that our company did some trailblazing as well, and was an experience I wouldn’t have gained any other way.

So you wanna get into the electronics business?

As I mentioned earlier, there is a lot more to write about PhatNoise, but since you don’t run into too many consumer electronics startups, I thought I would spend some time on some humble advice.

Try to avoid hardware. Really, it is awfully expensive and time consuming.  But if you got this far you are probably hell bent on making hardware an integral part of something new, so…

Use the biggest building blocks possible. It’s like Duplo versus Lego: you maybe able to make something more intricate with Legos, but that’s reserved for the bigger kids with bigger wallets.  For the Techcrunch tablet project, for example, they should really just book a weeklong trip to south China, look at lots of existing models that come close to their vision, and weigh the pros/cons of modifying it.

Weigh the opposing forces. There is a saying: fast, good, or cheap – pick two.  Well, I can make this a bit more precise for consumer electronics.  The NRE cost, final price, performance, flexibility, and mechanical constraints are five dimensions that generally oppose each other.  For example, tight mechanical constraints will make the product NRE cost more.  But lowering the NRE cost will likely raise the final price.  Increasing performance (faster processor, longer life battery) stresses the mechanical design (faster processors need better heat dissipation, longer life batteries are usually just larger ones).

Find an original design manufacturer (ODM) that can do it all, and let them do it all. Let’s say you violate this rule and hire an amazing mechanical engineer outside of the ODM to design an awesome dock for your web tablet.  The tablet is largely the ODM’s design, and the dock is from this super fellow.  And when you have the first prototype and it doesn’t dock correctly one out of a hundred times, who is going to find out what’s wrong and make the appropriate change?  Both the mechanical engineer and the ODM will point fingers as at you.  Let the ODM do all the work and manage their own subcontractors.

Make sure the hardware-software connection is clear. Lots of folks feel they have a stronger handle on the software than on the hardware, and thus make that the dividing line.  However, the hardware and software need to work in concert.  If your web tablet is supposed to have a “sleep/resume” feature, what is the mechanism of waking it up again?  Do all the peripherals get reinitialized correctly?  Are the things that are supposed to be non-volatile really safe?  How about updating the software?  Can you update the operating system?  If so, what happens if that update fails (and it will)?  If you are not careful you will be left with a cool paperweight.

Where is the product going to be sold, and how is it going to be used? This is painfully tricky – FCC is required in the US, CE in Europe, and it kinda varies everywhere else.  Do you know what the packaging requirements are like?  Do you have French everywhere in order to be sold in Canada?  Who is writing the user’s manual?  What are the environments this is to be used in?  What are the requirements for temperature, humidity, mechanical shock, EM radiation, EM immunity – and who’s going to test all this?  If you think this should all be “ok” the next time you try out that LCD panel that’s really cheap, think again — these are the exactly the areas the vendor is likely cutting corners without you noticing.  Lastly, if the product doesn’t pass FCC/CE testing, who knows how to resolve it?  If you have any “custom” electronics made, the ODM will just hand the problem right back to you.

I’ll have much more to write about both PhatNoise, building startups, and other aspects of the consumer electronics business.  This list above is really just the tip of the iceberg, but this post is already waay too long.  In the meantime, please don’t hesitate to contact me!