How to not fuck up your manufacturing startup

I was part of the founding team of a power electronics startup. We constantly tore down our competitors' products to estimate their costs, to see how they corrected design flaws between releases, and also to understand which component suppliers they chose to include (this is a proxy for passing their reliability testing).

I read the wikipedia page and that "what is TRIZ" article, and I still don't understand what it is. At times, it sounds like an automated program (especially with statements like "More than three million patents have been analyzed to discover the patterns that predict breakthrough solutions to problems"). But at other points, it seems like a human-centric problem solving strategy, but without the strategy. It describes problems and then solutions without any discussion of the in-between.

Do you have experience with TRIZ? What "is it" to you?

So wild! Such a surprise to find this on the front page of Hacker News. If it weren't for the author's username, I might have missed this gem.

I had worked at Edenworks as a software engineer for a few years, alongside Johnny. I don't pretend to know enough to speak on manufacturing itself, but Johnny's remarks on software development are spot-on.

When I had come onboard, I had naively suspected a typical software startup experience; rampant technophilia with an obsession for integrating the freshest software technologies. If 'Software is King' is true everywhere else, why shouldn't it be true here?

Edenworks is not a software startup, however, and it's important to realize that. Manufacturing is an entirely different beast, which makes steady, deliberate movements (i.e. it doesn't move fast, and it shouldn't break things). When the main product being developed is a tangible system, redos are way more costly. Adding flashy software features does not expedite this; lashing the latest and greatest Javascript library onto the fronted does not add value... not reliable value anyways.

When it comes to developing a manufacturing process, software should be flexible and let the process demands come first. The typical workload is more concerned with running test trials than hacking up something new.

For me, this realization was more emotional than organizational - sometimes you have to curb your hype. To add real value to the product, I had to watch my ego. In a manufacturing company, the Process is King.

>> "...No need to retool for the 2017 Lettuce."

These indoor farm outfits have nothing to do with lettuce. There's a reason they're building them in/around NYC, aka in the densest concentration of pot smokers the world has ever seen, far from Humboldt county's fields and Colorado's manual hydroponics.

The business model is just to get the automation figured out with some low-value crop, e.g. salad greens, while waiting for the legislature to decriminalize. The day Albany finally comes around to the idea, they'll retool for sticky green weed faster than you can pin up a Bob Marley poster.

It'll take them about fifteen minutes after the governor's signature dries to get the first pot plants started. The economics could not possibly work out for lettuce alone.

They teach you this stuff in product design classes.

TRIZ is a way of breaking down an engineering design problem into the thing you want to change, and the thing you can't change (a "contradiction"), then resolving it. A "TRIZ Matrix" is a reference tool that suggests ways of resolving conflicts between common design parameters (strength, weight, durability, manufacturing tolerance, etc.) based on a number of principles that have been validated over the years, like "nesting" or "prior action". Over the years, 40 standard principles (and 39 parameters) have emerged. They all have somewhat cryptic, consultant-handbooky names but make sense when you see some examples[1].

E.g., you have a beam and you want to make it stronger, but can't make it any thicker. You consult your matrix for "strength" vs "area" and get some suggestions such as "use composite materials". Or, applying the principle more generally, you try to extract techniques from the patent library or publications that resolve the problem.

[1]: https://www.triz.co.uk/files/triz_40_inventive_principles_wi...