As a non-techie, I was daunted by the task of starting a technology company, Posse. I had an ambitious idea to build a social network that connects customers and retailers but I didn’t know what a line of code looked like, let alone what language we should use or how to tell a good engineer from a bad one. Like many entrepreneurs, I had a vision but no clue how to execute it.
When I started meeting potential investors they all asked the same question, “How are you going to build this?” Even though they liked my story, they wouldn’t invest because they didn’t think I had the experience to pull it off. Everyone suggested that I find a technical co-founder who would be responsible for the product. I looked but couldn’t find the right person and so I muddled on.
Three years later, I can report that as a non-technical solo founder I must have made every mistake possible in building my product. But I’ve learned a huge amount in the process and now have a thriving team of 12 engineers and a solid platform.
I still think it is possible for non-technical founders to build technology companies. They just have to recognize that it’s going to be a tough and frustrating journey. Here are some of the things I’ve learned.
Trust your vision.
My first effort to build Posse was with a local development shop. I told them what I wanted the platform to do and they designed and built it. They all had fancy resumes and had worked on high profile websites.
When they showed me the first round of designs, I was worried. I felt that buttons were in strange places and huge amounts of prime screen space were being wasted. It didn’t make sense to me, and it wasn’t what I had envisioned.
At the meeting, however, I felt intimidated – these guys knew what they were doing, and I had no experience. So I didn’t speak up. They went ahead and built the website using their designs — and it didn’t work. As soon as we launched, we ran user tests that indicated that people were struggling to understand the point of the product. And even if they did understand, they couldn’t figure out which buttons to press and when. It was an expensive disaster.
Through this process, I learned that the only person who really cares about my product is me. It was my vision and my responsibility to ensure that it worked as intended. Since then, I’ve been involved in every aspect of our product design: When something doesn’t make sense to me, I have found that it usually doesn’t make sense to users either. We still make mistakes but now I own our mistakes.
After I raised my first round of financing, I could afford to hire my own team. Since I wasn’t sure how to build a development team, I focused on hiring one person to lead it and let him recruit everyone else. The problem was, how would I know I had the right person to lead?
Within a few months, we had a team of four. Development seemed slow and our live site was littered with bugs. Our team didn’t seem driven; they all finished work each day at 5:30. I remember watching “The Social Network” and admiring the passion and intelligence of the group of young engineers. My team didn’t look like that.
Then, at a start-up conference, I spotted Lars Rasmussen, the well known engineer who created Google Maps. I bowled up to him and sold him the Posse story. I outlined my challenges as a non-technical founder and asked for help. Within a week, he’d interviewed our team, reviewed our processes and introduced me to a lead engineer at Google who later joined as our chief technology officer. Lars joined our board, invested in the company and has since played a pivotal role in recruiting our engineers and overseeing product design. And with Lars involved, investors stopped asking me to find a technical co-founder.
Focus on design.
One of the hardest parts of building a product is getting the user experience right, and I’ve learned that the only thing harder than finding the right head of engineering is finding the right lead designer. We’ve been through three.
I know that I’m sometimes guilty of being a control freak, and I have often found myself micromanaging the lead designer: “Shouldn’t this be larger?” Or, “Why aren’t the action buttons the same color?” It’s frustrating for everyone, including me.
Our current senior designer, Anna, joined our team as an intern. She was so talented that I immediately hired her full-time, and within five months, she had replaced our lead designer. Every day she delights me with her creativity and ability, and I no longer feel the need to micromanage. I know her ideas are better than mine. I trust her.
Set non-negotiable deadlines.
It’s an unwritten law of nature that development always takes longer than predicted. Because I’m a non-techie boss, my engineers know that I don’t understand how much time they will need to complete a task, a deficiency that I’m sure they sometimes exploit and that I find incredibly frustrating.
I’ve learned that team motivation is the prime determinant of development speed. I’ve also discovered that nothing is more motivating than a high profile, non-negotiable deadline. Engineers are excited and nervous when they know that crowds of people will see and use their work at a big event, on a specific date. Our team performed brilliantly in the month leading up to our launch at the South by Southwest festival; they worked day and night. Now I look for major events that we can all work toward every three months. It’s a great way to keep everyone pointing in the same direction and working fast.
Don’t be afraid to scrap mistakes.
Our team always has lots of great ideas, and it’s impossible to know which ones will help Posse take off. I often get excited and press to build new features before we’ve completed and tested our current priorities. In our team, there are developers whose instinct is to press on, working quickly, trying different options and selecting the best — and there are others who believe in finishing each task to a high level of quality. I don’t think there is one right answer; good start-up development is always a balance of speed, testing, and quality. I have learned to focus on the most important things first and to test everything. And I’m not afraid to scrap a feature or redesign a process if it proves unsatisfactory.