When we started Woobius back in 2007, we believed (rightly or wrongly) that we needed to be able to provide a relatively complex, "UI-heavy" front-end to make things simple for our non-technical users. For example, one of the key screens in Woobius is an explorer-like file browser, loved by users, and only possible because of the technology we picked.
We surveyed the field in 2007, which was in the very early days of jQuery, Dojo and other rudimentary toolkits, and came to the conclusion that it would be very hard indeed to use them to deliver our vision (particularly since IE6 support was not optional for us).
So we picked... Adobe Flex.
As a technology cofounder, one of your unspoken functions is to be a visionary. Businesses are long-term endeavours (or should be). When you make fundamental technology choices for a business, they are there to stay. The longer such a choice is made and not changed, the longer it will take to change it. So, when we chose Flex, we chose it not for the short term (as we may have thought), but for years to come.
And, in hindsight, that was a mistake that cost us.
The cost of using Flex
When Kublax (a Mint clone) closed its doors in February 2010, articles mentioned there was an alternative called Money Dashboard. I went to check it out. I signed up. I went to the login screen, and I felt this sinking feeling in my stomach. Money Dashboard uses Silverlight. Oh woe! In 2010? Sure enough, within a year, Silverlight was doomed by Microsoft themselves (followed, a year later, by Flex itself). The anonymous tech cofounder of MoneyDashboard made the same mistake we did, though even more flagrantly. I never even bothered to log in, in the end, put off and saddened by the choice of Silverlight.
The history test
When you're picking what technologies to use in your brand spanking new startup, your responsibility as a technology cofounder is not just to make the best choice for today, but to look 3 to 7 years into the future, and make a choice that will be sustainable for at least that long, if not longer. Don't lock your startup into a technology path that is a dead end.
Yes, technology changes rapidly and somewhat unpredictably. That is precisely why you need to make sure that the fundamental, critical pieces of technology that your company depends on are there for the long haul, not dependent on a single vendor, and, most importantly, pass the "history test".
Every time you choose a critical technology to lock yourself into, ask yourself: "Is this technology on the right side of history?"
If it's not, think again.
If you read this far, you should follow my RSS feed here.
How to become a must-have ✶
Great article by Mark Richards, proposing a technique for identifying tough, valuable problems that could make you a lot of money:
The value of a problem directly correlates to the time people will take to tell you about it.
Time and time again we find that if busy people, who fit your target customer profile, are willing to give you valuable time simply to discuss a particular problem, with no clear promise (yet) of a viable solution, then you have an important problem. The kind of problem a startup, with limited resources, no brand, an incomplete product and a small team can actually sell into.
Worth reading the whole article. I'll keep an eye out for more good stuff from Mark, he seemed to be planning a follow-up to this, though it hasn't been posted yet (the article is from September 20th).
Zombie Startups ✶
My greatest fear as a startup founder isn’t to fail, it is to become a zombie startup. Kind of like in the 6th Sense when Bruce Willis doesn’t realize he is dead and tries to have a nice dinner with his wife, there are startups out there who are still “operating” but might as well not be.
The first thing you need to do is acknowledge the reality of your situation. From there, figuring out what to do next is a lot harder and a very personal and contextual decision, but you should embrace it with vigor. Don’t waste single moment of your life, or the time of those on your team, to begin plotting the next step.
Danielle also points out that if your startup has failed, hard, don't shy away from calling it a failure and moving on.
Remember: impatience kills startups, but patience kills human beings.
How to explore and develop a business idea ✶
Here's a great article by Noah Kagan, outlining the steps from defining a business idea, to evaluating its market potential and finally testing its viability.
This should be a must-read for new entrepreneurs, as a step-by-step template for getting started without risking everything into a moon-shot startup. This approach may not make you the next Steve Jobs, but knowing how to do it will require you to learn many skills which are useful in any business.
Build, polish, polish, polish ✶
Oscar Del Ben:
It’s very difficult to get it right the first time, so it makes sense to spend more energy polishing your products.
The old truism for software projects in big corporations was that 75% of a project's technology cost is maintenance. In the world of tech startups, where a product that stops being developed is a product that's on the (sometimes slow) way to the graveyard, you can replace maintenance with polish, and change the 75% to 90% or even 95%, if your MVP is minimal enough.
This is one of the reasons why outsourcing rarely works for long-term product development. Working with a vendor who has other priorities is rarely a great way to add polish. You need the person in charge of putting the technology together to care about the polish.
Launching too soon? ✶
Emile Petrone put his startup up on HN "before it was ready" and learned some lessons:
Because I launched Housefed before it was ready, I addressed the problems I didn’t know about. Had I launched when meal booking was fully finished, I would have been adding bugs ontop of bugs. Many of your initial assumptions are wrong. You won’t know which ones until you get real users on your site. So my advice -
Launch your before you core functionality is done. You’ll fix the bugs you don’t know you have.
The point seems fair, but a distinction should be made between "launching" and "going public". Launches are formalities, PR events that are contrived to build up attention and draw traffic. In that context, "launching" before you're ready can be catastrophic.
On the other hand, getting some attention from very-early-adopters like the HN crowd when your product is still very basic can indeed help tremendously. There are some ideas which you may want to keep under wrap until they're ready, but the vast majority of web startup ideas are not in that category. If you think your idea needs to stay hidden until it's ready, and you're not a startup veteran with at least three successful startups under your belt, you're probably wrong.
Don't be shy to have a proper "launch" a year later when the product kicks ass, though. Having millions of users doesn't mean you can't launch!
If you read this far, you should follow my RSS feed here.
What are the best metrics? ✶
Andrew Chen makes an excellent point about metrics:
Metrics are merely a reflection of the product strategy that you have in place.
What you are trying to do should lead what you want to measure, not the other way around. It’s for this reason that the blanket questions and answers around “best” metrics are meaningless- the question is, what are you trying to do.
It sounds obvious when stated, but it's so easy to focus on measuring metrics without understanding why you're measuring them. That being said, because most startup's goal is to increase the bottom line, there are some fundamental metrics which, when used properly, will tend to appear in almost any sensible strategy.
But, at the end of the day, the relevant metrics depend on what you're trying to figure out, what hypothesis you're trying to test:
So ultimately, the important part is to figure out what you are trying to do and what the expected behavior is around it. Only once you have that should you then ask yourself how you’d validate and test it using metrics.
Paid iPhone apps vs in-app purchases ✶
Tony Wright investigates the economics of paid apps vs in-app purchases, and finds that IAPs are where the money is.
So why are free apps outperforming paid apps? That deserves its own post. In brief, it comes down to ARPU (average revenue per user). Farmville-style games can pull in an ARPU $5 or more per month. In fact, there are reports of $13 ARPUs. Per month! Per user! Average!
How is this possible? Virtual goods elegantly fill up the demand curve for an offering. In other words, they accommodate customers who can happily spend hundreds or thousands of dollars (“Whales”, in Vegas parlance) without having to give up mainstream users (who can still be valuable as evangelists beyond the fact that they give the whales someone to play with).
This shouldn't be a huge surprise. After all, there's a good reason why SaaS is such a popular business model: a low monthly price tends to generate more revenue than a higher up-front price (for most types of products). IAP's throw in the advantages of an app-store like model where people can keep buying more without entering their credit card details.
In conclusion: if you can make your app charge via IAPs (but that's not always possible or advisable), do so, because it will make a significant difference to your revenues. In particular, as Tony suggests, try to ensure that if a customer turns up who, for whatever reason, feels like blowing $500 on your app, give them a way to do so.
If you read this far, you should get more similar articles by email.
Recruiting in the Valley: the recruiter honeypot ✶
Elaine Wherry has written a detailed analysis of recruiting in the Valley. If you're based anywhere else, it may be of mostly intellectual interest, but if you're competing for developers there, it seems like a must-read - and highly entertaining, too.
The honeypot idea emerged slowly, “If only I weren’t a founder! Which recruiters would have contacted me as an engineer?” I stewed on the idea of posting my resume online with a fictitious name for days and then one sleepless night, without telling anyone, I woke up and posted a small three-page website with an about page, resume, and blog for a supposed Pete London whose interests and engineering persona mirrored my own except he wasn’t a founder. I swapped out my post-graduate experience with my husband so it wouldn’t be too easy to trace back to me. I returned to bed with a small glimmer of hope – I had been hunting for recruiters for months but now the recruiters would come to me!
Elaine goes on to break down and analyse the data she has gathered, and derive some solid actionable tips for startups who need to hire. Read it here.