openSUSE:What is Strategy

Jump to: navigation, search

Why this clarification?

In the public discussions, we have received quite a bit of useful input and insight. One observation though is that sometime people were somewhat confused with the terminology used when we discuss strategy and e.g. confused activities with strategy. This way, some useful thoughts or insight may needlessly add confusion rather than clarity and may not receive the full appreciation. For this reason, we'd like to clarify a bit our approach and terminology and hope that this helps structuring the discussions a bit and this way result in more productive discussions.

So what is strategy?

A strategy is a set of choices that positions our project inside the industry so as to provide superior growth of community over the long run.

This is a classical HBS definition of strategy (Porter et al.) reworded to match an open source project and its goals.

A few remarks to the definition:

[1] Choices

Choices means trade-offs — while you can always try to be a bit more efficient in how you do things (and that’s something you should always pursue!), this will not set you apart from the competition — unless you believe you are a lot smarter than everyone else and experience tells us this is seldomly true in a sustainable way.

So trade-offs are what sets you apart — you take different trade-offs than the competition; while you focus on young newbie users, your competitions focuses on experienced developers. Some of the trade-offs may be just physical incompatibilities (your distribution can not be small and large and the same time) while other trade-offs may be imposed on you by the fact that you have limited resources. (I would argue that the elasticity of resources is somewhat larger with an open source project than a classical company, but they are still finite.)

The trade-offs determine your competitive advantages — this is what sets you apart from the competition and the competition can’t provide the same advantages as well unless they take exactly the same trade-offs. (Which would be a stupid choice and create a worse environment for everyone.)

You cannot have an endless list of competitive advantages. Typically, companies focus on less than a handful of high level things here, so the advantages can be explained, communicated and remembered.

Think a few examples:

What is the competitive advantage of Apple?
Usability and Integration
What is the competitive advantage of Toyota?
Quality (at an affordable price)

[2] Industry

You should understand what industry you are in and look at the players. We had a discussion what "industry" we are in ... and agreed that our main product "operating system" best frames whom we compete with: Other Linux distros, Windows, Mac, and possibly new form factors that replace what people used to use PCs/laptops with classical OSes for (Netbooks, Smartphones, Tablets, ... but also Cloud Computing).

We also quickly looked at ourselves being a community building project, where we would compete with Facebook and Twitter. We determined that this is a useful perspective, but not the main one.

[3] Goal and Sustainability

The original definition reads somewhat differently: ... to create superior financial returns over the long run. As a community project whose main goal is not to create profit, this would be misleading. We measure our success by growing our community. At this point, community is meant in a broad sense, users, contributors, supporters, ...

You should also note the "on the long run". A strategy is not about a great short term deal. It gives the project a direction and should hold for a few years without major change. This sets its apart from tactics.

Sustainable strategy will also think a bit about competitive dynamics -- competitors will react to your strategy; but also customers and partners -- and some of that will help you. In the best case, some partners will create complementary offerings and you have a virtuous circle. (Classical example for this is Intel and Microsoft.)

Strategy is public

A strategy is typically most successful if everyone knows about it and understands it. Not just the contributors (employees in a classical company), but also partners, customers, and even competitors. A secret strategy is very likely to fail.

This might be surprising -- not so much in the context of an open source project, but in the context of classical competing companies.

So what protects a company from having someone just copy everything?

The answer is simple: The tradeoffs.

A company copying another one would really have to take exactly the same tough decisions as the one it tries to copy. Could it do that? Yes! Though it would be stupid, trying to be the second company where it would much better define its own niche. And the copy would typically lag behind the original in implementation and in success.

There's another thing that makes copying hard ...

Strategy versus activities

You create your product and the value to your customer by activities; you develop software, you buy primary goods, you hire people, etc. Likewise, the competitive advantages are created by doing specific activities or by doing specific activities extremely well. If your competitive advantage e.g. is to provide lowest price furniture, your sales channel will have to be a low touch model, where you invest your energy to help customers with self selection by nice presentation in shops or even better online.

If you look at all the activities you need to run a successful project (or a successful company), you'll find a large number. Understanding which ones you need to do well to succeed and how these are actually depending on each other and/or reinforcing each other quickly gets complex. But doing a good job here is crucial.

The fact that the activity system is complex is one thing that makes copying a strategy hard -- the activity system is nothing that you would publish as a company -- you don't need your customers to understand your internal activities for them to decide whether you're the right choice for them. The activity system that supports your strategy is what you have invested a lot of work in and luckily it's hard to copy.

Activity priorities ("competitive mapping")

In our strategy proposals, we have looked at current and needed activities to achieve the desired advantages; the lists are not exhaustive, but are meant to provide enough data to understand in more detail what the strategies mean and whether and how they could be implemented in reality.

We have categorized activities in three buckets:

  1. Activities we absolutely need to excel in if we want to be successful with the strategy
  2. Activites that are needed, but it is good enough if we do them decently and we should try to not spend too much energy into improving those (as they would not help significantly enough to achieve our strategy)
  3. Activities that we don’t care about. These are things that we will not put energy in — this is something where we are happy to see the competition doing …

If you think about it, you’ll note that this requires courage — calling out things where you admit that you’re not best and things where you even admit that they are not important to you at all (and you probably suck at it or don’t do it at all). But it also is a relief — we are just normally so tempted in trying to be good everywhere and this way set unachievable goals to ourselves under which we then suffer.

Strategy is as much about calling out what you don’t do (well) as about calling out what you do.

Rather than trying to fix every weakness, you admit a number of them and don’t even try to fix, but define your strategy such that they don’t matter. You rather build on your strengths. This makes different competitors more different and creates a much better competitive landscape. (If some have read popular economics literature about blue and red oceans, this is exactly what this is about …)

Narrow vs. broad strategies

Trying to be best everywhere just does not work -- yet some companies tend to have too little focus and tend to have too broad strategies.

On the other hand, strategies can be too narrow. The IT industry is full of reinforcing trends where more users attract more Independent Software Vendor (ISV) partners attracting more users resulting on more OS sales making it a more attractive target for ISVs etc. These so-called network effects make it harder for players that chose too small niches and tend to favor monopoly situations. The monopolies on the other hand are characterized by something called platformization -- rather than having one player provide a completely vertically integrated solution as a monopoly (like IBM tried with their mainframes many years ago and Apple and Oracle are trying today), we have several layers, hardware platforms (PC), OS platforms (Win, Lin, Mac), Middleware platforms (DB, Exchange, J2EE) and a variety of solutions on top.

Keeping those two things in mind, avoiding a too broad strategy while reflecting the trend towards monopolies and platforms, a focused strategy could also be to focus on some layer and make it a standard platform for a broad ecosystem on top.