The other day, while sorting through some old paperwork, I found a document I’d written in 2004, while working on a project team for a groundbreaking new product, within a big global internet company which shall remain nameless. I left that company a while ago and the project ownership was shifted stateside the year before (as most juicy projects were), but the product itself finally launched late last year.

It wasn’t the groundbreaking, game-changing thing I’d dreamt up with a few people in 2004 and shepherded through the early stages of the political, business and technical badlands of a large and complex organisation with a growing identity crisis. But there were some resemblances.

The initial idea creation, proposition development and project validation had been done by a small group led by me for a year or so, working on this first as a side project with the blessings of the senior leadership team, and then full-time.

But soon enough, the project got senior-level sponsorship (the CEO of the entire global shebang said “There is no more exciting project within this company at the moment”, which either said a lot about the project or the company…) and as a result, everyone and their dog wanted to get on board and hop on board the glorytrain. I was swiftly relegated to “project visionary” and consumer experience lead - the spiritual owner of the product, with significant influence over what and how we should deliver, a license to interfere in all sorts of areas but no real power - and the message from The Powers That Be was clear: get it done. Fast.

So, in absence of the power to slap people and structure how we should work and exactly what we should deliver, this document was intended to unite a global team (working across five geographic locations and in disciplines from design to development and marketing to business planning) around a common set of values - an operating approach statement. The idea was that anyone on the team should understand that these points would inform and influence every decision which was made around the project, and anyone not on the team would understand why we might be doing things or asking to do things in a different way.

I present it below without commentary, mainly as a historical artifact showing how much things like this become unfortunately necessary when you’re working in a diverse, distributed organisation and struggling to change the way it worked.

I still believe that sometimes a team operating statement can be a very useful way to align people’s approaches - the end result might be very well understood, but sometimes the process can be very bumpy.

In work, as in Fun Boy Three and Bananarama collaborations, It Ain’t (just) What You Do, It’s The Way That You Do It (and That’s What Gets Results).

Or, to remix it slightly: the way that you do it can often affect (in both good and bad ways) what you do. Sometimes the journey is as important as the destination.

We believe, in order to make [project name] a success…

…we need to think BIG
• There will be one global product
  We will all make decisions for the benefit of the global product and project, regardless of where we sit
• Having a great, innovative, exciting product will lead to profit in the long term
  We need to balance short-term profitability with creating a quality product
• Category ownership is different from category creation
  We may be pipped to the post, but there will still be an opportunity to make an impact.
  We need to assess the market environment constantly and review/revise our plans accordingly.
  In both cases we need to make an initial tactical play and have a clear but flexible ongoing strategy in place as early as possible

…we need to think DIFFERENT

• This isn’t just another [company name] product
  Localisation should be as light as possible (i.e. language, billing).
  Flexibility is key: interface, UI, back end - my cousin in France or Brazil can have the same experience as me but in a different language.
• Existing [company name] members are important, but not more important than web users at large
• There needs to be a WOW factor
  An innovative customer experience which excites and delights users. An intuitive, engaging experience should be the starting point for product design, not the way we package standard features. The product doesn’t just need to look amazing, it needs to actually be amazing.
• The product needs to offer both web and client experiences
  Leveraging the advantages of both (i.e. universal access and reach via web, powerful upload/download/synch functionality via desktop)
• We have to make it personal
  We are our own best alpha/beta testers. As a team, we should be immersing ourselves in [the product] on a daily basis, including new and developing features. If you think this is a project for “them” rather than “us”, you probably shouldn’t be working on it. We are consumers, too: we should be voracious in researching and experimenting with alternatives, competitors and more - we need to experience things as consumers.

…we need to think FLEXIBLY about how we deliver products to market

• The normal [company name] route to market (including aspects of business strategy, product development, marketing and release) may not apply to this product. In fact, it probably won’t.
  We need to continually ask ourselves “how would an entrepreneurial, innovative, agile company do this?”
• We need to focus on not just what we do, but how we do it, with a focus on being entrepreneurial, flexible, innovative and responsive both in process and product, and with a focus on getting stuff done.
  This means skilling-up the business appropriately, thinking differently, being prepared to change the way that we work and challenging normal procedures if they won’t work for us. This also means aligning as a team around common, agreed values and threading them through all aspects of the project: making it real, walking the talk.
• We need to start with the consumer
  Figure out how to meet and exceed their needs (and remember that consumer requirements may be described in terms of emotional drivers rather than feature attributes). Then figure out how much they will pay for the solution (hint: could be nothing). Then figure out how much it will cost us to deliver the solution. Then figure out how to deliver it to meet that cost. In that order.
• Speed is important, but not at the expense of quality
  Being quick to market with a shit product means nothing.
• Timing is more important than size
  A small element of the product, done well and delivered quickly to market will have more impact than a big, feature-packed late arrival. We don’t have to do everything at once.
• There will never be a ‘GM’ (final release) for [product name]
  The product will evolve and develop over time: we can start small/simple. Beta is our friend (many exciting products are in permanent beta). Beta doesn’t mean what it used to - these days it means “we’re still adding stuff” rather than “it’s not ready”. Working in a modular, iterative way, in dialogue with our customers, may lead to greater, stronger long-term success. We need to focus on getting the basics right then deliver a rapid succession of small quick wins in terms of features, rather than waiting until we are in a position to deliver a perfect whole. It will be too complicated and too late.
• Incremental changes to existing products, edging them towards new category space, won’t have the same effect as a revolutionary new product in a new category
  The products or services that [company name] already has which are close to this, or nudge around its edges, aren’t expandable. Cobbling together a handful of almost-right products does not give one amazing user experience or proposition. It’s confusing, and we need to avoid doing it, however tempting and however much pressure we get from existing bits of the business to just tweak a little bit, when what we ought to be doing is throwing things away and starting again.

Needless to say, we started out bravely, and sooner or later the politics and process took over from the product. It got whisked away to a different bit of the company; launched two years later than expected, bloated with technology and yet with none of the really interesting and innovative functionality we’d planned. It had been lapped (several times) by others entering this market space, and as a result, struggled to take hold.

By the time it actually launched, I’d left the company and was glad my name wasn’t on it. Which is a real shame, because it could have been fabulous. And yet. And yet.

Just call me Meg Quixote.