After a successful Kickstarter campaign and 2500 people+ wanting our product we’ve had the amazing opportunity of getting to produce our first connected product: Hackaball. It is a connected toy that teaches kids coding through creating games in a free app and uploading them to the ball which in response will light up, make sounds and vibrate based on the rules for sensors and time. We hope it will make kids smarter and more active.

We developed Hackaball over a period of four years, continuously testing with users and refining our proposition. We’re now delivering to customers, so it seems like a good time look back on the last year and half of taking the prototype to production and what we’ve learned.

If you’re a tl;dr kind of person here they are in short:

Doing something for the first time you end up making mistakes as the price for learning. Here are our lessons learned:

1. Commit to building a team

As a digital consultancy Made by Many has a lot of in house management expertise, but we wanted this product to be led by someone who was experienced in building both digital and physical products — not a standard combination. Once we hit our Kickstarter target we started the hiring process, but we didn’t manage to find Seb Potter, who was the perfect person to manage the process, until 5 months into the production process.

Until that time we weren’t performing in top form as expertise and power of decision making were divided over many people. There are pros and cons to this way of working. If you’re a digital consultancy with an ebb and flow of client work it is tempting to resource side projects with people who happen to be available. The upside of this kind of team resourcing is that there will be a sense of ownership of the product across the company. The downside is that knowledge of the project spreads thin and the team loses speed.

Swapping team members is virtually costless during the prototyping stages of your product if you don’t have strict deadlines. It becomes costly when you need a strong focus on shipping your product. When the project gets serious you need to build a team around it.

2. Mark the local holidays in your calendar

If you’re working with suppliers outside your country, put all their holidays in your calendar now and ask how much time people generally take off and what their expected schedules are. In China factories are not only closed during holidays, but depending on the amount of orders they may close early and start late. When you are refining your production prototypes you provide such a small amount of work to a factory that you’re unlikely to be a priority. As a result you you quickly end up with a month delay in your production schedule.

3. Rework your processes for remote collaboration

We work from London, but all our suppliers were in China. This created issues due to differences in time, availability of tools and work culture. Working with Chinese suppliers meant it was easy to lose days between communication due to the time difference. You have to respond to questions while there’s overlap in your working hours to quickly move forward on problems. Rely less on working through your problems by talking in person and more on refining specs and creating constant feedback on those documents.

Availability of tools is also an issue. You can’t use Google products, but China doesn’t have any issues with Microsoft. We’ve used Excel for bug tracking and specifications, and Skype for day to day communication and chat.

The work culture differences are the hardest to tackle. Our suppliers are used to creating hardware to spec and delivering that at the end of the cycle. This is pretty typical for Chinese companies, and it’s the exact opposite to our lean way of working. Our favourite scenario includes daily code updates, version management, continuous and automated testing, constant refinement of the spec. Finding a good middle ground means constant compromise on processes. Be prepared to invest a lot of effort into getting on the same page about tracking progress.

The cost of working across timezones and cultures is intensified product management. The only way to really improve this is to send someone from your team to China. Even with our remote way of working it was vital that we were in China a few times at key moments in the project.

4. Don’t over-promise on deadlines, or make your supplier invested in timely delivery

In software we say: “Fixed price, fixed scope, fixed time: pick two”. In Made by Many’s development cycles we tend to choose fixed price and fixed time. Scope can vary, but quality and delivery on business objectives don’t — and we always ship on time. In this project we were working with a fixed Kickstarter budget, fixed functionalities that we’d communicated to backers and a tight timeline for Christmas delivery.

None of this was impossible, but it was difficult. 80% of Kickstarter projects don’t deliver on time. Developing new hardware simply has risks attached to the process because of the large numbers of unknowns — especially if you’re doing it for the first time. In reality 18 months is a fairly normal time to take a prototype to production, but because we over-promised on the timeline we’ve had to apologise to backers a few times for delays. In hindsight we could have calculated in more time for delays but then it becomes a more difficult sell on Kickstarter. Alternatively we could have added bonuses or penalties to our suppliers for achieving milestones by certain dates — but this needs to be negotiated at the very start of a project.

5. Understand how you measure quality

When we set off to build Hackaball for production we said we wanted to deliver a high quality product. Our lack of specificity in communicating what that entailed meant that the first production version of the electronics board was over-engineered. It was unnecessarily difficult to produce, using rare and very small parts, all of which made the bill of materials (BOM) more expensive and the proposed production process longer — and we’d have to change factories. The excess of options also increased complexity of the firmware with only minimal benefits to the customer.

We realised the value of quality for us was in the product experience. What we really wanted from the electronics was simply a board that worked according to spec. We then defined very precisely what functionalities would be good enough, rather than ideal. It turned out that some sacrifices in technical functionality could be fixed fairly easily through documentation and notifications on the app and ball.

6. Nail your Bill Of Materials by sourcing where you produce

The BOM is a negotiation between your spec, the minimum order quantity, the price per part and the current availability. We found it hard to efficiently do part selection on our side of the world when we wanted to produce in China. An example: a part selected by us wasn’t sold by any of our middleman’s factories so we had to source it ourselves. It was sold for the right price in the US with a parts reseller that operated in China. Yet China and US stock didn’t overlap. Importing the part into China with added import duties almost made it prohibitively expensive. Eventually it turned out that the part was listed wrong on the US suppliers website and wasn’t even available for our deadline.

We changed tactics and let our Chinese production partner lead on part selection. A process that up until that point had been fuzzy suddenly moved ahead very quickly. Against a fee we were able to return the parts that we’d already bought. Our final BOM came out cheaper than the one we’d originally provided. What we learned was to trust the experts on the ground.

7. Kill off your prototypes

Even though we were moving away from our Kickstarter prototype to a production prototype we continued development on the former. When you have limited resources it’s best to put your focus 100% on delivery to customers.

What we should have done at an earlier stage was freeze the Kickstarter prototype software and a version of the app specifically for the purpose of demos so we always had something to show to clients, journalists and at conferences. This wouldn’t have been the latest newest version of the firmware and app — but it would have been stable. This would have been a small time investment early on that would have paid off in speed later.

In addition to the mistakes there were also things that worked out great for us. These are our recommendations for first-timers in the field of hardware production.

8. Hardware is hard, so work with experts

They say hardware is hard — but that’s become a catchall for the fact that many people are inexperienced in the field. If you have experience with either physical products or digital products then you can create a digital-physical hardware product by collaborating with other experts. We are experts in digital, so we approached the industrial designers of Map Project Office to realise the physical prototype with us. Their expertise complemented ours and helped us realise the product quicker then we could have done by ourselves.

9. Become consumer-focused

Full commitment is a bare necessity when you’ve received thousands of people’s money and your reputation is on the line. If you are a digital agency going down the route of a hardware product you have to make the shift from being a client-focused company to also being a consumer-focused one. Post-Kickstarter your product isn’t a side project. We launched Hackaball as a separate company when we launched it on Kickstarter and put a dedicated team on it for production and customer support.

10. Work with a middleman

There is an additional financial cost to working with a middleman, but the benefits of a proven network and someone to manage a large chunk of the complexities of production are great. It means you can put your full focus on guarding the quality of the product. As mentioned previously, it can be hard to track progress when working remotely — and problems in China are often only communicated after they’ve been solved. We’ve learned that it’s a constant exercise between being on top of what you can control and letting the experts on the ground do what they’re good at.

11. Work from spec — but only after validating your product proposition

Before we went to Kickstarter we’d created a functional prototype that we tested with 100+ children. Although we still expected minor changes along the way we knew we the basic proposition of our product was right. This gave us enough confidence to outsource our firmware work.

We built the iOS and Mac apps in-house and, together with what we’d learned from our earlier prototype, we were able to formulate a communication protocol for the app device and ball that we could handover to the company developing our firmware. In addition we formulated documents describing the device states of the ball in Excel spreadsheets and state machine graphs using Graphviz to describe the ball’s response to sensor inputs and protocol messages.

12. Know what to test and who should do the testing

After writing your spec the next step is quality assurance. It’s in delivery of software that you’ll realise some of your spec was ambiguous. People with comprehensive understanding of your product need to be dedicated to testing it and writing the additional spec that emerges from testing. Don’t outsource this to a supplier.

Do in house:

Outsource:

Performing these tests raises the quality of your product and helps you find the problems with the product before it reaches customers.

13. Build technology for testability

Because the app and firmware were developed on different timelines our developer Julian James developed a separate Mac app we called MacTestaball for testing our supplier’s firmware against the protocol we defined. This test app used code from our production app, but was stripped down to specifically test sending and receiving all messages between the device and the ball.

By simplifying parts of the functionality it became much easier to figure out if failures in the product were a result of:

14. Create a minimal product to ensure quality

When we were planning delivery we decided we needed to prioritise stability and updatability of the product. The worst thing that could potentially happen to customers wrt the firmware would be to have a product with bugs that couldn’t receive any software updates.

We decided to build a stripped down out-of-the-factory version of our product with the primary focus of facilitating software updates. This version would be fun and interactive but not nearly as complex as the final firmware. Doing this we knew we could produce and ship a stable product as soon as we felt close to finalising the firmware. The rest of the time could then be spent on testing the 1.0 version of the firmware with a selected group of kids at home. This month would give us the assurance that the ball was functioning as expected in a real life scenario and would give us insight into what questions our customer support could expect once the balls were delivered to customers.

Shipping the ball with stripped down software essentially won us an extra month of testing.

15. Stagger delivery to improve the unboxing experience

Instead of shipping to all customers at once we released our products first to the EU, then to the US, then the rest of the world and lastly to our pre-order customers. Much like the minimal product, this allowed us to work on improving the product and FAQs based on customer feedback while shipping the product out.

As a result the later on in the delivery process, the more flawless the customer experience would be during unboxing. The only kink in our plan: our proximity to Christmas. Many parents kept Hackaball in its box so they could place it under the Christmas tree. To make sure that people wouldn’t run into issues we urged parents to check their product was working correctly and pre-upload the latest firmware to avoid disappointment under the Christmas tree, not in the least because every production has a failure rate. Luckily it turned that we had an extraordinarily low failure rate, which is a testament to our process, our partners and our suppliers. On Christmas day all Hackaball kids could unbox and play to their hearts’ content —if you’re curious, we’ve kept the tweets.

Hopefully the things we’ve learned can help others on their journey to production, but probably the best way you learn is by simply doing it. Seek out your local hardware community and talk to other people who’ve already shipped a product, keep your team in good spirits, sweat the details but never ever lose focus on shipping. Now go build the best internet of things!

We’re excited about the IOT product space, so contact us on newprojects@madebymany.com if you’d like to work with Made by Many to realise your next IOT product!

We found a very last batch of Hackaballs! Buy them on our website.

A big thank you to everyone who worked on making Hackaball a success! Special thanks goes out to Seb Potter who was a central part of much of the work described here, QA hero Jamie Mayes, Swift specialist extra-ordinaire Julian James, customer support angel Valentina Etaghene, reluctant Shipwire wizard Matt Williams, our industrial design partner MAP’s Julie Arrive and Jon Marshall who are so good they made their work look easy, and the vast amount of incredible people at Made by Many who all played a vital part in getting Hackaball into kids’ hands.