rrwhite

It seems that smartphone ownership (which is steadily increasing) is more of a factor of age than income (though both are a factor): http://www.nielsen.com/content/dam/corporate/us/en/newswire/...

And how does your request play out?

We halt any technological improvements which would result in lost jobs. Is there any historical precedence for such a thing?

You may not but the NY MTA does: http://en.wikipedia.org/wiki/Automation_of_the_New_York_City...

Exactly. Customer service jobs are actually increasing in pay and sophistication because there's less overall work to be done but what's left behind after automation is more complex.

You're spot on with that thesis. Automation is inevitable. How we react to it is what's going to matter. I tried to encapsulate that here: http://rrwhite.com/on-the-inevitability-of-automation

Which is why I talked about the concept of basic income. I don't know the answer but people are arguing about whether automation is good or bad which is irrelevant. These jobs will be automated whether you like it or not. If we play our cards right then perhaps more people can pursue their passions. If we don't... well I'd rather focus on making the former happen.

Wow. I hadn't seen that at all. That's simply reflective of the enterprise-focused path they've been on for the last few years. Micro-ISVs and SMBs don't pay real money for community software only the big guys do.

Yeah I could do a whole other article on how we shifted from minimizing friction on the sign up form to actually increasing it. If it's too easy to sign up for your service it's hard to tell if your marketing actually worked and you have qualified leads or if you just have a bunch of people that "clicked here".

Contacted them about fixing the images. In the meantime here's a PDF version with them:

https://dl.dropboxusercontent.com/u/28/UnSexy-PricingforConv...

My assertion is that you should provide severance in all cases. I chose to attack the most contentious case (poor performance) where one might think not to provide it to prove that point.

I didn't mean this to imply that it's a regular issue I have to deal with :)

PS Priority #1 post any firing is a careful review of the hiring process that got you there.

I did not mean to imply that all firings are the result of employee incompetence or poor performance. Because that's clearly not true. There are often other factors that lead to a bad "fit".

And yes, the first thing you should do post-firing is examine your hiring process to see if it could have been foreseen and prevented. But in some cases it does come down to someone just not having the experience, the talent or the work ethic to meet the performance required. It's those cases, especially with tech workers, where founders are apt to ask "do I really need to provide severance to HIM (or her)". Writing at $20K check to someone to walk out the door is never an easy thing to do especially at a startup where that $20K could go a long way. That's what I was addressing here.

In this context the original discussion revolved around someone being fired for cause (extremely poor performance). That someone was a knowledge worker and fairly well compensated. There was also little reason to believe that person wouldn't have a new job by the time they walked out the door (job market being what it is).

Thus my goal was to argue for a reason why you should always pay severance even when none of those conditions you mentioned apply. Otherwise I agree with everything you wrote.

Quick question: Do you live here (SF)?

Are the including Studios in this or just 1BR? I ask because a 1 BR is a luxury apartment for a single inhabitant. Most folks living by themselves would have a studio. SF is expensive but it's not that expensive.

Happy to have such a great (and successful) partner for mobile. Good work Andrew.

Loved the deck. Any plans to put up the a video of the entire deck.

It’s good to see someone taking a critical look at all the hype around “gamification.”

We (UserVoice) built our kudos and leaderboard system (which we hesitate to call “gamification”) based on the feedback we received from customer support agents who provide great Zappos-style customer service but felt they lacked any sense of accomplishment. We saw a lot of internal customer service reports in these organizations that used screenshots of positive support ticket threads to try and capture the sentiment that we now do with “kudos.”

It’s worth pointing out that there’s really two completely different worlds of customer service: the ugly, painful call center world and the much more humane version that’s coming out of internet companies like Klipfolio (check out my UserConf talk for more about this: http://www.youtube.com/watch?v=qKapwfmpvew&feature=relmf...). UserVoice users are decidedly from that latter group, so our “gamification” methods focus more on rewarding/ quantifying good work (driven by intrinsic motivations) agents are already doing. I, too, am skeptical that you could simply drop a leaderboard into a United Air Lines call center and get massively better output.

One final thing to note is that we go out of our way to make sure that kudos and our leaderboard are used for friendly agent-to-agent or agent-vs-self competition and do not become something on which managers base performance decisions. As soon as that happens, you end up with the “If you liked my service please give me a 10 in the follow-up survey call” that I’m increasingly hearing when I talk to the “old world” of customer service.

Richard White, CEO - UserVoice

What was most surprising was the staggering amount of junk emails on larger consumer apps (user clicks "help" link, goes to Mail view, freaks out and hits send to get out of it). We've also seen Apple reject apps that link out to a web experience for customer support that has any sort of sign in link. Native all the way.

It's deceptively a lot of work to do anything more than a Mail link. You've got server side calls, user identity, etc. Hopefully this SDK fixes that.

We used Campfire previously and there were a lot of things we couldn't do (1:1 chats, ad-hoc rooms, etc). So while in general I'd agree there are a lot of things which only worked once we moved to HipChat.

The question, as I wrote in the post, ultimately isn't about whether you need revenue or not. Of course you do eventually. It's about when you go for revenue.

This post is not at all meant to be about what to do with your bootstrapped business. It's only targeting high-growth, mostly b2c, companies in winner takes all markets with strong network effects (ex: Pinterest, Instagram). That's what I mean when I say "startup" though that term is completely overloaded and adopted by everyone nowadays :)

I meant that most people end up here rather that in the first scenario of hyper-growth. "Most people (who don't fail) end up here" would have been more clear. Point taken.

Nothing ever is which is why I wrote the answer to "when revenue" is: it depends. I wrote this post because I talked to enough people who thought companies not charging was completely irrational. I believe most people, including politicians, are rational actors you've just got to understand their motivations and goals.

We tested it using Optimizely, what we use for A/B tests, but rather doing a true A/B test we made into a sequential test (by manually setting all traffic to go to one variation versus another). It took a couple days to test and it's tough because since it's sequential traffic spikes will screw everything up and you'll have to start all over. So basically we compared two weeks with "average" traffic: running $5 plans one week and free plans the next week. Obviously if anyone noticed we allowed them to switch their plan to free.

Thanks for the love. If you read our previous post on our dev process using Trello it might interest you to know that feature came out of the internal idea inbox. We all quickly fell in love with it and pretty soon almost the whole team was working on some part of this feature. We took it from idea to launch in less than 6 weeks. Very proud of the work by our team.

We're a SaaS business so I don't think there's much we need to do here. We launch/promote something only when it's ready. The only deadlines we operate on are internal (ex: we need feature X in time for event B).

It's been a long time since I checked out Pivotal so I don't feel that confident in giving too much of an opinion.

However my main gripe with Pivotal was always two things: 1) Strict adherence to a Scrum methodology (forcing me to use a certain set of columns, etc) and 2) The UI. It frankly drove me nuts. The small text fields, small text areas and lack of wiki-style formatting. Anything longer than a few words was impossible to grok.

We flirted with trying it out about the time we adopted Trello but enough people had bad past experiences, like mine, that we never gave it a try.

There's simple a column for each quarter (ex: 2012 Q3) going about 3 quarters into the future. The only things on this board are big strategic projects.

It's worth noting that when we were in our last "building a big new product" push over a year (for our Helpdesk product) we were doing sprints because we had harder deadlines to work within. Having said that we still hated the overhead required to properly plan a sprint so even if we were in that phase again I'm not sure that we'd go back to sprints.