lI’ve founded three SaaS startups, all without writing a single line of code. Here’s what I wish I knew from the start…
“Sorry, but until there’s a programmer on the founding team, this discussion can’t move forward.”
Trying to raise money as a non-technical founder was an uphill battle.
One where I kept getting pushed back with politely-worded attacks of “you don’t have what it takes.”
Thanks for the vote of confidence, guys.
Even though I had a product, I wasn’t a developer. And despite my efforts, I didn’t have a technical co-founder, either.
In the technical world, non-technical founders risk being seen as unqualified.
I’ve seen the attitude from potential investors, employees, partners, advisors and even fellow founders who have no stake in the business.
You can’t build a software business if you can’t make software.
Bullshit.
While we’ve got a long way to go, I’m damn proud of how far we’ve come at Groove.
And we’ve done it with an outsourced prototype, a killer team and a ton of hustle.
And me. A decidedly non-technical founder.
This isn’t a woe-is-me cry for non-technical founders to get more respect in the industry. Respect is earned, and there are a lot of groups far more maligned.
But this is now the third time I’ve been a non-technical founder, and I’ve learned a lot of lessons along the way.
Lessons that have helped me work more effectively with my technical team members, add more value to our product and become a better entrepreneur.
I hope you can learn from them.
Note: a lot of these are great skills for technical founders to have, too. And many technical founders I know are really good at them. But from my experience, for us non-technical folks who can’t contribute to the codebase, I’ve found these to be absolutely critical.
The Skills That Have Helped Me Succeed as a Non-Technical Founder
1) Research and Validation
Before my first startup, I started my career as an assistant to my brother, a financial advisor.
Soon after that, I began to get frustrated that there was nothing out there to help us automate the customer management side of things.
Everything — followups, lead nurturing, tracking — was manual.
I thought that maybe if I was having this problem, then others might be, too.
So I put a PowerPoint deck together about the solution I envisioned — a CRM for financial advisors — and then I picked up the phone.
I called other financial advisors in my area, asking if I could have five minutes of their time.
Then I asked them about their own experiences and pains, and learned that dozens of them shared the same burning frustrations that we did.
It was then — and only then — that I decided to team up with my technical cofounder and get the product built.
It’s a process I’ve repeated for all of my startups, and the time I put in early on has paid off exponentially in building a better solution than we otherwise would have.
Takeaway: Without the ability to hack together a prototype, the easiest way to validate your idea is simply to go talk to your potential customers first. You’ll be amazed at how many people are happily willing to share their time and opinions with you.
2) Building Visuals
I was lucky to team up with one of my best friend developers who had just left Yahoo! and agreed to join me.
Before he got started, I tried to sit him down and explain all of the features and functionality I imagined our app would have.
After about five rambling minutes, he stopped me.
“We can’t build from a list,” he explained. “Let’s organize your thoughts and map this out so that we know what it’ll look like first.”
And so I did.
I started to draw sketches. And then those turned into wireframes. And finally, I learned how to use Photoshop and built mockups of the app.
It bridged the gap between the thoughts in my head and my cofounder’s understanding of them, which meant that we saved a lot of time on changes and iterations early on.
And while these days I’ve ditched Photoshop and switched to Balsamiq for mockups, it’s still my favorite way to show our team exactly what we need to do.
For example, I might point to a part of the site that needs fixing:
Or I wireframe up a whole page to make it easier for the team to understand my vision for it:
Or, if there’s a user experience issue, I’ll record the behavior using Jing, a motion screen-capture tool, and send it that way.
These are much more helpful to our team than a description could ever be.
Takeaway: Wherever you’re able, showing is better than telling. Pick good tools for mockups and screen captures, and use them to show your team what you want.
3) Giving Bulletproof Feedback
When you do tell instead of show, learn to tell as descriptively as possible.
Early on at my second startup, we were trying to build a login page for our customers, and it was going…poorly.
“The form needs to be bigger, and we need fewer navigation links,” I emailed our development lead.
If you have product development experience, you’re shaking your head in disgust right now.
“No problem,” he’d say. And an hour later, I’d get a new version with a too-big form box and critical links missing from the header.
We had been dancing this dance for days; me flat-footedly asking for vague changes, and him dutifully matching my steps.
Finally, I was fed up.
“Why on earth would we remove the link to the home page?,” I quizzed him.
“Um, you were the one who told me you wanted fewer links.”
And so I was.
That afternoon, we had a long discussion that was incredibly helpful for me.
I learned the importance of giving clear, thorough feedback.
After all, if someone sent a blog post back to me with the comment “needs to be shorter,” I’d be just as lost.
Now, instead of “fewer navigation links,” I might say “let’s remove the About, Contact and Features links, and increase the size of the form submit button by 20%.”
Things move a whole lot smoother.
Takeaway: There’s no excuse to give vague feedback. It slows down your team, creates confusion and hurts your product. Be clear, concise and direct.
4) Pre-Selling
At that first startup, while my friend sat coding, I, again, hit the phones.
I called more than 1,000 financial advisors around the country, and just as I did in our earlier stages, asked them about their frustrations.
And while I was able to get some amazing insights that helped us in our development, I also got something that massively increased our chances of success once we launched.
In those conversations, after hearing about how much the agent hated doing their follow-ups by hand, I’d say something along the lines of:
“Just so you know, we’re building a tool to automate all of that. It’ll do [X, Y and Z]. When it’s ready, I’d love to show it to you and get your feedback. Would that be alright?”
That effort got us a list of hundreds of highly qualified leads, and dozens of paying customers within weeks of our launch.
Takeaway: You can be selling even before you have anything to sell. In fact, while your product is being built, that’s one of the best uses of your time.
5) Selling
I’ve found that my job as a non-technical founder, more than anything, has been to sell.
Want to raise money? You need to connect with investors who see hundreds of pitches each week and make the case that your company is worth betting on.
Want to sell your product? You need to connect with your customers and deeply understand their challenges, hopes and fears.
Want to hire the best? You need to connect with talented prospects from a variety of backgrounds, understand their goals and show them why your company is the best fit for them.
Want to secure a profitable partnership? You need to connect with the person you’re exploring the deal with, know what they’re looking for and convey how you can help.
Want to manage effectively? You need to connect with your team and stay on top of a number of markers: happiness, productivity, obstacles, goals and schedules.
The list goes on and on.
Selling is a skill that can absolutely be learned. A couple of my favorite books that helped me do just that are Neil Rackham’s SPIN Selling and Yes! by Noah Goldstein, Steve J. Martin and Robert Cialdini.
But beyond studying, the most important thing is to practice. Early on, every day you spend selling gets easier than the day before.
As I’ve learned from my own experiences, and from talking to people who are much better at sales than I am, you’ll always run into new challenges and frustrations. But over time, you get much better at dealing with them, and the process becomes a whole lot easier.
And as a non-technical founder, it’s where the bulk of your value to the company will come from as you grow.
Takeaway: The biggest job of a non-technical founder is to grow the business through customer acquisition, hiring, managing and more. Get very good at connecting with people; it’s a skill that can be learned through practice.
6) Cheerleading
In each of my three startups, I’ve come up against people telling me that I have no shot because I’m not a developer.
Frankly, naysayers are a challenge that every founder deals with.
But they always sting the most when they harp on the things you know are true; like the fact that you can’t code.
I’ve had to learn to be my own cheerleader. To motivate myself to push through those fights and focus on what matters.
And through that, I’ve learned to be a cheerleader for everyone else.
When our developers are focused on a nasty issue that’s holding back the company, there’s not a whole lot I can do to help on the technical side of things.
But that’s when I can be a cheerleader for our customers, helping them get through the problem with constant communication.
And for our team, sharing every win I can to boost morale and keep everyone happy and motivated.
As the one who can’t dive into the server and fix things, it’s the biggest contribution I can make.
Takeaway: It’s your job to be a cheerleader for yourself, your team and your customers. It’ll keep you sane, your team motivated, and your customers happy and loyal.
7) Knowing the Tools of the Trade.
Like everyone else, developers use tools to help them do their jobs better and easier.
To avoid disrupting people’s workflows and stalling the development of product, I’ve had to learn how to use those tools.
Every team will use different tools, but no matter what your team prefers, being familiar with those developer tools can help the whole team.
When I find a bug, I don’t send a productivity-crushing email for each little issue. I write a descriptive user story and put it in Pivotal Tracker, which puts my feedback seamlessly into the development team’s existing workflow.
Most of the tools out there don’t take very long to learn (for example, Pivotal Tracker has great, easy-to-understand video tutorials), but it’s an effort that will contribute massively to the success of your team.
Takeaway: Don’t try to bring your development team into the tools that you use. Those probably aren’t built for development. Instead, streamline the process and make life easier for your team by learning their tools.
8) Doing “Everything Else”
I’ve had to learn to wear hundreds of hats.
Do we need to build a spreadsheet and find contact information for blog engagement?
That’s my job.
Do we need to research and pick an app for screenshare product demos?
I’m on it.
Does a developer need me to email Pivotal Tracker support and find out why our updates aren’t syncing?
Right away, boss.
I can’t afford not to do everything in my power to make everyone else’s job easier.
Takeaway: Ego has no place here; your job is to do absolutely anything that isn’t a good use of your developers’ time. Otherwise, you’re putting your growth at risk.
There’s Lots More to Learn
I’ve been a non-technical founder for almost ten years now, and I’m still learning new lessons every single day.
But right now, if you asked me what I wish I had known when I started, this would be it.
If you’re a non-technical founder (or thinking of becoming one), I hope these lessons help you succeed in working with technical people.
And if you’re technical, I hope this helps you understand the perspective of the non-technical people you work with, and how you can help them help you more effectively.
More than anything, I hope you understand that not being technical should never be the reason you don’t pursue a startup.
Get out there, get started however you can, and learn the skills you need along the way.