What working on Pebble taught me about building hardware

Eric Migicovsky

Building hardware is fun but tough. We worked on Pebble for a full four years before we launched on Kickstarter in 2012. We went on to sell over $230 million worth of Pebbles, or just over 2 million watches. While it wasn’t our top goal to sell to Fitbit last year, I’m grateful that they’re continuing to work on low-power, fun, hackable smartwatches.

Startups in general are like roller coasters; adding hardware to the mix just makes them even more stomach-churning. But if it’s so hard, why do it? The most rewarding feeling in the world is seeing someone out in public using a product that you helped make. If you’re working on hardware, especially consumer electronics, I hope you’ll get a chance to feel it. It makes it all worth it.

In my new role at Y Combinator, I’ve started mentoring and helping all kinds of startups. Naturally I get to chat with a lot of hardware companies. While each one’s situation is unique, I’ve noticed that some anecdotes about my experience at Pebble have been quite useful for 95% of hardware related projects.

Get something out there in a hurry.

One of your first goals must be to get a minimum viable product into users’ hands as quickly as possible. Try to get those users to pay something. If they do, the feedback they give you will be of much higher quality.

This approach is totally normal for software projects, but for some reason hardware founders keep making excuses: “Our customers expect it to be as beautiful as Apple products.” “If it’s too large (or expensive), then no one will want it.” “We need to add X/Y/Z feature.”

You don’t need to make it perfect. Get a quick-and-dirty prototype built that solves a real problem for your users. Use off-the-shelf modules — WiFi, Bluetooth, displays — as much as possible. Do something super-hacky, like shoving a tiny Android phone into a 3D-printed box and writing an app that simulates your product experience. It’s a waste of time to try to minimize the cost of your materials at this stage.

I can’t overemphasize how important this step is. Do not skip it.

Here’s why: If you can’t find anyone to pay for (or even use) your prototype, then you aren’t solving a problem that anyone really has. If people have complaints, try to address them quickly and inexpensively by modifying your prototype until customers are willing to pay for it and use it. The feedback you get at this stage will be invaluable and will help guide the eventual ‘production-ready’ version of your product.

Pebble founder Eric Micigovsky at TechCrunch Disrupt

Do this before you launch on Kickstarter. It sounds hard but it’s not (compared to the rest of the things you will need to do)! You will get a lot of people who say “no, not interested.” But some will say yes, and these will become your most valued users throughout the life of your company.

You could also consider running a separate Kickstarter project, with limited-run rewards, to fund this early prototype stage of your product. Just be honest about the state of your project development.

Identify what problem you’re solving for users.

Do this by talking and emailing with your users regularly. Check your assumptions with real people.

In the early days of inPulse, our first watch, we published a new software update every Friday. I personally emailed the update out to our 1,000 users. We got great bug feedback and feature requests. But more importantly we created a bond between us and our customers.

When we started working on Pebble, we asked our actual users what problems they had with inPulse: The screen was hard to read in direct sunlight. Battery life was too short. Doesn’t work with iPhone. No water resistance. From this feedback, we synthesized what our community truly wanted from a smartwatch: notifications, music control, downloadable watchfaces, and sports tracking.

And that’s basically the pitch from our first Kickstarter.

Talking to users sounds hard and tedious, because it is. But as a product designer you need to be constantly validating your assumptions to ensure you’re actually building something people want.

Learn how products are actually made.

This probably involves a trip to China. If you are working on a hardware project, you owe it to yourself to go to Shenzhen. Flights to Hong Kong (right next to Shenzhen) are under $1,000 from basically anywhere in the world. A week there costs a few hundred dollars.

When you get there, meet factories and vendors in your domain. Get inspired by walking through the Huaqiangbei electronics market (the farmers’ market of the electronic world). Get thebooks, and talk to people who’ve built products before at HAX or Seeed Studio.

Here’s how anyone can make contacts in Shenzhen:

  • Get WeChat, the must-have app for China.

  • Browse Alibaba or Taobao and find products that are similar to what you’re working on.

  1. Contact the vendors of those products over WeChat. You’ll often start by talking to a distributor — you need to work the chain backwards to find the original factory.

  2. Work with the factory to get a quotation for the actual product you want to make, leveraging as much existing tech as possible.

  3. Fly! Get on a plane to go visit your newfound friends and contacts in Shenzhen.

It’s not hard — everyone in Shenzhen is super-friendly.

Ideally you should spend time at a different startup before working on your own, so you can get some experience and start to understand the flow of a project.

Hardware is hard, but manufacturing is usually not the hardest part. At Pebble we ran into issues that had more to do with market positioning and cash-flow management. It turns out that deciding how much inventory to buy is crazy-difficult. Learn from our mistakes. Keep inventory under control by growing slowly and steadily, instead of building lots of product and hoping it sells.

The bottom line: Focus on talking to and caring for your backers and users. They are your #1 fans, so get your product out as soon as physically possible and then work your ass off to make sure those backers are happy.