"As engineers who had never done this before, talking to people didn’t seem like real work. Real work was coding. But in reality, 20 hours of great interviews probably would’ve saved us an accrued 18 months of building useless stuff."

"If you’re a technical founding team like we were, building it is the least useful way to reduce the risk in the company. You should be focusing the vast, vast majority of your effort as a technical founding team on making sure you’re really solving a problem. Because if you are, I’m quite sure you can build the solution."

"Rather than months and months of engineering effort, all we needed in the end was a landing page built over a couple days. That little open source library (with only 8 incomplete integrations) was our minimum viable product:"

"once we found that initial sliver of a problem, digging in has been incredibly rewarding, fun and challenging in new ways."

"if you’re not 100% sure you’re solving a real problem, you’re almost certainly not. Make sure you really validate the problem you’re solving."

"Y Combinator’s constant, sage advice is to avoid solving problems that nobody has. It’s the most common startup failure mode, and it was certainly our failure mode for that first year and half."

"Good validation work would’ve looked something like this:"

"Hour-long interviews with professors and TAs diving into what they found most frustrating about teaching."

"Digging and digging until we found a problem we could solve, or even more critically, possibly determining that there were no problems for us to solve."

"If you’re a technical founding team like we were, building it is the least useful way to reduce the risk in the company. You should be focusing the vast, vast majority of your effort as a technical founding team on making sure you’re really solving a problem."

"We were just starting to build our lecture tool (for students to say “I’m confused!”) and we figured we should have analytics on it. So we googled “analytics” and found Google Analytics, KISSmetrics and Mixpanel. Their APIs for collecting data and the graphs that each of them provided looked similar… we just couldn’t make up our minds about which one to use. So we wrote a pretty gnarly abstraction that just took an event like “Signed Up” and sent it out to all three analytics services."

"So my co-founder Ilya cleaned up our javascript library a bit more, gave it a name (“analytics.js”), added Segment.io as the fourth analytics service it could send data to, and open-sourced it on Github so that prospective customers could give it a spin. Analytics.js started getting some stars on Github, and even a couple pull requests, which was mind-blowing to us at the time."

"Then my co-founder Ian came out of left field and said: “You know, I think there’s a really big business behind analytics.js. We should drop all this other stuff we’re working on and focus on that.” I remember very vividly thinking (and probably saying), “That’s a terrible idea. This is a javascript library that’s already open source, it’s about five hundred lines of code… how could you conceivably build a business around that?”"

"I felt so strongly skeptical that I said something to the effect of, “Alright, before we can go ahead with this, we need some sort of proof that there’s a real problem here.” We decided to build a landing page that just explained analytics.js and the data-routing problem it solved."

"The skepticism and staunch disagreement between co-founders had forced an extraordinarily clarifying test. We already knew analytics.js solved a problem for ourselves, but after the HN launch, it was obvious analytics.js was solving a real problem for other people too."

"My advice from being woefully “lost in the woods” is that if you’re not 100% sure you’re solving a real problem, you’re almost certainly not. Make sure you really validate the problem you’re solving."