SmoothSpan Blog

For Executives, Entrepreneurs, and other Digerati who need to know about SaaS and Web 2.0.

Archive for January 1st, 2008

New Year’s Resolution: Keeping Head Above Water With RSS Feeds

Posted by Bob Warfield on January 1, 2008

If you’re like me, you took a little time away from the blogosphere and you’re coming back to find your cup runneth over.  Here are my tips for dealing with that problem all the time: 

Develop a Triage Mentality

If you are bothering to read very much of this article it’s because you have too much to read in your blog reader!  Develop a triage mentality.  You have to root out and mark as read as many articles as possible as quickly as possible so you can go back and focus on the important stuff that requires more thought. Create a Slush Pile and Empty it Frequently 

Use a reader that let’s you put feeds into folders, such as Google Reader.  Create a “slush” folder.  Put feeds in there that you won’t feel badly about if you don’t read every single post.  For me, that’s things like Techmeme and Scoble’s Feed Blog  (sorry Robert, but it’s 1/2 to 1/3 of my messages some days!).  Dump the slush folder every time you get finished reading.  Just toss out all those unread feeds.  If they’re important, they’ll turn up somewhere else before too long anyway.Use the Share Log and Star on Google Reader

When I mark an item to “Share”, it goes into my link blog so others and I can refer back to it as desired.  When I mark it with a “Star”, it means I really need to think more on the topic and maybe even blog on it.  I use the “Star” as a priority marker.  This gives me three easy priorities.  Starred are highest, Shared are next, and the Slush pile and items marked “Read” but not shared or starred are the lowest.

Scan First for Low Hanging Fruit

In the spirit of triage, learn to scan everything quickly first.  You’re not reading, you’re just scanning.  I do the low hanging fruit scan looking at “All” feeds.

Leave the slush pile out of the scanning process–you don’t know if you’re going to get to it or not.  Scanning gives you a quick idea of the major themes.  Try to identify the low hanging fruit.  These are articles that are easily marked “read” so you can move on.  Once you mark one article “read” on a theme, mark the rest without scanning any further than it takes to know they’re about the same topic.  You’ve already made a decision to pluck that low hanging fruit.  Learn to triage 2 out of 3 or so articles, or at least 2 out of 3 themes.  Anything less, and you probably won’t have time to read the interesting stuff.

If it’s important to know more about the low hanging fruit you sent on, it will either come up again, or you can go back and search for it.  At least you know about it.

Relegate Whole Categories to Low Hanging Fruit

This New Year’s I’m not even bothering to read anyone’s retrospectives.  Why?  Because all that stuff is old news.  If it’s important, it will come up again somewhere soon.  Someone will link to it.  You’ve probably already read it and triaged it earlier.  Why rehash it? 

I am tempted to put predictions into the same category, and have been pretty ruthless at triaging all but my favorite bloggers.   

I put link lists into this category year around.  Unless they’re really short and one catches my idea as I’m preparing to delete it, I’m not interested.  Sorry, but if it’s important, it will come back up.  It will be linked to in the context of a fuller article.  After all, the person publishing the link didn’t think it was important enough to spend much time on it, so why should you?  Note that I am schizo about it.  If someone makes their link lists as a feed, such as Scoble has done, I will often subscribe, but I’ll still stick that feed into my Slush Pile:

Create a Few Tags for Your Major Interests

I use these tags as a way to organize and triage.  I try to apply  the tags during the scanning pass.  Fewer is better.  Say a dozen or so that you can easily remember.  For me, it’s things like “SaaS”, “Web2.0”, “Marketing”, “Startups”, and so on.

Zap The Oldies

I tend to leave stuff hanging around in the reader when I think I want more time to get to reading it.  When the box gets overly full, it’s time to sort “All” into oldest first and get ruthless.  Am I really every going to get to that?  Is it even relevant any longer?  I once heard this described as the Napoleonic School of Organization.  If it’s important, it will come up again.   If you really feel guilty about zapping these, tag them.  It feels like you’ve almost done something meaningful with them if they’re tagged.

Learn to Quickly Triage the Biggest Posters

Techcrunch files a lot of posts.  I have to be more ruthless about triaging them.  I zap every “deadpool” post without a pause, which is a Techcrunch-specific tactic.  I zap the pure gossip from Techcrunch.  I look for real trends and interesting pieces that matter.  With frequent posters, look for fast “no’s” and zap lots of posts.

Consider which of the feeds you subscribe to generate most of the posts.  Develop some reflexes around triaging them based on what you like or dislike about them.

Dump Your Least Favorite Bloggers

Sometimes you subscribe to a blog thining its going to be great, and then it isn’t.  Maybe they always say essentially the same thing, just twisted to the theme of the day.  Maybe there is too much of their personal baggage involved.  Maybe they only write rarely about what you thought they were going to write about a lot.  Dump them from your feeds and find someone new.  Anytime a post annoys me, I go to the blog’s home and just take a look at the last 10 or so posts.  If there is nothing redeaming for 10 posts, I dump the feed.  That’s too high a tax to wade through.  If they say something important about a theme you’re interested in, you will likely see them quoted elsewhere. 

Put a Time Limit on Your Blog Reading

It’s very easy to get stuck checking for new posts all day long.  That’s a huge time sink.  Triage is effective when measured against a fixed time limit for blog reading.  I allow 1 to 2 hours a day maximum.  I prefer to read for an hour when I first sit down at the computer.  I may extend that to 2, but usually because I’m writing blog posts or researching a topic.  I will have completely scanned what’s there in the first 5 or 10 minutes and the rest of the time is more serious reading and research.

Posted in Web 2.0 | 3 Comments »

Amazon Raises the Cloud Platform Bar Again With DevPay

Posted by Bob Warfield on January 1, 2008

Wow, what an exciting time to be watching the Amazon Cloud Platform evolve.  We’re just beginning to think through the recent SimpleDB announcement when Amazon launches DevPayLucid Era CEO Ken Rudin says land grabs are all about a race to the top of the mountain to plant your flag there first.  It seems like Amazon has hired a helicopter in the quest to get there first.  Google, Yahoo, and others are barely talking about their cloud platforms and here is Amazon with new developments piling up on each other.  And unlike some of the developments announced by companies like Google, this stuff is ready to go.  They’re not just talking about it.

What’s DevPay all about, anyway?  Simply put, Amazon are providing a service to automate your billing.  If you use their web services to offer a service of your own, it gives you the ability to let Amazon deal with billing for you.  It’s based off the pricing model for the rest of the Amazon Web Services like EC2 and S3, but you can use any combination of one-time charges, recurring monthly charges, and metered Amazon Web Service usage. You have total flexibility to price your applications either higher or lower than your AWS usage.  In addition, they’re promising to put everything they know about how to do e-commerce (and who knows more than Amazon?) behind making the user experience great for your customers and you.

It’s not a tremendous big step forward, but it’s useful.  It’s another brick in the wall.  There are companies out there providing SaaS infrastructure for whom billing is a big piece of their offering, so obviously it is a problem that people care about having solved.  What are the pros and cons of this particular approach?

Let’s start with the pros.  If you are going to use Amazon Web Services anyway, DevPay makes the process dead simple for you to get paid for your service.  It’s ideal for microISV’s as a way to monetize their creations.  The potential is there for interesting revenue that’s tied to usage in the classic SaaS way.

What about the cons?  Here there are many, depending on what sort of business you are in and how you want to be percieved by customers.  I break it down into two major concerns: flexibility and branding.  Let’s start with branding, which I think is the more important concern.  It’s not clear to me from the announcement how you would go about disassociating your offering from Amazon so that it becomes your stand alone brand.  You and your customers are going to have to acknowledge and accept that the offering you provide is part of the Amazon collective.  Resistance is futile.  This is the moral equivalent of not being able to accept a credit card directly, and instead having to refer customers to PayPal.  It works, but it detracts a from your “big time” image.  If having a big time stand-alone image is important for you, DevPay is a non-starter at this stage.  It’s not clear to me that Amazon would have to keep it that way for all time, but perhaps they need to protect their own image as well, and would insist on it.

Second major problem is flexibility.  Yes, Amazon says you can “use any combination of one-time charges, recurring monthly charges, and metered Amazon Web Service usage”.  That sounds flexible, but it casts your business in light of what resources it consumes on Amazon.  Suppose you want a completely different metric?  Perhaps you have another expense that is not well correlated with Amazon of some kind that has to be built in, for example.  Perhaps you need to do something completely arbitrary.  It doesn’t look to me like Amazon can facilitate that at the present.

Both of these limitations are things Amazon could choose to clean up.  So far, the impression one gets is that Amazon is just putting a pretty face on the considerable internal resources they’ve developed for their primary business and making them available.  What will be interesting is to see what happens when (and if) Amazon is prepared to add value in ways that never mattered to their core business.  Meanwhile, they’re doing a great job stealing a march on potential competition.  As a SaaS business, they should be quite sticky.  Anyone that writes for their platform will have a fair amount of work to back out and try another platform.  DevPay is another example.  It will create network lock-in by tying your customer’s business relationship in terms of billing and payment to Amazon, and in turn tying that to your use of Amazon Web Services.  For example, that same lack of flexibility might prevent you from migrating your S3 or EC2 usages to, say, Google.  There doesn’t look to be a way for you to build the Google costs into your billing in  a flexible way.

We’ll see the next 5 to 10 years be a rich period of innovation and transition to Cloud Computing Platforms.  Just as many of the original PC OS platforms disappeared (CP/M anyone?) after an initial flurry of activity, and others have changed radically in importance (it no longers matters whether you run PC or Mac does it?), so too will there be dramatic changes here.  The beneficiaries will be users as well as the platform vendors, but it’s going to take nimbleness and prescient thinking to place all your bets exactly right.  The good news is the cost of making a mistake is far less than it had been in the era of building your own datacenters!

Related Articles

To Rule the Clouds Takes Software: Why Amazon’s SimpleDB is a Huge Next Step

Coté’s Excellent Description of the Microsoft Web Rift

Posted in amazon, data center, ec2, grid, saas, strategy | 5 Comments »

 
%d bloggers like this: