Best Practices

How to run a productive internal product bootcamp

When launching a new developer focused product, platform, API or hardware gadget it can be nerve wracking to imagine tossing your product “over the fence” to see how developers fare with it on day one. When real money is on the line, it is essential to understand how to organize and run internal bootcamps to polish your user interface and developer experience before it is time to launch. 

Having worked on the launch of numerous hardware platforms and developer facing APIs, I have organized many such events and wanted to share a few tips about how to go about organizing a bootcamp and maximizing the value generated from such events. 

How to run a productive internal product bootcamp


Bring a stack of use cases: The objective of an internal bootcamp around DX is not for people to vaguely play around with devices or a portal, although that can be helpful. What you really want is to get people to put the product through it’s paces and to systematically walk through all the key potential user experiences that most developers are likely to have. When I ran these events for the Intel Edison, Intel Joule, Arduino 101, Intel Curie and Intel Movidius products, we would get everyone together in one room and they would all get a print out of what we wanted them to test. 

Work in small teams or pairs: We found during our hardware DX testing that it was great to put people into small groups or pairs to walk through and test different situations. One of the biggest challenges with hardware is that Windows / Mac / Linux computers all have different drivers and USB behavior when plugging devices in. Putting people into groups ensured that combinations of operating systems and computers would get tested. 

Have a giant whiteboard: Be very meticulous at documenting all the problems and notes. It is very valuable to stop the process to ask people for their structured feedback. One of the big problems you may find is that people will locate a bug and then forget about it. Or they will think of an optimization or improvement and not write it down. If you are the one program managing these sessions, you have to be very deliberate about capturing all of the data generated by these events.

Rotate the room: This is easier to do at a large company, like Intel. If you keep testing the same people you may keep finding the same results. Or even worse – people get tired and bored of doing these dogfooding workshops and they stop being as disciplined and attuned to the product. For this reason, it helps to bring in fresh faces on a regular basis.

Test regularly: For our major hardware launches at Intel, we kept a running cadence of developer experience tests moving throughout the product development process. Not surprisingly, certain use cases would relapse to their original broken state after being “Fixed” and have to be addressed again. It is very valuable to keep people rooted in the problems that users have in the first ten minutes of their experience with the product. Chances are, if you can provide a great 10 minute experience, the rest of the experience is going to be great as well.