I think that the fact that these are post-mortems (e.g., dead startups) skews things a little. Could be that the founders weren't technical enough to deliver something interesting, which then caused the issues of wrong product (e.g., there was a technologically more challenging solution that would have made sense as a product), being unable to sell the product (e.g, you're peddling crap, and you know it), and not having a viable business model (e.g., noone actually cares enough about what you build to pay you for it).

That is total speculation though.

Here's how we're looking at what we're doing though. It's viable with a fairly low tech approach, and that's a good start. But we can use technology to take something that "works" and turn it into something that purrs.

It's like the phone switching terminals of old. You'd have an operator and you'd tell them who you want to speak to, and they'd plug the right wires in. It "works". Bell made money on that. They had the right product, strong sales people, and they had a business model. But to think even for a second that they could compete with that nowadays?

There's some irony that VCs investing in the industry that owes its life to computing and telecommunications are saying "Eh, the technology you're using doesn't matter".

But I do think that technology isn't the bottom layer of Maslov's hierarchy of startups. The existence of a market need is at the bottom, then whether your product is able to address this need, then whether you're able to reach that market, then whether you can get paid for doing so.

These layers are filters. It's not surprising that most startups fail on the ones that come first. That doesn't mean if you're shooting to be Uber, or Dropbox, or Facebook, or Google, that you tech doesn't need to be on point. And the best point to start using sane tech practices is, well, as early as possible, preferably once you've validated your other assumptions.

(I'm the author of the post.)

There's definitely some sampling bias from the post-mortem article. Alas, this is the the most relevant public data that I could find. I do have a good (anecdotal) first-hand dataset: I've worked closely with about 50 portfolio companies at this point, and I've tracked a few dozen more that my fund didn't invest in. Maybe 5 out of the 50 had real technical risk, and 2 or 3 struggled and/or failed due to technical issues. For the remaining companies, the challenges have always been market-related, hiring-related, funding-related, and so on.

There's a bias to your first-hand data too: throwing money at a problem does not usually reduce technical risk, at least in software, where a larger team is usually less well-equipped to execute on technical risk. Instead, you just need wrestle with the problem and develop expertise on it.

So a team working on such a startup idea is unlikely to be seeking venture funding. Instead, they're probably a university professor and a couple grad students, or just the grad students, or an eccentric genius in a garage. When they have something that works, then they'll seek venture funding to turn it into a company, but at that point the idea has already been significantly de-risked (and they'll often go to a "name brand" VC, since the de-risking of the business makes them attractive to pretty much all investors). If they never get to the point where they have something that works, then they go back to their research or get a job, and you never hear about them.

You are really missing the point of due diligence...

"Homeowners' insurance is a waste of money. 99% of the time your house doesn't burn down!"

You don't buy insurance because you expect your house to burn down. Similarly, you don't perform due diligence because you expect to find something. You do it to catch those rare 1 out of 20 events where something is f*cked up.

It's a little different in Venture Capital because exits follow power laws. So the big mistakes are literally the opposite of insurance: it's okay to make a lot of losing investments as long as you don't miss Airbnb. Missing out on Airbnb because you got stuck on it being 3 designers and no engineers is way worse than investing in Airbnb and 49 companies that go bankrupt.

Perhaps you do not use the term "due diligence" the same way that it's used in the investment management industry, which to be clear, includes "Venture Capital."

"Due diligence" does not mean making a judgment call on whether three designers can build, scale, and operate a tech company. Due diligence means diving into the details of a company you are going to fund and checking, among other things, that the things they've said are valid and that there are no skeletons in the closet.

Don't get me wrong: due diligence sucks for all parties involved. If you are investing your own money, you have the right to do as little work as you want and skip it, but when you are entrusted as a fiduciary of someone else's capital -- and paid for the job -- it comes with responsibility.

There are other factors, like Time, that influence the diligence process for (seed stage) venture capital. Investments are made at a fast cadence, which is good for founders and for investors. A seed fund might see 1000 companies in a year and invest in 10. That allows for a few hours spent on each company, but not much more than that. Similarly, a founder might meet with 50 or 100 investors before closing their round. 1-2 hours per investor will take a few months, but if investors spent too much time on diligence then a founder could spend all year just answering investors' questions. That would be like a twisted variant of the Uncertainty Principle, where just going through fundraising process basically dooms a company to fail because of the time required.

Given that time is a factor and given that I have 2-4 hours to spend with the companies I'm most interested in before making a final investment decision, I've gotten the most value out of spending 95% of that time on non-tech diligence. YMMV.

That does make sense. Investor & Founder time is limited, technical due diligence on the investor side takes too much time.

I'm coming more from a founder perspective though, and I think there's some dangers with the mindset as a founder, and I see it with a lot of people in the chinese startup community.

Whilst as an investor, one might get to play a bit fast and loose with technology choices, I believe that as a founder doing so is suicidal. I see startups here struggling to hire PHP programmers because they made the decision to go with PHP because they heard it was easy, and later on realized that that may have been a mistake. They try to smooth it over with funding later. PHP programmers over here have the same reputation. They learn it because they thought it was easy, and that there's a lot of companies desperate for that skill. It's a match made in hell.

Similar boneheaded decisions, preventable with a week of due dilligence reading, are made by founders here all the time. One thing I found interesting is that the people making these kinds of calls are always working on C-list ideas. It's always derivative businesses in markets that just don't care. They need to get their MVP out fast and half baked because what they're working on should have died on the drawing board. They're desperate for investor money because they think it will patch over major errors they've made up to that point.

Some of these ideas are salvageable. It usually requires restructuring on both the business side and the technology side, preferably to the point where they make sense as an integrated system. One guy I was working with, his startup is trying to create a site for farmers and rural Chinese to sell things on that, and that is so interesting, Alibaba jumped into the ring recently. Now he has a dinky site that does not solve anyone's problems. It's a website, which is greatly hindered by the fact that most villages have a single computer, and the people who wanted to trade with each other would sit at that computer, together.

I suggested to him that he change things up a little. Small farmers do suffer from information asymmetry with the people they're selling to. Technology wise, most of them have non-smart phones, but China Unicom is rolling out mobile coverage to rural China, because that's their market tomorrow. So, provide informational and automated brokering services over a website on the buyer end, and an SMS gateway on the seller end. Ship the FAQ on actual paper. Allow farmers to post their wares with a formatted text message, have offers coming in an hour later, goods shipped the day after. Give them a reason to upgrade to smartphones, pack in more features on the app once data becomes cheap. Do agricultural futures 5 years down the line, in one of the hungriest economies in the world.

The part where technology makes this interesting is that it allows you to reach a market segment that is unreachable over conventional means. Innovation is the edge startups have over large, well funded enterprises. Founders ignoring that side are blindsiding themselves to half their business.

I'm not sure why you got downvoted. Your comments here are not only valuable to discussion, but are aligned with exactly my experience.

Thanks. I didn't understand either. I guess I am cynical on this topic because all my career I've dealt with people complaining about DD rather than reframing it into an opportunity to learn and limit downside.

Isn't your tech background useful for smelling technical bull%&!t?

Yes. That's basically the only kind of tech diligence that I do at this point, and it's more conversational than diving into the tech. (And I only do this if someone is making very bold claims.)

Surely your ability to detect baloney in just a few minutes of casual conversation is far, FAR superior to that of, say, the stereotypical MBA or lawyer with zero technical expertise. There's more value in that than you suggest, I think.

It's definitely useful. I wasn't trying to say there was no value in a tech background in VC. Rather, I expected to use my tech skills to dive into code and understand technology a lot more, and instead I just use them as a baloney detector and a good differentiator from VCs who have non-technical backgrounds.

Makes sense. Thank you for taking the time to answer questions on HN in a thoughtful manner!

> I think that the fact that these are post-mortems (e.g., dead startups) skews things a little.

That's a very good! So it's 5% of startups that posted a post mortem (and it didn't disapear into ether), rather than 5% of all startups. These two things are very different things.

> we can use technology to take something that "works" and turn it into something that purrs

Well put. However, nowadays, the tech itself is often not the key bit in making the difference between 'works' and 'purrs'. Of course, there are exceptions, bigger and smaller ones. More often, it's understanding the problem, the users, and finding the fit. You can build a product with tons of technical debt and wtfs that gains some traction and then spend resources on improving it. However, it doesn't work the other way round. It often takes an experienced engineer to say 'right, let's start some cleaning up' at the right time. However, if your product doesn't solve any problems, no one is willing to pay for, etc, brilliant tech solutions are not going to help it.

> start using sane tech practices is, well, as early as possible, preferably once you've validated your other assumptions

Totally! It's just that it's often hard to tell when it's the right time.

These quotes really show the paradox: within the weird definition used in the article of "amazing engineers" which is not defined but seems to imply those who can talk a big game about architecture or score well on the HackerRank, the "quality" of the engineer has no relation to business success. That's because the engineer's quality is being assessed for being able to bullshit about architecture or score points for writing "clean code."

The idea that "even great engineers" might take on technical debt is insane. In a startup situation, great engineers take on technical debt with the greatest of glee and at every opportunity, as the primary goal is to find product market fit. Bullshitting about scalability, maintainability and frameworks is counterproductive and maturely, one understands that any software will be almost totally rewritten whatever happens: take this example by John Carmack to start a prototype environment for rapid iteration, explicitly laying out ways in which it should be rewritten if successful https://groups.google.com/forum/#!msg/racket-users/RFlh0o6l3...

Many good engineers stay in their comfort zone of some part of the software lifecycle. Seems like the author was trying to assess people imagining their situation was that of big company software project going in for a third generation rewrite with little uncertainty about what it should do. This is not the situation startups are generally in, and great engineers in this situation adapt; they pivot without getting stuck on old conceits, and have a knack of understanding which signals to heed to get to that glorious market fit where suddenly reliability is valuable. Definitely they can be assessed on ability.

It probably counts as failure because of poor management, rather than absence of amazing engineers ;)

That's obviously not the problem: "just look around -- aren't we amazing?"