Paid Apps Model Revisited

don27tmakeyour0acustomers0ahesitate0a0a600a28fenshui29-defaultHow many times have you hesitated before buying a 99-cent app?

You’re staring at the reviews. Looking for a Lite version to try out first. Catching yourself at the thought: “I’ve spent more time thinking about buying this thing than the 99 cents that it’s worth.”

What if I don’t like that game?.. What if it doesn’t work on my phone? I sure don’t want to call customer service to ask for a one dollar refund, that would make me feel even more dumb..

There’s a grand canyon of friction between free and 99 cents. An ocean between free and a $4.99 game that everyone is talking about. All of these are symptoms of friction. Friction that App Store tzars have created and are oblivious to.

What if, instead of asking you to think, causing you the angst of making a decision, Apple and Google learned from Xerox?

In the early 1960s, Xerox was a pioneer in the copier space. They had a significant issue, however: a large, expensive machine wasn’t an easy sale, and decision-makers would hesitate before making a purchase. Do we really need one? Will the office workers use this? Returning it would be such a hassle…

So Xerox leadership invented a stratagem. Their salesperson would bring the fancy copier to the office for free and just leave it there. Play with it, they’d say. It’s free, no obligations whatsoever. I’ll pick it up in a month.

Guess what – nobody wanted to give it up in a month. It was a great product and sales went up tremendously as a result of this move. We now know this move as a “free trial” – lots of SaaS and shrink-wrap software is sold this way.

Why aren’t app stores facilitating this type of transaction, though? Apple, Google – how about giving each paid app out for free, and only charging the consumer if that app is still installed on their phone a day later?

Of course, there are one-and-done apps that offer a single-use value proposition: museum tours, cheat codes, contact sync apps. These and similar apps should be able to opt out of this scenario. But for the vast majority of apps – apps that aim to deliver value over multiple sessions – this would be a huge net gain.

Just imagine: no need to develop and maintain a separate Lite version. No buyers’ remorse. No fear or hesitation when buying an app.

Whether you’re an app developer or an avid app user, let me know what you think about this concept in the comments.

Are Your Company Values Just Empty Words?

values45463675I had a chance to interact with two companies recently: Homegrown and City of Bellevue Utilities. These two companies helped me crystallize the difference between “value statement on the wall” and “values that are coming through to customers.”

Homegrown’s tagline is “sustainable sandwich shop.” Their About Us page has the word “organic” mentioned 22 times. It says that “stores are designed to be as low-impact as possible… [using] reclaimed, recycled … building materials.” Their napkin dispenser asks you to think about the environment and only take as many napkins as you will use. They have metallic cutlery at every table. Clearly, owners at Homegrown are trying to project an identity that stands for sustainability and environmental awareness.homegrown-logo

Yet, when you order a salad “for here,” you get a single-use plastic container with a salad inside.

Continue reading

Full Price is for the Lazy, or Stop Financing Their Marketing

hard-work-pays-offIn life as in business, if you are willing to invest effort into something, you will do better – a lot better – than average. Today’s story is about a real-estate purchase – and how doing your homework makes a 10x price difference for services.

Did you notice that you just paid your agent $1000/hour?

Basic dynamics of a real-estate transaction: when you buy a $500k home, 3% of the purchase price goes to the sellers’ agent; 3%, or $15k, goes to your (buyer’s) agent. What exactly are you paying for?  Continue reading

Why Are We Working on This?

why-shutterstock_126628475-600x709You’re a recent grad from a top engineering school. You come to a hot startup, and in your second week, you volunteer to implement an ambitious new feature. You slave away at it for a week, burning the midnight oil, trying to impress your new colleagues. You’re brilliant: you find an ingenious algo that solves the problem elegantly and with a lot less code than anyone thought was possible. You proudly check the code in, it ships to the site.

You’re proud of your accomplishment. You move on to the next big thing.

Spoiler alert: you screwed up.

Continue reading

Hire for Velocity of Learning

Let’s say you have an opening on your technology team: An urgent need for engineer that will expand your application written on top of the Spring Framework in Java. You use Puppet for deployment, and Jenkins for managing your builds. So naturally, you craft a job description that says “must know Spring, Jenkins, and Puppet.”

ImageYou look hard for a perfect dev for the job and find one. She’s been writing code in Java for the last 10 years; and Spring was at the core of a big project in the past. She has experience with Puppet. You proceed with the hire — and the new dev flies through the assignment and all is well.

Six months later though, you realize that your current Spring-based stack isn’t scalable; that you must switch over to Hadoop and HBase. That your front-end needs to be redone in Ruby on Rails or you won’t be able to evolve it to keep up with your competitors. So you switch.

But that dev you hired is struggling in the new environment. She’s really uncomfortable with Hadoop, and a few months in, still asks others for help with basic tasks.

You made a bad hire.

What? She was perfectly qualified for the task at hand! She did awesome in the beginning!

Exactly… in the beginning. She was doomed to fail from day one, because you hired for specific skill, as opposed to for the ability to pick up new skills.

In this day and age, there’s only one thing that’s certain: technologies of tomorrow will be radically different and dramatically better than what we use today: Postgres will outshine MySQL; NoSQL databases will trump relational in many scenarios. Hiring a full-time narrow specialist – someone who’s worked on exactly one technology stack throughout their development career – is a recipe for disaster if you expect your environment to change, either form a business or a technology standpoint.

So I invite you to hire for demonstrated ability to learn, versus specific skill in a technology-area-du-jour that you happen to have in your stack.

Wait… what are you saying? If I have a Ruby on Rails app, I should hire someone who’s done Django and PHP and C++ but no Rails over someone who’s been doing Rails their entire career?

Yes. This is exactly what we did at Wetpaint: most of the developers we hired had no or little experience in Rails.

Yet we are a Rails-based site with 100 million monthly page views and a significant codebase. We hired folks who’s experience has shown that they can pick up new technologies quickly. So they picked up Rails quickly; and then when we needed to do Hadoop, they picked that up too. And responsive design. And machine learning. I have little doubt that we’ll do great with the fancy new technology X that surfaces next year and revolutionizes the industry – because high velocity of learning is a core competency of the team.

How do you interview for the ability to learn?

—Look for radically different technology stacks, roles, company sizes on the resume.

—Ask the candidate about how they learn; those that have picked up a lot of new things in the past will be able to describe a thoughtful approach to learning and give an example of something they learned recently.

—Inquire about interests outside of work. A good sign is broad, diverse interests: those that enjoy learning get good at it over time.

This article was originally published as a guest post on Geekwire; it is republished here for the readers of this blog. 

Dogfooding: Find a way to be your own customer

This article was originally published as a guest post on Geekwire; it is republished here for the readers of this blog. 

In early ‘90s, while working on Windows NT, Microsoft popularized an idea to make everyone on the team use early builds of their own software.

Back then, it was quite a painful request — imagine developing an operating system on a box prone to crashes, where your basic tools don’t quite work right. This setup undoubtedly causes loss of productivity and frustration.

Are you eating your own dogfood?

Are you eating your own dogfood?

And yet, what it gains is something more valuable: an immediate feedback loop, where bugs are found quickly, where there is healthy peer pressure to urgently fix issues that are preventing your colleagues from doing their work. Since the cost of a bug goes up the longer it lives in the codebase, this feedback loop — dubbed “dogfooding” — is a significant net gain.

Today, it’s even easier for most technology companies to dogfood, because most of us aren’t developing operating systems. If your internal build doesn’t work quite right, you can still do basic things – so the downside of dogfooding is minimal. Let’s explore some simple, natural examples:

  • Facebook rolls out most features to employees first, and only then to a subset of external customers. Employees, of course, already use Facebook every day and can provide instant feedback.
  • Everyone loves LOLCats. Employees of the Cheezburger Network are natural customers, as they consume their own content every day.

At my company, Wetpaint, we build tools for publishers to develop relationships with their readers through social media. We take dogfooding so far that we’ve built an entire media business — a very successful one — to be our own customers, and to test-drive our platform before our clients use it. This has allowed us to evolve our tools at record speeds.

But what if you’re working on a product that isn’t so easy to dogfood? You have to be creative and find a way to incentivize your employees to be users in order to get the information you need. One way to set this up is recurring competitions; here’s what I would do with these businesses, for example:

  • Redfin, Zillow, Trulia (real estate): Employees must find the best real estate deal in their area. Give them virtual currency. Have them use your products — and competing products — to make their virtual investment decisions.
  • SEOMoz (search engine optimization): Each team member sets up a blog and must use the company’s tools to make it rank the highest a couple weeks later.
  • Tableau (data visualization): A leader selects a data set, and everyone is encouraged to find gems in that data set; the fastest, most interesting insight wins.

Give real prizes to the winners. Set up a weekly beer gathering, get the winners to share their strategy. I bet some product ideas will come out of that. Make sure these events are regular, not one-off, to encourage employees to keep thinking competitively and creatively.

Dogfooding programs complement agile and lean development practices very well, because iterating with the rest of your team for a few days before releasing an experiment increases your chance of success. You’ll also get the obvious feedback out of the way early.

Think of it as a modern version of Joel Spolsky’s hallway usability tests: instead of having to interrupt a colleague to review your UI, you’ll overhear “Oooh” and “Ahhh” when your code goes up on dogfood. That’s the perfect time to ask – “Hey, what do you think about this new thing?”