Hardware is Hard: Getting a Kickstarter project out the door

With Triggertrap Ada looking like it will ship a year after schedule, Triggertrap CEO Haje Jan Kamps reflects on what worked well — and what, er, didn’t.

Three weeks ago, I plucked my calendar down off the wall. Time for an upgrade. 2014 whooshed by at such a breakneck speed it’s hard to fathom. Above all, 2014 was meant to be the year of Triggertrap Ada: when we launched the Kickstarter campaign, we had an estimated shipping date of May 2014.

“Looking back at it now,
I have literally no idea how we thought
we were going to deliver on time.”

Between you and me, May 2014 was meant to be a conservative estimate — internally, we were operating with an April 2014 shipping date, and we had already started patting ourselves on the back. “It’ll be awesome”, we said, “when everyone is expecting May, but we ship in April.”

Looking back at it now, I have literally no idea how we thought we were going to deliver on time. Even though we already successfully delivered one Kickstarter project, for Triggertrap v1, (it was delivered around 14 months after the end of the Kickstarter campaign ended — around 7 months behind schedule), we figured we’d learned our lessons. We were veterans now! We know how to prototype, and how to turn our prototypes into serial-produced electronics, manufactured in China.

So, what happened?

Life after Triggertrap v1

That little green display was the culprit: We couldn’t get any more of them, which means we wouldn’t be able to make any more Triggertrap v1 units.

When we first put Triggertrap v1 into production, we were notified by the factory that the LCD displays we were using were no longer being manufactured.

In fact, we had to work really hard to convince the original supplier to fire up the factory one last time to rattle off a batch of these particular displays for us. In the end, they did, somewhat reluctantly; the number of displays we needed was far, far under their usual production run.

In getting one last batch of LCD displays made, we were able to deliver the Triggertrap Shield for Arduino and Triggertrap v1 (phew!), but there was still a problem left: We would never be able to make any more products, unless we also did an electronics redesign.

I am really proud of the Triggertrap v1 . I still use mine regularly, and I know there are still hundreds of units in active use in photography studios and wildlife installations around the world . Having said that, we also realised that there was a lot of stuff we could improve on.

Instead of worrying too much about which screens to use, we started work on what the next generation of Triggertrap high-speed triggers would look like.

The very, very first concept sketch of what Triggertrap v2 was going to be.

The job of taking Triggertrap’s second-generation hardware trigger from a twinkle in our eyes to the delivery room fell to Triggertrap’s CTO, Matt.

Settling on a name took a long time — but I think the one we settled on eventually was by far the best one.

The Triggertrap v2 project was originally called Triggertrap Stack, then Triggertrap Brick, then we chose a name that resulted in us receiving some rather threatening letters from a camera manufacturer, before finally settling on Triggertrap Ada. The name was picked in part as a homage to Ada Lovelace, and in part named after Matt’s first-born daughter, who, come to think of it, was also named after Ada Lovelace. Call it a double homage to the fair lady Lovelace, if you like.

Step one was working on putting together a technical spec for what the future of high-speed camera triggering was going to be.

Kicking off the work

Next, it was time to draw up a rough spec and brainstorm some ideas around what the new product was — and wasn’t — going to be. After having our first round of conversations with potential customers, our first mission in bringing this new product to market was to pick some solid partners to work with. We needed some external help with four key bits of the product.

1. Industrial design (i.e. the look and feel of the product)
2. User interface (i.e. the bits you can see on the screen. )
3. Electronics design (i.e. the actual physical components that go inside the device)
4. Firmware programming (i.e. the software that runs on the microprocessor)

James Lamb did a fantastic job on the industrial design for Triggertrap Ada

Matt spent a lot of time going through all the suppliers we had available to us, and eventually settled on three partners.

For the industrial design, we chose James Lamb of Lamb Industries; he turned out to be absolutely magnificent, and in addition to designing Triggertrap Ada, we chose him to also design the casing for the new Triggertrap Mobile Dongle.

In addition to the Triggertrap Ada product, James Lamb was involved in designing Triggertrap Mobile’s 3rd generation dongle.

For the user interface, we ran into some interesting challenges: The display we chose for Triggertrap Ada is more commonly known for featuring on the front of Nokia’s 5110 phones. It has some great benefits (very reliable, back-lit, low power consumption), but also some drawbacks.

Well, 4,032 drawbacks, to be exact: The display, at 84x48 pixels, is rather low resolution compared to the sort of displays you find on your average mobile phone, and designing a great graphical UI on a low resolution display is a surprisingly rare skill — but we found Realise, who were able to help us design fonts and the user interactions people would have with the device.

Finally, for the electronics and firmware, we chose Cubik Innovation. We first discovered them in connection with finding a supplier for Ada, but as Ada was such a big project, we used them for a couple of small projects before we kicked off the main work. The first project was redesigning the electronics for our Triggertrap Mobile Dongles, and the second was creating a test rig for the manufacturing of the dongles.

Quick note: I’m going to go dissect some of the things we got wrong first,
but hang in there, it’s not all doom and gloom: There’s good news and exciting stuff further down in the post!

Mistake #1: Picking the wrong supplier.

It turned out that not all of the agencies we chose were a great selection; Cubik, as it turned out, were able to deliver the electronics side of things rather quickly, but the software side of things were letting us down right from the start.

“We failed to check references
on a key partner we relied on to deliver a project.
That was beyond stupid.”

They say retrospect is 20/20, and as it turned out, we shouldn’t have asked Cubik to do the firmware for this product. By this point, we had used them a couple of times; once to develop the new internals for the 3rd generation Triggertrap Mobile Dongle (a passive circuit that doesn’t have a software element) and test rigs for the manufacturing phase of the same product. Both of these products worked great.

For Ada, did deliver the electronics, but as our subsequent code reviews revealed, they really shouldn’t have been asked to work on the firmware as well. When we started getting a few early warning signals, we made a sub-mistake: sticking with them to deliver the software piece caused an inception-tastic layer cake of delays wrapped in delays, with a sprinkling of delays and a side dish of additional delays.

In short: many revisions later, we ended up with firmware that worked, but source code that we weren’t happy with.

What was the impact?

Picking the wrong supplier for our software had a lot of knock-on effects.

Spot the mistake in this bit of code. Hint: One of the values returned is a thousand times smaller than the function name would indicate.

• Delays: We are months and months behind on our delivery plan.
• Battery life: We specified 6–12 months of battery life when we first specced out Triggertrap Ada. The first version of the software we received did around 20 hours, and the final version was able to do a maximum of 40 hours in timelapse mode on a single set of batteries.
• Source control: Early on, we asked the company to use GitHub, but they were unable to do so, apparently because they were unable to figure out how to use it. Given that we intended all along for this to be an open source project, that turned out to be a big challenge.
• Code quality: As I mentioned, with some minor caveats, we are happy with the functionality of the device now. However, the code is significantly less easy to hack and adapt than we had hoped, and before we set out to improve it, we feared that this might have an impact on how willing people would be to experiment and work with the open-source code base.
• Documentation: The code itself was quite under-documented when we received it, and we had to fight to get a readme.txt out of them outlining what each file in the bundle of files did.
• Cost: As it turned out, the cost for the software part of this project was much higher than was quoted for, and far, far higher than we had budgeted for, even taking into account the extra buffer we had put into our budgets.

What did we learn?

Finding stock photography that perfectly illustrates your first reaction to seeing your own source code for the first time is… probably not a good sign.

Picking the right partners for a project is incredibly difficult, because evaluating how good a new partner is before you start working with them is nigh-on impossible. But in retrospect, we could have done a much better job; at the very least, we should have asked more questions about the type of projects the supplier had experience in working on.

Specifically, if/when we work with partners in the future, we will be better at evaluating them on:

• Accustomisation to the adequate orders of magnitude: A company that is an expert on designing a product that will be manufactured in a quantity of 30 units at a price point of around £1,000 is not necessarily good for a production run of 1,000 units at £30: They are completely different skill sets.
• Open source: If the goal is to open-source the software, the company you work with needs to have experience in working with open-source communities. In the future, we wouldn’t work with a company that doesn’t routinely contribute to open source projects and that doesn’t have an active GitHub presence.
• References: We failed to check references on a key partner we relied on to deliver a project. That was beyond stupid. It’s possible that our reference checks wouldn’t have helped, of course, but the only sure-fire way to not get an answer, is to never ask the question.
• Contracts: By the time we made it half-way through the project, we realised that the fact that we didn’t have a proper contract in place, which meant we had few legal or financial repercussions available to us.

Mistake #2: Being under-skilled and mis-resourced

Triggertrap has a lot of fantastic staff — our support crew is second to none, and we have a fantastic operational and software development teams.

As part of the 3 months we spent in the Microsoft Ventures Accelerator in Whitechapel, we’ve taken a lot of advice on how to bring Ada — and future products — to market more efficiently. This particular photo is only relevant in that it was taken right outside Microsoft Ventures. Pretty glamorous, eh?

Unfortunately, that’s not enough. This essay is titled ‘hardware is hard’ for a reason — there is an incredible number of things that can go wrong when you’re working on hardware, because there are a few unusual skill sets required.

One example of us getting the resourcing wrong was not utilising skills we had in the company properly. I have done a lot of project management and product management in my time, but I was focusing on the operational side of the business, and decided to leave the delivery of Triggertrap Ada to my CTO. That made sense; R&D of a new product is more of a tech thing than a product / operational thing in our business, but we were also aware that the CTO had less experience than me on the project management front.

Finally, we simply didn’t have enough of the hardware skills in house, which meant that we relied heavily on our partner agencies. That is fine, of course, but that also meant that we weren’t able to evaluate the feedback we were getting from them as efficiently as we might have otherwise. In retrospect, it would have been possible for us to learn the skills we needed to properly manage the agencies, or to hire someone to help evaluate the work on an ongoing basis — the fact that we did neither was a failure on our part.

What was the impact?

• We trusted the agencies we worked with to a fault, and failed to ask critical questions early enough. If we had asked the right questions, we may not have had enough skills in house at the time to interpret the answers properly.
• We left too much of the project management to the agencies.
• We discovered far too late that the project was running significantly behind schedule.
• We failed to get early visibility on the source code, and so didn’t know that we might have quality issues until far too late.
• We just didn’t have the overview we needed.

What did we learn?

Mis-resourcing this project has been an expensive lesson for us, in terms of delays and wasting tremendous amounts of money in the process. There’s definitely a few things we’ve learned along the way:

The original project Gantt chart had us delivering in mid April 2014 — a month ahead of what we indicated to our Kickstarter backers. In retrospect, it was somewhere on the gamut between ‘optimistic’ and ‘ pathologically delusional’.

• You can’t underestimate the importance of a good technical project manager. When we pre-sold £290k ($440k) worth of products to our Kickstarter backers, our very first investment should have been in a project manager to keep everything on track — it would have made an enormous difference in the speed of delivery, or at least how quickly we would have discovered quite how out of touch our delivery estimates were.
• Ensure the team has all the skills needed: We didn’t have competent Arduino-wizards on staff, but we did have very smart software people. Upskilling one of them to be able to evaluate source code or hiring someone specifically to help look after the firmware project would have made a world of difference.

Mistake #3: Lack of communications

We said right from the start of Triggertrap Ada that we were going to keep our Kickstarter backers in the loop throughout the project. And yet, we screwed up on that front. Triggertrap’s CTO Matt left the company in May. It was a difficult time for everyone at Triggertrap, but we had to keep moving and focus on trying to get Triggertrap Ada out of the door. At the time, as far as we knew, we were ‘very close’ to being ready to ship… But that wasn’t quite the case.

Triggertrap’s Head of Happiness Helena is showing off Triggertrap Mobile at an event — expect to start seeing Triggertrap Ada at a show near you, soon!

When I went to see the agencies to see what the status was of the project upon Matt’s departure, I got a very nasty surprise indeed: In the meeting where I expected to go and take delivery of a final version of the prototype, we were told that there was still a lot of work left to be done.

We did a re-estimation of where we were at, and at the end of May 2014, we updated our shipping estimate to October, but sadly that wasn’t the final delay. In August, we figured we’d be able to deliver by the end of 2014. In December, we had more bad news, and re-estimated the shipping date to be May 2015.

Overall, I think lack of comms has been the most frustrating part of this project for everyone involved. Moreover, it’s something we’ve been guilty of across the board: The agencies weren’t communicating properly with us, we weren’t communicating properly internally within Triggertrap, and to top it all off, we weren’t good enough at keeping our Kickstarter backers in the loop either.

What was the impact?

Triggertrap Ada is so accurate that you can dial in the delay to exactly the time when the pellet comes flying out of the air rifle. Pretty awesome.

The majority of our Kickstarter backers are supportive, and excited about Triggertrap Ada, but some of them have given up on us. And it’s not hard to see how that could have happened. With a project that looks like it’s going to deliver around a year late, I fully understand that some of the backers would lose faith in us, but I also believe that if we hadn’t screwed up earlier in the process, we might have had the chance to learn how much we were behind schedule earlier.

The crux of it is this: If we had been better at gathering and relaying information on to our Kickstarter backers, we would have been far more successful in keeping everyone — if not happy, then at least in the loop, well-informed, and in full understanding when we ran into challenges along the way.

What did we learn?

Communication is one of the most important parts of product development, but Kickstarter makes it even more crucial than otherwise: If it hadn’t been for our Kickstarter backers, perhaps we would have struggled on behind the scenes. That simply isn’t an option: We’re late. We’re embarrassed. And now we feel duty bound to air our laundry in public, because ultimately, we’ve failed to live up to some of our backers’ expectations.

• Kickstarter backers understand that there are delays from time to time, and they want to be part of the journey through the minefield that is product development. Keeping our backers informed goes a long way towards having a good sense of understanding.
• Internal reviews and status updates are crucial: Leaving the project manager to run the project on their own is not just a lonely experience; they might also fail to spot problems or warning signs without the feedback loop in place.
• Managing external agencies is much harder than it seems. In the end, we were only able to get the product to the state it is in now by embedding a Triggertrap staff member in their offices. It felt like babysitting, but it also meant that we were much more on the pulse, and had a far better overview of what wasn’t working, and why.

Why are we sharing our failures?

“Having fallen into so many obvious traps along the way
has been deeply embarrassing”

Yours Truly, using the Triggertrap ScreamGrab booth to take a selfie by shouting as loud as I can. In addition to being legitimate testing, it turns out that the occasional primal scream is absolutely necessary when trying to bring a product to market. Fact.

Okay, so the first couple of thousand words of this blog post have been pretty grim reading. Yes, we’ve learned a lot, which is great, I suppose, but it’s also painful. I feel that we’ve failed to deliver on our promises, and that we’ve perhaps failed to take responsibility for those promises along the way.

Having said that, I also think that part of the reason we haven’t been good enough at communicating is understandable. We didn’t do it on purpose, but when I’m sitting here thinking about it now, the answers is simple: I’m embarrassed. Delivering late is embarrassing. Having fallen into so many of the obvious traps along the way has been deeply embarrassing. And not really having an overview over how delayed we are is beyond embarrassing.

So, why am I sitting up at 3am, contemplating where we went wrong, sharing my failures as a CEO, and our failures as a company?

As a company, Triggertrap believes in Kickstarter. As a person, I love Kickstarter. And as Kickstarter alumni, it’s our duty to share the traps we stepped into and the mistakes with our backers and the world.

I believe that there’s an incredible number of products out there today that would otherwise never have seen the light of day because of Kickstarter. Oculus Rift, the Pebble smart watch, the Kano computer, and the Form1 stereolithographic 3D printer all have three things in common: They are all bloody awesome. They have all had an enormous impact on their respective industries. And they were all significantly delayed compared to what the Kickstarter projects promised their backers.

Delays, mistakes, and problems are part of the journey, and the only way to help other Kickstarter project owners — to pay our gratitude forward for the future generations of Kickstarter projects — is actively participate: We’re going to continue sharing our screw-ups and our victories. We will continue to dissect where we went wrong, and offer tips, advice, and insights as we work our way through it.

Because two things are for sure: We will deliver an awesome product to our Kickstarter backers. And we’re in a deep state of awe and gratefulness that they are supporting us along the way.

But there’s some good news too, right?

We have a lot of really good news; despite all of the above, we’ve been able to solve a few huge problems along the way.

Victory #1: Ada is fast

Speed testing in progress. It’s fast. Ludicrously fast.

Triggertrap Ada is ridiculously fast, and the graphical user interface means that you don’t need an engineering degree to make heads or tails of it.

It’s been a long journey, but ultimately I feel that we’re on track to delivering on our original goal: Creating an awesome piece of kit that we’re proud to stamp the Triggertrap brand on.

We can’t wait to get it into your hands.

Victory #2: Ada is easy to use

We wanted to create the world’s easiest-to-use high speed camera trigger, and boy did we succeed.

It’s always pretty tricky to know how easy something is in use until you pass a device to someone who’s never tried it before.

The proof is in the pudding, as they say, and we couldn’t have been happier: When Josh, our brand new junior operations manager, joined us at Triggertrap Towers earlier this month, we handed him a Triggertrap Ada protoype, and he was snapping high-speed photos in no time.

Victory #3: The firmware is rapidly improving

We asked a handful of our nerdiest friends and Kickstarter backers — the ones who came back to us and said they had the most experience with embedded hardware code — to take a closer look at the firmware code, and we got a nasty surprise: It wasn’t nearly as simple or elegant as we had hoped.

With the help from some of our Kickstarter backers, the firmware for Triggertrap Ada has gone through a series of improvements. In this picture, we’re flashing the board with a new version.

Having said that, there was a great silver lining: The backers, fans, and followers who looked at the code were immediately itching to help and to get involved. We gave them early access to the code repository, to help us tidy it up before we release the source code as public open source.

Some of the results of their involvement are already coming through. For example: Remember when I said that our longest Timelapse lasted 40 hours before the batteries gave in? In the code review, one of our reviewers pointed out that the microprocessor we were using has loads of features built in, including a low-power mode, but that the firmware wasn’t using any of these features. That, as he put it, was less than ideal.

I feel obliged to point out at this point that other code reviewers agreed, but put it less delicately than ‘less than ideal’.

A lot of things had to die for our testing to be completed. In this case, this candy cane never saw it coming. Poor candy cane. (Don’t worry, the shrapnel didn’t go to waste — it was rather tasty!)

Anyway, this reviewer estimated that by implementing the power-saving modes built into the microprocessor, that he would be able to improve the battery life by 300–500%.

We asked him to go ahead and give it a shot, and when we got the code back for testing, we couldn’t believe our eyes — only after well over 400 hours did the batteries finally give in, a full 10x improvement on the original code!

The other thing we’ve been doing some work on is the readability and the maintainability of the code — not just for our sakes, either. We want our code to be available as open source and easy to hack even for people who aren’t expert embedded systems developers.

Victory #4: We’re delivering

Our factory is preparing final production PCBAs as we speak.

We’re finally getting near the end of the process, and we’re now working closely with the factory in China to iron out any last-minute kinks.

Most of the amendments we’re making at this points aren’t functional — the main purpose is to make making it easier to manufacture Triggertrap Ada at high volumes and as quickly as possible.

That piece of the work is now complete, and we are awaiting delivery of sample PCBAs from the Chinese factory, and the finalised tooling CAD drawings are being prepared.

Both of these things represent big steps; once we’ve done our final round of testing on these PCBs, we’re ready to say “Yep, looks great, let’s make lots of thousands of these gorgeous little beasties”, or whatever the appropriate wording of that is in the corporate world.

Victory #5: We found some superheroes

You know the Beatles song; you get by with a little help from your friends? Never has that rung more true than as we’ve been fighting our way through bringing Triggertrap Ada to market. Some of the legends we’ve met along the line I think deserve some special thanks:

Nick Johnson

In this particular photo, Nick is showing off his home-made digital theremin musical instrument at the Elephant and Castle Mini Maker Faire

Nick Johnson of Arachnid Labs is a hardware and embedded software impresario extraordinaire, and we think he can actually see the matrix.

He’s been a huge force behind improving Ada’s source code, and has helped us out with double-checking the electronics circuitry as well.

Nick was in charge of improving our timelapse feature from 40 hours battery life to well over 400 hours.

Awesome work from this true scholar and gentleman.

Seeed & Nana

Nana is our point-woman in our manufacturing partners, Seeed Studio. We love them so much, in fact, that we used them for Triggertrap v1, and decided to work with them to repeat the success this time around.

Making the leap from prototype to mass manufacturing is daunting as anything — but with Seeed Studio on our side, we’re confident the next phase is going to run smoothly.

Throughout the process so far, we’ve challenged Nana with quite a few technical issues, but she’s always come up trumps with clever and elegant solutions.

Nana is working with her team to tinker and enhance Ada — and the improvements in being suitable for mass manufacture, reliability, reduced stress on circuit boards, and better connections between Sensors and Ada. Bloody fabulous.

James Lamb

James in action, fitting an early prototype of the Ada PCBs into the 3D printed enclosures for the very first time. It was an insanely exciting moment.

As we mentioned, James originally designed Ada, and has been with us every step of the way. When problems rose their less-than-attractive heads, he’s been there with us to face them down.

Most recently, he’s been guiding us through the final stages of production, and will be making sure all the tooling drawings and processes will result in an Ada that’s every bit as pretty as our original prototypes.

James has been there and done this many times before, he’ll be providing advice over Skype when we’re out in China while Ada is being produced. Awesome.

What’s next?

Tom is Triggertrap’s Head of Photography — he’s going to work with the rest of Team Happiness to create a series of How To guides to ensure you’ll get the most out of Triggertrap Ada.

Until the product is in our customers hands, there’s still a lot more work to do and we’re not at the finish line yet. In other words: it’s still possible that we might get blindsided by something we haven’t anticipated, which could cause the project to slip further.

Having said that, I feel that we’ve been able to overcome some of the hardest challenges, and that we’re finally moving along at a great clip.

What exactly are we doing, you ask? Well:

• Triggertrap’s Head of Product Rich is continuing to liaise with Seeed throughout the manufacturing process.
• Team Happiness is working on creating tutorial videos and our manuals to ensure that all your questions are answered.
• Triggertrap’s operations team are making sure that our warehouses are ready to take on the challenge of shipping more than 2,000 parcels all around the world. We know the logistics company we’re working with will be doing a great job. Why? Well, they were also in charge of shipping out all the Pebble watches when their Kickstarter campaign finished.
• And finally… We’re going to continue to ensure that everybody is kept up to date in the Kickstarter backer updates.