The inefficiency of today's data centres

The Week (an excellent (weekly printed) aggregation of the best journalism across the globe) provides this excellent summary of a New York Times article about inefficiencies in data centres - The Cloud Factories - Power, Pollution and the Internet.

Some stats pulled from The Week:

• 30 billion Watts of electricity used by digital warehouses worldwide, roughly equivalent to the output of 30 nuclear power plants
• 76 billion Kilowatt-hours used by data centers nationwide (ie in US) in 2010, or roughly 2 percent of all electricity used in the United States
• 6 to 12 Percentage of electricity powering servers that perform actual tasks, according to consulting firm McKinsey & Company. "The rest were essentially used to keep servers idling and ready in case of a surf in activity that could slow or crash their operations," says the Times.
• EMC and the International Data Corporation together estimated that more than 1.8 trillion gigabytes of digital information were created globally last year.

These figures are horrifying - but why do they exist?

Simply, because there is a whole culture in the IT sector of having massive redundancy:

“You look at it [this report] and say, ‘How in the world can you run a business like that,’ Mr. Symanski (of the Electric Power Research Institute) said. The answer is often the same, he said: “They don’t get a bonus for saving on the electric bill. They get a bonus for having the data center available 99.999 percent of the time.”

Apple - the most valuable company in the world

Apple's market capitalisation is today worth $654bn - making it the most valuable company on the stock exchange - for all time. (Technically, Microsoft had a valuation of $615 billion in December 1999 - which would, in today's money, equate to $850bn.)

Some facts (courtesy of the Economist) about Apple's dominance:

• 4.8% of the S&P 500 
• 3.7% of America’s stockmarket
• 1.3% of the global equity market.

Check this chart for its meteoric rise:

Bulls reckon that the price could go even higher—and that Apple could become the world’s first public company with a trillion-dollar market capitalisation.

No reason to doubt the optimists.

The key point is that Microsoft and Apple both generated a new and better user experience for their customers. That's how valuable UX is!

November's Cambridge Product Management Network meeting debates whether Steve Jobs was the world's greatest ever Product Manager.

Come along and join us: details here.

Wi-fi predominant connection over mobile network for smartphone users

Deloitte Global Mobile Consumer Survey 2012 shows that 58% of smartphone users and 93% of tablet users connect to the internet over wi-fi rather than over the mobile network. It's faster more reliable and more responsive.

Interesting, smartphone users in other countries (US, Germany, France and Japan) prefer to connect via the mobile network.

• Other stats: 30% would prefer to pay for a fixed amount of data and then pay addition usage charges once they have reached the limit.  
• Half the smartphone owners subscribe to less than 1Gb of data and only a fifth of respondents subscribe to unlimited data package.

Mobile Operators are missing a simple trick - but one that massively demonstrates their value: a simple counter that is constantly displayed on their home page which shows their usage since last billing date / top-up date vs their contract ceiling. It should display call minutes, text minutes and data limits.

What I find irritating about mobile operators is that they wish to charge users a different additional tariff for tethering another device (for me, a laptop or a netbook) to their mobile phone. I tether these device infrequently to my phone, but when I do, it is very useful, but my usage isn't predictable enough to justify the expense - particularly when swinging off someone's wi-fi usually works.

Naturally, mobile operators don't want to offer unlimited data - this resources isn't infinite. Such a policy is madness, as I have blogged a long time ago:

• Orange (at last) has a common sense data plan (April 2007) 
• 3 launches X-Series - Mobile Broadband bundle - when will they learn?? (November 2006)

However, I would like to use what has been contracted without any gotcha clauses! David Halstead, technology, media and telecommunications partner at Deloitte in Cambridge recommends:

Mobile operatios should offer their customers a seamless connectivity experience including Wi-fi hotspots that their customers can use when they are out and about.

Hmm, this concept is known as fixed mobile convergence and has been around for ages!

Article first seen on Cambridge Network.

How to build a Product Release Checklist - expanded

On Tuesday evening, I was one of the panelists at a joint Chartered Institute of Marketing  and Cambridge Product Management Network event on Product launch disasters – and how to avoid them!

Prior to the event, I reviewed other examples of Product Release Checklists (eg New Product Launch Checklist and one of my own Checklists), then I thought that they were too specific for the product / release in mind.

So, as a Product Manager / Product Marketing Manager going through a release, you have to build you own. (Do use the examples above as reference - they aren't bad, just that you don't know their purpose!)

More useful, I thought, would be my technique for Building your own Product Release Checklist - technique that I used when I was brought in as a consultant to help deliver a release for ADP Dealer Serivces from June 2011 to March 2012

1. Determine the impact on all stakeholders

Consider how the release will impact all the stakeholders - both external (eg customers!) and internal . Some are obvious, some are more obscure and requires you, as the Product Manager to know how your company operates. See side panel for the list of (potentially) affected business functions for a B2B product release.

External Stakeholders Customers

• Front-line Users
• Customer Purchasing Decision Making Unit (technical, business, financial)

Channel Programme

• Distributors: Marketing, sales, operational teams, customer support
• Value Added Resellers: Marketing, sales, operational teams, customer support

Internal Stakeholders

• Sales
• Pre-sales
• Marketing
• Sales Operations
• Account Management
• Customer Service
• Contract / Legal team
• Installation Teams
• Finance

 2. What documents will inform stakeholders of the impact?

Imagine yourself as someone in one of these business functions listed in the side panel. What information (and at what density) will this person need in order to understand the product release and its impact on their business function.

For example:

• What product summary does an existing customer require vs a new customer
• Does the product demo need to be modified for either audience?
• Are there sub-sections of the existing customer base that will need a customised 'flavour' of the product release announcement, based their requirements? (Example: This may be necessary when not all existing customers are able to upgrade to this release.)
• What information would the Legal team require to understand the release? If there are no contract modifications required, then the Legal team would appreciate a note telling them so.

3. Build a Library of Reference Materials

As you go about your journey of discovery about a product and its release, you will amass a treasure trove of documents from internal commercial requirements to technical architecture diagrams. I recommend that you use a some sort of repository for these documents (with an index - see my example). Ideally, this should be online, so that it acts as a single repository for others to use.

Do not wait for perfection before you add any document to the repository. If the answer is 'Oh, it's the same as last time', then ask for the old version. You'll be surprised at the number of times the document from last time doesn't exist OR requires substantial revision even if it is merely freshing up the corporate branding and updating the copyright notice.

4. Build an Issues List

In collecting these documents, you will inevitably discover road blocks. Examples:

• 'Well, the product will do X or Y, based on customer Z's stated requirements, which we are waiting clarification on'. 
• 'I can't tell you the final pricing structure until person X has reviewed the operational costing for this year and next'

Note these down in the Issues List with responsibility, blocking issue and next decision date. Ideally I would recommend that you use the same tool as the document management repository because the Issues List and Document Repository are closely interrelated! Other tools that I have used are Excel and sometimes a bug management list works well too although assess to this list maybe limited),

5. Iterate!

Once you have started the document chase, you will quickly find that the Issues List far exceeds the Document Repository. The next step is to work through the Issues List allocating tasks to people and making sure that they understand that what deliverable is required of them and by when. And that you'll be nagging them (and subsequently their boss) for the deliverable.

As you may have guessed, this schedule then becomes a loose project plan for the release. In my experiences, the conflicting interdependencies within project plan (eg if we add feature X then the release will take more time and the training of the sales team will require more time). It's best not to start this project plan too early as you will be creating a rod for your back!

6. Communicate regularly

Communicate your progress on a regular basis.
With everyone

• I recommend that you have an All Hands meeting about the release. This is a great way of flushing out rumours and building enthusiasm about the product release. 
• Frequency: 2-3 months before release and the week before release date.
• With mid-management:
• This is the enabling body in any organisation - this crowd needs to be (a) onboard (b) have the ability to input their concerns and issues and (c) to be seen to be contributing in front of their peers.
• Frequency: every month or six weeks prior to release
• With execs:
• This is the decision making body. You need to schedule time with these guys to drive decision-making between their business functions and to prioritise work effort within their divisions
• Frequency: Every week or every two weeks. Book the time out now, even if you don't know how or what you are going to present!

7. Don't forget to celebrate!

Lots of effort has gone into the release - give thanks and appreciate to where it is due.

8. Conduct a Release Post Mortem

After a suitable period of time after the release, gather the stakeholders together and have an honest review of the release. What worked for each business function and what didn't?

How to build a Product Release Checklist

In review other examples of Product Release Checklists, then I thought that they were too specific for the product / release in mind.

So, as a Product Manager / Product Marketing Manager, you have to build you own.

Here's my technique for building your own Product Release Checklist:

1. Determine impact on all stakeholders
2. What documents will inform stakeholders of the impact?
3. Build a Library of Reference Materials
4. Build an Issues List
5. Iterate!
6. Communicate regularly
7. Don't forget to celebrate!