I didn’t say, “even Buddha valued measuring progress“, my friend Justin did.  He was referring to this:

The Buddha asks the group why they are practicing these austerities, and one replies that they are wearing away their past karma and would end their suffering by not adding any additional karma. The Buddha asks if they know how much of their old karma they have worn away. They say, “No.” He then asks if they know how much they have left. Again they answer, “No.” Finally the Buddha asks if they even know for certain they existed in the past and have karma to wear away. Again they shake their heads and say, “No.” The Buddha replies that this is meaningless practice.

Often, I get e-mail like this:

Hey, Scott…I have an idea for a web site.  It’s a flibber that does a gibber.  Do you think it’s a good idea?

The answer is, “maybe”.

First of all, I’m certain it’s a great idea.  Most ideas are great, even the evil ones.  I love ideas!  But, what I think this person is really asking is, “do I think it’s a good business?” or, more specifically, “do I think it will make money?”

With that in mind, honestly, I don’t know.  I have an educated opinion, but so much of a good idea is driven by a unique understanding of a market insight that only a founder has.  Also, in part, because I’m involved with an idea that nobody thought would work, but actually does (because our founder had a unique insight), so my calibration is off.

That being said, I have a few questions to ask that might help you figure out if this is a good idea.

First, “to what problem is this idea a solution?”

Second, who is the customer? Customers are different than users. Customers are people who pay for goods and services. Sometimes your users and customers are the same people, but other times they’re different. So, you may have users, but in order to be a business, you need to have customers, too.

Third, put the first two questions together: assuming there people who have the problem and will pay for that solution, then…

a) how many?,

b) how much?, and

c) and, most importantly: how are you going to find them?  In other words, you could have a great solution for people with real problem, but if you don’t have a cost efficient way to connect the two, then you don’t have a business.

If you can answer these succinctly, and have evidence to back your answers up, then you might be on to something.  If you can’t, then…well, maybe it’s a good idea, but not a good business.

Obviously, this is not every question you may want to ask in order to validate your idea, but I hope these are a few that help.

I have a friend who is seriously considering opening a boutique.  Nevermind whether or not you think opening a boutique is a good idea.  Just know that she’s really passionate about it, and really wants to do it, and that my job (and yours!) is to support her dreams.

So, she is in the planning mode.  She’s been in the planning mode for the longest time.  Forever, it seems.

You know the thing about plans, right?  The plans are worthless, but the planning is priceless.  But, at some point, the planning has to stop, and the action has to begin.

Anyhow, today, via e-mail, she was asking me for some advice, and I asked if she had a name for the store.  She did not.  So, I responded, with the following:

I think you should pick a name. Having a name will make it real. (Of course, you can change the name later if for some reason you decide you don’t like it, but it’s important to pick a name.)

Also, you should go get a business license. Seriously, just use the address of your house. You can always change it later.

The journey of a thousand miles begins with a single step…you’ve heard that phrase before. But, it has two corollaries: the journey of a thousand miles takes a million steps, and the journey of a thousand miles is completed one step at a time.

Start taking some of those steps…you have to take them eventually anyhow, might as well do them now.

Plus, when you take them two magical and amazing things will happen. First, the journey becomes real…it’s not an imagined journey. And, second, each subsequent step becomes easier because you have practice at taking steps.

The hardest part of the journey is taking the first step. Mainly due to fear. But, the thing to remember is that you can always turn back. Always.

After I hit send, I thought to myself, “one day, when I’m in her position, I hope that I’m brave enough to follow my own advice”.

Guest Post Week concludes with Dan Shapiro
Dan Shapiro is a friend who I’ve come to know through the Seattle startup community.  Dan founded the mobile software company Ontela, which he merged with Photobucket, and is now in stealth mode with a new startup named SparkBuy.  (Follow them to get an invitation to their beta.)  When I asked him to write a guest post, I wasn’t expecting what I received—an ode that humbles me.

I was talking to a CTO candidate some months ago.  He seemed terrific and came highly recommended, with only one concern – he hadn’t been at a single job for more than two years.  To his immense credit, he knew that was a yellow flag and, when we were talking about his resume, brought the subject up.

He did it in a great way too.  He pointed out the strength and depth of his experiences, and then said, “the one thing I regret about my career so far is I haven’t had an opportunity to really build a long term relationship with a company”.  He then explained the course of his career arc, and proceeded to dispel all my concerns.  There was a few acquisitions, a bankruptcy, and similar circumstances that explained everything.  Except one thing.

I asked him why he was leaving his current job, and he told me a few reasons.  But, the biggest reason he provided was that the codebase is a mess, and it needed to be rewritten from scratch.  He said that it was just painful to work in an environment like that, and he wanted to go somewhere that he could work on great, high-quality code.

This reminded me of the story of Scott Porad.

Awhile ago, I was having lunch with Scott, the CTO of one of Seattle’s most impressive companies, I Can Has Cheezburger?  I asked him why their company was built on WordPress and .NET, an unusual choice for someone in their space.  And that’s when I heard the story.

He told me that when the CEO, Ben Huh, hired him on, the site was a mess.   The complex process of processing user submitted content was managed entirely by a thorny tangle of PHP (in WordPress) and .NET.  This weird mix of ugliness was written by a contractor over the course of the preceeding six months.  It was undocumented and messy.  The obvious thing to do was get rid of it, and start fresh.

So, he sat down and talked to the CEO.  Times were tight: they’d raised a small round to acquire the original domain and hire some staff, but the money was disappearing quickly.   New features were needed to support better monetization, and they couldn’t get them done frequently enough.

Scott had a terrible decision to make.  He could scrap six person-months of work and build the site anew.  It would scale better, reducing costs would be easier, and he wouldn’t have to mix PHP and .NET.  They could purge their technical debt with one fell swoop.

But, that’s not what he did.  He told me that he wasn’t sure the company could survive locking down the business while he attended to development housecleaning.  So, he kept the company on the original codebase, platform, and architecture.

Over the years they’ve cleaned up most of the mess, but incrementally, and only as needed.  The company still runs on .NET and PHP.

When I finished this story, the candidate had a look I can only describe as dread. I asked him, “Do you know what it means to be a startup CTO?”

He said, “Yeah, I do. It means you have to be OK with a decision like that, because it’s in the company’s best interest.”

I said, “No, it doesn’t mean you have to be OK with it. It means you have to advocate for it.”

Scott’s a hell of a technologist, but that’s not why I admire him.  I admire him because he’s an entrepreneur first and technologist second, and he does a hell of a job at both.

What do your new employees do on their first day?

Fill out paperwork?  Collect up office supplies?  Fiddle around with the customizations on their computer?

At Cheezburger, our new developers write and commit code to our production software on Day One.  Yes, you heard that right…we throw a newbie into the fire before they even have time to know what hit them.

I would strongly encourage you to aim for this goal with your new employees on Day One.  The result will be happier, more empowered employees with an attitude of ownership and a focus on productivity.

Even if you don’t work with developers, you can find ways for your team members in other departments—marketing, sales, finance, operations, etc.—to contribute on their first day.  For example, for marketing it could be to identify an improvement to the copy on the site or run a new SEM campaign. For sales or customer service, it might be hopping on the phone with an actual customer.

To illustrate, let me explain to you what we do with our new developers at Cheezburger. Given that there are only eight hours on the first day, and the developer does, in fact, have some paperwork to fill out, that means there are a few puzzle pieces you need to have in place to prevent this from being a complete disaster.

1.  Start with a small, specific task that you want the developer to complete, such as a minor bug fix or a simple code change.

For example, our most recent developer fixed a bug where if a customer attempted to use a password that was too short the error message was unclear.  From a technical skills perspective, this basically meant adding a new test (to catch the bug) and a new case to a switch statement (to fix the bug).

Let’s be clear: the point of the exercise is not to have someone show you their amazing coding chops.  The point of the exercise is for them to learn the process for getting code from their keyboard into our software.  It’s simply impossible for a developer to be productive member of your team if they don’t know that process, so that’s what we teach them first.

2.  Have a well-documented procedure so that the developer can install a development environment on their workstation.

When our developers arrive on their first day, sitting on their desk is a brand new computer.  We have already setup all the accounts to all of our systems that they are going to need.  And, in their e-mail is the licence keys for any software that they are going to use.  In other words, there is nothing blocking them from getting started.

Next, we provide them a document with a 17-step process for transforming their machine into a development environment.  This includes steps for installing software they will need to develop on our code base, for fetching our code from source control, and, finally, for building and running the code on their machine.  All in all, it takes about 90 minutes to get up and running (which includes installing an IDE and database server).

In addition to the installation guide, we have also developed a few essential pieces of bootstrapping software to accelerate the install process.  One piece sets up and manages the database schema automatically, and the other manages application configurations from machine to machine.

Now, don’t think this comes for free.  We have invested in the creation of this process because it has more benefits than just setting up workstations.  When we need to build a new machine, we have the steps documented.  Or, heaven forbid, in the event of disaster recovery, we have the steps to be back up and running.

3.  Assign a mentor.

Even the best developers are not going to figure out how to follow your process and fix that bug on their own.  It’s just impossible.  On Day One, a new employee is still trying to figure out the location of the bathroom, for goodness sake!

So, we assign them a mentor to coach them through the day.  And, we don’t just say, “Oh, you can ask so-and-so if you have any questions.”  No…I take another developer and have him sit with the new employee, side-by-side, at the new guy’s desk, for the entire day helping him through the process.

Most companies don’t want to waste a second of developer time…they want developers pounding out code.  Yet, we’re “wasting” an entire day of developer time, so that we can get a second developer up to speed much faster.  In my view, that’s not waste because ROI on that day is spectacular!

In sum, the net result is that by late afternoon on a developer’s first day at Cheezburger they have been genuinely productive and are fired up to come back on Day Two for more!

—-

The inspiration for this post was that we had a developer start just last week, and he was thrilled to be productive on his first day.  That led to a conversation [via instant messenger] between myself and the three most recent developer hires at Cheezburger.  Here’s what they had to say about Day One at Cheezburger:

Me: So…how does it *feel* to commit on your first day?

John: Good.

Eli: Scary, and very good!

Me: Could you elaborate on that? Why did it feel good? Why scary?

Eli: At [my last company name], it takes at least a week to even get your box. At Cheezburger, you can feel productive immediately. It’s a little scary being so new and pushing something out to production to quickly, I didn’t want to make a mistake. But it’s awesome to have a system where you can push out so quickly.

John: Well put. Ditto.

Me: So, why was it awesome to do that? There’s something about that which feels….????

Eli: Empowering is a good term. I’d also say that there is a greater sense of ownership at Cheezburger.  At [my last company] there were several layers between the developer and production.

John: After coming from a big mega-corp with 6 degrees of separation between devs and the production environment, it was very empowering to be able to push the button without having to collect 12 different signatures or part seas.

James: At my last job, I spent 2 weeks trying to build a working dev environment.  It was so frustrating, and most amazingly (as I was just telling John and Eli) nobody was willing to help me.

Me: Wow!  That would make me want to quit.

James: I very seriously considered quitting in the first two weeks. It was a complete waste of my time. It was hard.

Eli: When new guys came into [my last company], you didn’t want to help them build their box because box building was excruciating. It’s better to hope the new guy figured it out from the out-dated documentation that you do have.

I’ll let you be the judge, but it sounds like developers enjoy being productive on their first day.  And, in my experience, happy developers are productive developers, so the efforts we make for Day One at Cheezburger are well worth it.

UPDATE: Based on the comments, some readers have interpreted the title of this post to mean that we actually withhold the location of the bathroom from new developers until they commit code.  Ha!  That would be funny…not.

We show everyone the bathroom…both, in fact, because we have two.  The title of this post was meant as a humorous way to illustrate the importance we place on getting people up and running.

If you read the post carefully, I never say anything about not showing new people where the bathroom is located.  I’m sorry if I caused confusion.

I regularly receive questions from readers about my experience working on the web, at Cheezburger, and so forth. I enjoy it when people reach out to me, which is why I make all of my contact information—including my phone number—available on my contact page. If you have a question for me, on- or off-topic, please don’t hesitate to send me a note.

The CEO of a startup recently asked me (via e-mail):

What would entice a developer to join a new startup?  If you know anyone I can email to get advice etc., and that includes you, I’d love the opportunity.

In the world of technology and developers, my interests tend more toward the product and business end of the spectrum.  So, for me, all the startups I’ve joined were simple opportunity…

• business financial opportunity — did I think this business was going to succeed and make money
• product opportunity — did this product seem like a good product…something I would care about or have fun working on
• personal and leadership growth opportunity — was I going to get an opportunity to grow and take on more responsibility and leadership
• personal financial opportunity — was I going to get paid, and if not, was the non-monetary rewards valuable

Those are the things I evaluate.  There’s no litmus test on any of them, but that’s just how I look at it.

That being said, I would imagine a lot of developers would ask…

• do I get to work with new and/or cool technology?
• do I get to build neat and/or cool stuff?

and things like that.

I would imagine there are other things people consider as well.  What are they?  What would entice you to join a startup?

Earlier this week, a group called the Seattle Collective organized a presentation with Dave McClure of Metrics for Pirates fame.  The slides from the presentation are below.

I’m a fan of Dave, and I’ve seen his presentations before, but I always am inspired or learn something new.  (Perhaps this is because Dave packs in the content—he covers 66 slides in the same amount of time ordinary mortals would cover only a dozen!)

How was I inspired this time?

I came away with a better understanding of the importance of measuring engagement and usage metrics such as activation, retention and frequency (on slides 13-15).  You can drive visits and convert shoppers into customers, but what’s the point they’re not using your product?  In other words, focus on usage and all the other pieces should fall nicely into place.

In addition, I was inspired by Dave’s idea for a “1-Page Business Model” (on slides 26 and 27).  The CEO of TeachStreet was in the audience and added that they’ve since refined their one-page model into a one-metric model, with a focus on leads between students and teachers of classes.

Now, that’s some serious knifepointing!

An update from yesterday…

Seattle 2.0

I talked to Jennifer Cabala of Seattle 2.0 about some of my professional experience—how I got my start, on getting a successful product to market, and what I will be speaking on at Seattle 2.0’s event for technologists, Deploy 2010 on June 24th.   You can read the whole interview here.

SMASH Summit

I presented at the SMASH Summit on the keys to the success we’ve had at Cheezburger.  The slides of the presentation are below, and in summary the presentation goes like this:

• We have lots of sites
• Traffic is moving up and to the right
• There were three secrets to our success

1. Create great content — in particular, content that strikes and emotional chord
2. Create lots of it — more content means you’re more likely to resonate with someone
3. Create it for less money — the key to this is knowing what about your content people are coming for; in our case, it’s the captions, not the pictures.

Seattle Weekly

One of my passions is music, and I was interviewed by the Seattle Weekly for their weekly Reverb Questionnaire, a list of questions they pose to folks outside the music industry.  Previous participants include Michael Chabon, Michele Norris, and Janeane Garofolo, so I’m in pretty good company!

At SXSW I had the pleasure of meeting Chrissie Brodigan, one of this blog’s loyal readers. Chrissie has an amazing and diverse story ranging from historian to news reporter to user experience designer.

After the event, she and I were exchanging e-mail messages when I asked, “after all your diverse experience, [why do you think] web sites or apps succeed?”

I loved Chrissie’s response, and she’s agreed to let me reprint it below:

I never would have thought this before watching companies with competing products go after users (e.g. Foursquare & Gowalla or CoTweet & Hootsuite or HuffPost & Washington Post)—I would have always said “UX”—but, it’s definitely relationships.

Here’s what I’ve learned:

Relationships with your business community get you connected to extraordinary people who can help you with ideas, resources, & more.

Relationships with your business partner users help you figure out who the right partners are (knowing that going after enterprise v. small business is the right business).

Relationships with your app’s end-users help you develop better user experience and support (you can have half the features that your competition has – but have the “right” features, and a great relationship with a loyal user base).

Relationships with your neighbors (the companies next door and across the street) help provide social energy, stamina, and honest feedback and assistance (bowling, bbqs & beer make a difference).

3 years ago, I would have always said “UX” makes an app or site successful, beautiful is not the same as successful, for myself, becoming a great designer and strategist was the easiest part, the predictable path, developing the relationships has proved much tougher.

There’s no clear grid-based layout for developing social swagger, but with some failure (sure!) and some more recent success, I believe it to be the secret sauce, potentially the greatest game changer for why some apps and sites succeed.

Yesterday, I wrote about how the conflict between penny wise and pound foolish is often the result of not having clear goals or strategy.  Today, it occurred to me that was just a variation of something my co-workers at Cheezburger hear me say all the time:

Conflicts in business strategy are fought out on the battlefield of design.

What do I mean by this?  If you’ve ever built a web site, you probably know exactly what I’m talking about.  But, if not, allow me to paint a picture for you…

You’re working on a project…let’s just call it a web site, but it could be lots of types of projects, such as building a house or designing the set for a play.  The salient point is that all of these projects have one thing in common: you’re building something.

You meet with the designer and you tell him or her what you want.  Maybe you give them a creative brief, or some bullet points, or even just a few words of direction.  Everybody thinks everybody is on the same page, singing from the same hymnal…the project is going well.

In time, the designer does their work and returns with mockups.  Excitement abounds.  A meeting is convened.  The designer rolls out their designs…and then the circus comes to town!

All the sudden everybody is arguing and telling the designer how to change things around.  All of the sudden everyone is a designer and has an opinion about the design.  And, the poor designer…just sitting there…servant to a hundred masters…has an impossible job to do.

And, you know what’s happening: a conflict in business strategy is being fought out on the battlefield of design.  And, just like the story of pennies and pounds, when you find yourself in this situation, it’s time to step back and look at your goals and strategies.