This post is a continuation of my previous post: Finding the Technical Know-How to Build Your Great Startup Idea.
My co-founder, Ivan, and I like to joke that I’m the “ed” half and he’s the “tech” half of our ed-tech startup, ProfessorWord. The fact that we bring different backgrounds and skills to the table is often a good thing. But it can also lead to confusion, because let’s face it, ed folks and tech folks don’t always speak the same language.
As the “ed” half of this edtech startup, I’m sometimes tempted to leave all the technical details to my “tech” half. After all, my job is to lay out the pedagogy and instructional design, and his job is to build what I describe. Right?
In our experience, the product development process just doesn’t work that way. For one thing, if you don’t understand how your product/service is being built, you run the risk of making decisions early-on that may end up limiting your functionality and may cost a lot to fix/workaround in the future. Also, product development is not a linear process. It’s actually a very iterative process, with constant tweaking, testing, and learning along the way. Learning to speak (some) tech and code (a little), has drastically improved how Ivan and I work as a team. The same is also true as Ivan has learned more about the education space. We communicate much better when we both have at least a basic understanding of each other’s domains.
Here are some of the things I’ve learned in the process of learning to “speak tech”:
Goal is to be conversant, not fluent.
There’s a lot of opportunity cost associated with taking the time to learn technical skills. We realized that we had to be very selective about which skills were worth the investment. For me, the goal to become a full-fledged web developer. Instead, the goal was to develop a basic understanding of how our product was going to be built and what trade-offs we were making, so that I could participate more effectively in the product-development process.
Start with outside resources first.
We learned quickly that it’s best for Ivan to act as a reference, not as a teacher. It’s frankly just not a good use of his time. If you’re lucky enough to have a technical co-founder (see my previous post: Finding the Technical Know-How to Build Your Great Startup Idea), don’t make the mistake of relying on him or her too much for assistance as you learn.
For example, I’m in the process of learning how to correctly use Git and GitHub, and I’m relying mostly on outside resources (i.e., online tutorials, YouTube videos, etc.). I only ask Ivan for help, when I’ve spent more than 10-15 minutes trying to Google a solution for a question/problem that I’m having. I’ve found that you learn more when you struggle a bit. But the key is not to struggle so much that I’m needlessly spinning my wheels, or to struggle so little such that I’m wasting Ivan’s time.
State your assumptions up front.
We’ve saved ourselves a lot of confusion by recognizing our different perspectives. For example, when we have discussions about what features to build, my education-minded brain is focused on what works pedagogically, while Ivan’s technical-brain is focused on the logistics of building that feature. It’s helpful to lay out our assumptions up front, to make sure we respect and understand where the other person is coming from.
That’s it for today. Let me know if you have any questions @professorword.
Until next time,
- Education Business Plan Competitions: Crafting the Perfect Pitch
- Five Tips for Ed-Tech Startups Entering Business Plan Competitions
- The Best Presentation Advice We’ve Ever Received
- How to Begin Your Ed-Tech Startup Journey Today
- Rejection Therapy for Ed-Tech Entrepreneurs and Startups
Have questions or feedback? Comment below or let me know on Twitter @professorword!