The Prepared is hiring a part time operations manager

The Prepared, my (excellent!) weekly newsletter, is growing. And while I never intended it to be anything other than something I did to keep myself busy in the evenings, it has become evident The Prepared needs part-time help.

So I’m excited to announce that The Prepared is hiring a part time operations manager. The role will cover a variety of research, archiving, and growth operations, and is remote-friendly. If you or anyone you know is curious, energetic, and interested in helping build a community of like-minded people (most of whom work in or adjacent to manufacturing), please apply!

As always, thanks to The Prepared’s sponsors, patrons, and subscribers for making this possible.

3MF on GitHub

Back in 2013, I wrote a short blog post titled “ISO should be an open source project.” In it, I (somewhat offhandedly) argued for a new paradigm for cross-industry collaboration - one in which both individuals and enterprises work together in the open.

Well this week, the 3MF Consortium completed its transition to hosting all of our specifications - as well as sample files, implementations, and much of our internal consortium documentation - on GitHub. Where they can be viewed, downloaded, forked, and pull requested by anyone in the world.

This transition took a considerable amount of work, and maintaining a culture of openness will require maintained effort. But the benefits are significant: Not only will we encourage newcomers to use and improve our work, but we have also streamlined our own workflow (emailing Word docs back and forth is pretty inefficient) and aligned it with the very stakeholders (product managers and software engineers) who implement 3MF specs.

Five years ago, I wrote: “I would *hope* that in ten, fifteen years max I'm seeing these standards in a web browser for free.” I’m proud and thankful to have that hope fulfilled :)

Strategy, sacrifices, and the margins your business needs

In an interview last week on The Amp Hour podcast, I put forth a provocative opinion: That it's okay to take a margin hit for strategic reasons.

Note: The full interview, which is too wide-ranging and generally entertaining to properly recap, is here.

Since I said the words below, I've been thinking more and more about the interchange and what my thoughts on margins are exactly. Here's a partial transcript (edited for legibility) of the relevant section, which begins at around 48:00:

SW: "I think there are a bunch of things that have to happen to make [stateside production of consumer electronics] feasible, and honestly one of them is that you have to change your expectation of your own standard of living, and you have to change your expectation for what your margin is going to be. Which is really, really tough. It's something that I [personally] feel deeply ambivalent about - like on the one hand I know I'm motivated by money, but also: Would my life actually be better taking a 40% margin, and then I'm able to see the person who's making my thing every couple months? Is that tradeoff worth it? I think in a lot of cases it actually is...

"I think that engineers and product companies jump to outsourcing stuff *way* too early, and there's a lot of units [of your product] that you could [personally] touch that would improve your ability to ship product and it would improve your customer experience in a lot of ways and it would just make your [social/professional] ecosystem a lot more healthy."

CG: "So when you say give up margins, do you mean give up margin at the beginning or give it up generally?"

SW: "I mean, both."

CG: "But it sounds like you're saying to give some of it up, and work out some of the wrinkles, and then eventually start to cost optimize and move to other facilities."

SW: "If that makes sense then sure. But I can say that the labor rates that we pay are way, way higher than we would pay going to China, and maybe that's okay. You know, you don't *need* your 60% [margins]. You can do things differently than the rest of the industry does... It's easy to read someone's blog post from some venture capital backed company talking about how they did it and think 'Okay, I'm gonna do it that way.' And thinking through those things critically is a good idea in general."

To start with, I should have added that sustainable (in the "financially sustainable" sense) businesses are *cool*, and I'm not recommending that anyone should put themselves in a position that'll eventually be untenable. I also recognize that when you've got a lot on your plate (as any entrepreneur does), there are a lot of things that end up being decided based on whatever the default is (i.e. whatever someone else has said publicly that they did).

That said: As David Ogilvy famously proclaimed, “The essence of strategy is sacrifice.” And just like you might give up a little extra money for your product to be higher quality, or for your customer to be a little happier, or for more efficient capital allocation, I think it's eminently reasonable to give up money for a more responsive supply chain, or one that isn't subject to big swings in international trade costs, or one that's easier for a resource-constrained team to manage.

As I said on the podcast (and as I've written here and on The Prepared extensively), I *like* doing business with people from other countries and cultures - and am particularly enchanted with China's culture and ability to execute all manner of undertakings in the physical world. But I'm a bit put off by the hardware scene's predisposition towards manufacturing *all* of our consumer electronics in the Pearl River Delta, and I would encourage anyone out there reading this to really consider the potential costs (both direct and indirect) of doing so.

Mini-review: Amazon Part Finder on iOS

A week or two ago, Jordan gave me a heads up about a new feature on Amazon's iOS app: A "Part Finder" feature that supposedly will identify fasteners using your camera's phone. The tech press is, predictably, excited about this: It's arguably augmented reality, and AR is hot right now, and most of the people writing about AR and Amazon probably don't own a pair of calipers, metric or inch thread gages, or a thread checker set. 

As one might expect, I was a bit skeptical to learn that it might take a journalist ten tries to even get the app to produce a result. So this morning I gave it a shot.

More or less at random, I opened one of my parts drawers and took out a selection of parts. I tried the following McMaster-Carr part numbers:

• 92196A581, 18-8 Stainless Steel Socket Head Screw 5/16"-18 Thread Size, 3/4" Long
• 91771A542, 18-8 Stainless Steel Phillips Flat Head Screws 1/4"-20 Thread Size, 1" Long
• 97517A025, Aluminum Blind Rivet with Steel Mandrel Domed Head, 1/8" Diameter, for 0.1880"-0.25" Material Thickness
• 97395A451, Dowel Pin 316 Stainless Steel, 1/8" Diameter, 3/4" Long
• 92196A194, 18-8 Stainless Steel Socket Head Screw 8-32 Thread Size, 1/2" Long
• 90895A029, 18-8 Stainless Steel Belleville Spring Lock Washer for 1/4" and M6 Socket Head Screws, 0.264" ID, 0.374" OD

TL;DR: I do not find this feature even a little bit useful. A few notes:

Lighting

My shop is lit mostly with task lights: Clamp-on fixtures with LED bulbs. This tends to cast shadows, which the Part Finder had a *really* hard time with; it took maybe 25 tries to get a single result. Worse yet, the app shows you the instructions every single time, making the photo process itself rather painful.

I next went outside and set up in full sun. This was even worse - the high contrast shadows seemed to throw the Part Finder off even more. Lastly I went inside in an area with a decent amount of indirect light, which worked much better - but still far from perfectly. 

In a few cases, the Part Finder couldn't even find the penny I was using, and once it claimed that it couldn't find the part. Some of these failures can fairly be blamed on my lighting, and some can probably be blamed on Amazon's image processing software. But the user experience sucked, and that falls squarely on Amazon's product team.

"Additional part details"

When I finally did get a match, the following message appeared:

Great, we have analyzed the photo and gathered specs. Please select the additional part details below:

The Part Finder seems to operate *only* on fastener diameter, length, and basic classification. It doesn't deal with head type or thread spec, and when I scanned the blind rivet the app prompted me to ask whether it was a "Drive Anchor, Post, Hex Bolt, or Blind Rivet." 

Some of this filtering may be useful to leave in the user's hands, but the range here calls into question exactly what "specs" the Part Finder has gathered. Which leads me to:

Thread spec

The Part Finder cannot distinguish thread pitches, nor can it tell the difference between metric and inch threads.

To me, this is a need-to-have feature for any fastener identifier. I almost *never* lack a method of determining a fastener's diameter and length (I bring a caliper with me if I know I'm doing much work at all), but my thread gages mostly stay in the shop. If Amazon wants to get serious about this, they *need* to include thread identification in the Part Finder.

Conclusion

As I've written before (see this and browse here), Amazon's total lack of product hierarchy puts them at a severe disadvantage when it comes to this kind of feature. The obvious counterpoint is McMaster-Carr, whose catalog structure is perfect for establishing the appropriate scope in a part identifier feature search. 

In other words: Partly, Amazon's Part Finder just sucks at identifying parts. But there are also institutional barriers in the way of Amazon ever being good at something like this, and (if AR gets better) I do still hold out hope for another player to tackle this problem.

Flying probe testing

This is an old video, but I only recently learned of it: The Public Radio's printed circuit board undergoing flying probe testing at the board house in 2015. 

Our design has changed quite a bit since then - the circular PCB was for some reason hard for us to get away from, but its current rounded-octagon shape is much more space efficient. Thanks to Chris @ Worthington Assembly for sending this over!

Looking for a freelance Ruby developer

Centerline Labs, the company I cofounded with Zach Dunham, is looking for a freelance Ruby developer to help improve our automated order & inventory management system.

I have written extensively (1, 2, 3) about our system ("The Coordinator") on this blog and on The Prepared's podcast (1, 2). It is the core of our ability to manufacture customized consumer electronics in a just-in-time manner. This is no small task, and we're proud to be doing something that enterprises and startups around the world struggle with.

We are currently looking for a freelance Ruby developer to help us improve and build additional integrations for tpr-coordinator, the backbone of our manufacturing operations. Applicants should have experience developing and maintaining web applications and should be comfortable deploying them on Heroku. Experience with Amazon's and Squarespace's commerce APIs, Shippo, and manufacturing systems in general are all pluses.

If this sounds like you, poke around tpr-coordinator on GitHub and then give me a holler here.

An interview with me!

Over the past few years, I've had the growing sensation that my public life is primarily focused on being a commentator or analyst rather than a practitioner. This is largely due to my role on The Prepared, but I'm sure is also influenced by my professional priorities and the fact that ultimately, I'm interested not only in any specific trade but in the broader saga of product development and business maturation.

And so it was just a delight to be asked to appear on 100 Product Managers, and a total pleasure to be interviewed by Suzanne Abate. Our conversation spanned not only The Prepared and The Public Radio, but also my time building high end custom bikes and robot doors. Throughout, we focused not only on the products being sold but also the products being used to make them - manufacturing tools, fixtures, and software. 

For the whole interview, head over to the 100 Product Managers site. Thanks to Suzanne for having me on!

The 3MF Beamlattice extension: A better way to describe lattice geometries

Today, the 3MF Consortium officially announced that its Beam Lattice extension has been ratified and released. And I'm proud to share that nTopology Element is the first piece of software to support it and that I (via nTopology) was a part of its development and adoption.

Brad and I first approached the 3MF Consortium about developing a lattice-specific file format almost two years ago. At the time, we had recently released nTopology's own LTCX file format, which we created and open-sourced in order to share files internally and with nTopology's early customers & research partners. LTCX is lightweight, portable, and high fidelity, and we wanted other companies in industrial 3D printing to have access to similar functionality. 

The 3MF consortium was an excellent fit for this, and late in 2016 I represented nTopology at our first 3MF meeting to discuss how LTCX could be adapted to meet the broader industry's needs.

For context: STL files have numerous well-documented issues, but they're particularly bad at representing lattice structures. STLs describe the surface of a part as a tessellated surface, which is (with large caveats) a fairly good general-purpose method of describing arbitrary geometry. But when you use STLs to describe lattices, you either end up with bad surface resolution or manifold/watertight issues, or both - and regardless, the file size is *enormous.*

The 3MF Beam Lattice extension solves this by describing lattices via their node and beam properties. This results in multiple orders of magnitude in file size reduction, while *improving* surface resolution. 3MF Beam Lattices live right alongside all of the other data that 3MF can handle: Not only meshes but materials, slices, etc. As a result, 3MF Beam Lattices are incredibly rich, and can be used for parts that comprise both lattices and solids with extremely high fidelity and portability.

Personally, the process of working on the 3MF Beam Lattice extension has been a pleasure, and I want to thank the entire 3MF Consortium for their dedication to our shared goals. In particular, Alex Oster, Scott White, Kris Iverson, Jordi Gonzalez, Mark Forsyth, Mike Facello, and Kurt Renap brought both enthusiasm and experience that was essential to the specification. I also want to commend the team at Netfabb for introducing 3MF Beam Lattice support with incredible speed, and for driving the development of the 3MF open source implementation. 

3MF has some great other projects in the works, and I can't wait to share them as well. For more information, visit the 3MF Consortium's website.

Looking for a laser marking vendor

An open RFQ:

I am looking for a vendor who can perform laser marking services on stainless steel parts. This is a customization that we offer for The Public Radio as seen below; we purchase the laser marking in MOQs of 100+ and have an estimated total usage of 2500 this year. 

If you do laser marking or know someone who does, please get in touch here. Note, my preference is to find a supplier that's within 1 day of ground shipping from New York City. 

The Public Radio's assembly & fulfillment processes

In preparation for our full rollout at our contract manufacturer, Worthington Assembly, I spent a bunch of time honing The Public Radio's mechanical assembly & fulfillment processes - organizing the workspace, testing each error check, scanning random shampoo bottles to make sure a weird barcode doesn't screw things up. The processes and tools we've developed will inevitably evolve yet, but at the current setup is solid.

So, video documentation!

Mechanical assembly

We begin by taking in printed circuit board assemblies and making mechanical assemblies. We typically do this in batches of 18, and once a batch is done they're scanned into inventory and put in a tray on a shelf:

Obviously, the mechanical assembly step is *not* done just in time; a mechanical assembly might sit on the shelf for a day or a week before its time comes. Then comes:

Order fulfillment

This is where the real engineering comes in. Here we have multiple systems - Tulip, our order management database, and a bunch of scripts & custom hardware to round things off.

So, two videos!

I gotta say - it's a pretty cool process :)

The Public Radio's inventory dashboard

Every few weeks since The Public Radio went into production last summer, I've been struck with a pressing - and often urgent - need for some new and/or improved business or operations tool. One recent occurrence was particularly pressing, as we've had a few (ultimately manageable) inventory issues and are facing continually more complex logistics: We needed to know more about what parts and assemblies we had on hand at any given moment.

The Public Radio is assembled, programmed, and fulfilled from two locations: Worthington Assembly (our contract manufacturer and PCBA house in Massachusetts) and our corporate headquarters (a.k.a. my basement). The materials we use come from China (our speaker, potentiometer, and a few other electronic and mechanical components), Taiwan (our lid), a few stock component distributors in the US (our jar and a few SMT components), and a few custom US manufacturers (our box, and for radio station orders some laser marking on the lids). Some of these parts are used by Worthington to make our PCBAs; some are used to make our mechanical assembly; the rest are used to fulfill orders.

What we need to track is that conversion chain: Parts to PCB assembly, parts (and PCBA) to mechanical assembly, parts (and mechanical assembly) out the door.

For my current purposes, there are three events in this chain: Receive inventory, Create mechanical assembly, Fulfill order. (Note that I'm ignoring the components in the PCBA at this stage, and instead simply tracking the PCBA at the assembly level.) The first of these happens every few months and can be done manually, but the latter two will happen something like ten thousand times this year; it simply needs to be automated.

Luckily, our entire manufacturing process runs online. Our order database runs on Heroku, and each manufacturing cell needs internet connectivity in order to process orders. As a result, I had a perfect opportunity to build a quick and dirty cloud based inventory dashboard.

As these things go, I ended up only having a few days to build the system, and I was pretty sure that the early data would need a good amount of ad hoc massaging (i.e. I would need to use a database that could be manually edited whenever inventory needed to be reconciled). So, Google sheets it was :) 

With manual edits being sufficient for receiving (and reconciling) inventory, what I still needed was a way to record inventory events and then send them to Google. The result was two scripts:

• The first records inventory events in a CSV that's stored locally to the event (on the manufacturing cell's Raspberry Pi). Each record contains a timestamp, the event type, and some username (either a string that's passed in as an argument or the Pi's hostname, which is unique).
• The second script parses the CSV line by line and updates our Google sheet for each inventory event. 

Our Google spreadsheet contains many sheets: One for each inventory part/assembly, and a dashboard which sums up the current stock on hand for all parts/assemblies. As a result, our second script needs to make multiple updates for each line in the CSV. This took a bit of fiddling to get right (note: appending rows one by one is slow), but now the whole process only takes a few seconds, even with 1-200 events (which is about what one manufacturing cell can do in a day) to update.

The result is simple, but powerful: A real time (or nearly real time - the second script currently runs once a day on a cron task, as there's really no need for more granular data) dashboard showing on hand inventory of 8 different items:

Critical levels all over the place. But also, just in time!

This will eventually get a few updates. The most important one is to track inventory of the two manufacturing locations (Massachusetts and Brooklyn) independently - a relatively easy task. I'll probably also create an interface for reconciling inventory, which is currently done by manually adding reconcile rows (instead it could probably be done by removing all old inventory events and adding a single "starting inventory" row). Lastly, there's a high likelihood that the work being done in the inventory scripts ends up being integrated directly into Tulip, which is already handling the vast majority of our operations.

But even without those improvements, these two simple scripts form an incredible tool. 

A year of commits

For years - through at least my three most recent jobs - I've wanted to write more software. The desire has been vague at best, driven partly by curiosity, partly by FOMO, and partly by wanting to be more personally effective - to be able to do more stuff. My jobs have supported me in broad strokes, but in my experience real progress occurs in times of real need, and ultimately my (nonexistent) skills as a software engineer simply haven't been on anyone's critical path.

Until 2017.

2017 saw a totally new pattern of work. At nTopology, I spent much of the year building an integration between Element and Abaqus, using the workflow to optimize material use on metal 3D printed lattice structures. This laid a good baseline of commits, mostly during weekdays. 

Later in the year, as The Public Radio's operations spun up, my commit frequency jumped significantly. Some days see dozens of commits, as I pushed in-development code from my laptop onto one of the Raspberry Pis we use to fulfill orders. This is a somewhat weird process, and I'll admit that it has the effect of juking my stats. But I'll also note that a lot of these commits occurred on weekends, which feels like it should balance my credibility out a bit.

It's yet to be seen if 2018 continues this trend. I'm still no developer, and the level of complexity that I'm able to take on myself will probably remain pretty low. But it's nice to see some progress :)

Logistics

Over the past few years I've become fond of defining manufacturing as follows:

Manufacturing is just people
doing things
again and again
in a predictable way.

One of the main reasons The Public Radio exists today is that it's an effective instrument for honing our skills at manufacturing engineering & management. We've seen our volumes jump an order of magnitude a few times now, and each time our manufacturing skills have needed to evolve. But to a large extent those evolutions have been incremental, whereas upgrades to our logistics have followed a step function.

As suggested in the definition above, manufacturing is (perhaps more than most people believe) mostly about people; logistics is similar. But logistics, being transient, requires trust among parties that will never fully get to know one another - and that, by their very nature, are separated at great distances.

Two TPR shipments make their way into the US.

Logistics also requires tools that aren't common in a shop (maps, week-of-year calendars) and is subject to delays that are often incomprehensible in their complexity (port labor disputes, weather, harmonized tariff schedules). And worse yet, logistics companies often impose strict firewalls between customer service and operations - making one's own self-eduction all the more frustrating.

That said, the magic of it - planning out a three month long production cycle and seeing it come together at the end - is remarkable. 

(He wrote, as he waited for packages to show up from around the world...)

A good, old, tool

In early 2009 I purchased a used (and nonfunctional, at the time) Abene VHF3. It was a rite of passage: The machine was over 40 years old when I bought it, and at the time my knowledge of machine tools was tenuous at best. But I wanted the challenge, and I had decent intel that the VHF3 was a good machine, and (perhaps contrary to popular belief) the internet provides thorough documentation for even obscure machine tools. 

In retrospect, the experience was transformational. In addition to the mill itself (and in addition to the way wipers, bearings, oil, tooling, and other sundries needed to restore a machine that's probably been sitting for a decade), I purchased gallons upon gallons of kerosene. Stripping the machine down to its core components - and stripping every bit of caked up lubricant off with kerosene - took about a month, during which time I learned not only how the machine worked but also how to navigate a good portion of industry as a whole. Simply purchasing the right lubricant would require a half dozen phone calls, a purchase order, and a drive up the island to some sleepy distributor. Replacement parts aren't just unavailable; they're totally undocumented, lost in some Swedish file cabinet. 

On the other hand, this was a tool; a machine. Its complexity only went a few layers deep, and given a week or two almost any problem I came up against was tractable. And the more I worked on the mill, the more I realized that it would eventually make the things needed to improve itself.

It was a beautiful machine. It was strong, versatile, and capable of precision work. In the right hands it would have put in another century of service. But ultimately, mine were not the right hands. I sold it a few years later, and since then have not had a shop space that would support a tool of its caliber. 

I'm not sure when I'll own another tool like it. It was a treat: Empowering, challenging, terrifying at times. I recommend the experience thoroughly.

The Prepared - Call for sponsors

Over the past year my little manufacturing newsletter, The Prepared, has grown up. It's bigger; it's gotten a bunch of design improvements; it started a podcast, got a real website, and has had a series of excellent guest editors.

So as 2017 comes to a close, The Prepared is officially looking for ongoing sponsors.

Sponsoring The Prepared gives brand and product marketers access to an extremely high value audience. It's easy, cost effective, and reaches engineers, managers, and operators at the most interesting companies in the world today.

If you're interested in exploring an ongoing sponsorship, get in touch! 

A Cell

This has been fun:

View fullsize

This is The Public Radio's manufacturing process development cell, and with it I've built and shipped hundreds of lil' mason jar radios over the past month. 

As I wrote in The Prepared recently: 

TPR is a side project, and the vast majority of our process development this summer was done either on my kitchen table or on my desk, which had been pushed over to the side of what was once my office to make room for our baby's play room. But as the complexity of what I was doing increased, and as I accumulated stacks of cardboard boxes and started really tripping over all of the ethernet cable, I finally admitted that I needed to move myself into the basement and set up a proper assembly station.

In retrospect I was silly for waiting so long to make the move, and despite the low ceiling and the lack of natural light and the hum of the dehumidifier it's clearly a superior workspace. This is partly because I can implement a bit of maker time there, but mostly because it helps my empathy towards the folks *actually* doing our manufacturing. 

The hard part is knowing just how much of the work I need to do. And to be honest, I know that my own sense of empathy grows in proportion to my tendency to think that I've figured out the right way to do the thing, which is not something I like to bring into a relationship with a contractor. I prefer to delegate completely; to trust everyone in the process to bring full responsibility over their domains. I'm working on it; it's a process :)

A few additional notes:

• Making customized-to-order products is *hard;* anyone telling you otherwise is either inexperienced or has some ulterior motive. We've put a *ton* of time into our order management and manufacturing operations systems (s/o to Gabe for the former and the whole team at Tulip for the latter), and there are still a lot of edge cases and error checks that I want to build out. It's either "you need humans with judgement on the assembly line at all times" or "you need to think through every single problem that someone would use judgement for and build its decision tree into your manufacturing system." It's *hard.*
• I've always been a stickler about workplace organization, but setting up an assembly cell (where tasks are discrete rather than general and will be performed thousands of times each) brings up ergonomic issues that I have never had to confront. Of particular frustration is basic stuff like the way that countertop height interacts with stool height (and, optionally, footrest height).
• If you're responsible for maintaining your product's (in our case, physical + digital) manufacturing tools, you should expect to be intimately involved in building thousands of units before handing the process over to someone who isn't a competent troubleshooter themselves. We needed to ramp up quickly, and rolled out to our CM a bit prematurely; the upshot is that Tulip an be updated on the fly and the majority of our physical infrastructure is purchased from McMaster-Carr and Amazon.
• Torque limited electric screwdrivers are great. Also, stackable/hangable parts bins. If anyone has experience/tips for easy + affordable conveyor or onramp/offramp systems, LMK ;)

Since writing the above, we've come over the hump and are now focused on holiday orders. This has required a lot of energy, and has largely sapped my ability to  post updates here regularly. BUT never fear! We're posting semi-regular updates on The Prepared's podcast, and will have a bunch more interesting stuff to share soon :)

In the meantime, enjoy this twelve minute video of me building TPR boxes:

A month or so of TPR work

The Public Radio is in preproduction.

First: I spent part of week in Taiwan, Shenzhen, and Dongguan in late June visiting a few of our component suppliers, and parts started trickling in at our manufacturing partner last week. Proof:

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

A few notes here:

• A huge thanks to Lucas, who came with me to the speaker factory and was just generally a hospitable guy while I was in Hong Kong & Shenzhen. Thanks also to Kuji for showing me an awesome time (see this video) in Shenzhen. 
• Visiting our speaker manufacturer for the second time (the first time was two years ago) was great. Knowing our suppliers is a real treat, and I've very much enjoyed working with them.
• Seeing the mold for our new custom speaker was big. This was an investment - both in the tool itself and in our relationship with our speaker factory - but it makes The Public Radio more robust and *much* easier to put together. It reduces the assembly's total number of parts and allows us to use larger screws, which are easier to handle and will take less time to install. That both saves us money and makes TPR an overall nicer product. This is also the second injection molded part I've ever designed and is *slightly* more complex than the one before it, so from a personal standpoint it was *really* fun to actually touch.
• China, as always, is just mind boggling. I especially appreciated Ofo, which is amazing.

Second: Since then, I've been dealing with our remaining procurement issues (mostly logistics & cash flow planning; some vendor management) and then hammering on our actual manufacturing plan. The Public Radio has an extremely simple user interface, and to create that there's a *ton* of work that goes into managing the assembly & fulfillment process. This involves a few special things:

1. As Zach and I discussed with Gabe on The Prepared's podcast a few weeks ago, we've now got a fully custom order management database which coordinates customers, tuning frequencies, and shipping data (and a few other little things).
2. An instance of Tulip, which will handle not only our assembly training but is also acting as the connective tissue between our database and the real world. Tulip will coordinate barcode scans, assembly steps, and our radio programming jig to keep everything in sync. It also logs productivity and can help track defects down the road. In short, it's awesome.
3. Our radio programming jig. Josh is taking a crack at this (among other things :) now, and hoping to make it more reliable & robust than the ones that we used on the first batch of Public Radios two years ago. 

These three things are *just* starting to really come together this week; I've got maybe a third of it all running on my desk right now.

Next up: We should have a fully functional prototype of our manufacturing system running in two weeks. We'll be testing it in NYC for about a week, and will then bring the whole thing to Chicago to fit it into Accelerated Assemblies' processes. By then we'll have all of our materials on site and, after a short run or two to iron out any kinks, will be in full production mode.

More soon :)

On Makerism

A few weeks ago, a reporter reached out to Zach and I to say that he was including us in a list of Brooklyn makers to know. He had a question as well:  How do you define "maker"?

This isn't something I've thought about in a while, and to be honest I've never really considered myself a maker in the first place. So while I was flattered to be on someone's top ten list, my response was nuanced: 

More than anything else, I think "maker" is a cultural signifier - something that denotes a certain sense of whimsy, combined with a bit of precociousness and craft. In the best cases, makerism is simply a gateway to something else; it's a stepping stone that eventually leads to a product business or a manufacturing operation. Zach and I have put a *lot* of energy into making this transition over the past few years, and most of the other people on your list have as well.

To be a bit more blunt: I've actively eschewed makerism in my own work. Not that I don't do makery projects or like cute things. But my tolerance for whimsy is relatively low, and the things that get me excited are real, sustainable businesses, and ultimately I find it difficult to maintain a strong sense of playfulness while my primary focus is on building something.

I'm sure other people have other definitions of what it means to be a maker, and those are perfectly valid. But I'd encourage everyone, as they're working on something new, to consider whether they're actually a maker - or if they're really just building a business around a cute product.

Now, to work

In reality we've been chugging away nights & weekends for months, but it's nice to have it be official:

As I said on The Prepared's podcast a few weeks ago, it's still a bit crazy to me that people like this thing that we came up with. It's fun - a rare way for me to relate to people who are otherwise totally dissimilar to me. 

There'll be lots to share over the next few months, and I look forward to sharing it. Thanks *so* much to everyone who kicked in - we're really excited to have you with us!

The Prepared's podcast + A history of The Public Radio

Some updates!

So, I've been working on some stuff. 

First: Thanks to The Prepared's *awesome* donors, I've redesigned and relaunched theprepared.org. Awesome!

Second: In the spirit of expanding The Prepared's purview (which is why I'm taking donations in the first place), we now have a podcast! The goal of it, as with this newsletter, is to help people prepare for good work - and to share the results of the big things they've worked on. To kick things off, we've got two episodes: One with Zach on the history and future of Centerline Labs, the company we cofounded to create The Public Radio, and one with Zach and Gabe about some of the things we're thinking about on the eve of...

Third: The Public Radio's launch on Kickstarter! I'm very excited about this, and it deserves a bit of explanation:

The Public Radio started in 2013 as a longshot side project - "a product idea for a single-band FM radio," as I described it four years ago. Going back through my blog while filtering for the "publicradio" tag shows a funny story. Early on, I posted a lot of "this was my workday" posts. Then there was more topical content - my struggles finding the right potentiometer; little thoughts on how to take crowdfunding offline. In early 2014 Adafruit posted something short about us, and shortly after we soft launched. 

All of that was under looks-like prototypes; it wasn't until mid 2014 that we had a works-like, which we assembled (without SMT stencils! we were so naive) by hand. At this point the design iterations were more substantial, but it wasn't until late that year - after our first Kickstarter campaign - that things really became serious.

At this point we started getting some real attention, and a bit of backlash as well. It's worth mentioning that at the time, my days were spent consulting for Bank of America and GE on management & marketing strategy; The Public Radio was a weird thing to match that with. But it was getting *fun* - real engineering problems, real supply chain problems; real business problems; real press coverage; my first injection molded part. I was interviewed by New Hampshire Public Radio and by Matthew Lesko, the guy who wears the question mark suit on old '80s infomercials. 

And then, all of the sudden, we (with the oh-so-gracious help of friends/family/indentured servants) shipped 2500 radios to people all over the world. We missed our Kickstarter shipping goals by about a week; pretty good.

Almost immediately afterwards, we went to China to plan for v2.0. We visited our speaker supplier in Dongguan and roamed the Shenzhen electronics markets, and did all of the other things you'd expect. But as we were heading back to the US, my day job was in the process of vaporizing, and for the ensuing two years The Public Radio has largely been relegated to the odd warranty email.

So, this relaunch. The thing is, The Public Radio is a good product, and we want to find a way for it to live on. This is harder than it sounds. No matter how much the traditional supply chains are being (*cough*) disrupted, it's still really hard to run a hardware business in your spare time. The Public Radio is an incredibly simple device - intentionally so - and yet it's real work to get it made.

But we're trying anyway. We've got a pretty nice plan here - one that keeps TPR lean on capital requirements, keeps our supply chain short, and (most importantly) makes for a really nice customer experience. There's a lot to unpack here, and you can bet that I'll be sharing more here in the next few months :)

Anyway, that's that. Please, check out The Public Radio on Kickstarter and share it!!!! They look great, work great, and make for *excellent* gifts. And as we build out our manufacturing process, you'll be right there learning about it with us!