Readwriteweb’s recent  addition of the “Readwrite Cloud” blog has been a real godsend for me and probably others who are faced with the task of creating products with “the cloud” in mind.  It seems like every product discussion I have, overhear, or read about these days involves a cloud component.  How can we “use the cloud” or how can we “cloud-enable” a product isn’t really how that discussion starts, though, and I think that it’s worth getting past some of the technical considerations and discuss what the cloud means really means for users and those of us who seek to please them.

Much like the now unfashionable and perhaps defunct “web 2.0″ label, “cloud computing” can mean lots of different things, but I think it is fairly simple if you look at it from the perspective of the end-user (as us Product people should always try to do). For me — in a nutshell – it boils down to a “where/how/when” question of access to data, content, or applications. Take this interesting company, for example:  http://www.zumodrive.com/.  As far as a “cloud” play for media, it can’t get any simpler, and there are lots of options for users for this kind of service. So how do they differentiate their product?  Well, its a subtle but interesting twist, pointed out here in this article on TechCrunch:

… the service includes a slightly different twist-ZumoDrive tricks the file system into thinking those cloud-stored files are local, and streams them from the cloud when you open or access them.

That might seem like a strange feature, but if you think about it, its terribly clever — users, even savvy users, aren’t yet completely used to/ and/or comfortable with the “cloud” concept, and by mimicking a boring old file-system, they bridge the gap between the users expectation and the real value of the service.  So, this got me to thinking… what’s a good short list to think about when you are developing products for the cloud?  Well, here is a short list…  I’m sure I’ll change my mind about what should be here as things progress, but this seems to me to be a good starting point.

1. Access – This is an obvious one, but it can’t be understated.  Users will use the cloud because it gives them access across time and space (whatever device, whenever they want)
2. Synchronization – While this is related to “Access”, there is a subtle difference.  Synchronization means that if I DO something or change any data via any interface or device, that change MUST exist across all devices and interfaces as soon as possible.
3. Trust – This is a big one, and recently, a lot of the bad publicity Facebook has been facing is driven by this issue. Users have to trust that their data is safe and private, end of story.  Something to consider here from a product standpoint, is allowing users to back-up their data. Also, companies should make it their policy in their EULA that if they go out of business, each user will receive a back-up before the doors shutter… that would be a big one for me if I was going to do anything really important in the cloud.
   
4. Openness – This is related to the Trust issue, but its slightly different in that what I rally mean is creating products that can share data with other applications and services, but also to keep the barriers to moving data entirely to another service simple and easy. Just like customer service 101 says that you are never nicer to a customer when they are leaving, the same should hold true for cloud-based services.

I recently read this quote somewhere, and unfortunately, I didn’t Evernote it (no attribution… so sorry!), but I did remember it.  I think its a good one…

Cloud Computing is not about Amazon, Its about how you reach your customers.

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.

When it comes to my blog and thinking and writing about things of interest to me (and hopefully others), I obscenely violate of the best practices that I enthusiastically promote to all those I work with – “generate ideas, quickly share them, iterate, optimize, repeat”.  Well, I’ve decided to stop violating this practice and share an idea that I’ve had rattling around in my head for quite a while: Productonomics. The idea is not especially revolutionary or even very original (the title may make some of you cringe – it even does me sometimes, but hey – it’s catchy). It may be that I am just collecting a sub-set of ideas or putting a slant on concepts that have permeated my industry for a long time, but I think that my approach narrow and unique enough to add some insight and value.  Most importantly, I have found this way of thinking to be very useful and productive in a very practical day to day kind of way. I strongly believe that that all companies and “product people” can benefit from taking a step back and looking at problems through different lenses, and the lense that micro-economics provides is very powerful and insightful for those of us who need to make decisions on a daily basis about “what people want and how we build it”.

I got so excited when I started to pull together these ideas that I went out and registered the domain and had all these delusions of grandeur of having the “Productonomics” blog taking off and getting me a book deal or something… well – for now, I still own the domain, but I’ll just post here on quiet little timjmitchell.com and set the categories of those posts to “Productonomics”.

Recently, I started consulting on a regular basis, and I am now feeling all of my time management skills put to the test.  I have always prided myself on good time management and good organizational skills, and I’m constantly tweaking my tools and process to optimize efficiency (yes, I am a self-repairing robot).  I am, in fact, an unapologetic “devotee” of David Allen and the “Getting Things Done” way of organizing and working. (Yes – it does look like a self help book, and yes, he does talk about reducing stress in your life, but it is extremely practical… I digress).  While working through a whole new set of processes for my consulting business, I ran across an old Powerpoint Deck that I put together a couple years ago for some time management training for my team.  Some of it is “loosely” based on GTD, and in order to get a glimpse of the “GTD way” you can take a look at the GTD Workflow Chart to understand a bit.I was managing a medium sized team, and it was a mix of a lot of different backgrounds — some music industry, some technology, some a little of both, some with a lot of experience, some not so much – you get the idea. The biggest productivity problems we had seemed, in many cases, to stem from some very core prioritization and work-flow issues.

Experience had taught me that as management, you simply can’t force people into “your way” of organization — especially in a rapid moving tech start-up environment.  People have to adapt to their own style and their own natural rhythm.  So, what I tried to do was formulate some really simple, non-preachy,  ideas around every day decisions that, in aggregate, eventually add up to all of the work we do.   There is definitely a good amount of “GTD” influence in here, but I tried to keep it light, simple, and more of a “guiding principle” kind of methodology instead of a “system”. You’ll even notice a fair amount of tongue in cheek in there — I was poking fun at myself for teaching “productivity”. Let me know what you think!  I’ll be posting some other interesting stuff about my experience with GTD soon.

A very good post and some really interesting insight, IMO, from The Heretech a few weeks ago about A Grand Theory of PM and its useless pursuit (also cross-posted here at Forrester Blog) .  I couldn’t agree more, in that the information economy we live is is just too complex and dynamic to try and nail down solid “truths” about product creation.  In fact, I advocate for methods and process that are, in themselves, designed to be MORE dynamic than the products we develop and not less, as is the case now.  If you think about it, the moment you create an MRD, it is probably out of date — there is already a new competitor, a new social networking dynamic, a new API, or a new technology that either you don’t know about or don’t yet understand.  Tom Grant’s opening salvo says it all:

When you’re start working in an unexplored field of study, such as PM in the technology industry, it’s tempting to propose the Grand Theory Of Everything (GTOE). It’s also the worst possible time to develop a GTOE.

I do, however, believe that “theory”, as a general  tool is very important, not so much for  “explanatory power“, but as guiding principle, analytical aid, and in a sense, an intellectual “port in a storm” when things get really complex and decision making becomes very hard.  I have been threatening for some time now to begin writing about my views on how economic theory (specifically modern micro-economic theory) is an excellent aid in product creation and decision making (its coming, really), and Tom alludes to the sociologic Middle Range Theory as a theoretical guiding principle, which I think is a good and relevant theoretical framework for PM work.  Theory has to be part of a PM’s tool box, and that theory, frankly, should come from a wide and not a narrow area of knowledge. Ultimately, if one can turn to Thorstein Veblen or Elinor Ostrom for inspiration rather than chasing down an arbitrary goal set for clicks on a new feature, then I think one’s decision making might end up more consistent and oriented towards the long run and quality outcomes (of course, selling that kind of thinking across the organization might be tough). Start-ups and small, fast-moving companies don’t really have th time or the resources to be drawing on a ton of empiricism for their decision-making.  Yes, we all need to measure certain things and use the empirical data to make decisions, but we have to be realistic about what we can measure, and more importantly, what real decision producing meaning we can glean from the data. Tom also points to the problem with lots of arduous up-front research:

If someone can figure out why even the most meticulously written and reviewed requirements don’t stop some tech companies from making products that their users don’t like or can’t understand, that’s a big contribution to our little field of study

Indeed, Tom. I am actually going to take a stab at this, but even if I’m not successful, I firmly believe that the era of the 20 page MRD was dead at least 5 years ago. We aren’t philosophers, us PM types, but can certainly use their wisdom from time to time.