Operations & Product Development

Going Fast Part III: Operations

aerodynamic bike helmet

[This is the third and last of a series on getting your start up to go fast.  See the first post to learn where these notes came from.]

Going Fast notes on Operations

Don’t allow process creep.  As part of maintaining a fast production culture, you should actively prevent too many processes from getting put in place.

No QA department.

10 at 10 meetings. Have a 10-minute, standing-up meeting at 10 am where everyone on the team reviews what they’ve accomplished yesterday and what they’re planning to do today.  This is a quick way to sync people surface any conflicts early in the day before too much work is done.

Spend less than 5% of the minutes you’re working per week on meetings. It can be done, and your communication will be much crisper and clearer if you hold yourself to this standard.

Engineering Task Blast. An engineer presents a task he/she needs to accomplish to the other engineers on the team.  Everyone writes down how long they think it will take.  Everyone shares their number and then talk about how the engineer might do the task it faster.  They agree at the end how long it should take, and then the engineer is held accountable by their peers.

Don’t create silos. Whenever an organization creates “engineers” or “marketing” silos, it slows the company’s progress down.  Only allow cross functional meetings.

Establish a cadence of work. Regular releases, weekly milestones, daily short meetings, monthly major releases, regular user testing and review of the report, after work drinks, etc.  Get in a grove with your team, your product and your users.

Drive batch size down.  “Continuous releases” or at least several times per day or at least once per day, has many advantages.  You can course correct easily based on user feedback.  You can avoid introducing drama and disruption to your team.  Makes it hard for your competitors to keep up. Makes it easy for users to see constant improvement.  (Google has small daily releases, medium releases every week, and large releases every 5 weeks.  They assumed 5 weeks was enough for almost anything, and that has proven to be true.)

Measure the right things and elevate those to everyone’s view. As a manager you should obsess about choosing the right metrics to measure, how you’re presenting what you’re measuring (meetings, daily email stats reports, flat panels on the wall with real time data, private emails) and then how you reward people for accomplishments publicly.

Quick, cheap, early user feedback. Put up design mocks on forums.  Put up a video of what you think it will do and ask for feedback.  One CEO told me the best thing he did in 2009 was implement a weekly program of buying 5 tests of his product by target users from http://www.usertesting.com and then reviewing the resulting videos on Friday afternoons.

Transparency. Having all goals and data available throughout the company allows good people at every level to make the right decisions faster.  You must make it really easy and really clear (and perhaps fun!) for people to get the data they need to make decisions.

Small teams. Google constantly breaks teams down into no more than 7 people.  Amazon has “Pizza box teams” which is defined as a group that only needs one large pizza to have dinner.  Over 300 Pizza Box Teams touch Amazon’s home page.

Communicate priorities. Create a spreadsheet that everyone on the team easily has access to that shows all the major things that need to be done in priority order with the name of the person to do them and the date they are to be done.  In meetings, argue over this list.

Create the perception of competition to motivate all external relationships.  Getting other organizations and people outside your company to move quickly (VC’s, clients, distribution partners, potential employees, users) is very difficult.  The main lever you have is to always make it clear to them that there is time urgency and competition for whatever they think they may want from you.  That’s the most repeatable and universally effective lever you have.

Ooga Labs, Operations & Product Development

Going Fast Part II: Culture & Personnel

[See the first post in this seriescheetah-running and an explanation about where these notes come from]

Notes on Culture & Personnel for Going Fast in start ups:

Get cultural DNA for speed. Make sure the people in your company want to go fast and know how to go fast.  Make it a major part of your interview process and visible culture.  Web 2.0 folks generally get it, but others don’t and they need to be cycled out.  Can you pair fast people with not-fast people and teach the not-fast people how to go fast?  No.  You can’t.  In short, get the right people.

Every engineer ships production code their first day at work. As part of building up the cultural DNA about quickly writing code and pushing it out for users to use,  you should set it up so every engineer writes and pushes live some code to the production servers on their first day of work.  If the site breaks in some way, shame on you for not having it set up avoid that.

Make shipping a fetish.  Make shipping product fast to the right customer the obsession.

Fast is not sloppy. Make sure your team knows the difference.

The best thing to do is the easiest thing to do. But do it right.  That’s speed.

Don’t own the product, own the goal. At Google, teams choose a goal to own, not a feature to own, or even a product to own.  What product solution ends up achieving a goal evolves much more in a business than the goal itself, so the goal is the better target, and gives the team more opportunity for creativity and speed.

Make decisions. Make sure you’re making decisions, not pseudo-decisions or delaying decisions.  Commit to it as a team, and have the team demand it from management.

Ship Fair or Good. Don’t ship Poor, but don’t ship Very Good or Excellent.  And when the Fair-Good is shipped, management is not allowed to send an email out noting the bugs or criticizing it. Get your team to embrace “Good Enough.”  I [heart] good enough. “That which is worth doing is worth doing poorly.”

Operations & Product Development

Going Fast, Part 1: Planning Notes & List of Resources

The Flash going fast

Speed.  The holy grail for small tech start ups.  A few weeks ago, I had the pleasure of sitting with 20 other entrepreneurs and talking through how we can make our start ups go fast.  Here are my notes combined with some additional notes I’ve taken over the years.  It’s divided up into 3 long blog posts: Planning & Resources, Culture & Personnel, and Operations. Many thanks to the many entrepreneurs who shared their thoughts openly that day.  I hope these notes are useful to you.


BLOG: Eric Ries  http://www.startuplessonslearned.com/

BLOG: Sean Ellis http://startup-marketing.com/

BLOG: Dave McClure  http://500hats.typepad.com/500blogs/ (Dave has a presentation called Start Up Metrics for Pirates)

BOOK: Four Steps to the Epiphany, by Steven Blank: http://www.amazon.com/Four-Steps-Epiphany-Steven-Blank/dp/0976470705/ref=sr_1_3?ie=UTF8&s=books&qid=1256622987&sr=1-3

BOOK: “Getting Real” eBook by 37Signals: http://gettingreal.37signals.com/

BOOK: “Lean Thinking” (a book about Toyota’s management process) http://www.amazon.com/Lean-Thinking-Banish-Create-Corporation/dp/0684810352

BOOK: “Back of the Napkin”  by Dan Roam: http://www.amazon.com/Back-Napkin-Solving-Problems-Pictures/dp/1591841992/ref=sr_1_1?ie=UTF8&s=books&qid=1256623431&sr=1-1

TOOL:  Balsamiq allows you to mock up ideas get the idea across and talk about it.  Very fast, saves time and hand waving. http://www.balsamiq.com/products/mockups

TOOL:  UserTesting.com : http://www.usertesting.com/

Notes on Planning

Fast toward what? You have to define your goal well.  Often it’s worth spending a few more weeks up front not building anything but doing more research, more inexpensive testing of your assumptions, and more brainstorming to get a better idea of WHAT to build before you start building.  Who is it for?  What problem are we trying to solve.  If you change your strategy, you could lose months of time.

Fast depends on stage of business evolution. When it’s you alone, fast is checking your assumptions and coming up with the right plan.  When you know what you want to try, but you have no working product, it’s perhaps getting a usable product to some potential customers.  When you have found product/market fit, “fast” will mean something different.  When you have revenue, it’s probably different.  When you’re profitable, fast is perhaps different yet again.

See Going Fast Part II: Culture & Personnel, and Going Fast Part III: Operations.