A Non-Techie Tries to Build a Tech Company
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.
Get advice.
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.
Commentaires
Enregistrer un commentaire