Tuesday, March 31, 2009

Achieving and maintaining leadership in the analyst community

Getting into the Gartner MQ leaders quadrant or leadership tier on the Forrester Wave is a lot like a restaurant getting a fantastic review in the newspaper or achieving multiple Michelin Stars.  Initially there is lots of celebration followed by a flood of business.  But, then you realize the pressure to retain your rating. For instance, extremely high-end restaurants live and die by their Michelin Stars.  The loss of even fractional star can cause the restaurant to tailspin.  I'm reminded of one of my favorite places in San Francisco who achieved 2 Michelin Stars the first year that the guide was published for that city.  The following year the restaurant dropped to 1 Michelin Star and within two years were out of business.
OK, maybe that's an exaggeration and there were other reasons why the restaurant failed, including the economic slow-down, but it's an interesting and relevant parallel.  There's a good dramatization of this phenomena in the Adam Sandler movie "Spanglish".  Yet, despite how many Michelin Stars a restaurant many achieve and regardless of whether the restaurant can maintain their position, a change in dining habits, lots of critical postings on Yelp, or a disgruntled community of bloggers on Chowhound can torpedo the success of a restaurant.  The fact is that a fanatical focus on maintaining an external leadership ranking can distract people and ultimately cause them to focus more on influencing the external party, rather than focusing on their business and doing what's right to succeed in an environment of ever-changing market conditions.

Technology is very different from the restaurant business, but the tremendous internal pressure to maintain an analyst leadership ranking is a lot like the pressure that a chef feels to maintain his Michelin Stars.  I've even heard of product marketers and product managers at large companies getting fired because their products either failed to maintain or meaningfully improve their position on the Gartner MQ.
Notwithstanding the issue of job security, maintaining an analyst leadership position can create a situation where the product strategy begins to pander to what you think the analyst firm wants to see, not necessarily where you see the market going strategically or where your most meaningful and addressable opportunities may reside.  This is a very, very difficult position.
Most analyst firms are conservative in their assessment of the market and this is yet another reason why many companies get stuck in the feature drag race.  The product strategy resorts to either doing what the analyst firm tells them to do or looking at the published leaders and then copying what they're doing.  Sadly, many product managers believe (erroneously) that more features cement a leadership position with the analysts.  This is not a viable strategy, unless you're large enough (e.g. Microsoft, Cisco, or IBM) to out-feature the competition, or win through superior routes-to-market or attrition.

Ultimately the way to overcome this dilemma is to begin to present a concrete vision to the analysts on how everything you do fits together.  Basing your leadership position with the analyst community on speeds, feeds, and features is ultimately an unsustainable and losing proposition.  Instead, spend the time influencing analysts on how your vision is unique in your space, how it's ultimately more relevant than what your competitors are articulating, and how your past actions, future directions (e.g. roadmap), and business performance are unified into this vision.

Look at what Citrix did with Access Gateway; we convinced Gartner and Forrester that SSL VPN was no longer simple remote access or network connectivity, but an integral part of an application delivery infrastructure (we implemented a Blue Ocean Strategy).  Nobody in the SSL VPN space, including Juniper, Aventail, or even F5, were talking about SSL VPNs as being applicable to application delivery, but they do now. Citrix continues to advance their vision around application delivery, and are experts at clearly explaining how they are out creating and leading the market.

Monday, March 30, 2009

Learning to say No

A common problem for Product Managers is how to say No, whether to sales, SEs, executives, engineers, partners or customers.  There has been a lot written about the psychology of saying no (search for "saying no" on Amazon), which I'm not going rehash - except always be polite and respectful.

Primarily, it's OK to say no, and it's OK for people to be unhappy with the answer - get over it. Your job isn't to make everyone happy or be the most loved employee, or the SE champion - it's to create market leading successful products.  Also, recognize that saying yes when inappropriate can be the source of damage, difficulty, and failure.

Showing integrity is standing by your convictions and being truthful. Respect is gained by telling the truth and delivering, rather than constantly promising and not delivering.  Sure, we may be uncomfortable with the no, but building a long term relationship is about honestly, reliability and mutual respect.  You don't get that by misleading or downright lying.

However, before you say no, make sure the requester knows you have heard them - often people just want to ensure that you understand their pain (i.e. show empathy).  A good way to do this is to listen, then reflect the request back to them e.g. "so what I heard you say was...".  Once they hear the reflection they know that you have at least heard their concern/issue/pain.  And it's OK to be sympathetic.

Next, understand the context of the request, how the requester encodes/decodes the world around them, and their motivation.  If the requester is a sales person then likely they have a deal riding on this feature, a deal means quota, which translates to $$$$ in their pocket.  So by saying no you are costing them money.  In this case, you'll have to explain the decision in terms they understand e.g. "if we do this feature it isn't repeatable (so you can't sell it again), and we need to change our plans somewhere else.  We may have to slow down the team implementing (insert cool new thing), and if we make that late then all your customers and prospects will get pushed back, so the next quarter will be tough".

What we are trying to do is get the requester to understand how and why we make decisions. You should have the vision, business plan and roadmap to show them why the product is on a path that makes them successful.  Customize presentations and dialog around the requester e.g. engineers will likely want to see quantitative evidence why they should be working on the strategic direction rather than their pet project.  If you can't find quantitative evidence, take them on a field trip to meet with customers, or invite them to customer meetings in HQ.  Give them the context for the decision.

There will always be people who cannot accept the no, and are convinced that you are on the wrong path.  Again, you need to accept that there are just some people who refuse to see the bigger picture, no matter how hard and long you try - if they have political power you may find a backlash brewing - so try to be aware of the environment and keep your management briefed. This has been the source of some of the most difficult moments in my career, so don't feel bad if you are in the situation and need to reach out to your manager for help.

The biggest risk is where saying no to a customer will kill the deal, especially if the deal is large. You really need to ask if this is the type of customer and market that fits where the company is strategically focused.  One company I worked for had a solution (set of features) that had not been worked on for many years, but were selling well in one regional market.  There were numerous other companies fully focused on this solution, and it wasn't part of our strategic direction. Product Management was constantly asked to present a roadmap to these customers, but our plans had no new features in this direction - there just wasn't the business to justify the engineering investment.  Initially we told the customer we regarded the feature set as mature and that the product was fully supported in this mode of operation (i.e. the truth). If the customer needed new capabilities we'd steer them to another company with a better solution - and the customer was happy with our honestly and openness.  We were solidifying a long term relationship, leading to better sales in our core markets and solutions.  

A few additional tips/recap:
  • Listen, and show empathy
  • Be consistent but don't be afraid to admit that you were wrong
  • Don't abuse your power or their may be a backlash
  • Recognize when things may be escalated, and prepare management 
The biggest challenge is likely to come from Sales, due to their focus on quarterly results and quotas driving income.  The hardest period is between starting the role and delivering your first results, so focus on key relationships and get them as comfortable as possible.  Once you have a reputation for delivering, life becomes much easier, and the no's are accepted much more readily.

Saturday, March 28, 2009

Mutualism as a Business Strategy

In these difficult economic times there is lots of discussion around capital drying up and how to make a startup or even any size business successful.  The answer is quite simple - mutualism, and a great example in nature is a cleaner fish.

These small fish maintain so-called cleaning stations where other fish, known as hosts, will congregate. Remarkably, these small cleaner fish will safely clean large predatory fish that would otherwise eat small fish such as these. The cleaner fish get the nutrition that they need, and the larger fish get a service with the removal of dead skin & parasites. This is an example of mutualism, an ecological interaction that benefits both parties involved

Use mutualism to your advantage - Instead of trying to attract the attention of your end customers directly, why not add value to a larger enterprise player (i.e. host) and help drive their revenue.  Co-market with the enterprise player, use their channel, and show their sales force and SEs how selling your solution will help them make their quotas.  Make the value prop to the SE or sales person and you both win.  Like the cleaner fish, your 'host' will not eat you as long as you are continuing to provide a valuable service.

This was the exact strategy behind Netoria in the mid-late 90s - we added value to Novell's strategic direction, Novell Directory Services (NDS).  Our products simplified the deployment of NDS, and added additional value to demonstrate to customers what could be done with a directory - a perfect example of mutualism - Novell wanted customers to hear about our products because it helped to position and sell NetWare 4 - and drove upgrades from Netware 3.  What is critical here is that we attached to a Novell strategic imperative

All Netoria marketing and lead generation was centered around Novell - Novell partner pavilions at N+I & Brainshare, advertising in Novell publications, speaking at Novell sales and SE events, meeting with Novell analysts, and reviews in Novell centered publications.  One of our most successful strategies was to travel the world meeting with local Novell sales offices, buying them lunch while we explained our products and the value to them.  This is something that many startups misunderstand - a strategic partnership with HQ is cool, but to drive revenue you must be out in the field with the people who actually sell (heck, you can do this without a strategic partnership).

At Brainshare we even had the "three amigos" use our products in the product keynotes - this strategy drove us to profitability every month, and over 1 million installed enterprise seats. The ultimate outcome was when Novell acquired Netoria in late 1999 - so although they did "gobble us up" it was on excellent terms.  If Novell had not acquired us, then our plans were to look closely at mutualism via Microsoft's Active Directory.

Another perfect example of mutualism is Citrix Systems and Microsoft - no other company has been as successful as Citrix at long term partnering with Microsoft.  Primarily because Citrix has always been able to demonstrate to Microsoft the added value and revenue - I can't recall the exact figure, but Citrix helps sells hundreds of millions of dollars of Windows Server and terminal Services licenses, all with minimal effort from Microsoft.  

The lesson here is not to dismiss mutualism as a strategy just for startups or small players. You can continue mutualism to a $1bn company and beyond like Citrix.

Right now there are hundreds of large companies out there forging new strategic directions, who need smaller companies to build out their eco-systems.  Personally I feel that there are huge opportunities in mutualism with the virtualization players like Citrix, Microsoft and VMWare, in the consumer space with Google, Facebook, et al, and what about the cloud players like Amazon, Microsoft and Google.  Just make sure that you are focused on a strategic imperative, not just a "nice to have", and be able to demonstrate how you drive revenue.  That's mutualism.

Wednesday, March 25, 2009

Route-to-Market and the channel

One of the most critical elements of a product success is the route-to-market.  My own thinking has evolved over the years - initially I thought that product success was all about technology and the product; the next stage was that effective messaging and positioning was the most important; finally, I started to think about the importance of having an effective route-to-market.

Of course the answer is that product success is a mixture of everything above, and more.  But let's explore route-to-market, which is simply defined as how you get your product or services to customers.  This is especially critical for startup companies - you may have the best product in the world, but how do you get it in the hand of your customers?

Remember that creating a route to market is about maximizing leverage.  You want to get a multiplier effect from your investment, not a 1 to 1 alignment.  If your business sells by direct sales touch, it's very difficult to scale the business quickly and economically.

Of course you must optimize the route to market around the target buyer and markets as defined in your business plan.  These days it makes sense to maximize returns from online selling (Dell anyone?).  I know this is very basic and obvious, but how many people are really doing everything they can online prior to embracing more traditional models - are you really optimizing your web searches, web selling, online community, blogging, new media etc etc. I'll leave it to the thousands of blogs to help you better understand how to get the most out of online selling, but as an example, check out the Google Analytics Blog.

When you are selling a product other than online, such as most enterprise solutions, you must embrace a different route to market, and this is typically the channel.  A channel is a 2-tier route to market where you sell to a small number of distributors, and they in turn sell to their own networks of resellers (however for a startup you may start out selling directly to resellers until you can get distributors interested).  The channel varies by market, buyer, and vertical  and there are some importance differences between the US channel and Europe (where Value Added Distributors or VADs are common), and the Pacific (especially in Japan, which is very unique). 

Novell is a classic example of a company that recognized the power and leverage of a channel - they quickly grew to above $1bn in revenue without selling directly. This was my first exposure to channel selling, and Novell did it very well.  I was a Novell reseller in Canberra, Australia, and we bought from a distributor (ComTech). In currently terminology ComTech would have been called a Value Added Distributor (VAD), because they did more than just move product - they trained and supported their reseller base, ran events, generated leads etc.  

The benefit of a channel is that it provides great leverage.  You have the channel partner's sales people out selling your product, being your representative.  You can reach worldwide and regional markets via a channel partner who understands the target market, customer, and local languages/customs.  A VAD can take pressure off your own support and training staff, and is almost an extension of your own company.

These days many distributors are what we call "box-movers", and just sell product to resellers without services.  However, these distributors (such as CDW and Software Spectrum) still create valuable leverage by being able to address a large reseller base, stock physical products, deal with local import/export laws, plus you only need to collect money from them (instead of hundreds of resellers).

When we started Netoria back in the mid 90's our route to market was 100% the Novell channel - we went to the Novell web site, got a list of their resellers and distributors, and targeted them to sell our products (SFlogin, SFlock, SFsend, Schemax), and show them how these products helped sell NetWare 4.  Our business plan was to piggy-back off the Novell channel, and it paid off! Initially we still had to sell direct in some markets, but we always priced above what the channel could sell for, and told the customer they could get it cheaper from a reseller. 

The biggest downsides of the channel are that you have limited visibility into your pipeline and customers, and unless you motivate them, the channel partner won't sell.  A channel partner won't sell your product unless:
  1. they make good money, and/or
  2. by adding your product into the mix they sell a bigger solution, and/or
  3. they can sell services alongside your product
Typically reasons 2 and 3 are much bigger, as margins are very small on products, and customers may ask for multiple quotes to make sure they get a cheap price.  There are ways to help reward value selling partners, such as deal registration and pass-back of a certain sale percentage, but I'll cover these in a separate post  (Ross Brown, the Citrix VP of WW Channels, implemented their excellent Advisor Rewards program).

Don't forget that there are different types of channels - networking channels, security channels, server channels, etc.  Target the type of channels partners who sell to your customers (Duh!).

What your company needs to do is motivate the channel partner to sell and reduce the friction of dealing with your company.  Think like a channel partner, and figure out what you'd like to sell a new product:
  1. Value proposition. Aka "what's in it for me".  Show the partner why their investment is worth their while.
  2. Training.  Show the partner how to sell, how to position, how to do a proof of concept. Give them product for free or at cost.  
  3. Support.  Give the partner easy access to help when they run into a stumbling block
  4. Leads.  This is critical - pass good, qualified leads to the channel partner.
  5. Marketing support. Give the partner assistance with marketing.  help them run their own seminars for their customers aka Seminar in a box.  Give them easy access to collateral.
  6. Recognize and reward. Show how much you value their selling, and help resellers grow their business
  7. An environment of trust.  We want mutual business success.  Resellers will very quickly drop companies they feel are going to compete with them.  I can recall back in the 90s when Novell introduced their own (direct) paid consulting services it caused tremendous friction with the channel. At Netoria, if a deal came through directly that a reseller had initiated, we sent the reseller their margin.  Our intention was to stop selling directly altogether, but we were acquired by Novell in 1999 before this could be implemented.
When ever anyone brings a business plan to me for review, the first thing I'll ask about is their route to market, and for enterprise products, the channel is king.

Monday, March 23, 2009

Product Management in a growing company

An area of constant discussion amongst product managers is way that Product Management changes as an organization or product grows.  In many startup companies the Product Manager is extremely technical and steps across the establish PM boundaries to become a Product Designer (PD)  or a product architect. They describe in high detail what engineering needs to build, but also how.

Whilst this may make PM purists shudder, I can think of many examples in my career where the PM has also been the PD and this was the right approach.  When I look over my old requirements documents, clearly I defined some of the how, especially when the engineering team's knowledge of the product/solution space was limited, customers had specific requirements, or we didn't have anybody else to perform this role (i.e. no architect assigned).
However, organizations reach a point where evolution of their products and business can no longer be sustained by a single product manager/product designer (PM/PD).  Usually this is because the single person acting as the PM/PD no longer scales - the business has grown to be too complex or the product too complicated for one person to handle.  Too often this person often ends up becoming the bottleneck in the product development process.
Organizations attempt to solve this problem in two distinct ways:
  1. Some organizations hire another PM/PD - this works temporarily, but usually it isn't sustainable long-term since there are relatively few people who are actually capable of being a PM/PD.  Most companies also find that they can't hire an external PM off the street to be an effective PM/PD since that new person simply won't have the in-depth product knowledge or historic context to be successful.  Even if these problem can be overcome, the bigger issue with this staffing approach is that it tends to breed a cadre of feature-driven product managers/product designers who ultimately lack business and strategic vision.
  2. The other approach, which I believe is ultimately more successful, is to begin to delegate PM/PD responsibility and then scale across the functions.  This delegation can occur in a number of different ways.  The PM/PD can become either a business and market focus product manager with the technical responsibilities farmed out to a technical product manager, product architect, or dedicated product designer.  Or, the PM/PD becomes the technical product manager and is backed up by a business-focused product manager.
 In my experience, I've seen the first approach to product management and product design stall the organization; it becomes increasingly difficult to grow the business beyond a certain size or gain a strategic focus.  The latter approach (delegating roles) tends to be much more scalable and sustainable.  Microsoft, Symantec, certain divisions of Citrix, Cisco, and other blue chip technology companies all tend to organize their product managers along the delegated approach.  Titles may be different depending upon the company (Program Manager & Product Manager at Microsoft vs. Technical Product Manager & Product Manager at Cisco and Symantec vs. Product Architect and Product Manager at Citrix), but the associated roles and responsibility are essentially similar.

Monday, March 16, 2009

Waterfall versus Agile

At the recent Product Management PCamp 2009 event, held over the weekend at the Yahoo Campus, there was a real focus on Agile.  One of the best sessions I attended was "Agile 101" by Chris Sims of the Technical Management Institute.

I have seen far too many large waterfall projects fail - people spend years defining what the market needs up front, but finally what they deliver comprehensively misses the mark (NetWare 4 or Windows Vista anyone?).

Even in smaller companies, the amount of churn and change control meetings to get to a released product is unpleasant and combative - there has to be a better way.  And does anyone really think in our current economy that the market needs are going to remain static for long periods of time?

Luckily there is a better way - Agile Development - this was described at the conference as "building a mountain 1000 feet at a time".  To quote from Chris's handout:

"Agile development employs the same steps as the waterfall method: requirements gathering, design, coding and testing.  But instead of completing each step before moving onto the next, an agile team does a little bit of requirements gathering, a little bit of design, coding and testing, and delivers a little bit of value to a customer.  They then do it all over again... and again, refining and tweaking their process as they go..

Agile is actually a fairly disciplined approach to software development.  It is agile, not ad hoc."

The biggest takeaway were the four core values of Agile versus Waterfall
  1. Focus on individuals and interactions (over process and tools)
  2. Working software (over comprehensive documentation)
  3. Customer and stakeholder collaboration (over contract negotiation)
  4. Responding to change (instead of following a plan)
There were some great sessions on implementing Agile within Enterprise organizations, and one of the best was a case study from Borland.  The take-away here was that it doesn't need to be an "all or nothing" implementation, and that a lot of preparation, executive sponsorship, training, and planning is required for a successful implementation.

But more on that later...

Friday, March 13, 2009

How should Product Management be Organized?

A common question is how should Product Management be organized?  By technology, product, market, vertical industry, etc?

The answer is easy.  The primary role of Product Management is to deliver the right product to a market.  PM builds a business plan for each market that the organization addresses, derives a vision, and then presents a roadmap of product releases, each with incremental features and capabilities.

So primarily, organize around the market(s) you address.  As an example, if you organization sells products to security and networking buyers, first organize into a security PM team, and a networking PM team.  The heads of each team own the product revenue number, along with their mar
keting counterpart, and of course work very closely with the engineering lead.  By organizing this way you optimize each product for the market it serves - not just features and capabilities, but by pricing and packaging and other GTM (go-to-market) factors, such as route to market, buyer, etc.

Once you have the primary market focus established, next look at large chunks of features/capabilities that may require specialized PM skills, or are common across both business units.  Some examples here would be a common OS PM or hardware appliance PM - or if your OS is broken up into major pieces, then perhaps a PM owns each major piece. 
Importantly, their customers are the primary market focused PMs.

What generally doesn't make sense is to just organize around technology - if each PM just has a piece of the technology, how can they build a business plan, vision and roadmap for the product?Of course if you only serve one market, then the head of PM will own the business plan, but lo
oking closely may uncover sub-markets where PMs can be organized.

The question of organizing around industry segments always comes up - my advice is that if you are selling the same product to multiple verticals, then you have a horizontal product and should be organized by the complete market.  Only organize PM by specific verticals if each vertical is it's own unique market and the product(s) are unique or significantly customized.  The only exception here is where you assemble specific product bundles for unique verticals - then you need a PM to work with the individual product PMs to define what the bundle needs (as the bundle is essentially a unique product).

This discussion is limited solely to product management - often it makes complete sense to have groups within Product Marketing focused on specific verticals - they take a horizontal product that PM delivers, and customize the outbound marketing to appeal to a specific vertical (e.g. healthcare, government, finance), often in conjunction with specialized sales teams.

So remember, the starting point is to organize Product Management around primary markets - it's that simple.

Wednesday, March 11, 2009

Do you have a visual vision?

Thinkstock Single Image Set

Does your product and organization have a clear vision of where you are headed in the next 3-5 years?

Can you explain it clearly to employees, customers, channel partners, analysts etc?

When you do a roadmap review of an individual release, do you explain how it fits into the overall vision?

Do your product people spend at least 20% of their time working out where they are headed (strategy)?

If your answer to any or all of the above is NO, then you're not alone. Your company may be succeeding and winning in a feature shoot out or just by focusing on the next release - tactics are an essential part of business, but by themselves will almost never lead to success (hey, there are lucky people in this world who win against all odds).

The good news is that it isn't hard to create a vision, and it doesn't need to be real. A vision is something that lets everyone understand where you are headed, and is a filter on the roadmap, product and company to ensure that each step is taking you somewhere. Obviously there is a business context behind this vision, which I won't go into during this post, but the vision is really the ultimate output of the business plan.

Instead of describing your vision with words, leverage what we all know, that people remember more of what they see than hear - create a visual vision. Some screen shots, a flash demo, or even a short movie are good examples. In this day of digital editing creating a movie can be very inexpensive, or you can go for the full production values (if you have a nice marketing budget)

The grand-daddy of visual visions is the Apple Knowledge Navigator series of concept videos. You can see one of them here http://www.digibarn.com/collections/movies/knowledge-navigator.html, or do a search across YouTube. Done in the 80s, they were clearly defining a future far ahead of their time, and were not technologically possible to implement (probably not even now). But these videos created a huge amount of buzz, analysis, criticism and praise - the main thing was that Apple was willing to put out a vision of the far future that made them a leader.

When I worked at Citrix we created a similar "Access Navigator" video that really helped to focus the company. I saw the most impact with this within the company, as it helped employees to grok that Citrix was more than a one-trick-pony thin-client company. Like all visions this was useful for a period of time, and then the company continually refined and created how they communicated the vision.

Even done on the cheap a visual vision can be very effective - at one company we had a graphics artist create a series of six screen shots that showed a future system. Every customer and analyst we showed it to loved the vision, but we had to be very clear that this was just a vision and not a prototype (that's the risk). We also got some really good feedback on how it could be changed to be more effective - we ended up having the customers engaged in building an even better version of the vision. Following the vision was always the 18 month roadmap, so the customers could then see how each release took us closer to the vision - it provided a united framework for our whole product strategy, instead of customers just seeing a series of point releases.

This strategy is not without risk - many of your tactically focused colleagues will criticise you for showing something too far out. But they are missing the point. Customers want to engage with companies with vision that align with their own. You're also getting very early validation of being on the right path as you make your visual vision a reality.

Tuesday, March 10, 2009

The most popular (and least successful competitive strategy)

Without a doubt the most common competitive strategy that you'll see in the valley is the drag race. It's also the least successful and imaginative.

When companies engage in a drag race they are telling customers that they have similar solutions and the choice should be made based on who has the best features right now. Product Management and Engineering is driven by an endless cycle of trying to 1-up the competition, and often the leader will flip-flop as they each strive to catch up and pass each other.

Ultimately this strategy will always fail. Why? Because all products reach a point of maturity where they do enough for most users. The extra bells and whistles only appeal to a small number of users - while the mainstream now sees that each product as essentially equal.
When you can't compete on extra "gee-whizz" functionality, the inevitable outcome is price competition, and product commoditization. A good example of this is the portable music (MP3) player market (let's ignore the Apple iPOD for the moment) - open up a flyer from your favorite electronics store, and you'll see an endless price battle between the various MP3 player manufacturers - consumers believe that these players all do essentially the same thing - allow you to upload, organize and play music.

There is an alternative - smart companies create their own unique market where nobody else can compete. W. Chan Kim and Renée Mauborgne coined the term Blue Ocean Strategy - "The aim of BOS is not to out-perform the competition in the existing industry, but to create new market space or a blue ocean, thereby making the competition irrelevant."

Their book and framework for describing strategy is essential reading for any business person - why compete when you can create your own unique market space.

Back to the MP3 player example - Apple created a Blue Ocean by linking the iPOD to iTunes, and creating a business selling music (and other entertainment online). No other MP3 player can compete with the iPOD, simply because they do not have access to iTunes, and cannot deliver the complete experience. It doesn't matter to me what features an iPOD has, as I want to use iTunes - so I don't even compare the competitors - Apple has made them all irrelevant.

Selling a Blue Ocean strategy inside your company is often difficult, as you have to first stop the drag race - a lot of communication and education is required, especially when the sales force has been accustomed to feature selling, and expects a new slew of "competitor killer" features ever quarter or two. Remember that the aim is for the customer to not even want to evaluate the competition, as they see only you can deliver what they need.

You've got to get the sales force and SEs on-side, and you likely will still need to deliver some drag race features until you can deliver on the blue ocean. Find some sales people who succeed at selling a Blue Ocean model and make examples out of them - show the others how they made a sale without getting involved in a long competitive shoot-out.

There are countless more examples of successful Blue Ocean strategies, and my advice to everyone is to head to Amazon and grab a copy of the book. Why not buy a whole lot of them for the marketing team, and the organize a workshop on possible Blue Ocean Strategies.