Ecosystems: Knowing Customers by “Currency”


For a long time, I have been a fan of the “ecosystem” thinking with regards to product concepts and business practices, and it will undoubtedly become a consistent theme in this blog. My affinity towards ecosystem thinking comes at least partially from the frustration of working quite a while in an industry (digital music) where a healthy ecosystem is both lacking and desperately needed.  The core concept of the “Business Ecosystem” has been around for over a decade, and while the concept may be overused a bit, the logic behind it still rings especially true for media and the internet. Many of us in the digital media world have often found ourselves in a position of “explainer/evangelist” of the concept, due to the lack of a cohesive ecosystem – sometimes its hard for those at or near the top of the food chain to understand “balance” in a healthy ecosystem… but I digress – – different post.

4 Currency Explanation

Eric Ries’ well-crafted post, titled “Business ecology and the four customer currencies“, explains the “4 currencies” of money, time, skill, and passion and how they influence customers’ decisions. He does a fantastic job of illustrating the currency concepts and how important realistic customer segmentation is.  Eric has lots of good posts on Freemium concepts, and the ecology discussion is closely related.   He also pointed me to this DEEP article by Andrew Chen that goes into some interesting underlying economic concepts behind creating a successful freemium model – – definitely worth the read.

I have been thinking a lot about business ecosystems lately as I’ve been working through product concepts, and I think that as a “product people”, we ought to consider that our customers self-segment based on their mix of “customer currencies”. Ries provides currency definitions using gaming as an example, wherein the different user types achieve success using different currencies.  The basic concept is simple to understand (I”ll paraphrase here): players with money can buy success, players with lots of time can slog out success, and players with skill are good enough to achieve success quickly and cheaply. The players with a lot of passion are put into a special category, and he argues that while it may not seem like they have “what it takes” to be successful, they are often the hidden reason for the success of the game (and thus the ecosystem) overall.

Each of these four currencies represents a way for a customer to “pay” for services from a company. And this is true outside of games. Constructing a working business model is a form of ecosystem design. A great product enables customers, developers, partners, and even competitors to exchange their unique currencies in combinations that lead to financial success for the company that organizes them.
He goes on to provide great examples of how this affects companies’ decisions and growth patterns, and ultimately how it leads to freemium decision-making – – who do you charge and when.  This has to be one of the hardest decisions to make, and I’ve certainly got it dead wrong at least twice that I can remember, so It got me thinking about the power of the ecosystem and “currency” methodology with regards to making any kind of product decision and how it might play into the pre-development  process.

Ye Olde MRD

One of the exercises we (as in product people) almost always go through when setting out to build something “User Profile” or “Market Segmentation” analysis. In the internet / start-up world, segmentation is typically done in the some MRD, PRD, or other such long and wordy document, and in my experience, it is mostly ignored.  Analysis like this is quickly set aside in order to get to the “real work” of defining features  – – this is always viewed as the “real meat” of what the PM should be doing.  The reality is that you just don’t really know who’s going to use your product (start-ups and fast moving web and software companies rarely do extensive or expensive market analysis, nor should they), and this is why this process is not given the appropriate level of attention.  One usually ends up doing some light-weight market analysis, some “user profiles” (suzy is an 34year old architect in NY… blah, blah) and then perfunctory predictions about segmentation.  Here is an example of a typical MRD from a PM Consulting firm.  You’ll notice right away that there is a lot of information to be filled out  in the “Customers and Buyers” and “Users and Personas” section, and it all seems very relevant and useful, and yet when it comes to decision making time (which this document is supposed to support), this data always seem inadequate and vague.  Why? Well, as Steve Mushero points out in his discussion of “Decision Documents” as part of the MRD process, what ultimately matters is the decisions that are made and the thought process to get there, and not the underlying analysis output.  So how do the “4 Currencies” and ecosystem thinking help here?

Customer Currency and Engagement

One approach that I have tried in the past is to segment by “potential level of engagement”. While I didn’t realize it at the time, this is the same methodology, but not as clear nor as useful.  My experience with segmentation ex-post launch, had always been that the real segmentation of users had nothing to do with their demographic profile or their overall-“tech-savvy-ness” or anything like that.  Their experience and satisfaction was more a function of how engaged with the product they were. What I found was that a very simple conflict formed between the “power user who wants  lots of deep features and rich content” and the “casual user who just wants quick hits and not to have to spend a lot of time figuring it out”.  This also applied to media sites as well, where it wasn’t’ necessarily a “technical feature” divide, but a “deep” vs. “shallow” content divide. I still believe that this is the core segmentation problem to solve, and the “4 currencies” analogy goes much farther to define how to think about your users.

Applied 4 currencies Process

The “4 currencies” approach, IMO, is really useful, because not only does it provide simple parameters, but it also allows you to fairly accurately apply values to those parameters that will allow for real decision-making.  For example, let’s say that I’m developing a play-listing application within a music player or site. The real segmentation challenge here is that I will probably have users who are heavy play-listers and users who are either new to the concept or they aren’t heavy play-list users.  We have to make all kinds of assumptions here to make this example work, and one of them is that play-listing is core to our product goal (if it weren’t, then we might decide that play-listing is for play-listers and users who self-segment out of play-listing don’t suffer as a result). So, if we think about our users as having different mixes of the 4 currencies, then a quick segmentation might look like this:
  • User A= Time – 20%: User A has lots of time to kill and can explore every nuance of the application.  As a result, since setting up a play-list is fairly simple, these users will most likely create lots of play-lists and experiment with the utility of all of the surrounding features.  They may not understand all of the advanced features, and may opt for volume of play-lists, or they may lean heavily towards social sharing of play-lists.  Ultimately, we should expect mostly volume from these users, and we should encourage social integration as this volume, if shared with friends, will drive new users.
  • User B = Skill – 10%: Skilled users will be looking for sophistication and shortcuts. They will certainly want to import existing play-lists, and if we can’t map the data correctly, or if we don’t import lots of different file-types, they may be frustrated and leave. IF they like the sophistication level, we can probably look to these users to not only create volume, but to drive new users through evangelism and sharing.  We can also look to them to drive our product features, as they will undoubtedly start innovating within the parameters of what we give them (analogy: @replies on twitter wasn’t an official feature until very recently).
  • User C = Money – 35%: Users with money (and by this, we mean more money than time… they may be skilled as well) might be candidates for an upgraded version.  This could be, perhaps,  a very fast desktop client that would auto-scan the user’s hard-drive for viable files to import. This might search for other play-lists and recommend other users’ play-lists (this is  probably a feature we want anyway) to make their own.  These users want a quality experience without spending time, and if we could do it, they might pay for it.
  • User D = Passion – 35%: These are the users that will be the core of our testing and feedback. They will probably use every feature and help other users on the message boards. they may blog or tweet about our success for shortcomings, and we should engage with these users. We may want to ask for volunteers from this set, and we may want to give away our premium product to them for testing purposes. These users will be our biggest evangelists, and also our biggest critics if we stray. It will be good to view our ongoing competitive analysis through the eyes of these users, as they typically will be continually comparing our product against our competitors.
So, that’s just a quick example, and without having any idea what this product does, I had to be kind of vague, but I think you get the idea.  You see that I put % – – that’s gonna be hard to do, but ultimately, its not a predictor, but really what you desire.  By thinking about what kind of audience you WANT, and then understanding what those users bring to the table, then all of a sudden, it starts to become clear what features you might want to focus on.
Thanks for the insight, Eric.