porchdog:

Twitter’s gigantic freakin’ revenue opportunity is promoted tweets. And similar to how Google found its business model at Goto.com/Overture, Twitter is taking its cue from StumbleUpon. But first….

Remember when Google didn’t have a business model? Yeah, the Internet and media giant with a valuation of $150-200 billion, $35+ billion in annual revenue, and ~$15 billion in annual cash flow couldn’t figure how to generate revenue while it was growing like a weed before 2000. Then they ‘adopted’ the paid search model; i.e., took it from Goto.com (which became Overture, which was acquired by Yahoo), got sued by idealab (Goto.com’s parent), settled for 2.7 million Google shares (which would be worth over $1.5 billion today if they never sold it - but they did), and yada yada yada for more information, well, Google it.

 

Read More

Great post from David

(This was originally published as a guest post on Betabeat)

You’ve made the leap and are doing a startup. It’s just you and your co-founder, and you’re pushing out code on a daily basis. Fast, fast, fast. You’re well versed in the rules of agile development, have tried out 10 different feature and bug tracking tools, but you’re still falling back on email as a primary way to communicate changes to your product. And remember that bug you talked about over the phone three days ago? Yeah, that never got fixed. Here are five tips on how to organize your project without compromising too much on speed.

1- For new features, new layouts, new anything, read and memorize Ryan Singer’s Introduction to Using Patterns in Web Design. More importantly, you have to buy into why this is important. After a long conversation about a new feature immediately sketch out a design following these steps. If you’re an amazing developer (or are as lucky as I am and work with an amazing developer) sometimes you’ll get out of a meeting and the feature is ready in 20 minutes. It’s still worth going back and documenting this with design patterns after the fact. More on this in #2.

2- With only two people, feature and bug tracking software can feel like more trouble than it’s worth. There is one important reason to continue doing it: keeping good records. I like Pivotal Tracker, but there are plenty of good options that are free or affordable on almost any budget. Even if a bug was fixed 10 minutes after an email exchange, go back and write the bug up and mark it as cleared. There will come a day when that bug creeps up again and you’ll be able to flip the switch that it needs attention again. There will come a day when you want a new hire, contractor, or potential investor to see the evolution of your product. You can continue with emails and note cards, but keep these records even if it feels like a hassle now.

3 – Take testing seriously. If you don’t have a QA environment set up, you need to pick out low traffic times and test like your reputation depends on it. It does. Set up a check list for major changes to your product. With every major bug fix and enhancement, run through those same critical actions first, and then obsess over the specific change made. Don’t wing it and don’t ignore potential collateral damage. The only thing more impressive than two people pumping out an impossibly hard project, is two people pumping out an impossibly hard project that works the first time you use it.

4- If Google Analytics doesn’t include your key performance indicators, build those analytics systems in house. We couldn’t afford the email analytics packages on the market, so we built them. This initial investment of your time will pay for itself 10x over the lifespan of a project, and will be a pivotal part of your prioritization process for steps 1 and 2.

5- If a live bug is continuously being pushed down the prioritization list, consider nuking the feature all together. If it’s not important enough to get fixed after a few release cycles or weeks, just get rid of it. This is true regardless of your team size, but it matters even more when it’s just the two of you. There is no one else to pull off a project to give this attention. Your analytics and user feedback will serve as confirmation of this decision.

You’re moving so fast with two people that you’ll often feel burdened by process. Make sure you’re balancing light weight process with good documentation and some semblance of routine. This works for me. How does your two person team pull it off?

My mom is awesome.  She’s writing a bunch of family stories and publishing them to a private blog for our family to read, and in one she explained the history of The Get Down Guy: 

1986
William, Philip, Mary, Tipton, and I attended a University of Texas baseball game at Disch-Falk Field. Philip was playing t-ball, and we were going to see the big guys play.  And of course there were hot dogs to be eaten, stairs to be climbed, tunnels to run through, and other folks to check out as well as watching the game.
Philip watched some of the game, and he wandered around a bit exploring.  He was old enough to have some freedom in the stadium.
Will was about two and a half.  He just watched the game. He did not ask to go places or to follow Philip around. 
We were more than a little surprised at how intently Will was following the action.  He stood and watched. He sat and watched. He ate and watched. He watched!
About mid-way through the game William turned to Tipton and stated, “When I be big, I be The Get Down Guy.” He pointed to the catcher.  

So there you go.  That’s how this blog got it’s name.