Hard Tech Startups
blog.ycombinator.com
blog.ycombinator.com
I think this is key and I hope it takes off beyond YC. I used to work on a DARPA-funded R&D project in the wireless space. DARPA's culture is really cool: throw a bunch of money at PhD program managers, give them a ton of directorial discretion, and let them fund "blue sky" projects they think are really cool. But it's a very academic mindset and the mission creep is huge. DARPA kept sending us down these "oh can we do this?" rabbit holes. At one point our radio grew an expert system that processed XML-formatted regulatory directives.[1] We spent huge amounts of time doing things other than solving the core problem. A decade later consumer deployment is still a ways away. It would be so much further along if DARPA had the focus of something like YC.
It seems like a no-brainer to those in Silicon Valley that you should find a tractable subset of your problem and pound on it until you've figured it out. That's not the way the big research institutions working on "hard tech" usually operate, and it's not really how major research universities teach people to think.
[1] https://en.wikipedia.org/wiki/DARPA_Agent_Markup_Language
Though that can be a bad thing. You don't want to be in a position where your DARPA project ends but VCs aren't ready to look at you yet.
That happened a couple of times during my first stint in VC in the mid-2000s -- ideas pioneered (and often reduced to practice) at PARC or other pure R&D facilities were finally finding mass-market or industry adoption.
The very interesting thing about DARPA is how its management is structured so differently from every other government agency. DARPA has a $3 billion budget with a staff of less than 300 people who are mostly project managers and administrative staff (compare to NIH - $30 bil/20,000, NSF - $7 bil/1,700, or NASA - $19 bil/17,000). By policy these PMs have a strict term limit of four years and the only DARPA PM I know of that served a second term did so over two decades after his first. These PMs have scientific advisory boards that don't have any term limits but the mandatory turnover for management means that they come in with clear goals and deadlines that seem to remove career advancement out of the picture (although to be fair, most DARPA PMs are way beyond worrying about their career prospects). No other government agency works this way and it has paid dividends not only for our defense but for technology and society as whole.
Unfortunately there isn't a DARPA equivalent of https://spinoff.nasa.org
Imagine if during the Mercury project, someone threw in: "oh, and while we've got someone in space, we should do a spacewalk too."
The ability to produce AI tuned opportunistic spectrum allocation could have far reaching implications in fields outside of spectrum analysis. Many of the biggest problems faced by modern organizations is dealing with beaurocracy while efficiently allocation resources. Maybe this never lead to anything, but then again who knows if this could lead to a whole future field of efficiently scaling large organizations ... Take a look at the outputs of undirected DARPA funding and the results still bearing fruits decades later: computer animation by people like Ed Catmull (culminating in Pixar), Alan Key and object oriented programming, tcp/ip, etc. The bigger question of whether this side project could yield fruit has more to do with the type of team environment of the project and whether the pursuit came from a genuine "I wonder if...". E.g. One of the best predictors of the useful of such blue sky discovery is whether there's a large element of "this seems fun/intruiging!" as appeared to the driving motivation of Ed Catmull when he invented texture mapping.
And thanks for the links! I'm actually _very_ interested in reading these papers. There's been a lot of intruiging work and research on type-valued types (c.f. Iris programming language). But there's a difficulty of describing and translating rulesets from various vague human logic into effective computer passable rulesets.
As a separate follow up project; not as a sub-project that stalls the main project (which is how it will be done since "What else are we going to do with the money? Doing the boring work of ironing out the kinks in the main project?").
What's the evidence for that? The Idea Factory, a history of Bell Labs, claims that it was originally "system engineering", back when America's phone network was called the Bell System. Of course, there was a lot of overlap between Bell Labs and NASA. Echo, Telstar, transistors and so on.
I think this post has it right too in that finding a small application of the technology is a good approach to sustaining yourself while you get to a bigger goal. This however adds a magnitude of complexity - which means funding requirements aren't that much smaller. For example you have to build a product while also building the technology - vs just building a product on exiting technologies, which is hard enough itself. It's also a risk because if that one product is not a winner, then it poisons the larger play - even though it might be itself very valuable.
The challenge comes when you have to explain that, no actually this first thing is just the POC for a larger thing we're trying to do - especially when you are building the market for that larger thing.
I think the best path for hard tech companies is to have a lot of money from the start. I know that sounds obvious, but I think it's true specifically for hard tech companies.
Unfortunately that usually means you as a founder are a known entity in the venture world. Whether that means you use your own money from a previous exit (like Musk) or convince someone to fund a lot of it (probably because you had a previous exit and have connections) you need a lot of capital up-front.
So if you are an unknown to the people with cash, with hard tech plans, prepare for a tough time ahead.
> Very often, the first thing we do is help hard tech founders find a small project within their larger idea that fits the model of quick iteration and requires a relatively small amount of capital. This project is often the smallest subset of their technology that still matters to some user or customer. It may at first look like a detour, but it’s a starting point that lets founders build measurable momentum–for themselves, for recruiting employees, and for attracting investors.
Edit: The realtime 3D object placement in the demo video [1] is incredibly cool. I've done enough computer vision to realize you have some non-trivial technical work, but I'm not sure if I would label it hard tech personally. I think the gray area is all around the real-time constraint.
So far it is working - but as you say it is a real pain point.
The biggest problem we have is that venture people focus on our first product only so they are looking at traditional metrics such as MAU, Revenues, exits etc... which is reasonable if they assume that Pair the commerce platform is all we ever want to do - nothing else we are doing seems real to them. In theory, the commerce platform alone is a big product, but it's maybe 1/1000th of our whole stack we're building.
but I'm not sure if I would label it hard tech personally. I think the gray area is all around the real-time constraint.
Without going into a long technical explanation, our mobile monocular SLAM implementation, semantic segmentation, structure from motion and relocalization (loop closure) systems are firmly in the Machine Learning/Hard Tech sphere. Our team is ML/CV people and we're focused on building fundamental infrastructure for future computing platforms.
None of that is obvious from our marketing materials - because it would just be confusing for those in our first market/vertical.
As I said before, this approach is doubly hard than building just a product because you have to build it on top of all the other stuff.
Trust me, if I had 10s of millions of dollars, we probably wouldn't be working on this commerce platform (even though we have had good success and it's a great tool.)
The video reminded me of Ikea's virtual furniture app [1]. Tech-wise the comparison is superficial, as your tech is so much harder / more sophisticated, but my first thought as a consumer was "sounds like an iteration of that".
I wish I had suggestions. Computer vision research on the edge is hard x starting a startup is hard. That's tough. Maybe someone else will have more insight.
[1]: https://www.wired.com/2013/08/a-new-ikea-app-lets-you-place-...
I am sure it was hard for you guys but aren't these systems no longer technical unknowns? There are lone PhD students who managed to build them and open sourced their work. [1]
This is no longer hard in the sense of "I'll need a research team and five years -- and we might not figure it out." It seems like it's just academic technology transfer where you need people who can read the latest papers and implement them.
[1] http://vision.in.tum.de/research/vslam/lsdslam (The author is now at oculus research)
Notice also that those systems are built for robots and standup machines to run it, not mobile handsets. Sounds like a small difference if you aren't in it, but it is critically harder, so the approach is actually different. It's not about just "reading the latest papers and implement them." Somewhat offensive to assume that is the case. I'd challenge you to find a mobile monocular SLAM system that is up to our capabilities, let alone usable. They have all been acquired (Apple, Facebook, Intel). The reason you can't just copy paste implementations is because they are non-deterministic in optimization.
Second, SLAM isn't the only thing we do. In fact it's not even the hardest thing we do. The majority of what we do isn't something I'll go into in depth, but it actually falls into the category of "I'll need a research team and five years -- and we might not figure it out" - though now we're in year three and have made enough progress that it's starting to come out of the realm of "we might now figure it out."
I wouldn't take too much offense to it. From my (much smaller) experience in computer vision and pattern recognition, everything in CV sounds easy until you actually do it AND make it work in the real world. Real data, poor lighting, low contrast, realtime, etc. There are just so, so many factors that make this an extremely challenging field.
When I was in grad school (2012–2013) the textbooks we used said things like "generalized object recognition is an unsolvable problem". In a lot of ways since then "unsolvable" problems have been solved. The field is just changing so rapidly.
Put it this way, when you buy a car, the difficult part for the manufacturer wasn't the customer-experienced design of the car, or even the driving concept. The hard part is designing the assembly line, and designing the car in such a way that 100,000 of them can be put together such that the assembly of each individual piece takes exactly the same amount of time, otherwise there are assembly line stalls. Then you also have to design, or at the very minimum optimally position and program, the machinery to put the pieces together, organise supply chains, deal with subpar contractors whose quality changes even if they are delivering theoretically the same product, etc.
Seriously, I have done my time in the CV space, and it is a lot easier than real world hardware, even if CV is still being explored, just because of the distribution and replication of a finished product.
Is there software that solves this problem of factory layout? Why or why not?
I too have worked hardware and on those projects we could get fairly low level line workers on assembly up to speed quickly, source our parts in a repeatable fashion and build systems to scale without too much brain power. Not easy, but more logistics management than creativity.
With these non-deterministic CV systems (for example point cloud generation) the path to working is much less clear.
I'm not saying one is harder than the other, but the class of unsolved problems in CV/ML doesn't have off the shelf solutions, so they pose different but similarly hard problems as hardware.
Pair3d looks really cool -- I've been making a list of neat industrial uses of computer vision tech and virtual showrooms isn't something I'd thought of.
A friend actually did something similar the hard way -- he and his fiance were apartment shopping in nyc, but the apartments were empty and they were having a hard time visualizing what they would be like (less spacious, for starters) with furniture. So they cut butcher paper into pieces the size and shape of their major furniture and laid it out in the apartment to see what it would feel like with their couch, bed, etc in the apartment rather than empty.
Feature extraction (AKAZE, BinBoost), matching (GPU brute force hamming), RANSAC (with PROSAC and relatives), bundle adjustment (Schur Decomposition with LM), point clouds (SGM, PatchMatch) and mesh (Poisson, FSSR).
Each stage has tuning, and real-time requires sacrifices on the hardware we have available, but we know with better computers we can have it. (HSA has me drooling, hurry up with Zen, AMD!)
IMO the harder stuff is in semantic segmentation of point clouds and dynamic scenes, but I have high hopes for the next few years.
lol, hey it's hard enough to do with static images. Feature matching pointclouds is probably turing complete :P.
That's the kind of shit we're working on though. We're trying to turn the real world into a platform.
It's one of those things that we can do efficiently, so with enough priors of what scenes look like a sufficiently informed ML system should be able to get decent accuracy.
Some people think YC only funds software startups."
Kinda strange that software is not seen by YC as "hard tech".
I think there's lots of hard tech in software but the way venture capitalists/angel investors tell it, you should only ever build software that can be made in a weekend and then iterated upon.
The outcome of this is the X thousandth dog walking social network for uber drivers staying at AirBNB - i.e. stuff that you can build in a weekend and iterate on. And this is why demo days are full of such lightweight software applications - people are actively discouraged from taking the time to build something large scale and, well, "hard".
Sometimes it makes sense to make a big bet on building some complex software that might take months or years to build, with lots of moving parts, but once complete solves a big problem. That is software that is "hard tech".
.
I think "hard tech" in this instance means "technology in the form of hardware" or "technology that is physically manifest" and not "technology that is difficult."
> [1] I use 'hard tech' to mean a startup is whether there is doubt that the technology can be built at all.
Edit: I'm glad he defined it for this post. In general though, there's definitely ambiguity around the term.
[1] I use ‘hard tech’ to mean a startup where there is doubt that the technology can be built at all.
It’s relatively easy for a software startup to take short cycle times and low-costs to an extreme, but hard tech founders are often surprised by how effectively they can do this, too.
What I think he is really referring to as "hard tech" is the move from the consumer electronics and office automation markets to the grittier, less-visible industrial verticals: Automotive, industrial, energy & utilities, aerospace & defense, etc. Verticals which have generally been dominated by a GE/Siemens/Boeing/ABB/Schneider etc. due to the high R&D costs needed to realize a certified, generally safety-critical solution in a highly bureaucratic environment.
Dropbox is down for a few hours? We'll have a few pissed customers. The ADAS system in a customer's car failed momentarily? They'll be lucky to survive and massive lawsuits/loss of business could ensue.
As an aside he should really define key terms up front to avoid this sort of confusion and to allow us to focus on his main point: YC is trying to move into and disrupt this lucrative but hard-to-broach space.
(But seriously, at least in theory, there are sort of obvious things you can do to isolate anything failure-critical behind statically or dynamically checked contracts, which then allows rapid iteration outside of the small set of things that are truly failure-critical. But you need those contracts trustworthy enough that you can iterate without worry, flexible enough that you can iterate on economically important sub-components, and applicable to a system or set of systems where this iteration gives you the trump card in a billion dollar(s) industry. As I said, it's "hard tech" -- which almost by definition means some people will think it's impossible.)
I really challenge the accepted wisdom of "build something tiny and iterate" as being the only way to build software.
Even with things like nuclear energy and particle colliders I'd guess those who succeeded probably started small and iterated.
[1]: https://en.wikipedia.org/wiki/Software_development_process#A...
(I disagree on the premise, BTW. I saw a number of successful machine-learning systems at Google, and the most successful were always the ones that combined machine-learned functions - sometimes many of them - with traditional algorithms. AI is a tool that extends the reach of software into new problem domains, it's not going to replace software itself.)
Accepted wisdom remains accepted until eventually people start to realize that it's not entirely correct.
Obviously in reality, things are a lot more nuanced than 'always', but when your goal is to help as many companies at once, where the degree of experience varies, it often help to simplify the problem. In one-on-one situations, the partners can give you more personalized insights and in general are quite insightful.
It's hard to be positive of causation, but correlation (long time to initial customer contact <=> software doesn't make customers happy) is pretty strong.
If you want to challenge it, you could try to deliver a successful large multi-year software projects with no prior customer engagement, and document the process. People can then make informed comparisons against the accepted wisdom.
Then wrong users can oversteer your product. For example, BigCo wants Feature X and will pay $100k/year for it, you add it but it complicates the experience for others and delays the rest of your roadmap.
Another is knowing when your users are wrong, they request Feature Y, but really what they want is Benefit Z.
Of course there's also nuance around how exactly you define minimum viable product (i.e., the part built before you start exposing it to users). I've seen experienced non-startup business people describe an entire app with every feature that they envision, then claim that's the MVP. It can be a hard model to adjust to.
The biggest (by val) technology startups that we know of (Uber, Lyft, AirBnB, Snapchat, Dropbox, Pinterest) are by no means hard tech. Even the public ones aren't hard tech (Facebook, Linkedin, Twitter). So that's what these investors look to as the types of investments that make sense for them.
The question is, do hard tech companies have similar probabilities of outcomes or bigger?
Other than that, I largely agree. The last software hard-tech company to strike it really big was Google. There've been a number of open-source projects doing what I'd consider hard-tech software, though - Bitcoin, git/Mercurial/Darcs, Bittorrent, TensorFlow, etc.
(My definition of hard tech, as applied to software, is "Software where you need to use scientific-method trial-and-error to build core pieces of the product." If you can read an online tutorial or reference manual and build the product, it's not hard tech. If you need to poke around at things, observe the responses, and build your own model of how things work, it is.)
I think that's a great definition actually and fits with how ML systems are built.
This, IMHO, is a really bad example.
This is pretty much just a few days of sitting in GDB for the right engineer[1]. Now, maybe it require people experienced with debugging tools, but it's really not "hard tech". Now, productionizing it so it works on all versions, yeah, a bit trickier. but again, none of this is at the level of basically "understanding how to make custom bacteria that do a thing", etc. If this is the example you mean for "did stuff people assumed was impossible", then i strongly disagree.
""Software where you need to use scientific-method trial-and-error to build core pieces of the product.""
This, IMHO, is way too low a bar. By this definition, the clang compiler we built for windows is "hard-tech". While it requires time and energy and trial and error, that is not hard, in the same way the dropbox stuff is not hard.
It is known that it is possible, and requires the reasonable application of good engineering skill. That engineering skill may often involve the scientific method trial-and-error, but you know you will eventually get there.
The same is true of dropbox, and in particular, your finder example. The only thing unknown is the timeline, and even that you can take a reasonable stab at if you have good enough engineers.
[1] I did it before they did, and i wasn't even the first. Plenty of people have made this happen :)
That's why I prefer to put the dividing line at "must figure out things by poking at them rather than by reading documentation". The definition of "research" can be pretty vague - is a security team poking at a product conducting research? How about a UX team trying to figure out how their users behave? A search team doing language modeling? All of these would count in my head, and if a startup built their product around one of these results I would consider it "hard tech", but evidently not everyone agrees.
Someone potentially had the answer at one point. That person/organization may be dead/defunct, or the knowledge may otherwise be lost to time.
[1]: http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.109.4...
Dropbox, BTW, was 4-5 engineers and 1.5 years.
[1] Actually more like 4-5, Larry & Sergey had help.
Hard tech = "There is doubt that the technology can be built at all."
Though many pieces of technology face huge doubts, what's key is often a team can get to a working prototype or partial release in way less than 5 years! (E.g. Dropbox.) YC is exactly the type of environment to refocus a 'research style' team exclusively on demonstrable progress.
The problem with the xkcd definition (if attempted in a startup) is very few research teams can continue to fundraise for 5 years without a product or significant prototype.
A partial solution to the "doubted" tech is often good enough to build a great company.
As someone sort-of familiar with gdb (but not extensively so) I have no idea how I'd do that. Can you point me in the right direction?
Use dtrace and create a lot of such events. They're presumably using kqueue or some event mechanism to be notified when the file arrives. Do this with many file types if they look different in Finder. Somewhere in there should also be a read that corresponds to the dirent. You can break on these things.
attach the debugger and create the events. Step through the code to find when these things are read. Attempt to discern how what is read differs between file types. Do stuff like make files with conspicuous attributes (e.g., file size), because it's easier to correlate from traces. The data is probably a file containing file metadata somewhere.
This is probably mostly looking at the bytes coming off the read. dtrace makes this easy because you can trigger it to set a flag when the kqueue event fires and then just dump bytes and locations from file reads/opens. If it's more integrated into the OS Finder would have to have its own special syscalls to read stuff off inodes or whatever. You'd be able to see those happening too.
Once you think you know how it works, give it a try. Rinse and repeat.
Now it may be you have surprises here and there and it's kind of annoying, but I'd be surprised if I couldn't do it.
* jvm -- it wasn't clear you could build a vm that was fast enough to compete with c++;
* c2 compiler inside the jvm -- also not clear you could do this, fast enough, or one that optimized enough to care about
* azul systems / zing -- could you build a gc that tolerates terabit allocation rates w/o stop-the-world pauses?
IMO, the only thing on your list that comes close is the Azul GC which, in my limited understanding, actually advanced the state of the art.
1. Tesla (Market Cap ~$29B w/$14B+ in pre-orders) 2. SpaceX (Valued north of $10B) Elon's companies faced massive doubts about tech feasibility, both when started and at basically every-point since.
3. Oculus. Sold for $2B in March 2014, including $1.6B in FB stock that's now worth 2x more.
4. Machine Zone The messaging platform for Game of War/Mobile Strike is very "hard tech". (Google/AWS still lack equivalents and MZ was kinda forced to take a "time out" to develop it.) In 2014 the WSJ said they where fundraising at close to $3B and now their cash flow powers global TV add campaigns.
5. Cruise. "Hard Tech" and a big win for YC.
6. Zoox. They started w/a prototype and have made huge progress.
Many new business lines at public companies faced huge doubts about tech feasibility and are now clear home runs:
7. Nvidia Every new chip is "hard tech" and they've grown massively in the last decade.
8. iPhone/Apple + Android Inc. Smartphones are really, really, "hard tech". So many doubts on both the tech and product side are now forgotten!
9. Google (mentioned by others) In addition to search/adds/Android, I'd say maps/gmail/infrastructure/android are all examples of "hard tech". Each was viewed as "hard tech" when released. (Contrast Google Maps w/Apple's disastrous maps launch years latter.)
10. AWS If you had pitched AWS as a startup, in late 2003, you would have faced lots and lots of technology skepticism. A phenomenal success.
11. Amazon Echo Hard tech, took a massive team to develop. Doing great as a product.
Crossing "the valley of death" in commercializing new tech is really hard. But there are vast success!
If your mocks were sufficient for gathering user feedback, that may be okay. I've certainly seen groups with no written software place in the top 3, off of designer mocks alone.
If the judging panel is less technical, you'll have to sell your idea differently. I've seen cool tech hackathon projects fail because of bad presentations, either because they're ineffective or they just didn't practice. It's kind of less than ideal that you're judged for the whole weekend based on how well you can sell in a 2-minute pitch, but then again it's not all that different from the real startup world.
And remember, it's a weekend: the "winners" typically don't turn the project into an actual startup.
I think of like in school, you can learn because you want to know things or you can learn to the test because you want the mark to move on.
Would you rather build something hard or build something more likely to win? From my experience, it's not the same apps that do both. I also don't think one approach is necessarily better than the other, just personal preference, plus also depends on the team dynamic you end up with. For example, I wouldn't try to solve a hard tech problem on a team with mostly non-tech people because their expectations can be unrealistic. But if my team is 3 experienced startup engineers that can iterate, well why the hell not?
perfectionists don't
Yay, business interests.
Perfectionism should become a skill, not just a characteristic.
There are other issues at play, of course. In cases where quality and business profitability are strongly aligned - think avionics - then there is plenty of high quality software.
I disagree.
Looks at any exploit database. A large percentage of the exploits on any typical day are the sorts of mistakes that a well-educated developer wouldn't make, or that best practices and modern tooling would prevent.
That's not even a cost/benefit problem, because in many cases there's no additional cost to doing things the right way. It's a culture and education problem[1].
[1] by which I do not mean traditional university education, fwiw.
At the risk of splitting hairs... there are costs associated with finding developers who have this education and/or fostering a company culture where security best practices are important.
If software companies were seriously punished for compromising PII, then I imagine we'd see a change.
And much of the discussion about technical debt, about "the web toolchain sucks", or "operating systems suck", or X, Y, Z, they all suck... so often, I think that's just a different way of saying "we have this really hard problem, and we've spent decades piling really innovative partial solutions to it on top of other really innovative partial solutions, but nobody has come along with something that really, really works." And it's a tremendous problem.
The response I've seen in the past is, "We love those ideas, they're just more appropriate for, say, YC research." But for hardware, the bar is automatically different: it's understood that there must be some degree of longer-term research and development that goes into a product. And I think that's completely untrue: both require experimentation, both require feedback, both require upfront work to get right. And to be honest, this misunderstanding probably stands at the core of the strongest arguments I've ever heard against the maturity of the software industry.
Could the reason be that pure software patents have a weaker status than hardware patents and/or are more difficult to enforce?
> I use ‘hard tech’ to mean a startup where there is doubt that the technology can be built at all.
> Some people think YC only funds straightforward software startups.
In general I think you are right that VCs have the bias you're talking about though. Not all VCs but many. It's not totally irrational, software that can be built in a weekend has fewer risks associated with it and can have just as much upside. However there are many very problems that are worth solving and can only be solved with complicated, hard tech, software. Investors with this bias cut themselves off from this opportunity.
If and only if, a market for such a software still exists and continues to grow when you deliver the product.
Is 3 months sufficient time for working on hard tech startup ideas. The original 3 month batch format was designed for software & web startups - YC's initial focus. It seems to me that the cycle time for iterating and testing different approaches to solving problems in hard tech would be much longer - hence require more time?
It can take up to a month to receive a specific part for a prototype, and prototyping takes a lot more time in real space than in software.
I can change a class or a module in some code and 15 seconds later have the new version running. Changing a single part in a hardware system could take a day of work, changing both the software drivers and the actual physical hardware.
You can't just NPM install a new part and see if it works, you have to actually order it and wait for it to arrive in the mail.
Tesla is my favorite example of how powerful this small project + long-term planning mentality can be. Their vision has always been to bring an affordable electric car to the masses, but they first built the Roadster—the opposite of a mass market car—to generate revenue to get to the Model S.
so designing and building a top of the line sports car is a small project? what?
So yes it is.
Remember, also, that the roadster was based substantially on the Lotus Elise, and Lotus built the bulk of the vehicle. Look at us as a drivetrain project rather than a car project and it looks at least a bit more manageable (which isn't, by any means, to say trivial).
The Lotus Elise + minor delta was the original thinking, but Tesla/Elon has repeatedly pointed out that it was a mistake; the Elise frame was dramatically reworked to the point where it would have been better to have started from scratch.
Look to GE for a prime example - a $250B manufacturing and processing behemoth rebranding itself as an agile tech startup with GE Digital and Predix rolling out across many of its factories. Its 2015 10k was titled "Digital Industrial" and really describes the company's new focus on "hard tech":
We are just beginning our transformation as the Digital Industrial Company. The Internet has had a massive impact on consumer productivity and commerce. Its impact on industrial markets is just now being realized. By 2020, 10,000 gas turbines, 68,000 jet engines, more than 100 million lightbulbs and 152 million cars will be connected to the Internet.
At GE, we have decided to generate and model this data ourselves—both inside the Company and with our customers. This is what we mean by becoming a Digital Industrial. Our Digital Industrial capabilities will expand our growth rate, improve our margins and bring us closer to our customers. There was a time when every sale had a clear endpoint, followed only by routine service and maintenance. Now, sensors on our products send constant streams of data, analyzed and translated into upgrades that drive productivity in industries where even the smallest incremental efficiency can mean very large gains. Capturing it will be a mission in every one of our businesses. Our aspiration is to offer with every GE product a pathway to greater productivity through sensors, software and big-data analytics.
Why GE? I assure you we didn’t wake up one morning with “software envy.” We have been investing in software and accumulating data for decades. Competing will not require big acquisitions. Rather, the technology required to compete is in our sweet spot. So, why not us?
Similar story if you look outside of the traditional IT market and across the embedded market. Software is being layered on top of "hard tech" to collect data and provide value in a ton of markets that you won't see covered in Tech Crunch. Or maybe you will, given that YC is now pushing for founders with knowledge of these grittier industries.
If you really have a true hard tech company with a solid idea, you are probably much better approaching industry partners than going the VC route.
If it is that good, you might not even have to sacrifice hardly any equity at all.
That's what I'm trying to do right now.
We are focusing on telecoms, utilities and large electronics corporates as strategic partners.
Early days, but so far seems like a good strategy.
Except the Roadster didn't generate enough revenue, Tesla was on the verge of bankruptcy, and Elon Musk swooped in to save the day (and have himself labelled a co-founder as part of the deal).
The Model X was supposed to be a quick reskin of the Model S chassis as an SUV to provide a stopgap model while the Model 3 was developed, but that turned out to be more complicated than expected and Musk's demands for those striking but complicated gull-wing doors caused development and production problems that delayed it for years.
I'm readying the popcorn for the delays and production issues of the Model 3.
- growth in pure/easy SW projects is stalling, need to find new areas
- trying to get away from the "bro" prejudice against SW startups
- YC has found a good way to bring rapid, iterative development techniques to hard/HW projects
Hopefully the third one but probably a combination of all of the above.
As a scientist who founded a hard science startup (and now work for another), I feel like the hands down biggest barrier is lack of access to free/low-cost space to work. These projects aren't the kind of thing you can do out of a coffee shop, it's just too dangerous. Plus it requires expensive capital outlay to do the initial work, even if you only need the equipment for one or two tests.
The fact that they partner with a national lab to provide those testing resources saves so much time and energy that's better spent on finding product fit than fundraising enough to get to the point where you can even find out how well your technology can perform.
I'd strongly suggest at least reaching out to them to see if they can help advise, they've had amazing results so far.
Isn't that just because several highly valued software startups haven't exited yet? Judging by this list:
https://www.cbinsights.com/blog/y-combinator-startup-valuati...
In fact, in her How to Build the Future talk [1], Jessica Livingston said that most unicorns have come out of YC.
Russia has operating sodium-cooled reactors (BOR-60, BN-350, BN-600) and low-power critical facilities (BFS-1&2). Using those, they can develop and test new nuclear structural materials and fuels that push the envelope. And shipping materials to Russia for testing and bringing it back for investigation is ridiculously hard. Politically streamlining collaboration is essential for nuclear progress.
The US shut down its best test reactors (FFTF near Handford, WA and EBR-2 in Idaho) in the 90s so it's pretty challenging to iterate. At least we're trying to turn TREAT back on now.
So what can a nuclear startup do? Sam is right. You have to focus on small things and bootstrap yourself up. I was an advisor to Nuclear Innovation Bootcamp a few months ago and the team wanted to build a new giant reactor in Diablo Canyon's containment for hydrogen production. Big picture stuff. I encouraged them to focus on something more specific, like technology for coupling the nuclear island to an industrial unit (hydrogen, desal, ... anything) while being able to smoothly alternate power between it and the turbine (for load following on the grid). It's a lot less glorious to work on something like that, but that's the only way to get started in this field unless you're sitting at the non-existent international nuclear tech center, or on $1B of very patient seed money.
The Internet was born out of probably the worlds most successful long term focused VC - DARPA
now I can't tell if this is the VC community going back to a long term model and invest for decades before expecting a return. 11 trillion would do a lot of good invested for ten years in the globes best and brightest
If we don't know if the tech will work at all (fusion etc) then YC is effectively funding academic research. Which is fine, but I assume the right way to build a business may not be the right way to choose the next research project. Gittens index notwithstanding
Are these businesses measured in some way differently to the next Uber? Different P&L expectations, different pool of funds? If not then ... ?
Also, I can attest that is extremely difficult to build a startup with a heavy research focus. However, from the brief write-up presented, I don't see how YC is in the position to help build and scale hard tech startups at scale - especially those with a tremendous need for capital invest to further research and manufacture.
Just consider what $120K buys you. Barely one mid-level engineer for a year (don't forget the taxes, social security). In that year you would have to create and mass-produce and sell the product, just to keep paying the salary.
I'm surprised YC doesn't offer something like $500K for 50% of the company.
That $120k is intended to last 3 months, not 1 year. And afterwards most companies go on to raise 7 digits for much less than 50% of their companies.
It's something I've long wondered but it's never been answered to my satisfaction.
It's great money if you have all the time in the world and really like writing grants. Or if you have no other choice. But you will pay for it with your time. Also, you will be at a huge disadvantage unless you have a PhD and university contacts. Writing successful grants is a difficult skill that takes a lot of practice, and you will be competing with people that ONLY write grants.
There was a time, pre-2000, when VCs did almost entirely "hard tech" startups. VCs were more profitable then. But the weakening of patents by the anti-patent lobby has made this infeasible as a business strategy. You have to buy market share now before someone steals your technology.
I still think that technology risk tends to be underpriced by VCs today. The pendulum's swung too far, where everyone assumes that the tech is just a commodity and what really matters is how many Facebook ads you buy, and that's left several openings where consumers are not consuming because existing solutions suck too much.
In that light these businesses were easy tech but hard Businesses that ended up being worth a lot: Ebay, Amazon, Uber, AirBNB, Dropbox, and more.
EDIT
10 of the top 15 Unicorns
Uber - Not Hard Tech
Xiaomi - Kind Of Hard Tech
Didi - Not Hard Tech
AirBNB - Not Hard Tech
Palantir - Hard Tech
Snapchat - Not Hard Tech
Wework - Not Hard Tech
FlipKart - Not Hard Tech
SpaceX - Hard Tech
Pinterest - Not Hard Tech
Dropbox - Not Hard Tech
This is a great way to build a company, because you have real data about which scaling problems are actually important, and a real operation to incrementally test solutions in.
One of the hardest things for people that have never started a company before is to understand just how hard it will be. Having people on your side can make all the difference, if only to improve morale and help you maintain you sanity.
It's hard to give you more feedback without knowing more. If you don't want to focus on growth and realistically take VC money, YC might not be for you (these are generalizations, I'd argue Wufoo was a YC success story and they barely took any money at all).
They've taken the price from $100 to $500+ over the course of a decade. There's got to be a way to (1) make epi-pens for $25-$50 (which mylan does), (2) sell them for $50-$100, (3) get stupid rich (4m sold per year in the us alone), and (4) do good for the world as well.
Shoot me an email [redacted] and I'll help you with your application if you want.
Your idea is important too, but mainly as evidence that you can have good ideas. Most successful startups change their idea substantially."
Could you possibly be more la dee dah?