Mistakes made, lessons learned

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.

This is what a serious committed team looks like

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.

Time is money, efficiency is life

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.

Shenzhen

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.

The Kickstarter prototype boards

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.