화요일, 5월 08, 2012

Early Startup Time Wasters

Early Startup Time Wasters
Source: http://talkfast.org/2012/05/05/early-startup-time-wasters

May 05, 2012
by Jeff Miller


A major difference between launching a brand new startup and working on one that’s a year or two old is quality of shot selection. Every day begins with 1,000 doors in front of you: which door do you go through to make the most progress? Shot selection is choosing what to focus on at the expense of other forgone opportunities. It’s one of the most critical skills in running a startup.

As a company matures, I think it’s normal (ideally) for judgment to improve and shot selection to get a lot better, resulting in less wasted time and more forward momentum. This can be driven by many things. Maybe it’s having enough live users to give you feedback on market fit. Or you found some role models to help with targeted advice. Or you figured out how to optimize against your true traction metrics.

Looking back on the first six months of my own startup, I’m embarrassed by how terrible my shot selection was. I routinely spent time on features that ended up having zero impact on the business. I was especially prone to working on short-term (1 to 2 week) projects that seemed fun and harmless, but wasted a lot of time when you add them all up. I simply wasn’t focused enough. Thinking back on it now makes me cringe.

Here are some things I wish I had never spent time on:

1. Invite-only access. Invites are traditionally a strategy for stoking interest in your product while also managing the scalability of your roll-out. In my case, all I accomplished was making some users angry when I left them on the invite list too long. It seems strange in retrospect that I would keep new users out of my app on purpose, but at the time I thought it would help with virality. Also, implementing the numerous moving parts of an invite-only access system consumed much engineering time.

2. Real-time traffic measurement. I went through a phase where I used GoSquared (and before that, Chartbeat) to observe users of my webapp in real-time. I was able to see how many visitors were on my site, where in the world they were coming from, which pages they were viewing, etc. Vanity metrics at its finest. And, of course, I had to waste time checking the traffic dashboard 10 times a day. Nowadays I ignore real-time stats and just use Google Analytics to look at historical trends.

3. User admin dashboard. Another engineering boondoggle, I built this amazingly detailed admin panel where I could view all my registered users along with matching social and biographical information pulled from the Qwerly API (since acquired by Fliptop). For example, if a new user Fred Bloggs signed in to my app with Facebook, I could also see Fred’s LinkedIn profile, his handle on Twitter and his picture. The original purpose of this dashboard was to identify influential users to further engage with, but I never found the time. And after my app gained more than a few thousand users, the dashboard became unscalable.

4. Experimenting with ads too early. I was so eager to attempt monetizing my site with ads that I placed grocery-coupon text links on the front page when I only had a few thousand uniques/day. Don’t know why I was surprised when only about ten people clicked on the ad. It was a cold-shower lesson in low CTR’s. You need real traction and attention on your site to attract quality advertisers, too.

5. Amazon affiliate links. Another monetization experiment I shouldn’t have tried in the first place, but was driven by an unfounded belief that users would want to purchase cookbooks while browsing my site. Building this system also consumed several days’ worth of engineering time—it required learning about the Amazon Affiliate API, writing code to match cookbooks to recipes, and so on. The final profit was less than $1/day. I have yet to meet anyone who is making serious money on the side with Amazon links.

6. TechCrunch. TechCrunch can be a good way to gain visibility among investors and the tech community in general, but in my experience, it didn’t have value beyond that. (Perhaps some SEO value.) I regret I expended so much mental energy figuring out how to get my startup covered on TC. When I finally did make it onto TechCrunch, both the article itself and the resulting traffic were very underwhelming. I should have concentrated on other outlets that are less tech-centric and more suited to my site’s audience—for example, LifeHacker and kottke.org, which ended up yielding 100x as many signups as TC.

7. One-off partnership projects. I once spent about two weeks building a custom prototype with my API as part of a potential partership with another company. The partnership was never fulfilled and the final result ended up basically zilch. There’s nothing particularly wrong with this situation; sometimes you have to gamble a little bit of upfront time for a larger gain down the road. But two weeks worth of time is way too valuable in the early days of a startup. I should have just said no thanks to the partnership and instead devoted that time to making my product more awesome.

8. Coffee meetings / “let’s jump on a call”. This is rookie stuff, but initially I was caught off guard by how insidious a “quick” meeting or phone call can be. They always go longer than expected, can eat up half a day of work, then destroy the productivity of the other half because of lost focus and having to play catch-up (especially if you’re writing code). It’s important to concentrate on meetings that add value or build relationships, and avoid the people who just want to pick your brain for their own purposes.

9. Excessive side projects. Side projects are like comfort food for coders. I’m a believer in doing a side project here and there to keep burnout at bay. Unfortunately, there was a period where I overdosed on them and was working on enough side projects to rival my real startup. I think it’s particularly easy to fall into this trap when your company is new but not brand new, i.e. traversing the Trough of Sorrow. Better to just suck it up and stay focused on product.

10. Working from home. I spent the first year of my startup working from a home office. After that, I moved to a spartan desk in a shared space in downtown Palo Alto. My productivity from the office space is easily 2-3x that of the home office. I can’t explain it well but there’s a mysterious psychological barrier that prevents me from truly cranking when I’m working from home. If I had started on day one working from an outside office, I’d be way further along on my company now. At the outset, I had no idea that would be true, though. Hindsight.
It’s easy to criticize with the benefit of hindsight, but I believe most of these mistakes were avoidable at the time. They all distracted me from the one strategy that always works no matter what—iterating on your product vision, listening to feedback, and working towards making your product awesome.




-----
good article...

Cheers,
June

화요일, 4월 17, 2012

CryENGINE 3 gives us a glimpse at the future of gaming [video]

CryENGINE 3 gives us a glimpse at the future of gaming [video]
Source: http://www.bgr.com/2012/04/16/cryengine-3-gives-us-a-glimpse-at-the-future-of-gaming-video/





-----
OMG, looks great!!!

Cheers,
June

월요일, 3월 12, 2012

방황해도 괜찮아

고도원의 아침편지


'방황해도 괜찮아'


기회는 얼마든지 있습니다.
내가 찾고 만들고 도전하면 됩니다.
젊다는 이유 하나만으로도 뭐든지
도전할 기회가 있습니다. 연구하고
도전하고 그에 대한 결과를 만들어
간다는 것은 성공 여부와 상관없이
그 자체만으로도 행복한 일입니다.


- 법륜의《방황해도 괜찮아》중에서 -


* 젊음에 주어지는
몇가지 특권이 있습니다.
방황과 실패입니다. 방황한 만큼
성숙해지고, 실패한 만큼 위대해집니다.
방황해야 또 다른 새로운 길을 찾게 되고
실패해야 또 다시 도전할 수 있습니다.
젊었을 때만 특권처럼 주어지는
아름다운 선물입니다.

-----
그래... 괜찮아...
Cheers,
June

목요일, 3월 01, 2012

[고도원의 아침편지] 서른다섯까지는 연습이다


고도원의 아침편지


서른다섯까지는 연습이다


'어어, 이게 아닌데...'
하면서도 무엇이 맞는 건지 잘 몰랐고,
내가 정답이라고 생각하며 내렸던 결정은
되레 덫이 되어 나를 넘어뜨리곤 했다.
내년이면 서른다섯이라는 생각에
새삼스럽게 그리고 소스라치게 놀란
어느 밤, 이제 그 헌 연습장일랑은 덮고
새 노트를 펼치고 싶다는 생각이 들었다.

- 노진희의《서른다섯까지는 연습이다》중에서 -

* 서른다섯.
기막히게 좋은 나이입니다.
지천명, 이순을 넘긴 사람들에게 서른다섯은
입을 쩍 벌리게 하는 '무한대'의 새파란 나무입니다.
뭐든지 할 수 있고 무엇이든 다시 시작할 수 있는
나이입니다. '어어, 이게 아닌데'가 아니라
'아아, 이제부터 진짜 시작이다' 외치며
신발끈을 다시 묶고 달려 나가십시오.
한숨 대신 함성을 지르며...


-----
꼭 서른다섯이 아니더라도 "서른다섯까지는 연습이다"
듣기 참 좋은 말입니다.
지금까지는 앞으로 달려 나아가기 위한 연습이었다.
이제 신발 끈이 잘 풀어지지 않게 맬 수 있으니 자신있게 한 번 뛰어보자...

Cheers,
June

토요일, 1월 14, 2012

The World is Full of Real People

Source: http://jumpstartlab.com/news/archives/2012/01/13/the-world-is-full-of-real-people/


The World is Full of Real People

Posted January 13, 2012 by Jeff

Yesterday at CodeMash 2012 in Sandusky, Ohio, I gave a five minute lightning talk about something that’s been in my mind: the developer’s life of priviledge. Here’s the text of my talk:

The World is Full of Real People

You are in a spot of exceptional privilege. You’re well paid to move your fingers around a keyboard. Your greatest danger is probably carpal-tunnel syndrome.

In a time when almost thirty percent of our country is unemployed or underemployed, you make jokes about how annoying recruiters are wanting to offer you job after job. There’s nothing here that’s your fault. You didn’t do anything wrong. This isn’t about blame and I’m not saying you should be ashamed of anything.

But you do need to recognize you lead a life of privilege.

We need to do more.

It is easy to write software for other developers. You understand what it’s like to be a developer, so you know exactly how they think and operate. If you want to make quick money, build tools that make developers lives easier.

We can all then form a big circle and pat each other on the back.

Meanwhile, your new testing framework didn’t make any jobs. It didn’t bring significant joy to anyone’s life. In the big scheme of things, you’ve taken your gifts and used them to pleasure yourself.

Let’s take a step back.

Real people don’t use technology, at least not the technology you build. Unless you work at Facebook, the chance of anyone at this hotel having ever heard of your company, much less your product, is slim. Why is that? Why do we build so many things for ourselves?

Because it’s easy.

Solving real problems is hard. Changing real lives is hard. Making real people happy is hard. When we do write things for the public, we find out that those users are “such idiots” – they can never do things properly. “It’s not worth it!”

You wield the power to make amazing change in the world. You can fix problems with a speed and scale that no other industry can match. Your work, once created, can be replicated at almost zero cost. Your power breaks economics, terrifies governments, and endangers the status quo.

Instead of measuring ourselves by the size of our Series A or our average profit per employee, let’s measure in lives changed.

I want to look back and say “I worked harder than I had to. I gave up time with my kids, with my friends, to do what needed to be done. To give back to the rest of the world, to enable them to live just a little bit happier, a little bit better.”

The problems of our world can’t be fixed with software, that’s naive. But they can be fixed by people, and great software helps people do what needs to be done.

As a developer you can only do so much. You don’t understand all the problems, the nuances, the challenges of the world. That’s ok. The people who do understand those challenges are desperate for your help – they’ll tell you everything you need to know. Just ask.

I’m not saying you need to change a thousand lives. But if you could say that you really changed ten, what would that feel like?

You might not ever have a Wikipedia page, but you’d live on in those ten memories – in the lineage of families they start, the kids that grow up happier because their parent is employed, less stressed, or otherwise improved. When you think about generations upon generations, the compound interest on the investment you make in others pays off in the biggest way.

Your software will be forgotten, but true impact never will.

What’s your mark on the earth? Is it big enough, is it deep enough, is it good enough?

Get to work. Thank you.


-----
Cheers,
June