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 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?

  • Touring homes
  • Negotiation advice
  • Access to boilerplate real estate transaction forms
  • Administrative services (shepherding the paperwork)

I was unable to find hard data about the average number of homes that buyers look at these days  and the average number of offers that people make before making a purchase, but anecdotal evidence (one, twothree) suggests that: consumers tour 5-10 homes before making a purchase and make 1-2 offers before reaching mutual agreement.

If you convert that to the number of hours that your real estate agent spends with you, you are looking at about 10-20 hours of work. Dividing their fee by the number of hours, you are paying your agent $750 to $1500 an hour. That’s more than what you’re paying your lawyer – heck, that’s more than what your brain surgeon charges.

There are better real-estate firms out there: Redfin, for example – I love Glenn Kelman and I’m thrilled that he’s working to disrupt this industry. For example, Redfin’s field agents that give you home tours have no incentives to sell you those homes. But what Redfin charges is still far too much: on a 500k home, they charge you (3% – $5000 rebate), which still turns out to be about $500/hour. You might argue that Redfin value prop is a lot higher: they enable the consumer to make better decisions through data on their very awesome site. Unfortunately, this is all but commoditized today (every real estate site does it) – and a savvy consumer has no incentive to subsidize software development efforts behind the self-service site.

Finally, if you look hard enough, you can find flat-fee firms: real estate firms that are specifically designed for savvy buyers – those that simply need help with the paperwork. I just worked with Shop Prop, a flat-fee agent in Seattle area. Shop Prop took several thousand dollars for the transaction and refunded the rest of the buyer’s commission back to me. I paid an order of magnitude less per hour than I would have paid an “old-school” agent. Why? Because I was willing to invest time into finding the right deal.

The craziest part: most consumers are irrational and the rebate is not the reason people go with Redfin. Glenn, the Redfin CEO, writes:

.. commission savings that Redfin offers home sellers and home buyers dramatically lowers our profits margins and there is no evidence that it drives more revenue… [We have] given away $100 million [in rebates]“

What’s behind this?

  • Lots of Emotions: the buyer is making a life-changing decision for his/her family. They want to know they’re getting a good deal, which is difficult to judge since they haven’t done many deals like this before. They want to go with a professional – social proof here (“my neighbor did business with this great agent”) is very important.
  • Apples and Oranges Marketplace: even though all houses are out there for consumers to review and evaluate, it’s hard to develop a quantitative sense for “this place is 200 sq ft less but has a remodeled bathroom… does it mean it should be similarly priced?”
  • Competition: real estate market is in the state of frenzy in Seattle area, with lots of international investors making cash-based offers; many homes get 5+ competing offers. Buyers think they need the help of a professional to win in such a market.

Problems with so-called “professionals” that are paid ~3% of the transaction, beyond their exorbitant fees:

  • Incentive Misalignment. There is no incentive for your agent to help you get a good deal on a house. He/she just needs you to buy any house as soon as possible, so they can get their commission and move on to the next client.
  • No Meaningful Expertise. Real estate agents require no meaningful training to practice their profession; the only actual requirement is a vast network to generate demand or supply. Buyers and sellers take 100% of the risk; moreover, as a buyer, if you end up closing on a place, you are so far in the weeds that your “commitment bias” (sunk cost) makes you so convinced that you got a good deal that you will biased to resist any evidence of the contrary – thus convincing you that you had a good real estate agent.

438110523b4cba59613c4dba6d34a734That is, most consumers would rather take $10-20k of their hard-earned money and gift it to a stranger for no meaningful reason – instead of spending it on vacation, their loved ones, or charity. A rational consumer – that’s not afraid to do research, that understands built-in irrational biases inside their mind – will fair an order of magnitude better.

Do you have an example from your life or work where careful research and effort have paid off handsomely? 

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.

You thought that you were done when the code was checked in and shipped.

Not even close… It turned out that the feature you so proudly shipped actually didn’t make a difference for the business; it didn’t improve customer experience in a meaningful way, didn’t move the bottom line for the business at all.. Your hard work didn’t bring value to your company. All of that effort to make a beautiful algo was a waste. That’s because you cared about the code, the “how to solve the problem,” not the “why” behind it.

Peter Drucker famously said that “There is nothing quite so useless, as doing with great efficiency, something that should not be done at all.”

Next time a feature is assigned, consider asking: “Why are we doing this? What value do we expect this to bring to our business?”

It might sound like a challenge to your boss or to your product manager — it actually is not; their primary job is to make sure that every engineer is working on something that moves the business forward. They’ll happily explain the intent.

When you find out the “why” behind a task, it is much easier to make sure the implementation gets to the heart of it — without any extraneous effort. Maybe the task you’re assigned is just an experiment — with a super high business risk, and it doesn’t matter whether it’s scalable at this phase. Or maybe — just maybe — you will have a better idea on how to solve this specific “why” than what’s in the work item.

If you want your work to have an impact on the company you work for, you have to be an entrepreneur, not just a coder. Challenge the assumptions when you’re given a task; find out what metrics are expected to move as a result of this task being done; instrument your code so that you can actually know.

Don’t start the work until you have an objective way to judge whether it’ll have a positive impact on the business. Don’t stop until you see that your work made the business forward. Look at the data after your feature ships, share your findings with your team, suggest iterations.

Let’s explore some examples.

 —A task is to change the layout of the signup page.
Why? To improve our conversion rate and make more money.
What’s the actual objective measure? Conversion rate over time.
How do we know whether it’s successful? We need to have an objective measure of conversion rate before and after the layout change.

—A task is to fix a bug in the retry logic for Facebook Insights data collection.
Why? So our customers should always have stats about their Facebook activity.
And why does that matter? So that our customers could judge the effectiveness of their campaigns and use that knowledge to make more successful campaigns.
How do we know whether this work made our business better? We’ll see improved stats of Facebook campaigns that our customers initiate.

—A task is to fix a rare crash of our iPhone app on old versions of iOS.
Why? Crashes create really unhappy customers.
No really, why? Because a handful of folks that use an ancient iPhone get really angry and leave 1-star Apple Store reviews.
What’s the measure of success for the business? Number of 1-star reviews of our app that mention crashes and old iOS is down.
What’s a good proxy of this metric? Actual number of crashes — you need to be capturing crash stats for your app and monitoring it over time.

Eric Ries created a fun term: “achieving failure” – perfectly executing a flawed plan. He talks about this phenomenon happening on a large scale (entire startup), but it happens all the time on a small scale, too (individual work items).

By asking “why are we doing this,” you help insulate your group against it, and also remind the group of its shared purpose, bringing the team together.

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

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?”

Hackathons at Startups: Creative ‘Fresh Air’

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

Every now and again, we hear about hackathons: Startup Weekend, Facebook’s famed all-nightersHack Week at Dropbox.

However, in a startup, it’s so difficult to imagine how organizing a hackathon can be anything but harmful: “What do you mean, take a couple work days and drop what we’re doing? We’re in a race with competitors! There are holes in our product – and they’re blocking adoption! We can’t just waste a couple days!”

A scene from the recent Sports Hack Day

A scene from the recent Sports Hack Day

I know you’re under pressure. That’s the nature of startups.

And yet, allow me to ask you: how many times have you fought an issue for weeks, only to find an elegant solution that takes a day to implement? Have you ever built a feature that nobody ended up using? Have your employees begun talking about the “grind,” the soul-crushing 80-hour-week pace where bugs never end?

If so, hackathons can help with each of these. They let folks take a step back, concentrate on the big picture, and apply their passion – usually where it hurts the most.

Allow me to share a story from Wetpaint. In summer of 2011, we were struggling with our data warehouse system; we’ve had all the symptoms from the list above. This system was so unreliable that our internal customers didn’t trust the data. Engineers were burnt out from every-Saturday-is-a-workday routine. After a couple months of treading water, we realized that we needed to change something structural in our approach.

One key change we introduced was a framework for open-ended innovation. The intent was simple: all participants drop their day-to-day tasks for a couple days, and work on whatever is exciting for them, as long as it has something to do with our overall business. No top-down mandates. Work alone or with others. The only requirement is to show – demo, not PowerPoint! – your results to everyone else at the end.

We called this framework “hack days.”

I was amazed by the results. Initially planned as a morale-boosting exercise, there were somany great ideas that came out of it. One engineer’s 2-day project disposed of the majority of the issues we were having with the data warehouse. It took a completely different approach to the problem, challenging some of the foundational assumptions that no one ever doubted. Another engineer built a mind-blowing prototype of a tool that we ended up building over the next three months, and that tool had a significant impact on our bottom line.

Most importantly, this breath of creative, fresh air gave a sustained boost to everyone’s output, even as we re-entered regularly scheduled sprints. We made these hackathons a recurring activity – every quarter, coinciding with company-wide business reviews. Everyone in the company is invited to the debriefs now – and they walk out energized and motivated by the ingenuity of their peers.

Moreover, folks outside of engineering are adopting this framework, too. Our social marketing team, for example, drops their best-practices playbook for a couple days once a quarter, and encourages each team member to try their craziest, riskiest ideas. We’ve seen great results from it.

Give it a shot in your startup. Hackathons can become a “startup factory” in an established company, too. If you’d like help setting up a hackathon, send me a tweet, I’d be happy to help.

Measuring interruptions: How to keep your team in the ‘zone’

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

When you look at productive output from a software development team, there’s one factor that almost always predicts problems. You can have top talent; an outstanding idea; great agile process. And yet, if you don’t treat interruptions as a significant source of danger, the progress will be slow and painful.

5368292088_37f5fce714_n[1]We all know and love the feeling of “flow:” You’re in the zone, coding away or deep in thought on a financial model. There’s plenty of research that suggests that we do our best work in this state. We are also happiest at work when we are in the zone often.

But far too often, this state is broken up by a tap on your shoulder or a phone call. There’s a small, innocent question – and it takes you five minutes to answer it. But when you come back to your original task, the inspiration is gone. The “zone” is gone. You need a half hour to just bring back all the variables back into your mind. Or worse, you may not catch the sense of “flow” again that day at all.

That’s the scary thing about interruptions – they typically only take a few minutes to handle, but then bring a trail of a scattered state of mind.  What’s worse, it’s easy to embrace this interruption as a good thing – hey, I just solved a problem, unblocked a customer, made someone’s day better. And yet, for an organization, more often than not, this interruption was a net negative.

Technology startups have a key property: if they stagnate – stay with the status quo, spend too much time on sustained engineering – they die. Time is of the essence; competition is fierce, someone else is going to win that customer, build a better product, hire stronger talent. So only the time that you invest into important AND non-urgent things is bringing you closer to your vision. Troubleshooting is a necessary evil. You must make your current customers happy. And yet, if you spend all of your time on it, you’ll never make it.

So I encourage you to take a systematic approach: actually measure interruptions and create goals to reduce them to a reasonable level.

Create a mailbox connected to your issue tracking system. Every time someone has a question or request outside of the current sprint’s priorities, have them send an email to that mailbox – or do it for them. There are, in fact, two mailboxes: one for emergencies (ex. site’s down) and one for regular issues (ex. data in the analytics DB doesn’t add up). At the end of each week, count the chickens.

Categorize each interruption by component. Draw a graph over time. Discuss it with your senior engineers.

You’ll be amazed. I sure was when we did this at Wetpaint. When we started this practice, we noticed that we had an average of 60 interruptions a week for a product development team of 15.

This, coincidentally, was a time when we were seriously struggling as an organization – we had a hard time moving the product forward. We dug into the root causes and noticed that most of these interruptions were triggered by two systems. We invested time in two sprints to systematically address these issues, and the interruption count dropped to 10-15 a week. Not surprisingly, our productive output shot up.

Morale also improved significantly. Folks felt like they are working on features that move the product forward, instead of constant firefighting.

An important factor in our setup: we established a rotation program to triage interruptions –and only placed managers on this pager duty rotation. Some interruptions are 3am emergencies that must be dealt with immediately; when managers have to be the first line of defense, root causes tend to get a systemic resolution surprisingly quickly.

Another positive side effect of being systematic with interruptions is that nothing falls through the cracks anymore. An internal customer would find an issue and send one of the devs an email, or just chat with them in the kitchen about it. Sometimes, requests like this would be lost – or delayed far enough to get the customer concerned. After we set up this rigorous interruption tracking, every client knew where to look up the status of their issue.

The movie Social Network has a magical moment. A loud house party is going on. And yet there’s a guy in the middle of the room with headphones on, coding away. People walk around him, careful not to disrupt – nobody dare interrupt his flow!!

Do you know how many times a week your product development organization is interrupted today? Can reducing that number take your crew to the next level of productivity?