11 August 2010 9:48p Pacific

Alikewise learnings #1: DIY PR

by Matt Sherman

Thought I would write a few posts to reflect on what I’ve learned with my startup, Alikewise, day jobs, and NYC. This is the first.

Quick history: I decided to leave a comfortable job at a great design firm in early 2009 to pursue this idea, spent about a year getting things off the ground, and launched earlier this year. A couple of months ago I took an opportunity at Stack Overflow.

Alikewise is a two-person company, and we are quite enamored with the DIY thing. I figure there is nothing I can’t learn.

So we decided that PR was one of those things. We figured it was all about putting in the time, finding the right names, sending email, following up. Almost nothing resulted from that.

We reluctantly hired a (very) small PR firm. We are paying in the low 4-figures on a 3-month contract.

The results have surprised us – a steady stream of articles and blog posts, probably 20 substantial ones so far. Each article manages to ripple out to Twitter and Facebook and other blogs. We’ve gotten around 1000 new users over the last month.

Our PR team is not particularly tech-savvy, but they’ve gotten it done. I don’t think it’s magic – I think it’s elbow grease and good instincts.

Editorial articles (ie, written by real people at real publications) have given us the highest-quality traffic: low bounce rates and high time-on-site. Them’s our customers.

Aggregators like Reddit and StumbleUpon are lower quality but higher quantity traffic. StumbleUpon is our largest referrer, but the bounce rate is high. We’re not complaining, but aggregators will not make your business.

(Facebook and Twitter, btw, and medium in both quality and quantity. That’s to be expected: they are halfway between editorial and aggregator.)

Each new customer acquisition at this early stage is disproportionately valuable. The first 1000 real people are the difference between existence and non-existence. If it ain’t happening, you gotta consider getting help.

So, lesson learned: I am glad we tried the DIY PR route. When it became clear we weren’t getting it done ourselves, we switched from DIY to “YDI”: alright, You Do It.

Coincidentally, it’s allowed me to focus on our product and our customers. :)

Future topics:

  • A day job can be good for your startup
  • Focusing on the “normals”

15 July 2010 5:31p Pacific

Sherman’s law of prior knowledge, or, predicting the past

by Matt Sherman

“When a disaster happens, large or small, there is a 100% chance that a headline will be written claiming ignored warnings.”

I’ve come to realize, that’s the narrative. It’s always the narrative, and the details of the incident matter little.

Apple Engineer Told Jobs IPhone Antenna Might Cut Calls

BP warned of rig fault ten years ago

Bush Warned of Hijackings Before 9/11

…etc. It’s not that any of these folks are blameless. It’s that, in all likelihood, they acted like you and I and everyone else would.

And we (they) have to. If we responded to everything that might be a disaster, we’d never leave the house. Did you read every street sign, every warning label today? Every word of every email you were sent?

Your life is full of possible disasters. It’s just that 99.9% of them won’t come to pass, and your only choice is to make the best of incomplete information. Remember, useless panic and irrational caution have costs.

After the fact, however, we need a story. It’s called the narrative fallacy. If we can imagine incompetent people taking reckless chances, then disasters start to make sense.

But making sense is not something that most disasters do. Which is called the ludic fallacy – that probabilities tell us something, and that these things in the past were predictable.

And yet that assertion is self-refuting. Why? Because we didn’t predict it.

Sure, someone did. But you’ll only find out who in retrospect.

13 July 2010 9:00p Pacific

The busiest people at Apple right now…

by Matt Sherman

…are the ones planning the hardware recall. The second busiest are the ones figuring out how to coat the antenna with an electrical insulator that doesn’t hurt the aesthetics.

10 July 2010 9:22a Pacific

When “infographics” jump the shark

by Matt Sherman

google-history-social-media-pre Mashable offers an “infographic” describing Google’s history in social networking. And it’s pretty and all well and good, except that the graphic adds no information.

Rather, it’s simply a set of data points that happen to have been put into an image. It’s as if Illustrator had an “Import from Excel” function.

Infographics are supposed to add information, by giving you a visual or intuitive sense of, say, proportion or relationships or trends. This one does none of that. What we have here is not design, but decoration.


18 June 2010 7:44a Pacific

HTTPS is the least of your problems

by Matt Sherman

It’s cool that the EFF is offering a Firefox extension to use SSL where it’s available. I prefer to encrypt things too, but really, that’s the least of your problems.

As I am sure you know, HTTPS simply encrypts data between your computer and the web server, while it’s in transit. It does nothing to ensure that your data is handled correctly at the other end.

When you hear about credit card or other privacy breaches, it’s usually due to mishandling – databases that get into the wrong hands, or software flaws that reveal information. SSL can’t help you there.

Using SSL by default is still a good idea. But it’s like locking the car doors on the way to drop off your kid at day care. Those doors locks are fine, but it’s the day care you need to trust.

6 June 2010 5:05p Pacific

Stacking up

by Matt Sherman

I am happy to announce that I’ve taken a job over at Stack Overflow.

I’ve been a reader and admirer of Joel and Jeff for some years now, so I am thrilled to be working alongside them. (Hopefully they won’t catch on to the fact that I don’t write code, I merely copy-and-paste from Stack Overflow.)

In fact, I wasn’t really looking for a job, what with Alikewise and some freelance gigs I’ve been doing. But upon hearing that they were hiring, I had to put in a CV to see what would happen.

I am flattered by their interest, and hope to assist in their goals of world domination do some great stuff.

I’ll reveal an unflattering truth: I kinda like thinking I am the smartest guy in the room. The time I’ve spent at S.O. so far has cured me of that fantasy. Wish me luck.

--

Update: http://blog.stackoverflow.com/2010/06/new-hires-in-new-york/

4 June 2010 10:29a Pacific

Beware the truth-tellers

by Matt Sherman

I find it is so funny and ironic when a person has to tell you they are telling the truth before they tell you the true thing that is truthful. Today, as part of a otherwise interesting and opinionated post, we learn:

I try to be a totally dispassionate truth teller.

Um, who doesn’t? I assume that when any person writes something, they believe themselves to be telling the truth, or offering an honest opinion.

Projection is a sly mistress. To claim truth prior to argument is to accuse your audience of bias or closed-mindedness. Which reveals something about the writer.

It’s like someone starting a conversation with “Hi, I am not lying!”. I didn’t think you were. But now you’ve planted a seed.

A person that calls themselves a truth-teller is not only an egotist, but someone who struggles with the difference between opinion and fact. A person who has trouble imagining that their opinion is not capital-T Truth. Which to me connotes a defensive mind.

It is also a most irritating form of “going meta”. Calling oneself a truth-teller is to make an argument about an argument, before making the argument.

In other words: if you’re smart, I will probably be interested in what you have to say. Show me the product, and spare me the spin.

31 May 2010 6:34a Pacific

Please don’t write “efficient” CSS

by Matt Sherman

Contra many smart people, I am going to make a contrarian request: please do not attempt to optimize your CSS for performance. Instead, please optimize for correctness, specificity and maintainability.

A quick bit of philosophical background. CSS is a declarative language, not unlike HTML and (basic) SQL. It is designed to describe what you want, but not how to execute it. Thus, declarative languages have no verbs – only nouns and adjectives.

Second-guessing how a browser will execute your nouns is a) a shot in the dark and b) a misuse of the language. You’re trying to micromanage without verbs. It reeks of premature optimization. And your optimizations may not be optimal in the future, or across different browsers.

More importantly, a user is more likely to notice something that’s wrong as opposed to something that’s only 99% as fast as it could be. (And if it takes you an extra 15 minutes to locate and fix a bug, they’ll notice that too.)

Instead, think of CSS like other programming. This means you should focus on:

Separating concerns: You should be able to modify style without modifying HTML.

Managing scope: Local style changes should not affect other parts of your application.

Optimized for scope:

#home .advertisement h3.vendor { … }
#productreview h3.vendor { … }

Optimized for “performance”:

h3.vendor { … }

Correct semantics: Classes and id’s of HTML elements should describe what they are, not how they look.

class="mediumheader red" class="storytitle featured"

Brevity: Write the least amount of code for the task at hand (aka YAGNI).

Optimized for brevity:

<div class="story"><h2>My title</h2><p>The description</p></div>
div.story { … }
div.story > h2 { … }
div.story > h2 + p { … }

Optimized for “performance”:

<div class="story"><h2 class="storytitle">My title</h2><p class="storydescription">The description</p></div>
div.story { … }
h2.storytitle { … }
p.storydescription { … }

I believe that following these rules will actually achieve higher CSS performance in the long run. Writing 10 smart rules will probably perform better than 50 micro-optimized rules. Adding classes and id’s only for the sake of CSS performance will probably cost more than it saves.

And remember, computers are fast and cheap. Programmers, by comparison, are expensive and slow. :)

--

Addendum: Another way to think of it is that CSS is a query language. That’s why they call them “selectors”. More rules = more queries. Keeping queries as few and as specific as possible should give the best results, just like SQL.

18 May 2010 5:07p Pacific

0.facebook.com is not neutral

by Matt Sherman

A while back I mentioned the idea that some content sites would offer free shipping for their bits. It would be the inevitable result of metered pricing on the Internet, an idea with which major (wired) carriers are experimenting.

For example, ESPN might make a deal with Comcast to say “any video from ESPN flowing over Comcast’s network will not count against the customer’s bandwidth bill.” Basically, ESPN becomes toll-free for the customer, not unlike an 800 number.

It turns out Facebook is the first to do this, and they are doing it on wireless networks where bandwidth is – ding ding – metered. They made deals with a bunch of wireless carriers.

This seems like a win-win-win; Facebook is (presumably) compensating the carriers; Facebook gets to tell their customers that they are free to use, increasing their traffic; and customers save money.

But is this a neutral arrangement, in the sense of net neutrality? Clearly not. Facebook’s bits are being delivered at a different price than other sites. That sort of thing certainly seems to be the fear of net neutrality advocates.

What the advocates misunderstand is that non-neutral networks can be better for the consumer, as in the case above. What’s less likely is that a carrier would charge more for a YouTube; what’s more likely is that YouTube would subsidize the consumer.

In other words, by making “upcharges” illegal, net neutrality would also make discounts illegal. “Neutral” means neither positive nor negative, and it means that differences (and experimentation and variety) are prohibited – even if those differences benefit the consumer.

29 April 2010 7:06p Pacific

Adobe: call it Flash 11 already

by Matt Sherman

I feel like I’ve been hearing about Flash 10.1 forever. The earliest public announcement I can find is October 5 of last year. That’s over 6 months of development for a point release.

Which is entirely understandable – it’s a “maintenance” release, in the sense that most of the goodness is under the covers. Hardware acceleration, better mobile, more platforms. Sounds like it will fix a lot of performance and reliability problems. Architectural changes are tedious and hard, and they need to be transparent to the user.

Given all the tit-for-tat and publicity that Flash is getting lately (con and pro), this is not a moment too soon. Flash’s credibility and future depends on this release.

So a bit of branding advice: send a message and call it Flash 11.

Windows 7 was a big refinement on an existing, but poorly-regarded, platform. They improved the product and came out confidently on the brand – again not a moment too soon. This is Flash’s moment.

Tell others

TwitterTweet this page
Digg!Digg this page
TwitterAdd to Google Reader

Experimental! Let me know how it works for you.

Shorten this page's URL

Learn more about the TinyASP URL shortener

ASP.Net jQuery Controls

Implement jQuery effects using familiar ASP.Net server controls. Learn more...

Recent posts

Alikewise learnings #1: DIY PR

Sherman’s law of prior knowledge, or, predicting the past

The busiest people at Apple right now…

When “infographics” jump the shark

HTTPS is the least of your problems

Stacking up

Beware the truth-tellers

Please don’t write “efficient” CSS

more...  

About us

ClipperHouse.com is brought to you by Matt Sherman and Fernando Chilvarguer, among others. Contact us here.