8 Lessons From a Non-Technical Founder

Scroll down to content

I am the non-technical founder of a technical product. Simili is not yet successful, so I don’t know that I’m really in a position to be giving advice, but at the same time, I figure it’s worth sharing what I’ve learned in hopes that it can make someone else’s learning curve a little less steep.

  1. Don’t worry about the tech (AT ALL) until you’ve validated the idea. This means actually talking to people – lots and lots of people. Don’t be like me and tell yourself that once you build the MVP (minimum viable product),  THEN you’ll have users you can talk to; you don’t need to have a product that “works” in order to get useful feedback. I wasted over $10k and 9 months of time because I am shy and didn’t want to talk to strangers. I stubbornly convinced myself that all of the Lean Startup customer discovery stuff I’d spent so much time reading about didn’t really apply to me or my idea. That was prideful, dumb, and expensive.
  2. You will probably go back and forth, back and forth, trying to decide if you should learn how to code. All I can tell you is this: I didn’t, and there have been SO many times that I was glad I didn’t. When the tech people around me talked about bugs that took them 2 days to squash, even just thinking about being in their shoes made me want to pull my hair out… but having said that, I also just signed up for my first “intro to web concepts” class, am working on plugging in to the local “women in tech” community, and spent some time this weekend on Codecademy. So… take from all of that what you will.
  3. If you’re NOT going to try to learn how to code, at minimum learn enough to understand the basic principles of what you’re trying to build. I was lucky, in that the second developer I worked with took the time to break it all down for me so that I could understand why what I’d had built previously pretty much had to be scrapped, and how they were going to build it differently the second time around to be more future-proof and flexible. Again, hindsight is 20/20, but I wish I’d learned more before I built the first (wrong) version of my product, rather than jumping right in and finding someone to build something for me. (Are you sensing a theme, here? Move a little slower in the beginning and you’ll be able to move more quickly – in what will hopefully be the right direction – later.)
  4. Related to all of the above, finding the right resource makes a huge difference. Unless you’re phenomenally lucky, that perfect “technical co-founder” you wish you could find is NOT going to just fall into your lap. You will soon come to appreciate that you don’t just need “someone who knows how to code.” For one thing, there are about a gazillion different coding languages, and just because someone can speak a language doesn’t mean he or she can carry on a conversation (or write a novel). If you truly don’t have technical knowledge, you’re going to need to hire more than just a “coder” – you need thought leadership – because figuring out WHAT to build and HOW to build is often harder than actually doing the building.
  5. You may not be the one coding, but you are most likely acting as the product manager, and that means figuring out what the MVP will be. Ideally, you’ll figure this out BEFORE you start scoping out the work with your developers. This is another thing I did wrong — I was simultaneously working on customer discovery in order to figure out just what the MVP should be AFTER my project had kicked off with the development team. (Because… see #1 – I’d just entered the incubator program at the UVA iLab, and every. single. mentor. told me that I needed to talk to people. Do not pass go, do not collect $200 – just return to the beginning. Or at least, that’s how it felt at the time.) Fortunately, it was still fairly early in the process and there wasn’t any wasted work, but I still didn’t like feeling a little flaky – “build this… no, wait, actually – build this, instead… no, wait – we don’t really need that feature…”
  6. Remember that just because you can’t code doesn’t mean you’re coming to the product-development table empty-handed. Part of what you bring is the real empathetic understanding of the user (once again, see #1). It’s your job to translate that understanding into what the product becomes. This means knowing the “job to be done” and recognizing that sometimes engineers think more about the technical aspects of features than about why those features need to exist, or relatedly, the way users need to experience those features — that’s your job.
  7. Go find yourself a community and a network. Yes, even if you’re shy. The pain is real – I get it – but I  guarantee that you and your idea will not grow stronger without the right environment. If you’re going to be a founder, you’re going to have to put yourself out there sooner or later, and it may as well be sooner. I’ve been amazed at how much of my time has been spent talking to people and building relationships. I’ll reiterate that Simili is not yet “successful,” but this feels like a win, no matter what happens – my professional life is richer for the connections I’ve made, and that gives me joy and confidence.
  8. No one’s gonna steal your idea. I promise. Ideas are easy; making shit happen is hard. The magic is in the execution. And yes, you CAN do it.

Please feel free to reach out to me with any questions, or just to practice talking to strangers. So many people have helped me along the way, and I’d love to pay it backward.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.