Stephen Hawes

The Onion of Tolerance

2024-04-02T00:00:00+00:00

Throughout the course of LumenPnP development, I’ve adopted a product development methodology I call The Onion of Tolerance that has worked really well for us so far.

…what? An onion?

When you first put something out the door, the people that will give it a chance are early adopters. They generally understand that it’s an early-stage product, and that there are going to be some rough edges. They have a high tolerance, sometimes surprisingly so. They’re involved because they’re excited about what you’re doing, and they want to be part of it.

You’re going to get a lot of feedback. They might be tolerant, but they’re still human. They care about what you’re building, and they want it to get better, so you’re going to hear about a lot of stuff that sucks about your product, which is great. The real challenge comes when deciding which order to fix the issues in.

Your early adopters are the very center of the Onion of Tolerance, the unwavering unshakable core that will put up with an absurdly frustrating and finicky experience. The next, larger layer of the onion is slightly less tolerant of a bad experience, and there’s more people in that layer. The layers continue.

I posit that the next thing you should fix or add to your product should unlock the next-biggest layer in the Onion as a potential customer. Fix the problems that keep them from engaging, then move on to the next layer.

Why do it this way?

This approach has a lot of benefits. Every time you fix a batch of problems and move to the next layer, you unlock a whole new category of customers, helping the organization grow or increase runway. This is fantastic for cashflow if you are bootstrapped, and a steady increase in revenue looks great on your P&L.

It also manages expectations really well. You’re never overpromising, always just selling your product to the people who are truly excited to exchange money for the amount of “done” it currently is. As a fledgling startup, you draw a fine line. You want to get your product into peoples’ hands, make sales, and keep the company alive. But you also don’t want to overpromise and give it to somebody that is looking for a more plug-and-play experience, and have the customer be frustrated. This whole thing only works if you’re comfortable saying to a potential customer, “it’s not ready for you yet.”

Typically the problems you’re solving to get to each new layer of the onion are the biggest, most annoying issues shared by the majority of your existing users. This means existing users are constantly having their largest frustration fixed, which shows solid and consistent progress on making the product better. Showing your userbase that you’re listening to and acting upon their feedback is one of the best things you can do to help your community grow.

How to do it

Determine what sucks

There are two main ways that we’ve used to find out what sucks about something: customer interviews, and dogfooding.

By conducting customer interviews, you’re getting right to the heart of the matter. Don’t choose folks that seem to be having a good time with your product. Pick the folks that are upset. Pick the folks that write you a novel about all the things that frustrate them. These are the perfect people to talk to. Praise is a good indicator of things to keep, but the negative feedback is orders of magnitude more valuable. The more critical, the better.

This does absolutely suck to do, to be fair. I think that’s why many companies don’t do these interviews, instead assuming they know what the customer wants. Spending an hour listening to why your decisions are bad and how this thing you built absolutely sucks is not fun. But it’s the most important thing you can do to make it better.

I also recommend getting on the phone or a video call with a customer and letting them just talk, instead of only sending a survey. Surveys can be great for some A/B decisions, and even as a way of finding frustrated customers that you then reach out to for a call. But if every one of your customers is having an issue you aren’t even aware of, and there isnt a spot on the survey to convey it, you’re loosing that signal. You don’t know what you’re looking for yet, so it’s best to just let them talk.

Another, less effective way is to dogfood your product (or, using it yourself). The idea is to tighten the feedback loop between creator and consumer, making it so that fewer bugs are introduced and issues are fixed quicker, because you’re your own user.

This is a great technique, and I think dogfooding also says a ton about the confidence your company has in the product, but you will always view your product with a bias. It’s yours. You designed it. Your ego, emotions, effort, and sacrifices went into making it. You will always view it in a different light than a customer. You will make excuses for it that a customer will not. This isn’t a reason to not dogfood. It’s just never going to give you the full picture.

Order them

After a ton of customer interviews and your own experience using your product, you should have a list of stuff that sucks. Now you need to order them in the order you will fix them.

Critically, the rank is not based on how much they suck, but instead the next layer of the onion. Often, these are the same thing, but sometimes they differ slightly. The idea is to open up the product to the next layer of the onion, while also trying to reduce net suck for everyone. What’s going to allow more folks to use it successfully? Who is the next-most tolerant group of potential customers? What feature or bugfix will unlock the next wave of sales that propel you to the subsequent layer?

The other main variable in determining the order is the difficulty of each item on the list. Rating “suck” on a scale from 1-10, 10 being the worst, a relatively easy 6 should ship way before a complex 10. Of course, the 10 is way more important and greatly reduces the total suck, but it shouldn’t gate that 6 from shipping much sooner.

Fix them

Now, fix them relentlessly.

With each item on the list, you’ll have a ton of feedback about why it sucks, and also probably a lot of suggestions about how to fix it. In general, you should take the fact that something is bad as gospel truth, but don’t put too much weight in the suggestions on how to fix it. Bill Hader has an excellent quote about this in regards to writing:

Your customers might have some excellent ideas about how to fix the problem, and you certainly shouldn’t disregard their suggestions. But they likely don’t have the context on the product (and the company) to know the best solution. The solve should come when looking at the entire scope of the product, company, and even future products in development.

What we did

Opulo followed this system for the LumenPnP. We got our first version of the machine (a kit) out the door to early adopters, and did a ton of customer interviews. We got three incredibly strong signals from those interviews, which we ranked:

It’s a pain putting the machine together
Strip feeders are finicky
OpenPnP is difficult to use

Again, this rank is not how much each of these things suck. It’s the most logical order to solve them for the next-most tolerant shell of the onion.

The signals we got from those interviews (and many more afterwards) have informed every single release we’ve done since. We immediately switched to an almost fully assembled version of the machine, solving issue one. Next, we designed and shipped component feeders, solving problem two. We’re working on number three right now.

This has resulted in a consistent, steady increase in sales and general perception of the machine.

Notes

What if I rasied VC money?

If you have a ton of cash, you don’t need to worry about this tier system of incremental improvement. You can just tackle the whole onion at once. You should still be doing customer interviews and ranking the suck of each issue, but you can parallelize better and fix more of them simultaneously. This system is meant for a profitable, cash-flow dependent startup company.

What’s the last shell?

The last shell of the onion isn’t the general consumer market, although they’re the second-to-last! The last shell is reviewers. These folks are the most picky, as they should be. It’s their job to be the most aware and critical of their experience using a product, so that they can inform people about things that might be frustrating for them.

Given that they’re the absolute last shell, you should only reach out to them when you’ve arrived at the last tier (or shortly before). The internet is written in ink, so if you’re going to send a unit out for review, you better be pretty damn sure it’s going to be a good review.

But it’s hard to fix hardware bugs!

That’s super true. Depending on how you manage your hardware production, “patches” are much more difficult. The LumenPnP is accessible and modular by design, so upgrade kits are very easy to manifest, allowing previous customers to enjoy the benefits of modern designs.

But an injection molded product with adhesives and heat stakes is not quite so editable. What you ship is more or less permanent. I’d imagine that much of this onion philosophy would occur on a longer timeline for those products, given that small, incremental improvements might be less feasible and a full new product release might be necessary to get to each new layer of the onion.

This is dumb.

Fair! I wrote this in the imperative mood, but I’m certainly not trying to prescribe that everyone does things this way. It has some problems! What if a pithy feature opens up the next layer of your onion, but leaves your existing users to deal with a really frustrating problem? That sucks! What if the next layer of the onion is unlocked by a four-year R&D saga that you absolutely don’t have the runway for? You have do something else. This is a tool, not a rule. It shouldn’t be followed all the time, but instead only when it’s useful.

Four Years of the LumenPnP

2024-01-18T00:00:00+00:00

Today marks four years since the beginning of the LumenPnP project. Four years ago, I posted a YouTube video announcing a project that would eventually dictate literally every aspect of my life.

Given that it’s an anniversary, it’s a great opportunity to look critically at how things have gone. What have we accomplished? What worked? What didn’t? Here’s some of the main things I think of looking back on the last four years.

YouTube Videos

YouTube worked great, and in so many ways. Posting videos was an incredible way to get some eyeballs on the project and bring in smart folks that were excited to work with me to make the project better. It built a huge community of people that are excited about the mission, and what eventually would become an early adopter market for the kit we’d soon sell.

After that, YouTube started working differently. It was critical in the early days of the project, but as certain R&D decisions became more established, the base of people that were subscribed for engineering videos were bound to be disappointed. The work shifts from design to logistics pretty damn quick when you start shipping.

I’ve been struggling to find a new voice as the company has taken so much of my time. It’s not about building a pick and place anymore. It’s about building a pick and place company, and that’s an entirely different thing, for a mostly different audience.

Should I go back to random one-off videos circa 2019? Switching the channel to being more company-focused? I really love making videos, but they have to benefit the project and the company in some way for me to choose to invest time in them, at least for now. This is a large consideration for me this year.

Community

Wow, what an incredible boon. The LumenPnP Discord server is now 4k people strong, and they have become such an incredible driving force behind design decisions, UX improvements, and engineering solutions.

One of the corrections from the community that I’m most grateful for is about my focus for the project in 2021. I had gotten into an iron-clad cadence of making a new, entertaining video about R&D every two weeks. After a certain point, the body of work that really needs to be done is validation and lifetime testing. The community gave me really excellent feedback that I should probably be shifting my focus to these challenges, and they were completely correct.

More recently, the community has been instrumental in making updates to the LumenPnP’s motherboard. Last year we tried a new format of review for PCB designs that’s been working really well that I’m excited to continue using into the future.

There’s also been really incredible efforts to design and document mods for the machine. A handful of other feeder designs have already been adapted to the LumenPnP, and one is even in the works that supports our communication protocol, Photon.

Github

We’ve taken a pretty aggressive stance on our management of source material. Every bit of source is tracked in Github. PCBs, 3D models, even wire harness designs are stored in the repository.

But git is designed for text. Merging a KiCAD schematic file from a divergent branch is effectively impossible. Your only real recourse is to choose one and overwrite.

We manage things a little differently. Using Git LFS, we can “lock” a file, ideally preventing anyone else from editing it while it is locked. In practice, it’s not quite so perfect, but it is a universal way of marking a non-mergable file as “checked out” so collaboration becomes easier. With this tweak, we’ve been using Github to manage our design source happily for the past few years.

Because of Github’s excellent CI/CD tool, we can even do things like automatically export BOMs for the machine, generate gerbers, or even render images of all the FreeCAD models. (Example in this release.)

This single source of truth has been fantastic for sharing the design and tracking versions.

Kit vs Assembled

For the initial kit version of the LumenPnP, a customer had to solder dozens of through hole components, 3D print tons of separate plastic parts, and engage in a tedious build spanning many hours. It was one hell of an ask. I am grateful so many people came along with us for the journey that early in Opulo’s lifetime.

Feedback from customer support was a clear indicator that we needed to own more of the process. Many problems that folks were having with the machine stemmed from bad print quality, incomplete THT soldering, or damaged SMT connections. We ended up solving this with semi-assembled machines where the customer is only plugging in some cables and bolting together subassemblies.

If the customer is building the machine, then every machine is built by someone doing it for the first time. They don’t get to leverage the experience we have for common assembly gotchas, or optimal ways of doing things. Taking most of the assembly in-house greatly reduced the number of issues, and resulted in happier customers.

Other Open Source Projects

The LumenPnP is built on the back of dozens of other open source projects, and it is better for it. Some of these projects are clean, isolated black boxes of utility that grease the wheels of development. But some require a bit more consideration, particularly Marlin and OpenPnP.

These projects are true behemoths with years of legacy and design decisions. Making edits to something so large and complex is hard. I think this is just the nature of large software projects, particularly ones that are designed to support many types of hardware.

We’ve made significant edits and patches to both projects since the beginning of the LumenPnP project, particularly around supporting the LumenPnP feeders. It’s been such a cool experience to see how other projects manage contributions. I spend most of my time working within the structure of the LumenPnP project, so to dive into how other folks operate an open source project is a great opportunity to challenge my own methods and see if I could be doing things better.

User Feedback

One of the most important things I’ve learned in the past four years is the importance of user feedback. Understanding what users of your product are experiencing and reacting directly to that information is such a crucial part of making something great.

In college, I worked on a muscle-controlled prosthetic hand. I designed a joystick driven menu system for selecting different grip strengths, and was pretty proud of my feature. When I showed this to the amputee I was working with, he said, “I will literally never use this. If I have a free hand to change a setting, why wouldn’t I just use that hand to pick up what I want to pick up?”

I was floored. In retrospect, it’s so obvious that that feature would never be used, but because I was not the target user, I was missing critical context about what using the product would be like.

At Opulo we use the LumenPnP every day to build boards, so we’re effectively our own user. This certainly helps us keep the right context, but there’s no replacement for listening to your users.

Balance

I have been unbalanced these past four years. I have effectively shut off every aspect of my life besides Opulo and the LumenPnP. I have gone to an extreme.

To be totally fair, it has worked. Opulo is a successful, profitable company, making tools that do useful work for people all around the world. But the way I’ve managed it has been unsustainable for myself. I need to find a better way of operating, because I’m sure as hell not going to slow down.

The problem is that I love it. I absolutely love working on this project and this company, and there are always a million things to do. Making the conscious decision to not is incredibly hard for me, even if it’s in my own best interest.

A few months ago, I started putting some things in place that help me continue to be the most effective that I can without losing my mind. Having a group of other founders to talk to has been unspeakably good for maintaining sanity. Also, taking an evening every once in a while to truly not think about work is surprisingly effective. Picross and Dungeons and Daddies have been my saving grace. It’s incredible how much taking some time off will make you more effective when you are working later. It’s not about the hours, it’s about the effectiveness.

I love running Opulo and the LumenPnP project more than anything, and I want to do it the best that I possibly can.

Next Four Years

We’ve hit some pretty excellent milestones since the project’s inception, but there’s still a lot of work to do. The midscale operation still has some gaps.

One of the most difficult things for folks starting out is having the right information. There’s a ton of resources out there for engaging in midscale manufacturing, so we recently started Midscale.io to help share these resources to others trying to get started. The OHM Podcast that we started last year also aims to accomplish that goal.

The LumenPnP’s UX can also see improvement. OpenPnP runs well, but can be difficult for new users to learn. Calibration is very thorough, but many parts could be automated. Also, job setup (mounting feeders, PCB panels, and strip feeders) is quick but could be quicker.

There are also other parts of the midscale SMT line that need work. I experimented with the idea of making a reflow oven, but there are really excellent machines that already exist. The same goes for stencil jigs. Some of these problems are not engineering issues, but availability issues. Importing and distributing these things would be the most pragmatic way to fill these gaps, and not by reinventing the wheel.

The management side of a midscale operation is also slated to improve. The already excellent Inventree which helps keep inventory, builds, and purchasing in order is constantly getting better. Standardizing BOM structure and sharability, hardware releases via Github CI, and git-based collaboration for ECAD and MCAD are things I’m working on in the coming months.

What We’ve Accomplished

I’m truly proud of what we’ve been able to do in four years. It’s been dozens of creative, intelligent, passionate people working together to develop a platform that helps folks manufacture their products. People have started companies, shipped products, performed research, and changed the world for the better with the hardware we’ve built.

In four years, we have:

developed a pick and place system from scratch that is completely open source, and self-buildable with off the shelf components
developed multiple updates and revisions to that pick and place system, improving speed, rigidity, and reliablility
developed pick and place feeders that support the vast majority of components
developed standardized feeder firmware and a custom protocol supporting feeder discovery and loaded part tracking, plus integrating this protocol into Marlin and OpenPnP
written thorough, annotated user documentation and assembly instructions
raised money to enable the first batch of material purchases and office space
developed custom testing software and production jigs to allow for these machines to be assembled and tested
built and shipped thousands of units to every corner of the world
started a podcast and developed resources for folks diving into midscale manufacturing

I am so incredibly grateful to anyone and everyone that has contributed to this project in some way. If it wasn’t for all the folks that helped craft it into what it is, it’d still just be me in my Somerville apartment, tinkering away. Thank you.

2023 Review

2023-12-31T00:00:00+00:00

After reading Thea Flowers’ year-in-review post, I decided to shamelessly steal the idea and do a similar one. Akin to a skill index, the things you’ve done in a year are hard to hold in your brain in their entirety, so writing them all down can be helpful for context.

Summary

In many ways, 2023 was a year of staying the course. In late 2018 I decided to start a YouTube channel with the express end goal of starting a hardware company. 2019 was lots of videos, and no real traction. 2020 was LumenPnP development. 2021 was going full-time and prepping for launch. 2022 was shipping a machine and getting stable. 2023 was staying the course.

This year begain with a stable organization, sales, employees, and an office. We end the year similarly, but just, more. More sales, more employees, more products. After four years of constantly shifting, having a more consistent existance has been wonderful, particularly for taking some larger swings and knowing the things we’ve done to stabilize are there to catch us. The more stability you have for the basics, the bigger risks you can take.

Opulo

A lot of this year was just focusing on shipping. It takes a tremendous amount of effort to “compile” a hardware product, so a lot of my time this year was spent on improving that process.

On March 31st, we launched the LumenPnP 8mm Feeder. These were truly the make-or-break point for the LumenPnP project. A pick and place really shines with automatic part feeding, and how well that works defines a large percentage of the machine’s user experience. A bad feeder solution can easily disqualify the machine for many users; we had to nail it.

And the feeder isn’t simple! The LumenPnP relies on many proven ideas about linear motion, so validation was simple and straightforward. The feeder is doing a number of more unique things that required thorough testing before contact with a customer: printed gears, a custom protocol, cable-free connectivity, etc. We did a number of things to ensure we caught any weird bugs or mistakes before shipping:

Lifetime and Validation Testing - Sporting no fewer than three 3D printed gears, wear was definitely a concern. We ran hours of lifetime tests, feeding over a quarter million cycles uninterrupted on many units.

Feeder liftetime jig with infinite loops of tape and film

We also developed a jig that instructs the feeder to feed with empty tape, and performs machine vision to ensure the accuracy is within spec. The feeder has to do what we say it will, and for a long period of time.

Beta Program - We shipped DVT units to high-use customers, and incorporated all notes of feedback into the PVT run. This feedback also heavily informed our documentation about setup and usage of the feeders.

Launch went spectacularly, and reception has been great. We even tried hiring a professional production company for our launch video.

Shoot day

Dropping off the first batch feeders at UPS

The wonderful LumenPnP community has helped with an updated version of the feeder controller PCB, firmware tuning, and even hacking the slot interface to support other feeder types.

We have around 80 feeders in use on our own production line across four LumenPnPs, and they make it feel like a brand new machine.

A few months after 8mm Feeders launched, we introduced the 12mm Feeder. We’re still experimenting with 16mm and 24mm feeder solutions, particularly in regards to peeling thick adhesive film from the tape.

The 8mm and 12mm feeders, along with 16mm and 24mm prototypes

We also launched v3.1 of the LumenPnP, which has many DFM and user improvements, but mainly implements Thea Flowers’ linear rail mod, allowing the machine to move much faster.

I also spent a ton of time this year working on ads, mainly understanding how they work and what role they should play at Opulo. There’s a surprisingly large amount to learn and I was quickly humbled after diving into it.

Lastly, we started the OHM Podcast! Lucy and I have been sharing some of the things we’ve learned shipping an open hardware product in podcast form, as most of these topics aren’t good YouTube material. It’s been a blast recording, and it’s been interesting working on something on-mission that isn’t shipping a physical object.

Events

Every year I hope for a calm, productive year in Pittsburgh, and every year I find myself traveling thousands of miles for various events. I already have three lined up for next year!

In late April, Jaden and I went to Neotropolis, a cyberpunk-themed immersive festival in the Mojave desert. It was a fully-fledged LARP event; you were obligated to be in costume throughout the festival, and were expected to be in character throughout as well. After a brief adjustment period, I fell into my alter ego and loved the experience.

Jaden brought her van and Vardo trailer along, which was an awesome look with the cyberpunk theme.

The Vardo next to MegaBlock1, a two-story city block the Neo team builds in the desert.

Vardo installed in our faction’s cell in MegaBlock1

Then, a four-day cross country trip back home.

In July was Open Sauce. Earlier in the year, William Osman reached out to me about attending a weird new event he was planning, supposedly a cross between VidCon and Maker Faire. And that was exactly what it was.

Adam Savage’s Keynote

I hacked a LumenPnP to draw portraits, and set it up at the event so passerby could simply press a button and have their visage plotted on the machine.

Meeting dozens of other creators that I deeply respect and having the opportunity to have extended conversations with them was definitely the highlight of the event for me.

Bunch of creators after going out for Thai food

Got to see Ryan from V1 Engineering, the Maslow team, and Chris from Sienci Labs

Packing up after the event

Lastly was Hackaday Supercon! I have given a talk there before, but this year it was really lovely not having that added stress and instead being able to just enjoy the event. The best part of Supercon is just hanging out with a bunch of intelligent, interesting people.

Finally getting to meet the wonderful Maggie and Thea in person!

I also spent a week in Denver with LumenPnP developer Justin Nesselrotte, working on some feeder protocol updates and checking out Denhac.

Web Tooling

This year I became obsessed with little single-page web tools. Github Pages makes deploying a website so insanely simple that making a tiny web service is such a great, quick solution to a lot of problems.

The crown jewel of this year’s sites is definitely the LumenPnP Config Tool. Input the number of unique parts your SMT job has and the tape width they’re in, and the site will calculate the optimal configuration of powered and strip feeders, and even render the layout of the config in a 3D model. Figuring out how to optimize the feeder configuration was a great challenge, and I really enjoyed toying around with Three.js.

I also created a tool that tells you when a LumenPnP purchase pays for itself (still in progress), a site outlining tools for open source hardware (still in progress), and this website you’re on right now, along with personal sites for a number of friends.

Just recently I began work on a WebSerial based tool for configuring and debugging your LumenPnP, meant to aid in setup and troubleshooting. I’m also looking into ways of standardizing some of the tools I’ve developed for exporting and rendering the Bill of Materials for an open hardware project, and I think a little web viewer might be included.

Personal Projects

Despite the frequently overwhelming responsibilities of Opulo, I managed to squeeze in a couple projects just for fun.

This summer I designed and built Gradientbloom, an open source alternative to Spectrabloom, which is a simple array of red, green, and blue point-sources of light meant for cool color mixing visuals.

The original is just three LEDs on dimmers. My version has a microcontroller on board, and each of the three LEDs are fully RGB themselves, leaving a lot of room for cool animations and patterns. I designed it originally for my cousin, but ended up making a few more for friends and family.

I got (re)chipped this year! I had an xEM RFID tag implanted in 2014, then removed in 2019 to make way for this new one. Now sporting proper NFC, my xNT tag is readable and writable from my phone. Lots of projects in the pipeline next year using the chip!

Jaden and myself, freshly chipped!

I’ve also started work on a new open source project. My ATH-M50xBT2 headphones are wonderful, and have served me well for around 5 years of heavy, daily use. However, they are quite frankly beat to shit, and I’m about 5 repairs deep into them. I want headphones that are easier to fix, and without having to rely on Audio Techinca for replacement parts.

The PheadHones (I love Spoonerisms, I know it’s a stupid name, dont @ me) are fully open, over-the ear, Bluetooth headphones with support for wired connections. Right now I’m just building them for myself, but they’ll be fully documented and are designed with the Opulo-ethos of easily accessible, off the shelf parts.

2024

As Opulo grows and the stress of maintaining it increases, I’ve been learning some tough lessons about how to manage my time and sanity. My main focus is to keep stepping on the gas, so figuring out how to do that in a sustainable and reasonable way has been a core thought. There’s still a lot to do.

Render of Beta 0 of the next revision of the LumenPnP motherboard, being fabricated as I write this!

I’ve got a ton planned for this year. Lots of content around the details and thorny roadblocks with certifications, and getting back to making videos on a regular cadence. Plus, a new and exciting project that unfortunately I cannot yet share. Lots of cool stuff coming up this year, and I cannot wait to dive in!

Mid-Scale Manufacturing

2020-02-27T00:00:00+00:00

After I finished shipping the Glowtie Kickstarter, I had a conversation I had with my friend Alex Madinger about the different “levels” of making (and selling) a product. We defined them as follows:

Level 1 - Someone at home in their pajamas making something on a Saturday morning with tools and materials available to someone with a hobbiest budget.
- Scale: 1-100 units.
Level 2 - Someone using some outsourcing and some in-house fabrication techniques to make things at a much larger scale, representing a sizable amount of money and effort.
- Scale: 100-5000 units.
Level 3 - Traditional mass production, hiring a contract manufacturer and getting things made at a factory, most often overseas.
- Scale: 5000+ units.

Of these three, Level 3 is how almost everything you own is made. Huge factories making parts by the thousands or millions, with a huge supply chain and logistics team. Processes like injection molding and pick and place machines that allow things to be manufactured at a breakneck speed, but with an upfront cost that only justifies their purchase at absurd quantities. And that’s how consumer products were made since the First Industrial Revolution.

In the last decade or so, we’ve hit this beautiful point where anyone can prototype anything in their apartment with PCB mills, low-volume PCB orders, FDM 3D printers, free CAD packages, and a ton of other recent changes in the market.

But in between? It’s a no-man’s land.

The wave of “desktop-ifying” industrial machines takes an expensive technology (Level 3), and make it cheap and accessible (Level 1). Making plastic parts used to only be a Level 3 technique with Injection Molding, but now we have cheap FDM machines that let you make them at Level 1. What about Level 2? What if you want to make more than 5, but less than 500,000? Do you empty your bank account for an injection molding die, or buy a bunch of printers and run them nonstop? Either way it’s a stretch. There aren’t great solutions to take a prototype to the next level of scale, without biting the bullet and going straight to full scale Level 3 techniques.

As a quick aside, I’m not considering software in all of this. The difference between making an application for one person versus 100,000 is relatively small, and can easily be scaled up with awesome services like DigitalOcean or AWS. Of course I’m oversimplifying, but in comparison to hardware, the Level 2 gap is satiated pretty well in the world of software.

So, what are the fabrication techniques that still have this Level 2 gap? Plastic parts for sure. Things like Form Cell adapt additive for Level 2, but it’s at a Level 3 price point. It only really makes sense for bulk custom parts that traditional Level 3 techniques don’t account for like Injection Molding, like in the case of Gillette Razor Maker. You can pull a Prusa and set up a bunch of FDM machines for mass production, and while that’s pretty viable, it’s not tremendously automated. Lots of techs are necessary to run, monitor, and remove prints. I think the current best thing is outsourced urethane casting. It has a very low upfront cost while maintaining a pretty cheap per-unit cost that makes it a great choice for Level 2 sized production runs. While this works, I think there is still room for growth in this area.

Another area that has a Level 2 Gap is PCBA assembly. This was the real pain point for the Glowtie Kickstarter. I soldered almost 3000 components by hand (the Level 1 approach), but having a board shop assemble them for me was prohibitively expensive, time consuming, and risky if they fabricated them incorrectly (the Level 3 approach). There was nothing in between to speed things up, but not cost a ton.

Lastly comes organization and logistics. How do you track stock, production rates, and yield? Kanban ordering/fabrication of parts? When you’re only making a few of something, it’s easy to keep track of how many boards you have in stock. When you’re making hundreds of thousands, the Contract Manufacturer can own supply chain and stock management. But what about Level 2? How can you easily track stock flow and production at larger quantities without paying someone to handle it full-time?

There is space for growth here. People with an idea and a working prototype shouldn’t have to refinance their home to start selling their product. There should be tools and processes in place to allow someone to move past Level 1 without having to take such a risky leap of faith.

The Absurdity of Memorization

2017-04-17T00:00:00+00:00

“Never memorize something you can look up.” — Albert Einstein

My fourth grade math curriculum was comprised of mainly one thing: multiplication tables. Essentially all of the math-allocated portion of the day was dedicated to drilling a set of seemingly arbitrary sets of numbers into our skulls. After a couple months of training, one of my peers asked our teacher why it was necessary to memorize our multiplication tables. Our teacher responded with, “Well, it’s not like you’re going to keep a laminated reference sheet with you at all times!”

So that’s exactly what he did.

To my knowledge, twelve years later, he still has a laminated multiplication table reference sheet folded up in his wallet. This serves no practical utility (especially given the fact he was still required to memorize his multiplication tables), but he did it to make a point: you can always look it up.

My fellow fourth grader laminated in defiance around 2004, but his point stands even stronger today. We each carry with us a pseudo-infinitely large “multiplication table” in our pockets at all times, leaving the modern need for memorization the smallest it’s ever been. Phone numbers, directions, conversion units, the air-speed velocity of an African swallow, you name it. Anything we can Google, we also efficiently eliminate from our brains.

Of course, some things are still crucial to memorize, namely in the case of an emergency where an internet-connected device is unavailable. A few important phone numbers, your social, stuff along those lines. And sometimes it’s wildly efficient to memorize something you use on a daily basis. For example, it would be prudent for a scientist who works frequently with a certain chemical compound to memorize its molar mass, or other commonly needed characteristics. But 99.5% of information can be cleanly purged without ill-effects.

I think this is fantastic. Intelligence isn’t a measurement of how well you can regurgitate information. Intelligence is a measure of what you DO with that information, and your creative solutions from a unique outlook. If we’ve built machines that are wildly efficient at organizing and indexing data, why bother trying to do the same? We should reserve our brain capacity for something only we humans can do: think critically. The information age isn’t making us stupid, it’s making it easier to be smart.

Keeping a Skill Index

2016-11-07T00:00:00+00:00

I was recently asked, “What was the first thing you built that you were truly proud of?” My answer was an RSS feed aggregator I build in high school to get my feet wet with php, database management, cookies, etc. But as I was explaining the technical details of the project, I was surprised recalling what skills I had used to complete it. Granted, it had been four or five years since I had worked on the site, but this was slightly jarring to me. How many times had I neglected to consider that I had the ability to develop in some way, and altered my development stack because of it? I felt like this was unlikely; who actually forgets they have a skill? But I had clearly done it to some degree.

This got me thinking about all the projects I had worked on. What went into them? What did I have to learn in order to complete each project? What are all the skills I’ve collected over the years? And most importantly, what are all the features I could incorporate into a hardware and/or software widget?

So I counted.

I opened a new note in Evernote and started listing. Software, hardware. App development, data storage and management, programming languages, libraries, APIs, methods of automation, bluetooth and wifi connectivity, development boards, all of it. After an hour or so, I felt like I had summarized my smattering of technical capabilities into a neat, hierarchal format.

My first reaction was satisfaction. This document had become my “maker resumé.” All of my “just-for-fun” projects suddenly had a very practical result by adding a skill-set to my development toolbox.

The second was potential. Patterns emerged while scanning this collection of seemingly non-related capabilities. And they were definitely not USEFUL patterns, but it got the gears turning. I started picking three random topics and trying to see how I could combine them. A script that tweets the first hit on Google Images of the word you’ve said most that day. A heads-up display that constantly shows you how many steps away you are from Reno, Nevada. A thermostat system that changes the temperature in accordance with the NASDAQ. Again, not tremendously useful, but a fascinating exercise in creativity. Seeing the possibilities of what you can create is an empowering feeling of possibility.

If someone asks you if you’ve read Stranger in a Strange Land by Robert Heinlein, you know immediately if you have or haven’t. But if they ask you to tell them all the science fiction books you’ve ever read, that is a MUCH more difficult task. So, the point of this exercise wasn’t to help me remember what I’ve done. If someone asks me to build a web scraping app, I can tell them immediately if I can or can’t; my memory wasn’t the issue. The point of this exercise was instead to be able to see all the “science fiction books” I’ve ever read in one place for easy reference. To get the juices flowing. To see how any combination of these techniques could be used together. To keep possibility on the front of my mind.

This becomes the most useful when brainstorming solutions. If a solution is simple, it becomes a “Have I read this book?” scenario. But if you’re attempting to solve a complex problem, looking at everything on the table gives you more context and perspective on ways to build a solution.