Learning from Competition
Gotcha. Traitor. Snicker. Those were some of the reactions when people discovered that I was using an iPhone. I stand before you accused of using a competitor’s [sic] product and I plead guilty.
Moving beyond the gotcha blogs, there’s an actual reason for using technology products and services other than the ones you make (or happen to be made by the company where you work/ed). I think everyone knows that, even a thousand tweets later. The approach in many industries to downplay or even become hostile to the competition are well-documented and studied, and generally conclude that experiencing the competition is a good thing.
Learning from the competition is not just required of all product development folks, but can also be somewhat of a skill worth honing. Let’s look at the ins and outs of using a competitive product.
Obviously you should use a competitive product. You should know what you’re up against when a consumer (or business) ultimately faces a buying decision. They will weigh a wide array of factors and you should be aware of those not only for the purposes of sales and marketing but when you are designing your products.
It is easy to fall into the trap of checklists or cloning competitive products and so that might be why you follow the competition. That’s a weak way to compete. Part of planning your product/service is establishing your unique value proposition—is it features, pricing, implementation or execution for example?
Simply being the same as your competitor that might be more established is not good enough and so knowing the competition for the sake of skimming their value proposition won’t work. Generally speaking, just adding the cool thing from a competitor at the last minute to your product’s plan is not going to work well for customers and will be readily transparent. That’s checklist product development.
Product development is a complex endeavor. There is no magic. Worse than that, most people making products in a “category” are pulling insights, ideas, and technologies from the same sources. What separates wildly successful products from distant number two products can often be just a few of thousands of choices.
Studying your competitor, well, gives you a chance to evaluate your choices in an entirely different context. When you make a product choice you are making it in the context of your company, strategy, business model, and people/talents. What if you change some of those? That is what knowing the competition allows you to do, and basically for free (no consultants or top secret research).
What does it mean to study the competition well? What are some common mistakes made when studying the competition?
Even when you study the competition, there are some techniques that are often employed, and with the best of intentions. There are ways of executing on a competitive analysis that leave some information on the table.
Worse, it is possible to execute on a competitive analysis from a dismissive or get this over with posture that takes away what is perhaps the most valuable source of information in forward looking product design.
While there are many potential challenges, here are a couple of examples of patterns I’ve seen.
- Using the product in a lightweight manner. All too often analyzing the competition itself becomes a checklist work item. Go to the store and play with it for a few minutes. Maybe ask a friend or neighbor what they think. The usage of a competitive product needs to be in depth and over time. You need to use the product like it is your primary product and not switch or fall back to your old way of working. Often this is weeks or more of usage. Even as a reviewer this applies. Walt Mossberg famously took an iPad on a 10 day trip to France—no laptop at all. That’s how to use a product.
- Thinking like yourself, not the competition. When using a competitive product you need to use it like it was intended to be used by the designers. Don’t get the product and use the customization tools to morph it into the familiar. Even if a product has a mode to make it work like the familiar (as a competitive bridge they offer) don’t use it. Use native file formats. Use defaults in the UI and functionality. Follow the designed workflow. They key is to let loose of your muscle memory and develop new memory.
- Betting competitors act similarly (or even rationally). If you think like a competitor you have to make future decisions like they might. Of course you can’t really do that or really know and this is where product intuition comes to mind (and also why blogs predicting product directions are often off the mark). You have to really wrap yourself around the culture, constraints, resources, and more of a competitor. The reality is that your competitor is not going “fix” their product to turn it into your product. So then the question is what would a competitors do in their context, not what would you do if you were designing the follow-on product in your context. This might actually feel irrational to you. One of the most classic examples of this is whether or not the Mac OS should have been licensed to other PC makers or not. Arguments could be made either way, both then and now. But what is right or assumed in one context simply doesn’t make sense in another. That context can also include a time dimension where the answer actually changes.
- Assume the world is static. Even after you’ve reviewed a competitor through usage you might feel confident because they are missing some features or might have done some things poorly. That’s a static view of the world. Keep in mind analyzing the competition is a two-way street. If you noticed a weakness there’s a really good chance the competitor knew about it. When everyone pointed out that a phone was missing copy/paste, don’t make a mistake thinking that was news to the development team and would remain a competitive advantage.
There’s a reason Patton often made reference to Thucydides treatise on the History of the Peloponnesian War. It is a thorough and thoughtful analysis that goes beyond who won which battles but gets inside the minds of the men, the culture, and the thought processes. Competing in business is not war and should not be treated as such, either literally or as a metaphor (the stakes are relatively insignificant and business is an endless series of skirmishes and battles rather than aiming for an ‘end’, at the very least). However, the idea of being thoughtful and understanding tactics, decision making, resource allocation, and more are important.
There are a few techniques that are often used in conjunction with using the product. The most important thing is of course to use the product and to adopt it as your primary tool for all the uses it was intended in the manner in which it was intended. With that raw data, there are number of potential tools for sharing that learning:
- Feature comparisons. The most obvious tool is to make a long list of features and compare products. This works well for some folks and especially when handed to customers. It is also the least useful in product design. A feature checklist is only as good as the features you put on it. We all know how easy it is to make a product look feature rich or feature poor simply by picking the right set of features to check off. You can even pick weird measures for whether a feature is in or not—you could have a “WiFi” check item or you could make it “WiFi a/b/g/n” and change who won or lost. You can also lead to a false conclusion if you try to score or just count features—it is doubling the error rate of your check list because you’re doubly-assuming your context.
- SWOT. A common “single slide” approach to competitors is to distill down competition into something like strengths, weaknesses, opportunities, threats. These are very hard to do well, again because of the context, but by including all of these you force yourself to confront your own product shortcoming and missteps. Personally, I don’t like the use of “threats” because it starts to conjure up war and sports metaphors but you can think of them as risks that customers won’t choose your product/service. SWOT is often used by the marketing team because you can intermix near term tactics in the marketplace (opportunities).
- Scenario comparisons. A nice way to take a more end-to-end approach to competitive analysis is to consider more complete scenarios. If you’re testing for battery life then don’t just play a movie, but play a movie with the radios on and an active mailbox, as an example. As with everything, it is important to pick scenarios that are truly representative of what a product was designed to do and how it was designed to do it, not how your product/service does. Measuring a scenario comparison could involve clicks/gestures, clock time, resource consumption, and more.
- Competitive review or blog. My favorite test of really getting in the mind of the competitor is to challenge yourself to review your own product as though you were the competitor. Alternatively, you could write a press release or blog for a competitive product—the product that competes with you. I remember once writing a whole “press kit” for what became Visual C++ as though I were the Borland C++ team. It was great fun. Rather than focus on Windows (3.0!) development, I focused on compiler speed, code size, array of command line options, and more. Those were the things that Borland would focus on. I then ripped into Visual C++ as a Borland person, highlighting what options were missing, the slowness of the tools, and so on. Even though VC++ 1.0 had a Windows dev environment, resource editor, class library and more—all assets relative to Borland.
Of course not matter what your approach, be sure to write down your work and analysis (writing is thinking!) and share it with the team (learning by sharing).
Those are a few common pitfalls and approaches to competitive analysis. There are many more. Feel free to share your favorite approaches in the comments.
Finally, studying the competition is the job of everyone on a team. Importantly, the people doing the work need to study the competition. It is not a job for a staff function or those outside product development. Management studies the competition not just receives reports on the competition. Experts in domains that are parts of a product should drill into the details of the competition (hardware, software, subsystems, peripherals, APIs, etc.)
Be obsessed with the competition. Always. This has never been truer than the fast paced and dynamic world of products where the flow of information is instant and the scale and complexity are greater than ever before.
PS: My plan was not to publish so frequently/rapidly, but even in my old MS blog if something came up that was so timely relative to the ongoing dialog, I’d do a quick post. I’m still going to pace myself :-)