Thinking about market segments
It is a reasonable (over)simplification to say that my business boils down to:
- Advising vendors what/how to sell.
- Advising users what/how to buy.
One complication that commonly creeps in is that different groups of users have different buying practices and technology needs. Usually, I nod to that point in passing, perhaps by listing different application areas for a company or product. But now let’s address it head on. Whether or not you care about the particulars, I hope the sheer length of this post reminds you that there are many different market segments out there.
Last June I wrote:
In almost any IT decision, there are a number of environmental constraints that need to be acknowledged. Organizations may have standard vendors, favored vendors, or simply vendors who give them particularly deep discounts. Legacy systems are in place, application and system alike, and may or may not be open to replacement. Enterprises may have on-premise or off-premise preferences; SaaS (Software as a Service) vendors probably have multitenancy concerns. Your organization can determine which aspects of your system you’d ideally like to see be tightly integrated with each other, and which you’d prefer to keep only loosely coupled. You may have biases for or against open-source software. You may be pro- or anti-appliance. Some applications have a substantial need for elastic scaling. And some kinds of issues cut across multiple areas, such as budget, timeframe, security, or trained personnel.
I’d further say that it matters whether the buyer:
- Is a large central IT organization.
- Is the well-staffed IT organization of a particular business department.
- Is a small, frazzled IT organization.
- Has strong engineering or technical skills, but less in the way of IT specialists.
- Is trying to skate by without much technical knowledge of any kind.
Now let’s map those considerations (and others) to some specific market segments.
- Traditional large enterprises’ central IT organizations commonly:
- Favor large, proven vendors and well-accepted IT methodologies.
- Would like to consolidate their IT vendors as much as possible.
- Have major challenges with legacy systems and data integration …
- … which are often exacerbated by mergers.
- Spend a lot of cycles on bureaucracy and company politics.
- Notwithstanding the forgoing, have resources to invest in some “sizzle” initiatives.
- The very largest enterprises are more likely than their slightly smaller counterparts to:
- View IT as a potential area of competitive differentiation.
- Believe much of what they do should be custom, due to their unique needs and resources.
- Experiment with unproven technologies.
- Smaller enterprises may:
- Have small, generalist, overwhelmed staffs.
- Hope for turnkey application solutions (SaaS or otherwise).
- Get very committed to/reliant on a small number of vendors.
- In particular, IBM or Microsoft loyalists can be:
- Extremely locked into their preferred vendor’s strategies.
- Not very fruitful for rival vendors to attempt to sell to.
- Humongous consumer internet companies tend to:
- Have very high opinions of themselves and their technical abilities.
- Be open source zealots, for reasons both of free-like-beer and free-like-speech.
- In particular, not want to buy anybody else’s software.
- Not be big fans of relational database designs.
- Other large consumer internet companies tend to:
- Be like the humongous ones they look up to, but maybe not to the same extremes.
- In particular, be more willing to pay for software.
- Be mired in company politics only/mainly to the extent they are both large and old(er).
- Smaller consumer internet companies tend to:
- Be like the large ones they look up to, but …
- … be quite short on traditional IT skills, and work around that shortage by reinventing various wheels.
- Business-oriented SaaS (Software as a Service) companies commonly:
- Are drawn to the cool open source technologies consumer internet companies use …
- … but may wind up using more traditional kinds of DBMS, for the same reasons those DBMS are used in other business applications.
- Are more primitive in the analytic capabilities they offer their customers than I think they should be (analytics-only vendors sometimes excepted).
- Are refreshingly free of traditional IT politics, because technology is too important to them to mess around with too badly. (Of course, any other kinds of company politics may still come into play.)
- Internet operations of traditional enterprises:
- Sometimes are just like stand-alone internet businesses.
- Sometimes are just like — and part of — the rest of the enterprise’s IT operations.
- More commonly are somewhere in between.
- Marketing departments of traditional enterprises sometimes:
- Want to do their own data acquisition, management, and/or analysis …
- … without having great IT resources of their own.
- Invest in departmental analytics efforts or even …
- … have line executives who are analytically proficient.
- Make heavy use of SaaS, as an alternative to relying on central IT, or as a natural byproduct of acquiring third-party data.
- Large investment firms commonly:
- Have numerous departments, each with its own IT experts.
- Care about sub-millisecond latency …
- … and sub-week time-to-value.
- Experience return-on-investment in a very different way than most businesses do.
- Telecom service companies commonly differ from other similarly-sized enterprises in that:
- They are more aggressive about using innovative technology to manage (and analyze) data.
- Somewhat resemble investment firms in having multiple departments that each have broad engineering discretion.
- National security customers often:
- Want the best, cutting-edge, sometimes custom technology, yet …
- … make themselves very cumbersome to sell to and support.
- Are not forthcoming about how they use what they buy.
I could keep going for quite a while — but for now I won’t. Vertical markets I’m thus omitting include but are not limited to:
- Pharmaceutical researchers
- Hospitals
- Insurers
- Academic scientists
Finally, for yet another omission — in my original outline I contemplated distinguishing among various geographical areas, with my first-pass segmentation being:
- North America
- Europe
- Japan
- China
- Smaller geographies
Comments
9 Responses to “Thinking about market segments”
Leave a Reply
Great post! I feel marketers and product designers greatly underestimate this diversity…
I’m curious how you concluded that humongous consumer internet companies do not like relational designs. The folks I have met from such companies seem to have fairly catholic tastes in data management and tend to use whatever works for the problem at hand. Facebook, for example, is one of the anchor users of MySQL and drives much of the innovation in that community. Google and Yahoo also have enormous installations of MySQL. All of these companies also make heavy investments in non-relational solutions such as HBase, BigTable, and PNUTS.
Well, look at what Facebook does with MySQL. Nontransparently-sharded MySQL is not a very relational design in my book.
Facebook did invent Hive, but if they really cared about relational stuff they’d use something with better SQL performance than Hive.
I guess we would need to let Facebook folks comment. One of them did so at least informally when Domas Mituzas strongly refuted Mike Stonebraker’s criticism of Facebook’s MySQL application design. (http://dom.as/2011/07/08/stonebraker-trapped/). Experienced practitioners in the MySQL community consider the Facebook implementation a model for how to scale SQL databases effectively.
Exactly my point, Robert. Mike Stonebraker criticized the Facebook guys for not engaging in traditional relational modeling or schema design. They don’t dispute the characterization, but strongly dispute that they’re doing anything wrong.
My read at least from the Derrick Harris article was that Stonebraker was attacking the overhead of implementing on MySQL, not Facebook’s relational modeling approach per se. That’s the HStore/End of an Architectural Era argument. It’s interesting, but as no implementation based on HStore concepts has 800m users it seems we should not be overly hasty to accept that criticism. At that scale it’s unlikely you can do “traditional” anything.
Robert,
Oh yeah. I think you’re right about the Stonebraker critique.
Even so, if you don’t do joins, you’re not using RDBMS in a traditional way. So I continue to be baffled as to why you’d raise Facebook as a supposed relational traditionalist.
I unfortunately can’t comment further on the Facebook architecture for a variety of reasons. In general, however, sharding does not preclude joins. It just restricts their scope, for example within a set of users belonging to a particular service. In that sense you are right that the system is not fully relational, at least at the level of the DBMS. However, in large systems, you cannot join with everything anyway and still scale linearly. At some point you have to break things into pieces to ensure performance and availability.
There was a nice article by Pat Helland a few years back called “Life beyond Distributed Transactions: an Apostate’s Opinion” that laid out the issue of scopes very neatly for infinitely scalable systems. Within such scopes nothing precludes use of the full panoply of relational techniques.
This is an excellent set of categorizations. I’ve noted that some small organizations can get way out of whack when they fall for an inappropriate dogma. For example, the $20M business that hires 12 programmers to spend a couple of years writing a whoop-de-do custom postgres system, then throw it all out when someone shows them some vanilla OTS that does the same thing, plus it’s been battle tested. 20 years ago it might have made sense (with the tech of the time) because the OTS didn’t exist.
I could rant on about traditional enterprises and SAAS, talk about lack of relational design ability, sheesh. I blame it all on MS Excel, confabulating presentation and data layers.