… And This is Why Flexible Products Matter

The Devil We Know

On the heels of introducing “Productonomics“, I figured I should go ahead and post something relevant, and this article caught my eye a few weeks ago from Silicon Alley Insider: Facebook Has Zynga By The Short Hairs — But It Needs To Be Careful. Yes, of course I appreciate any business article that can refer to pubic hair, but it speaks directly to the kinds of “broad spectrum” econ-based concepts that we all need to be thinking about as we build products.  I have always felt that when developing products, you aren’t JUST dealing with the current marketplace and what you think users want… you are mightily constrained by “what you have to work with”, and many times those constraints matter more than we think.

Its easy to examine at our “product arsenal” and determine the following:  “I have X many designers, developers, and project managers, and I have these tools and technology providers – ok, go”. The problem with that line of thinking is that, in a sense, we are creating an experimental environment that is doomed to provide a false reading of our reality… a  reality that is a complex system with lots of moving parts. We really need to think about the business and competitive environment that our company exists  in, and in many sectors, the business development and legal efforts may have more impact on your decision-making than anything else (just ask anyone building digital media products).

The article discusses the buyer-supplier hold up problem, and in my mind, its an insightful view into the relationship of Zynga and Facebook – – or any app developer to platform provider relationship (iPhone and Android App developers, take note – – – same situation).  A Product Manager, looking at their options from a pure “user advocate” position, might opt to say “well, our users love our game on Facebook, and it works well on Facebook, and we can develop many more features if we stick to one platform, and overall, the product will be better”.  That actually might be a true statement, but past the short-run, if the the party that provides the platform has too much leverage, the product can suffer severely from restrictions that you didn’t bargain for – – or more likely, the profits of your company suffer severely from leverage that you gave up (and then the product suffers from lack of resources).

So what conclusions can a Product Manager draw from this lesson? Perhaps another micro-economic principal is helpful to throw in to understand their situation: Interdependence.  A popular buzz-word thrown around these days to describe the positive side of interdependence is “ecosystem”, but its the same idea. We don’t live in a vacuum with our users, and our companies don’t operate in a static world.  We need to think ahead, and plan for “scale” and all that — but relying on your intuition to make the right guess is pretty damned risky – – I think the lesson learned is for us product people is that we are advocates of users, yes, but also advocates of flexibility.  The real value of Farmville is the game itself, and Zynga might lose some short-term market-share by building in some “flexibility”, but in the mid to long-run, they will be better off with a healthy if not slightly competitive relationship with Facebook and a product that can evolve regardless of the platform or distribution environment.  That discussion will will probably manifest itself in a “we need to give up short-term feature-improvements for longer term flexibility” discussion… not the easiest one to have. Clearly, though, its the conclusion that Zynga drew: http://www.technewsworld.com/story/70086.html.

Ecosystems: Knowing Customers by “Currency”

ecosystem

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.