01 5 / 2013
The biggest mistake I made with my startup(s)…
image credit: Victor1558
I’m going on my 5th year of running my own company, so it’s been fun to look back at all the mistakes that I’ve made.
With my first startup Parrotview, the biggest mistake we made was not using the Lean Startup methodology to see if anyone even wanted our product that we spent so much time building. (No one wanted it.)
I started my second startup LaunchBit, an ad network for email, only after experimenting with many other ideas with my friend and co-founder Jennifer. For LaunchBit, from day 1, we’ve been able to sell ads and get feedback to improve. And, since then, we have continued selling and growing. But, it’s taken us a while to get on the growth curve we’ve wanted to be on. In large part, it’s because it takes time to forge friendships with potential customers and partners — you don’t get to be best friends with people overnight. And with that trust follows business. In other words, we’ve grown recently, because we’ve gotten to know our audience and vice-versa.
I don’t regret the time it’s taken to cultivate these relationships. But, in so many ways, the biggest mistake I made with both Parrotview and LaunchBit are the same. I didn’t build an audience or relationships in my market before starting my company. And, your ability to do this is really what puts you on the right track to understand how to build a successful company. Build relationships with your key partners and target audience before starting your company.
What is the biggest mistake you’ve made with your startup?
Permalink 2 notes
10 3 / 2013
What female-founders really encounter when they fundraise?
Image credit: Tax Credits
I was fascinated by a recent article entitled “Money matters: why women struggle in the Silicon Valley” in part, because it’s an inside look into what women founders really do/encounter, and for so long, this topic has largely been kept secret.
So, I posted my thoughts on “What female-founders really encounter when they fundraise?” on Quibb. Would love to get your thoughts on this on Quibb.
Permalink 4 notes
05 12 / 2012
5 things a non-technical founder can do
Photo courtesy: thetaxhaven
For all intents and purposes, I’m the non-technical co-founder of my internet company LaunchBit, an ad network for email. I barely write a line of code anymore. So what do I do?
I sit around and boss people around. I’m the ideas person. I write strategy docs. I manage products.
When I started my failed startup Parrotview, I had no idea what to do. This is a primer that I wish I’d received myself. Moreover, if you are a non-technical entrepreneur looking for a technical co-founder, showing that you can do these things effectively will set you apart from nearly everyone else.
It can be easy as a non-technical co-founder to sit around and do nothing in the beginning, because no product has been built. But, actually, this is when you are MOST needed.
When there is no product, your job as a non-technical co-founder is to somehow get customers AND keep them happy. (tweet this)
At the beginning of a potential business idea, I would meet with random people of our target demographic to ask them questions about their pain points and problems. When I first started customer development, it was really daunting. I would often have to cold-call and approach random people I didn’t know to do these customer interviews. But, it was absolutely necessary to make sure we were solving a problem, and it was a my job.
Wizard of Oz Customer Validation
Then, after figuring out what problem to tackle, my co-founder Jennifer and I would figure out the minimum viable product (MVP) we’d need to create. Since speed is everything, we forced ourselves to do MVPs in 2-4 weeks. This meant there wasn’t a lot of time to build much technically. So, most of our MVPs have been very concierge-style. To put it bluntly, the product was just us doing operations manually behind the curtains.
For example, with LaunchBit, our advertisers emailed us their creative, and our publishers would copy and paste it into their newsletter. Advertisers would send money to my personal PayPal account. There was no ad server. No dashboards. Virtually no technology in v1. Once we started getting more advertisers and publishers with this approach, things started becoming chaotic. We needed to keep campaigns straight and keep track of who paid and who needed to be paid. Sometimes, because there was no technology, mistakes would be made. A publisher might inadvertently leave off the last couple of characters in an ad campaign. Or an advertiser might forget to include an image. And, I’d have to sort out those mishaps.
As a result, both advertisers and publishers would get frustrated or angry, because this concierge-style service was tedious — not just for us but everyone involved. It both hurt *a lot* and was incredibly exciting to hear these complaints.
Complaints are our #1 indicator that someone even cares about what we are doing. Indifference is our #1 enemy.
Doing customer service was also my job. (In parallel, after we had all these customers clamoring for a non-manual product, my co-founder Jennifer started coding like a madwoman to address the most complained about issues.)
In parallel to Jennifer’s product-building, we needed to keep getting new customers to keep getting feedback to make sure we were improving. So, I would do a lot of cold-calling, cold-emailing to keep a pipeline full of customers.
I’d never been a salesperson before, so much like with customer development, it was difficult at first to work myself up to emailing/calling random people to do sales. It still is sometimes.
Lastly, once you have product/market fit, it’s the non-technical co-founder’s job to figure out how to grow. It could be through business partnerships and direct sales. It could be through online marketing: advertising, content marketing, built-in product virality, etc. Since, your particular company’s growth could come from a number of different channels, the most important skillset at this stage is to figure out a) how to test lots of growth channels quickly and b) how to measure those tests both qualitatively and quantitatively to see what is working.
I’m certainly no expert on all of these things, but these are the skills I’ve found to be the most important as a non-technical founder. This is what I think non-technical co-founders should be doing in a startup to make themselves useful. What does the non-technical co-founder of your startup do?
Permalink 6 notes
11 7 / 2012
Is your startup constantly zig-zagging? (like mine)
Photo credit: Gary Brownell
Hello world. After a long hiatus from my short-lived blogging career, I’ve decided to come back.
If your startup is anything like mine (LaunchBit, an ad network for email), I’ve found that we’re constantly zig-zagging in various directions. Even if you’ve decided on an idea and have set a general course for your company, there are so many zigs and zags that happen everyday. For example, a few months ago, we were trying to decide what ad formats to support in our network. We started with standard display ads, and then zagged to experiment with something completely different: text ads. And, after those experiments, we ended up adopting that format and building support for it into our platform. Other experiments we’ve tried have been complete failures, and so we’ve entirely scrapped those. When you compound decisions like these multiple times a day over the course of weeks, your startup ship ends up zig zagging a lot from its original position. And, this can be hard for a team — it seems unfocused and like we don’t know what we’re doing.
The truth is — we don’t know what’s going to work until we try it. So how do you message this to your team? How do you get everyone onboard with the idea that you don’t know what you’ll end up doing? I’ve thought about this a lot for the last couple of years, and so I’ve introduced a Ship-Raft(s) framework and tell my team this:
We’re on a tall ship — it’s our current product as we know it. We’re headed for the New World. We think the New World is generally in X direction, but we don’t have a fully resolved map for this. Since we don’t know how long it will take to get there, we need to make sure our ship is well maintained - immediately patch up any leaks that happen and stock up on enough food and resources to keep us going. But at the same time, since we don’t have a nuanced map, we need to build rafts that we can quickly launch into the water to help us explore better routes. We should spend about 20-30% of our time working on rafts, because it’s these rafts that will continuously help us improve. At this stage, we need all of our rafts to be focused on helping us find a better route for our only ship, but someday, when we grow our armada of tall ships, these rafts may be used to explore completely new directions and products. We should absolutely sink our rafts if they aren’t helping us and incorporate the knowledge we learn from our rafts into making our tall ship sail in a better direction.
In our bi-weekly goals meeting, which I structure similarly to my former employer’s OKR meetings, we decide what we need to do for our ship and our rafts. Yes, that’s literally what I call them when I write them down: “ship” and “rafts”. Our ship objectives are about executing more efficiently. We have learned X either from running our ship or from the learnings of our rafts, and so we’ll decide to incorporate Y to make the ship run faster or in a better direction. In some cases it may mean *removing* Y from our ship. Our raft objectives are about discovery — we want to learn more about A, so what’s the minimum that we need to do to accomplish this?
With this Ship-Raft(s) framework, I think we’re able to have a lot more structure amidst the zig-zagging chaos. The ship is supposed to plod on efficiently, and it does. The rafts are supposed to be running around all over the place and get dropped in and pulled out of the water quickly, and this happens too.
How do you keep everyone on the same page amidst chaos at your startup?
Permalink 3 notes