Just logged in to Google Analytics today to find that Weebly is used in exactly 200 countries! Pretty exciting. Our top countries are:
1. United States (55.65%)
2. United Kingdom (8.06%)
3. Canada (4.55%)
4. India (3.22%)
5. Australia (2.44%)
6. Brazil (1.81%)
7. Philippines (1.74%)
8. France (1.21%)
9. Netherlands (1.12%)
10. Sweden (0.99%)
One interesting observation: English speaking countries make up 70.7% of Weebly's user base. (Time to internationalize?)
Also interesting to compare against Alexa's estimates of our traffic origin:
United States (40.6%)
India (8.7%)
United Kingdom (5.9%)
Canada (4.7%)
Australia (2.4%)
Germany (2.3%)
Singapore (2.0%)
Italy (1.7%)
Brazil (1.6%)
Indonesia (1.4%)
Looking at the errors in these estimates, it looks like Alexa is heavily biased to non-US visitors, and biased towards Indian visitors.
What does your global usage look like?
If you're running an internet service, you'll probably need to send emails to your users at some point. Getting those emails through to their inbox can be quite a challenge.
You can pay someone to do it (ConstantContact, Boomerang, etc), but their rates are through the roof -- this can be as high as a couple cents per email. The lowest quote we were able to get was about $0.003 per email, with huge volume. Sending out one email to our user base would have cost nearly $2,000.
At that point, you've just got to do it yourself. One of the main things we didn't want to handle was tracking bounce messages. All major services require that you do this: if you send a message to an invalid address twice, you will be heavily penalized.
I hacked up a quick script to login to an IMAP server, check for bounce messages, fetch the dead email, and move the messages out of the inbox. Since I figured it could be useful to more than just me, I've open sourced it.
You can grab a copy of the source here: monitorBounces.php
If anybody else has written any other software to help them get past the near defacto spam classification, please let me know : )
There's one thing you'll almost certainly need when starting a company: other people's help. The right introduction at the right time can make a world of difference.
How do you get people to help you? If people's interests are aligned to yours, they'll help you out. Those people are called investors. There's another way to get people to help you: make them like you and want to help you.
This ties in with a more general problem that a lot of very technical people face: How can I be a fun person, someone that people want to hang out with?
I was born in France, lived there for seven years, then moved to Casablanca (Morocco) and lived there until I came back to the US for college. Having never spent significant time in the US, I wasn't entirely used to the socializing process when I got here, but I picked up a few simple tips by observing how some of my more popular friends acted. Since I actively did that, I made a mental note of each one. These could generally be summed up as:
"How do I make a good first impression and get people to like me?"
1- Always introduce yourself (with a smile). For some reason, this is really important and labels you as assertive, friendly and outgoing. Make sure you introduce yourself to every member of the group and look them in the eye when shaking their hand. Don't be impolite by interrupting someone, but having said that, there's something very weird about someone who stands around and doesn't introduce themselves.
2- Ask a question. There are a ton of really easy questions you can ask, depending on your social situation. These include general questions, like "Where are you from?" and "What do you do?" as well as more situation-specific ones, like "What company are you with?".
3- Listen to the answer. Keep an open mind and don't assume anything negative. That seems simple, but too many people end up hogging the conversation off the bat by talking about themselves, or judging the other person. However, everybody likes a pleasant person who asks about them, listens, and responds intelligently. They'll usually return the favor by asking about you.
4- Figure out another question to ask based on the previous response. If you can find a way to add some kind of rapport, this is best, like "Oh, you're an engineering major? So am I!" or "You work at Trulia? I have a good friend that works there!". At worst, you should be able to ask for more information: "You go to UCSB? What major are you?"
5- Ask another question. Rinse and repeat.
That's really all there is to it. Besides being generally beneficial to your social life, being a genuinely fun and interesting person has one important benefit to your startup: It makes people want to help you, even if they won't personally benefit from doing so.
In other words, if you get feedback that you're not very "sociable", it is a huge benefit for you to learn to be so. It's not something that everybody is born with, but it is most definitely learnable.
Was reading an interesting post by Seth Godin this morning about bounce rate called Silly Traffic. Google Analytics defines "bounce rate" as "the percentage of single-page visits". Which got me thinking -- what's our bounce rate?
The last time I calculated our bounce rate (before we installed GA), it was pretty good: about 50% of new traffic signed up for Weebly.
Traffic to Weebly.com is made up of about 40% new, 60% returning. Of the new traffic, a significant portion -- a little below 40% -- arrives from search engines.
I was quite surprised to log-in this morning and find out that our bounce rate is 33% for new visitors, and 20% for returning visitors.
On the face of it, this seems to contradict the beginning of Seth's article, that all sites see at least a 75% bounce rate from unfocused traffic, but I haven't had much time to think about why that might be.
What's your bounce rate?
You've built a cool product. Great! Now, you need to show it off to people. Usually, this is a demo: a quick, 5 minute tour around the product.
Giving a demo is a lot better than trying to explain what your product does in words. It lets people see exactly how things work, and is the fastest way to help them understand your product. There's also an important set of people that will be particularly interested in your demo: investors. When raising money, a good demo to investors can make-or-break the decision process. So how do you give a good demo?
When raising money for Weebly, our demo was pretty simple. We'd spend about an hour ahead of the meeting looking up the investor's website, downloading the pictures and text, and importing the template into Weebly. Then, we'd spend a few minutes to practice creating the site quickly. The end result: we'd recreate an investor's site "from scratch" in front of them in 3-4 minutes. It definitely had the intended "wow" effect.
How do you put together a good demo? Here are a few tips:
- It has to be short. It should take 5 minutes or less in person. An online video should be no more than one and a half minutes long.
- It has to look really, really cool. The demo is a visual tour, and your audience will be concentrating on what they can see. Your goal is to get them to say "Wow!" Fades and animations get annoying in the final product, but they can look really cool for a demo.
- Adapt your demo for the audience. In our case, we would tailor the presentation to the investor we were presenting to. The person you're presenting to should be able to relate perfectly to the need for your product.
- Use real data. Don't ever type in "asdfasdf" for a form field. It's so much easier to understand what an application does when you can simulate a real user. Junk data makes it much more difficult to understand the use cases. Make sure to pre-populate your application with real data that highlights the story you're telling.
- Don't demo all of your features. Just demo the ones that best show off your product and give the maximum "wow" impact.
- Follow one general topic. If you're going to switch themes, make that very, very clear. It's like driving a car: if you want to change directions, you have to stop the car first.
- Have an offline or backup version ready. The worst thing is having to fiddle with the wifi connection for 10 minutes, or something going wrong with your host/colo while you're presenting. You might only have one chance -- make sure to have an EVDO card in case wifi doesn't work, or a local version.
- Show your product in the best light. You can be realistic about the shortcomings later, if/when asked. Make sure to always show off your product, and don't ever purposely demonstrate any shortcoming.
Finally, be confident and excited! You've built something really cool, and you should be conveying that message to the audience. If you're not excited about your product, why should they be?
Just read this post on TechCrunch talking about Amazon TextBuyIt. There's 2 things interesting to me about this:
1) Is this product a result of the TextPayMe acquisition?
2) This has some very interesting implications. Amazon can now be located in any storefront, and if it becomes easy enough, it could detract from the value of traditional brick and mortar stores. I could be at Best Buy trying out an MP3 player, decide that I like it (the benefit of physical interaction), text Amazon, and buy it, all from within the Best Buy store. Best Buy paid the cost of the physical interaction (employee, store, inventory costs), but Amazon was able to score the sale.
And the obvious first upgrade: Snap a picture of the ISBN/UPC code with a camera phone and send it via picture message to Amazon.
It's always interesting to see new technology for sound. There's a huge opportunity for someone to create software that's better able to understand music the way a DJ might (BPM, key, etc) and automatically create a mix by beatmatching and cycling through the circle of fifths, for example.
thisismyjam.com tries to do that. It's a demo product built on The Echo Nest APIs. It's cool to see something like this on the web, but from my testing, it's about as good as existing software out there that's desktop-based or built into hardware like the Pioneer CMX-3000.
There's no reason why a computer can't eventually do the same thing a human DJ can. In the meantime, here's a quick mix I created with thisismyjam.
Do you take into account the hidden cost when making decisions? It's one of those areas where I used to fail miserably. I've learned to take it into account over the last couple years, but only recently was able to formulate the concept properly.
The idea goes something like this: Behind most obvious decisions is a non-obvious hidden cost, which can often outweigh the benefit of the "obvious" decision.
I stumbled upon a great real-world example in the drive-through to Taco Bell a few days ago. I realized that there was a flaw in the system: I could order, then drive up to the payment window, and not be able to pay. Taco Bell would likely throw away the food, and have to eat the cost. The system had a flaw. Engineers like fundamentally perfect systems, and that's a good thing.
But if an engineer had designed the drive-through, you would probably have to pay before they started making your food. Impossible to game, flaw destroyed. The problem is, what's the cost of the extra time involved in waiting until you receive payment before you start making the food? And what's the cost per meal wasted times the number of times that the customer is not able to pay? There's a reason they start making your food right away: It saves a ton of time, and people are able to pay most of the time.
Seems obvious, right? Then why do we still insist on requiring two password fields, one for verification? Or two email fields? Sure, a banking application might require this... but your average web app? You could look at it this way: What's the chance that someone will mistype both their email AND password, weighed against the drop-off in signups because of the extra form fields. You will drop a significant number of sign-ups with the added fields, but there will be a very small percentage of people who get both their email and password wrong.
Another pet peeve that PG originally pointed out to us: requiring email confirmation as part of the sign-up process. Email is notoriously unreliable, and often gets flagged as spam or not delivered. Why would you require an email confirmation as part of your sign-up process when there is a high probability that the email will never be received, and the user won't be able to sign-up? Maybe I'm in a computer lab and I get email on my laptop. Tough luck, I can't use the website now, when I want to -- I have to wait until I can check my email. Does that high of a percentage of people not supply their correct email address, that you need to require confirmation? And does having a confirmed email address outweigh the big drop-off in signups?
We've learned to take the hidden cost into account with Weebly. It can apply to across the board: Adding features weighed against the added complexity to your application, bootstrapping weighed against the loss in growth momentum, increased security weighed against the increased difficulty in using the application.
In a nutshell: each decision you make will have a negative counterpart. Even (and especially) the most obvious decisions. Figure out what that hidden cost is, and make sure it doesn't outweigh the original benefit.
Netvibes, I've loved you since day 1, but you've been getting progressively worse and worse. Please, shake off your aspirations of ruling in the hot buzzword categories -- stop trying to be a social network, that's not why I use you, stop trying to be the end-all-be-all of widget embedding (ditto).
I don't really care about your new releases (Ginger, Coriander, paprika or whatever), I just want to be able to log-in every day and check my news feeds. I don't want to have to go through a painful "migration process" -- sounds like something taken out of an enterprise software book, definitely not suitable for a consumer product. And I don't want to have to request an invite to said migration process, get the email, input the invite into netvibes, begin migration, and have to wait hours until the migration is complete.
What I would like is if you fix your most basic bugs that have been there since day 1, instead of developing world-dominating features. The bugs that relate to your feed reader, the core of your product. Like the bug where when I have a feed open and the feed refreshes since I've had it open, the stories I click on display the story a few places up. Or the bug where about 50% of my feed will start the "Loading..." process, only to go completely blank -- the rest of my feed is ok though! Only half of it goes blank when it tries to load, the other half loads properly. That is especially annoying to me. Or the fact that hitting "refresh" on your feeds is flaky -- I usually have to reload the page if I really want to get a refresh.
I'd be the first to understand that everybody has their bugs. But before embarking on these huge feature releases, can you please fix the small things that have been there since the beginning?
EDIT: check out the comments on this blog post and this blog post -- looks like there are a lot of unhappy people.
