Friday, July 18, 2014

Day In Pictures: Thursday

Ellie at Boxcar pulled together a yummy Cortado to start things off.

Rachel Ryle of Don't Stop Motion fame shares her creative experiences.

Johnny telling me about hanging art in The Laughing Goat. He made me my first latte many many years ago.

Nice girl at Zoe Ma Ma taking orders for the noodles.

April after a solid early afternoon hike.

Rachel for pre-therapy iced coffee.

Therapy session with Jillian.

TechStars Boulder begins! Team/Mentor meet-and-greet.

Matt and David. Good talk about 16-digit numbers.

Catching up with Rob Taylor & Nicole Glaros.

Talking about whale and the history of buckwheat vs. corn meal polenta with the maestro Bobby Stucky.

Talking about risk with entrepreneur Kyle Kuczun as the day winds down.

Wednesday, July 16, 2014

Hiring Your First "Sales Guy"

Knowing when to hire your first sales person is the answer to one of those million dollar questions. We did a great job hiring our first sales person at Gnip (an Enterprise SaaS sales scenario), and this post describes how I think we pulled it off.

There were three things I wanted us to have before we pulled the trigger.

I wanted us to have some actual revenue first. Not a ton, but a handful of months that showed growth. Something I could show a salesperson prospect and say, "See, there's growth here. Your job isn't to start the growth, it's to increase the slope of the curve!" Of course, I also wanted some revenue and growth trajectory to convince ourselves that we were onto something too.

I wanted us to have some semblance of a pattern that illustrated the deal process and showed a prospect coming into the top of the sales funnel, and then out of the bottom, cutting us checks. This pattern, or template, would be something we could hand to a salesperson prospect and say, "This is how we've gotten this far. Are you comfortable with a model like this? Can you make improvements to it so we can have more money flow in?"

I wanted us to have the experience of having done the first wave of sales in order to really know what we were up against.

Put all that together and I think what is was, was that I wanted the upper hand in bringing on our first salesperson. Without the above, you're at the whim of the salesperson, because.... well... "You don't have a proven model here." Danger, danger.

I did NOT want us passing the sales buck off onto some new hire that couldn't fully understand our product, our prospects, our customers, our software, our challenges, our margins, etc. Understanding all of that stuff takes many months, and you want this person generating money quickly. I firmly believe hiring someone to sell your stuff before you've achieved the above items is a recipe for disaster. It will end with the firing of anyone you hire. You will fire them because "they don't understand our product" or "they don't understand how to sell our product" or "they don't understand our customers" or "they don't understand where they can flex on price." Those are all reasons you need to sort out before you hire your first salesperson. Now, you may have to let your first salesperson go anyway, but don't start off with one hand tied behind your back.

Oh, and another thing, I didn't want to hear the new salesperson say "you've never sold this product successfully. I'm trying to get our sales engine going here. it's going to take time." Fuck that. No excuses.

My board of directors drilled into me that we would fire our first salesperson hire (whoever they turned out to be), and that was something I was going to have to be prepared for. Our first salesperson drove Gnip into shit-tons of revenue; years later he's still with the company.

Your mileage will vary.

Monday, July 7, 2014

Your Startup's Identity Crisis

photo by Hans Richard Pedersen

Don't think about the following question; just answer it.

Is your startup a Product company, or a Services company?

If you answered "kind of both," you answered wrong. Only mature firms can handle both. If you're still trying to find decent revenue streams, and/or product market fit, and you answered "both," I'll bet you a dollar you're tearing your sales, engineering, product, marketing, and "services" teams apart at the seams.

If you started out as a Product company, but then started doing more custom/one-off/services like projects to make financial ends meet, be honest about the situation and acknowledge that you're organization is likely suffering from the challenges of trying to both, without the experience or maturity, or resources to actually pull it off. The challenges of doing both are nothing to sneeze at. I'd argue they're the hardest to resolve.

If you stated out as a Services company, but then realized you had a leverageable Product on your hands, consider carving it out as a separate entity (with separate staffing) to give it the air it needs to breathe and fully succeed, without the oil and water challenges of trying to do "both."

Over the past six months I've spent time with several startups (from 1 to 100 employees, and from zero to ~$15m in annual gross revenue) conversing about various challenges the business is going through. More often than not, there's confusion around whether the company is a Product company, or a Services company.

A Product firm != a Services firm. They take two different kinds of brains most of the time: from the CEO, to the individual contributor with her fingers on the keyboard.

Pick one; until you're older and wiser.

Sunday, June 29, 2014

My Daughter's First Software Creation


This weekend my eight-year-old daughter built her first program using an iOS app called Hopscotch which uses the Hopscotch programming language (kind of like Scratch). It's not a static or compiled language like C or Java (her dad's background :) ), but, variables (values), events, and control flow logic abound.

She engaged really well, and picked up the visual nature of the framework with ease. Variables and some of the built-in events took some explanation, but it was awesome to watch her rapidly close the loop between logic creation and "running" the app.

She was able to debug issues that arose, and easily dig into adding more and more functionality to her objects.

Best of all, I found her creating on her own a couple of times, without any prompting from me.

"Daddy, come see what I did!"