Live Work Oakland, the exciting project I have been working on for the past 6 months, launched yesterday and is live at liveworkoakland.com. This site, focused on building innovative business community and tech economy in Oakland, CA, is a wordpress site with an interactive map and directory, how-to guides for doing business with the city, a bloggers directory, and articles about tech/business leaders and projects of note. Because it is me and because it is Oakland, we are of course, amazingly focused on diversity, women, youth, people of color, equity issues and job creation. Our wonderful partner in supporting this has been the Kapor Center for Social Impact, who are a group of superb people who have really helped shape the core of this project.

At 7 PM yesterday, I found myself in front of 200 people, many of whom I’d worked with and dreamed with  for the past 4 years of doing Oakland Local, presenting a brand new site that was really focused on growing business community. We’d gone live, aka cut over from the staging server, maybe 4 hours before, so this was brand new to all. As I stood there, getting funny as I often do when I feel under pressure (and making a hellluva stump speech about tech jobs for Oakland), I thought about the factors that made this project–and therefore the launch–work well.  That’s what  I want to share and reflect on here.

WHAT MAKES A GOOD PRODUCT DEVELOPMENT CYCLE AND LAUNCH PROCESS?

1. Know who the team and the decision makers are before you get going

We had a capable and trusted developer, maiki interi–we have worked on projects together since 2008-who was going to be the tech lead.  I was the product lead, and my counterpart at Kapor, co-managing director, Cedric Brown, was our sign-off resource–in other words, we were going to build something that met both the goals and the quality level Kapor expected.

2. We speced the minimum viable phase 1 product out, agreed on names and URLS before we started.

Oaktech? Live Work Oakland?  I bought about 6 domain names for this project as we planned it, but we were able to select one and secure the social media assets early on, so that was out of the way.  We also wrote a simple spec and prioritized the features against the budget and the timeframe. In that process, core items like a mobile friendly map and directory rose to the fore, while others, like a multi-author capabiity for articles, fell down the list.

I also started a Google folder and docs where I listed potential authors and contributors, story ideas, data needs, and resources. That became the core planning tool for the project on the content and business side. We created a seperate google folder with some–but not all–of the plans–for the freelancers we involved.

3. Great effort to have frequent communication and tools to support it

maiki and I live to work with basecamp or a similar tool where we can have a project and leave notes for one another. We also use jabber, hangout and similar tools to talk. (And we do meet in person as well.)  With Cedric, we shared documents, data, and plans, then brought him in at some key moments about the back end, and shared the theme shortly before launch(we were super tight on time for this).

4. A dedicated and resourceful developer who likes to solve problems

How many custom post types did maiki have to build to meet our needs? A lot would be my answer. As some of the requirements became clearer to him, we had to customize more. And he was totally willing to go there!

5. Deadline for a beta we raced to meet–and an event that forced completion

We knew we had to show the site on Nov.20 at an event–and we wanted to finish the whole site by Nov. 10. Of course, that didn’t happen. Instead, maiki was tweaking the back end by the 10th and implementing the theme, which also needed lots of tweaks and modification (we used Swatch).  But we were able to be close enough on the 10th that we knew we could make our drop dead deadline in good shape-which brings me to the most important point:

6. Be willing to cut features to make your deadline

As we worked to finish the site, some plans fell away and were delayed. The great piece of reporting we were going to include got pushed off till 2014–as did the third How-to guide. We also identified features we wanted that were out of scope–and  instead of trying to cram them in, we both agreed to delay them for a later phase (and in that lies the secret of success).

7. You can never do too much proof-reading and fact-checking–so leave time for it

For all the people I asked to edit and proof the site, I found myself getting notes from Cedric, 24 hours before launch, with some notable errors. Like, why did our listing for the Kapor Center have their OLD address (and I thought I had corrected that!)   Once I got Cedric’s notes, I personally went through every entry, checking everything. Some of the corrections I made included out of date addresses, garbled social media links, CEO email addresses vs. general inquiry email addresses for some companies, and a couple of entries where the upload of most of their data, except the name, had failed. I was able to fix everything I found, way in advance of going live. This was the kind of moment where the Andy Grove aphorism “Only the paranoid survive,” helped.

8. Explain and model tasks for your team in detail if it’s a new task/project

Two of the folks I work with regularly, both of whom worked on this, had some margins of error. One, who asked great questions, didn’t make any real mistakes. The other, who did just a little bit of work, but didn’t ask, did pretty much 90% wrong–which was my fault for not being clearer.

9. Remember it is iterative–but people judge on first impressions

Don’t overbuild–but also don’t be sloppy and claim BETA as an excuse. It’s got to be good, even if it feels limited compared to the entire vision.

10.  Install metrics and watch user behavior

How are people interacting with your new site? What are they doing and where are they going? Observations now can help drive development later.