Scott Porad

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.

Penny wise and pound foolish.

Who hasn’t heard that expression before?  Saving a penny today at the expense of a pound (the British equivalent of a dollar) tomorrow.

What occurred to me over the weekend is that startups are all about making choices between being penny wise versus pound foolish.  From the minute you decide to create a product or service, these types of choices are presented daily.

Sometimes you have to make efforts now that will pay off in the future.  Other times you just have to choose to do something the cheap, quick and dirty way knowing that you may have to pay more to clean that mess up in the future.

It can be a real struggle to make choices that you know are dooming you to future headaches.  Each of these is a little debt that may have to be paid back one day.  On the other hand, if you spend a bunch of time on something that isn’t worth it, then your startup may never survive until that magical future when those little IOUs come calling to be paid.

Of course, the whole thing is the art of knowing which to choose when.

Actually, it’s not that much of an art if your goals and strategy are clear.  Clear objectives make many of the penny vs. pound choices clear as day.

Often I get bent out of shape over a penny vs. pound decision, but usually what helps me decide is getting a clear handle on our goals or strategy.  In fact, often these types of conflicts are a result of unclear objectives.

When they happen, I find the most success when I take a few minutes to step back and consider the big picture.  Typically, finding clarity in the path we’re headed leads to an easy decision about pennies vs. pounds.

The other day I wrote that what’s most important for a successful startup is:

…finding a product-market fit…. Everything else is just commentary.

and I stand by the first portion of that statement.

However, I sort of take issue with myself on the second portion: is everything else commentary or noise?

The more I think about it, the answer is noise.

Think about the post I wrote last week about getting started with Lean Startups.  Or, likewise, the one about how to create a successful blog.  Both of these had to do with cutting through the noise and paying attention to what’s most important.

Keeping your eyes on the prize, as they say.

Often, when we talk about building startups, or technology, or social media, we get carried away with so many ideas and details.  It gets confusing and noisy…we get mixed up with Methodology X or Philosophy Y or Practice Z.  All of these methodologies and philosophies and practices serve a purpose, and that’s what we often forget.

Simply put, we confuse ourselves and lose the forest for the trees.

This tweet caught my eye last night:

which led to a post by Antonio Rodriguez summarizing a keynote he gave at PyCon (i.e. a conference about the programming language called “Python”).

Rodriguez made three key points in his presentation, only one of which I’ll address here…he said:

I think every employee in a web startup— or in fact any company which depends on software in any meaningful way— should learn how to code. From the slickest sales guy to the most obstinate operations guy, from the laziest intern to the most professorial manager, if they don’t have their hands in the code, your startup is much more likely to fail.

I don’t disagree with this idea, although I terrifies me a bit. Rodriguez’ arguments for this are two fold.

First, it breaks down the false dichotomy between “business” and “technology”. I agree, in a web startup—the only type of place I’ve ever worked—the technology is the business.

Second, he argues that if everyone were able write code—even if it is just a marketing person updating the UI of an analytics report—”will tighten the loop and give you massive competitive advantage”.

I would add a third point, based an idea Joe Heitzberg mentioned to me the other day: in a web-based company, there are two types of workers: “work creators” and “work doers”.

A person who writes code is a “work doer”. A person who writes a spec is a “work creator”. (A person who designs web pages is a little bit of both.)

That’s not to say a person who writes a spec isn’t important…they play a crucial role in making the person who writes code efficient and effective. However, it takes another person (a work doer) for the value created by the spec writer to be fully realized.

The point isn’t that your company should be all “work doers” and no “work creators”. The point is balance…having an appropriate number of work doers versus work creators.

At a previous place I worked, I’d estimate we had 4 work creators for every 1 work doer. That was not the right balance.

On the other hand, toward the end of last year at Cheezburger we had the opposite problem; we had too many work doers and our ability to write code outpaced our ability to figure out what exactly to write.

Effectively, Rodriguez’ point is that everyone should have some work doing capability, even if it isn’t their primary job role. As a result, startups will have greater flexibility because they will be able to more fluidly maintain the proper work doer-work creator balance that is essential for success.

We were recently interviewing for a position at Cheezburger, and a candidate was describing a difficult situation at one of his previous jobs.  I asked, “How did you resolve it?”

“Well, I’ve never seen the world’s problems solved without communicating,” he replied.

I practically wanted to hire him on the spot.

—

One of the things I’ve been thinking about quite a bit lately is putting together good teams.  (Randy recently suggested a book called Beautiful Teams, but I haven’t had time to read it.)

More specifically, I’ve been thinking about when startup teams start to grow beyond the point where everybody can sit in the same room.  There are three dilemmas that have been on my mind.

Specialization versus Generalization

When there are only a handful of people, specialization is something that’s hard to afford.  Instead, a startup needs jacks- and jills-of-all-trades.

The thing about these jacks and jills is that they’re hard to interview for because most of what being one of them entails are intangible qualities: a good attitude for doing anything and being flexible, and the ability to figure things out on your own.

Ben is always suggesting doing some sort of screening or “testing” to find candidates with these qualities, but have yet to think of a screen or test that will find these types of people.  I would completely be open to your suggestions in the comments.

Organizations in Flux

Another dilemma has to do with building teams at an organization in flux.  One quarter your building widgets, but the next quarter you’ve pivoted based on the “product/market fit” and you’re building gidgets.

At a more stable company, or where you have larger organizations (and specialization), it’s much easier to say, “we need a widget stamper” and hire someone against that need.  But, at smaller companies you’re always looking for people who could potentially fill two or three roles.  “I need a widget stamper who could also manage the widget stamping team, and occasionally make gidgets.”  Again, this raises the degree of difficulty on hiring.

Functional versus Tactical

A functional team is, for example, the design team—all of the designers report into a design manager.  A tactical team is a “project team”—in this case, there is a cross-functional group that works together on a specific task.

In a startup, tactical teams are absolutely the way to go.  In a small startup like Cheezburger, we’re basically just one tactical team all working together.  But, as startups get bigger, having one giant tactical team is impractical.

This is illustrated by the following riddle: “If it takes 2 people an hour to dig a hole 10 feet deep, how long does it take 6 people?”  As anybody who has ever worked on a group project knows, the answer is not “20 minutes”.  At best, it’s “one hour” and more likely it’s “an hour and a half”.

As a result, the practical thing to do is split the group into multiple tactical teams.  Yet, there are two challenges I see with tactical teams.  First, is the obvious, “who reports to who?”  Is it realistic to expect a project manager to supervise a developer or designer?

The second has to do with actual quality: at some point, as you have more than one tactical team, there has to be someone ensuring the “quality of the craft”.  In other words, someone making sure that all the developers, designers, etc. are working to the same standards of quality across all the teams.

Typically, what ends up happening is that there are functional teams and tactical teams.  The official org chart has functional teams, but as a day-to-day matter people work on projects tactical teams.

The introduction of functional teams means hiring functional team managers, which adds overhead, both monetary and organizational.  A startup might be able to afford the monetary overhead, but it’s the organizational overhead that is the killer.

Why? All of the sudden, there are do-nothing-managers having meetings with other do-nothing-managers about what the actual do-something-workers should be doing.  In the meantime, the do-somthing-workers sit around and wait to be told what to do.  At this point, most likely, your startup stops being nimble and dies.

Square Pegs

These issues are murky and challenging and there isn’t a right or wrong answer.  These dilemmas have probably been around for generations—I bet the bible even has suggestions on org charts!

Yet, all of this confusion leads me to a final thought: earlier in my career, if there were a team member who didn’t fit—a person who was competent, but who was a square peg in round hole—my inclination was to replace that person with someone who is a better fit.  I regret some of those decisions because now, with more experience, I see that that as a mistake.

The biggest challenge in hiring people is finding someone who is a good fit.  Hiring for a startup is risky and hiring mistakes are expensive, both financially and organizationally.  As a result, these days my inclination is the other way: if your team has someone that is “good”…someone who is competent, who works hard and is committed to their jobs, who is pleasant to work with and willing to be flexible and learn new things…then find a place for them.

A startup is probably better off with these people than with the unknown of a perfect widget maker who probably has some other set of issues that, as a startup manager, you’ll have to deal with.  In other words, it’s the devil you know versus the devil you don’t!

Dave McClure recently wrote a blog post that everyone is going gaga over…here’s the money line:

Gradually we are discovering that the default revenue model on the internet should probably be the simplest one — that is: basic transactions for physical or digital goods, and recurring transactions (aka subscriptions) for repeat usage.

This is not new.  In fact, it’s the same shift that happened after the first dotcom bust.

When we launched drugstore.com, it wasn’t initially clear if the core of the business was e-commerce product transactions or health and wellness information (like WebMD) or an online health magazine.  But, when the economy tanked, the answer became crystal clear: e-commerce was the core of the business because it was the actual way to make revenue.

Now, we’re in Web 2.0 and we’re doing the same thing over again.  The economy has tanked, people need to make money, and…oh, look at that, charging for things is the best way to do it!

In other words, Web 2.0 is the same thing as Web 1.0, it’s just that the players and technologies are different.

There’s an old phrase, “those who don’t study history are doomed to repeat it”.  I’m not sure if this is “doom” versus the realization that every business cycle has similar characteristics and phases.  In another 5 years, this phase of Web 2.0 will shake out, and then we’ll be on to some new technologies and Web 3.0.  Rinse, lather, repeat.

From there, Dave goes on to explain who—as part of this great revenue realignment—is going to win.  His points on the winners and losers are interesting.  I can’t say one way or the other if his predictions are correct, but his trendspotting is right on.

I am on the board of a local non-profit.  Like the broader economy, and many non-profits, finances have been tight.  The good news is that our 2010 budget is looking pretty okay.  The not-so-good news is that our 2011 projections are not so rosy.  As a result, we met over the weekend to discuss and plan.

A pastor from a local church with a lot of experience in non-profit management and fundraising who counsults with other non-profits came to meet with us.  We had a long meeting, but he shared a few key thoughts on fundraising that somehow seemed applicable to the world of startups:

• Philanthropy directly correlates to volunteerism.
• If you need money, ask someone for advice.  If you need advice, ask someone for their money.
• People will not contribute to a non-profit because it has needs; they will contribute because it meets their needs.
• Fundraising is about having relationships…with people who make decisions about money.

How I word translate these to startups:

• Revenue from customers directly correlates to participation.
• If you need to raise money for your startup, build a circle of advisors to can guide you.
• Customers will pay for your service because it meets their needs.*
• Business is mainly about relationships, but revenue is about relationships with people who make spending decisions.

A final note on the item I starred (*): Kathy Sierra extends this thought in a way that I am fond of.  She says making great products isn’t just about serving customer needs…it’s about making them feel that they’re more excellent for using your software.