Monday, April 27, 2009

How to find a new Tech job

With the downturn in the economy, many people in the tech industry are finding themselves laid-off. Don't despair, as there are always opportunities for the right people, and I've notice a recent upswing in hiring activity.

Now is a great time to take stock, and work out exactly what you are looking for in the next role.  Don't just jump into the first opportunity, but take time to consider what you really want to do with your life.  Big company? Small company? Career change? Startup? Sit down with a piece of paper and work out where you want to be in five years - then create a roadmap of how to get there.

Once you know what you are looking for, here are some suggestions, based on my own recent experience:
  1. Don't let your ego dictate that you need the job with the biggest salary or biggest title. Choose the role based on your career roadmap and best fit - the happier you are, with the best fit, will produce the best long term opportunities.
  2. Linkedin is easily the best job and contact finding service. Change your profile to show that you are now looking - insert a dummy company that says "looking for the next opportunity". Search the jobs available regularly, and apply for anything that looks promising. Recruiters regularly scan linked in looking for candidates.
  3. Make sure you have linkedin recommendations, and ask for them before you need them.
  4. Always reply to recruiters, and build a relationship - even if you are happily employed. Recruiters remember people who helped them fill positions by recommendations.
  5. Update your resume to two pages maximum.  Remember that the aim of the resume is to get an interview, not the job.  Be as results focused as possible, and have friends and colleagues critique the document.
  6. Reach out to your network via phone, email etc.  Now is a great time to catch up with friends for coffee etc.
  7. Research the company and products before any interview.  This includes reading 3rd party material like analysts etc. I've always been amazed when interviewing for PM roles, that some candidates don't even understand what the company does.
  8. Practice before an interview - have friends and colleagues interview you, and prepare to answer possible tricky questions.  
  9. Have 5 or so questions of your own ready - show that you've thought about the role - my first questions  are always:  "what do you expect me to have produced in 90 days and 180 days?" and "How would you judge success for this role".
  10. During interviews, try to demonstrate results by showing actual work (if possible).  I have a (non-confidential) reseller kit that we produced at Citrix, and was able to use that as an example of channel marketing.  Bring in press releases that you authored, public presentations etc.  Never show (or keep) confidential material as that brings your integrity into question.
  11. During the interview, don't talk past the close - once the interviewer indicates that they want you to meet some more people, the selling is over.
  12. Once into the interview process, assemble your thoughts into a presentation for the interviewers - this is what I did recently - put together a business plan based on my notes from the CEO, execs & board.  While this is a somewhat risky move this will show them how you think, and likely will allow you to better evaluate your fit with the organization.
  13. Don't forget during an interview that you are also interviewing the company to ensure the right fit.
One thing I learned from recent events was the need to build a network before you need one i.e. take the time to meet as many people as you can in your industry and area - you can do this at seminars, conferences, startup events etc. Reach out to the type of people you'd like to be working with in the future.

Hatred is a bad business driver

We're all aware of how hatred being a powerful force in the world - leading to so much misery, suffering and unhappiness. Hate is a destructive emotion that can control us completely.

In psychology, Sigmund Freud defined hate as an ego state that wishes to destroy the source of its unhappiness. In philosophy, Aristotle viewed hate as a desire for the annihilation of an object that is incurable by time.

If we all recognize hate as such a powerful and negative force in the world, why are so many business leaders driven by hate for the competition, and feel it can be a rallying cry for the organization.

I remember being at Novell in the late 90's and feeling absolute hate emanating towards Microsoft.  This was despite us all using many of their products internally - including Windows - Microsoft has some extremely good products (Excel is a case in point). Novell's hatred of Microsoft caused them to go on an irrational buying binge to assemble products (Wordperfect, DR DOS et al) and compete head-on with Microsoft. As we know, this didn't work - nobody can beat a bigger adversary by attacking them head on.  Hatred created a flawed strategy that led to failure.

Instead of trying to take out Microsoft directly, Novell had multiple chances to create and dominate industries where Microsoft was not strong.  Novell could have been NetScape, EMC, Cisco (Novell had a multiprotocol router before anyone else), RSA etc. Novell had one of the largest installed bases in the world, and could leverage these assets in so many positive ways to create and grow. Novell could have channeled their energy from hating Microsoft into making them irrelevant.  We all know that Google doesn't have a close relationship with Microsoft, but they are attacking not by destroying what Microsoft has created, but by being creative and moving the industry to new ways of doing business.

Another company I worked at had a CEO very focused on hating a key competitor, and had previously built the company on hatred of another competitor.  The company had been successful, however, both competitors were still in business, and had a higher market cap - the company still competed directly.  I wasn't at all motivated by a strategy of hate (the competitors actually had pretty good products), and felt that we had much better opportunities to make them irrelevant by moving into a Blue Ocean and taking our business upmarket.

The takeaways here are:
  1. Don't be driven solely by hate, or assume it's motivating to your organization.
  2. There is nothing wrong with respecting a strong competitor and their products.
  3. It's OK to have a strategy of taking business from your competitors (hey that's capitalism), but do it by creating and not destroying.
Martin Luther King said "We must develop and maintain the capacity to forgive. He who is devoid of the power to forgive is devoid of the power to love. There is some good in the worst of us and some evil in the best of us. When we discover this, we are less prone to hate our enemies."

Wednesday, April 22, 2009

Pricing thoughts

One of the most complex areas of the product mix is pricing.  Get it right and revenue is maximized, while poor pricing has the opposite effect.  

There are a huge number of factors to consider when pricing products, such as product elasticity, competition, product costs, regional pricing, target markets, and competition.  I'm not going to delve into the mechanics of pricing, and recommend that readers pick up a copy of the pricing bible - "The Strategy and Tactics of Pricing" by Nagle & Hogan.  Instead, here are some lessons I've picked up along the way:

1. Customers compare prices to competition and alternatives to get a measure of the value.  When setting the price for Netoria products, we were targeting Novell Netware administrators who typically paid $60-$70 per Netware user.  As our products were utilities (like Norton's) we adopted a pricing strategy of 25% of the Netware license - $15 per user.  This had a number of benefits:
  • Our strategy was to gain seats within the NetWare installed base - from memory there was over 50 million Netware seats in use, giving us a huge potential market.
  • Our customers could purchase the products without a complex ROI calculation.  We were aspirin, solving a pain point, and could be quickly purchased and deployed.
  • Administrators could purchase within their expenditure level, leading to a faster sales cycle.
  • Deals could be quite large as we moved into the enterprise, but there was never any push back on price.
2. Non-profits and education always expect a discount.  Don't fight it, and give them 20% off list.

3. Higher overall prices typically mean longer sales cycle, with much more sales support.  There is nothing wrong with high prices, but you often need to help the customer justify the purchase up to their management.  One of the best ROI tools I have ever seen is provided by VMware, and is a service hosted by Alinean.

4. Be very careful of regular discounting, especially at end of quarter.  You can inadvertently train your customer and channel to wait for the discounts. Dennis Rose (VP of Asia Pacific at Citrix) was the first person who showed me the pitfalls here - too much discounting, and customers would just wait until the next promotion.  Instead of price discounts, try adding in extra value, like support or consulting.

5. Don't be afraid to experiment. During my seven years at Citrix we regularly raised prices, and each time the business tracked upwards.  One of the most impressive pricing experiments I have seen is Valve with their excellent Steam game distribution service. Steam is huge in the gaming community, as valve has opened it to their competitors and distributes hundreds of games.  Games have a very predictable sales decay (like most entertainment products), but by providing a combination of updates and discount sales, they are able to keep sales high - take a look at the chart below:

For another example of innovative pricing, check out the upcoming Battlefield Heroes game from Electronic Arts, where the game is completely free, but real money is used to purchase upgrades. the message here is clear - track pricing innovations in other industries, and consider lessons applicable to your products.

6. It's always better to start with a higher price and move downwards.  If you work out a price range that your customers accept, start at the higher end of the range.  Sales can always discount by creating a price exception.  Tracking the number of pricing exceptions gives an indication of whether the price is too high (but not too low).  One company I worked for had pricing exceptions at 70% of deals in a particular region - clear indication that the price was too high, and sales had to work extra hard to negotiate a lower price. Typically you want pricing exceptions to be 5% or less.

7.  Create higher value bundles as the primary lead - sales can always drop back with a la carte pricing.  We did this at Netoria by bundling all our 4 products into a suite, Citrix does it (starting with the MetaFrame bundles, progressing to the Access Suite, the Platinum products and now Citrix Delivery Center), and Microsoft is the master with the Office suite amongst others.

8 Finally, create an annuity stream - if enterprise customers are using your solution they typically expect to pay annual fees for maintenance, support, and updates.  Make sure you maximize this revenue by having sales (inside sales) ensure that customers are up to date. Of courses services are the ultimate here, creating recurring revenue every month ( anyone?).

Monday, April 13, 2009

Meeting Alan Cooper

Not everyone has the opportunity to meet one of their heroes, but last week I was very lucky to last week spend some time talking with Alan Cooper.  

I can remember almost ten years ago when I read his first book "The Inmates are Running the Asylum", and the huge impact it caused.  At the time I was a Product Manager at Novell, and trying hard to figure out why a company that had such a great past and so many good people, could be producing such terrible products as NetWare 4.  This was my first Product Management job, and I received no training or mentoring, so hit the books to learn what I could.

In the book Alan describes why most high technology products (not just software) are infuriatingly difficult to use and importantly how to restore the sanity.  Novell could have used his advice on moving to a more user centric design model - but instead they were focused on features implemented via a very difficult to use product (that required weeks of training to properly install & manage).  Microsoft beat Novell by coming at the problem more from usability (and a GUI) - I can remember the first time I installed Windows NT networking (zero training) and had a working system in less that an hour - I knew we were in trouble.

Since those days I've used techniques like Alan describes, such as his concept of persona's, and seen the beneficial impact of being able to describe what customers are really like to the Engineering teams.  Used correctly, persona's can be applied across the whole organization to focus them on the customers (and markets) that the company serves.

I have distributed hundreds of copies of the book to friends, peers, colleagues and senior execs, and would easily rank it as my #1 business book.  The book stands the test of time, and movements like Agile are finally attempting to create permanent solutions to the bad habits.

As well as the the inventor of Personas, Alan is also known as "the father of Visual basic", and author of an equally influential book "About Face: The essentials of user Interaction Design".  He is the founder of Cooper, a well respected San Francisco based design, training and consulting organization.  I met Alan during the recent Innovation Games course (which was held at his company's training facilities), and we sat down for a discussion during lunch.

Alan has not lost any of his passion for remedying bad software and design, but sees some hope with the movement to Agile development processes.  Alan contends that for many years developers have loved to "throw away their toys" and reinvent news ones, such as the movement from procedural to object oriented languages, from client server to web services, from text based to visual environments etc, but Agile is the first time developers have focused on people and process.  Although there are many specific agile development methods, most promote development iterations, teamwork, collaboration, and process adaptability throughout a project - not just better tools.

We also had a discussion how many technology companies are very conservatively managed and organized, and he felt it was because society adapted to manage technology companies using the same tools that were taught to manage industrial processes in the early 20th century e.g. Max Weber (1864-1920) developed organisational structures of management by the office, and was the originator of the term bureaucracy.  The goal of practitioners like Weber was to develop principles whereby large corporations could be controlled and developed (way before software existed!).

Using traditional scientific management principles, such as tight control of the inputs during manufacture, are still relevant today to physical manufacturing, but do not make sense when applied to technology.  His example was Google and their outcome (the largest and most profitable media company in the world) would have been the same whether they spent $50K, $500K or $5M to get their service up and running - the success of the output is not directly related to control and manipulation of the inputs.  Alan postulated, for this reason, that trying to calculate ROI across an IT project is a ridiculous concept.

One of his stories I liked is that Alan mentioned recently learning to play golf, and figured out why business executives like it so much.  In any well designed golf course the penalties for risk are far greater than playing safe.  If you or I tried to play like Tiger Woods, we'd likely hit the ball into the trees, and be on the green in 4 - when playing it safe would guarantee being on the green in 2 shots.  So golf actively reinforces not to take risk.  Most executives like to think that they take risks like Tiger Woods, but when it comes to the crunch, they take the safe play.

A number of times during the course Alan said he'd like to work out "how to make old farts think young" - to generalize, how do you get conservative technology organizations to see the need to change.  After spending last weekend at the SF Startup Weekend, I know exactly what he means, there is a generation of young people (or the young at heart :-)) who do things differently, such as how they use social media and development processes like Agile.

Interestingly, I had an interview at an 8 person startup in San Francisco last week, and they were very concerned that I was one of the "old farts" (after so long in large corporates).  They were happy to know that I used tools like Twitter, Google Apps, Wiki's, Blogging etc, and had build an app in a weekend.  I had to work really hard to convince them that I could exist in this new world.

Ultimately, companies that do not adapt will be swept away by a new generation of people and the companies they create  i.e. organizational Darwinism - you will either adapt, or become extinct.

Tuesday, April 7, 2009

Optimizing sign up pages

Al Abut just sent me a great email about using Google Optimizer to rotate different web pages to optimize response for snoozemail. I'd never heard of Google Optimizer, but it's free and is an easy-to-use tool for testing site content that delivers actionable results.

How to build a company in one weekend

Last weekend I attend the San Francisco Startup Weekend.  The concept was founded in 2007 by Andrew Hyde, as a conference focusing on learning by creating - from their website: Startup Weekend recruits a motivated group of developers, business managers, startup enthusiasts, marketing gurus, graphic artists and more to a 54 hour event that builds communities, companies and projects.

I arrived on Friday night at 6pm, not knowing what to expect - the event was held at the Microsoft office in San Francisco (thanks Microsoft!), and would estimate around 300 people in attendance.  We started with a discussion panel from a series of VCs who focus on seed funding early stage companies. The take away from this panel was when pitching:


Everyone in the room then was given an opportunity to pitch (in 5 minutes) their company idea/concept.  The VCs kindly helped coach many of the pitches - Dave McClure in particular was very blunt and helpful to a number of the presenters (and funny).  After the pitches, everyone assembled into teams based on the ideas that were pitched - I sought out anyone who had pitched an email idea (mine was around solutions to email overload).  I was very lucky to meet Al Abut who had pitched an idea of "Snoozing email", and he ended the night with a list of everyone interested in email.

At 9:00am the next day we all assembled, and started texting, tweeting, and emailing those who were interested from the previous night.  One of the takeaways from Startup Weekend is that you need to get out and sell your idea to assemble the needed team - there is a lot of competition, and I was extremely impressed by how Al brought us together.

We ended up with a core team of five people and a very good mix of skills - Al was a user experience designer, Allan, Peter & Stig were all developers - but with slightly different skills.  We had occasional help from others in the room when needed.

The first thing that we did as a team was sit down, get to know each other, and define the problem.  Given that we had to be completed in less than 48 hours, we agreed to constrain the problem to Al's original idea of email snoozing.  This was a key reason behind our success - we took the time to properly define the problem, constrain to something solvable, and ensured the team was in alignment.  This was written down for constant reference, and we continually checked that we were heading in the right direction.

There was an intense period of brainstorming of different approaches - client based, Google Gadgets, Greasemonkey, server based etc.  After some time we settled on building a web service and interacting with email clients using standard folders/labels.  This makes the basic design completely universal and platform independent, but for time's sake we limited ourselves to Gmail.  The programmer guys decided to implement the web service using Ruby on Rails for rapid development, and reuse of existing code. As we used IMAP there was no need for us to store email, making the service highly scalable.

Al did a really great job throughout the project of assigning tasks and keeping everyone focused. We all trusted each other to get their pieces done (no time for micro management).  While people were coding I focused on putting a founder agreement together, helping Al on the web UI, and then working with Stig on a long term and short term roadmap.  We put together a wiki of ideas, 
and I contributed some marketing and business development ideas.  Every now and again the team stopped to sync that we were on the right path.

Come Sunday, Peter and Allan had not slept, but our service was up and running!  It even worked from an iPhone.  Al had the web site together, and it was now a matter of integrating all the pieces.  During this time I worked on the 5 minute project pitch, and from about 5pm Al and I started rehearsals - we must have gone over the pitch ten times - prior preparation is an important thing in any presentation.

Come 7:00pm (after a panic when the service lost it's IP address) we were fully functional and Al gave a flawless pitch.  We had done it - planned, built, launched, and presented a cool, complete and useful product and basis of a company.  Whilst it may be more of a feature right now (albeit a very useful one), we have a strategic roadmap for the future involving some very cool ideas to manage email overload and automate getting to a zero inbox.  

What I got out of the weekend:
  1. A huge amount of fun, creativity, and learning
  2. Meeting great new friends
  3. Learning a plethora of new open source and social networking tools - e.g. I had never used Twitter before, I saw other people's Moo cards and order my own, learnt about Rails, and wiki tools like basecamp.
  4. An insight into how young entreprenurs think, the tools they use, and how they are changing the world.  Seriously.
Mark Templeton, the Citrix CEO, used to talk about the Echo Generation and how they were changing the world and would not put up with how IT systems worked in a traditional company - after this weekend I really understand what he meant. Every technology executive should attend a Startup Camp, just to see what is possible with the right people, tools, and attitudes. 

We had a fully functional product in TWO days, and people have been signing up like crazy at  My eyes are open to what is possible.
As for Snoozemail - who knows where it will go next, but we're already collaborating over the web, and meeting in San Fran tomorrow night to decide if we want to proceed.  But we're already all winners, considering how much fun we had.  

A special thanks to Andrew, Tyler and all the other organizers, without whom there would be no weekend's like this - great job guys and we really appreciate your time and efforts.

If you'd like to check out the presentations from all the teams, the full 2+ hour video is here:

So the takeaway is clear - go to, and look out for one in your area.

Monday, April 6, 2009

How to sell techical products

I was recently asked the following question:

When there is a technically challenging product and complex solution, how I keep the channel interested to provide the first level support? 

The answer is quite simple - seek out resellers who add value, or in industry terms VARs - Value Added resellers.  This type of reseller, and sometimes distributor (known as VAD, and common in Europe), love to sell technical products, as they make their money from services - design, installation, and support.  They often the product revenue sale as "gravy" on top of the deal, and sometimes even a necessary evil.

VARs want to charge to provide first level of support to the customer, and deliver important leverage to a vendor's support organization. To ensure that the reseller delivers good support, you should give them access to training, knowledge, and tools. And measure their customer's satisfaction from time to time to ensure that your product is being represented well.

Believe it or not, many of these resellers will actively ask a vendor NOT to make the product easier to use, as they feel a complex product maximises their ability to sell services. I don't subscribe to this point of view, as the easier you make the product to evaluate, the easier for the reseller to sell.  So you train your channel to move their services up the value chain and sell more 1st line support, design/architecture and consulting services.

Where this can come unravelled is when an organization gets greedy, and tries to cut out their reseller channel and go direct.  Always remember that these guys are your partners, and they give your organization needed leverage.  Can you really afford to lose that?

Sunday, April 5, 2009

How to effectively measure product management

One of the most difficult issues that organizations deal with is how to measure the success of Product Management (and Product Marketing), especially in the short term.

The financial system forces companies to focus on short term quarterly results, and we are all used to the matching company quarterly business review. Our VP wants metrics to track the effectiveness of Product Management from quarter to quarter - just like manufacturing and support. Easy? No. Let's discuss...

Product Management isn't a discipline that can be measured scientifically - the inputs don't necessarily correlate to the outputs (results).  Writing code is part art, part science.  Deciding candidate features is a complex business planning process involving a huge number of dimensions.  As Alan Cooper mentioned last week, would the outcome for Google have been any different if it cost $50K, $500K or $5M to get to market - the answer is a resounding NO.  They would still be the powerhouse that they are today. 
So what we end up with is Product Management being tracked against a project schedule e.g. was the PRD submitted on time, did the product ship on time, was the SE training completed on time. The problem is that this type of measurement is not only completely invalid, it's actually counter productive. Defining the entire project dates up front is a waterfall technique, and as we move to agile it clearly doesn't make sense anyway.

The only measurement that matters is did the product release meet the established market objectives. These could be:
  • Revenue from new customers
  • Additional revenue from existing customers
  • Increased Market share
  • Increased user satisfaction
  • Decrease support
  • More successful evaluations
  • Getting to market before a competitor
Track and measure success against these market objectives, no matter what the time frame. Don't complain that you are dependent on other groups like sales & marketing - your role is to ensure that their plans line up against the release goals you defined. Product Management is the "product CEO" and should be held responsible for the ultimate success or failure.  Yes, this may need to be over many quarters, but it gets the team focused on the long term strategy.

Throughout my career, we've measured the most successful projects based on revenue increase - mostly new projects, so revenue was what we were after - nobody particularly cared about how closely we hit or missed project dates, as long as we kept the exec team posted on any slippage on the release data (and didn't cross a financial quarter, which has revenue recognition implications). Sure we had quarterly MBOs, but these were always qualitative, but measurable and made sure we were focusing on the right things.

When an organization focuses completely on measuring achievement against a project schedule, the team will modify their behavior to hit the dates. I have seen features dropped and products released that are complete crap, just so the team  can hit the date and get their bonus. So the product team stands up and praises how wonderful they are, even if the product dies in the marketplace. NetWare 4 is a great example - I can remember many engineers and managers who were proud that they "got it out the door", but never mind that it was extremely buggy, and NDS was too large a leap for many NetWare 3 users (this is the subject of a future post). Would Microsoft regard Windows Vista as a success in the marketplace?

This isn't an excuse to be loose and not care about dates - dates matter, especially if you have a specific target market window to beat a competitor, hit a financial period etc.  But what really matters is that your product is successful in the marketplace, and you measure and reward Product Management to hit this goal.

Saturday, April 4, 2009

SF Startup Weekend in progress

This weekend I am up at the San Francisco Startup Weekend, just to have some fun and meet new friends.  So far it's exceeded all my expectations.  After hearing all the pitches, a number of us who were interested in email got together, and picked an idea that could be completed in the weekend.

We're building a web service that allows you to snooze emails for a certain period of time, and then remind you to respond.  Our working name is SnoozeMail, and we are each working on different aspects of the project - I am doing Marketing/Product Management stuff, Al is a User Experience designer and is crafting the web site, Allan/Peter/Stig are our coders, and have decided to do the prototype using Rails.  This morning we got alignment on the problem we are solving, created the requirements, and the coders decided the architecture.

You can follow our progress on twitter -

A group list of all the attendees is at

Our web site is

Tomorrow at 7pm we present our completed product, and have 5 minutes.  Less than 24 hours to have our product working and have the presentation nailed.

The Snoozemail team

Choosing a company logo

A question I have been recently asked is how to pick the right logo for a company. As we know a logo (and a company name) should be meaningful, memorable, and reflect the image that you want/need. We see company logos on websites, printed materials, buildings, business cards, advertising - lots of places.

When a separate logo is executed well it can be very powerful - the best example I can think of is the apple computer logo - but how long did it take for them to establish the link between the logo and the company - years.  They also had it a little easy, as their logo is a representation of their name i.e. an apple.  If you have an abstract company name then you have a bigger task to create a linkage between your logo and company name.

My own opinion here is to make the logo the company name and don't have anything separate. Go for a clean and neat  look.  When your company name is the logo the brand is being reinforced. Some of the logos I really like are Google, Microsoft, Citrix, Amazon, FedEx - all use their company name in the logo, are very neat and easy to read.

Amazon is particularly clever for two reasons; firstly they tell you their web address (, secondly, the arrow shows that they sell from A to Z.  Cool.

Novell is an interesting case, take a look at their original "shark teeth" logo - the problem was it was impossible to render on screens of the day without getting the "jaggies" - we're talking VGA here :-) I'm also not sure what it exactly meant, but it's probably a stylized "N".  But for those of us hard core networkers who remember NetWare 3, we did love that logo (I seem to remember lots of people sporting shark teeth temporary tattoos at Brainshare one year).

The next was the very short lived "Novell Balls" logo.  This was not very popular as it was too large and the rounded balls were very difficult to render nicely on a computer screen in the late 90s.  And the inner "N" was hard to see in many forms.

Their new logo is just the company name, neat and clean. Beautiful - especially when you compare it to the two above.

This brings me to an important point in picking company names - try to come up with a name that doesn't have any descenders i.e. letters that drop below the horizontal, such as p and q.  It's much easier to have a neat logo without descenders. If you do have descenders, then try capitalizing, or somehow working the descender into the design.  Take a look at the logo below - pretty cool use of the descender, and it ties into the company name.

Thursday, April 2, 2009

Customer Understanding through Innovation Games

Last week I was lucky enough to join a class to learn how to select, plan, facilitate, and post-process Innovation Games.  The event was help at Cooper in San Francisco, by Enthiosys - Luke Hoherman (the author and creator of Innovation games).  Luke has to be one of the smartest and nicest people I have ever had the pleasure to meet, plus he is an amazing instructor and presenter.  

Luke is the CEO of Enthiosys, an Agile product management consulting company.  They are the  leading Agile product management consulting firm - I love this description from their web site - "Business agility is more than building high quality software faster. It’s about creating options, outmaneuvering your competition and creating sustainable profits over time. We help you do this by understanding and collaborating with your markets, letting you effectively bridge the planning gaps between strategy and execution, building the right products and solutions, and capturing maximum value from customers."  I started working with Luke when I was running the Product Management Team at Blue Coat, and was very impressed from the start.

Innovation games are a branch of serious gaming and are designed to help organizations understand what their customers want, need and will pay for. There are twelve games in all, and a rich process for determing the most appropriate game to solve a particular problem.  These games are not limited to any particular industry or technology - Luke has a vision where innovation games can be used to solve problems across all industries, and even within government (more on that later).

We've all been to the typical customer council, where customer listen while you pitch a roadmap and give comments.  Does this really work in drawing out their hidden needs and desires - NO!  Enter Innovation Games - these interactive techniques let your customers and prospects create the products they want. Understand customer needs, identify product functionality, learn how customers interact with your products, and shape your products’ future.

Another aspect here is that if your organization is becoming more agile, then you need to validate with your customers more than once per year - Innovation Games are a way to get rapid validation of ideas and directions, with actionable results to feedback into the process.  Luke has even implemented Innovation Games Online, and currently has already implemented Buy a Feature online - so you can run market research without the typical costs of bringing your customers together in person (important in this economy).

The twelve Innovation Games included here are all described in Luke’s book, and have been used extensively by Enthiosys, clients, and Certified Facilitators all around the world. Importantly, start with research objectives, since Innovation Games are designed to deliver actionable results. 

For instance, if you are exploring core customer needs, you might use Product BoxMe and My ShadowBuy a Feature, or Remember The Future. For details about product functionality and feature preferences, consider Product Box20/20 VisionBuy a Feature or Speed Boat.  Product Box was without a doubt my favorite games, and one that clients always love to play - they start with a blank box, and put together the product they would like to buy and then finish with a presentation. During my course we designed a box for an Internet enabled coffee machine that could be programmed from an iPhone.

You can learn about how customers use products (and services) by playing Spider WebStart Your DayShow And Tell or The Apprentice. Customers can help you shape your product for the future with Prune The Product Tree20/20 VisionBuy a Feature or Remember The Future.

If you want to learn anything else, then buy the book from Amazon - it's really worthwhile.  Or contact Enthiosys about Agile Product Management and Innovation Games. 

Some things I learnt from the course:
  1. Innovation games gives your customers permission to be creative.
  2. There is a lot of preparation for the instructor to consider.
  3. Having enough observers and getting them to record just the facts is critical
  4. Follow the process to pick the right game, or you won't get the needed results.
  5. The average game is around two hours, a speed game is 20 minutes.
  6. The facilitator doesn't control the room, but guides the room.
We had a great group of people in the class, including some industry luminaries, such as Alan Cooper, Jeff Patton and Giovanna Pico.