“The Google+ platform is a pathetic afterthought.” So says Google engineer Steve Yegge in a recently leaked 4,578 word, internal post and critique of Google's recently introduced social site. Now, I have to admit, I thought Yegge was going to expound on the value of Google+ in light of the alternatives or how Google+ missed the mark in understanding the social customer experience of it’s target customers. Or even, how Google+ wasn’t delivering on the original vision.
Instead, it was a well-written and, at times, entertaining perspective that revolved around three main points:
- You can’t build one product and have it be right for everyone - accessibility is the Most Important Thing.
- A platform-less product will always be replaced by an equivalent platform-ized product.
- Platforms solve accessibility - a platform is accessibility.
To boil it down, Yegge seemed to be saying with a fair amount of passion and angst that the failure of Google+ was that it continued Google’s emphasis on building products that weren’t service-oriented architectures (SOA). His premise is you can’t be all things to all people so you need to build a platform so that other people can make you all things to all people.
Where was the customer in all of this? I’m sorry, maybe I missed it but it didn’t seem focused on the customer at all. After all, who IS the customer for Google+?
Now, I have nothing against SOA and I think his points about Accessibility are quite valid as he states “When software — or idea-ware for that matter — fails to be accessible to anyone for any reason, it is the fault of the software or of the messaging of the idea. It is an Accessibility failure.” I agree with this point - after all if a customer can’t figure out how to use your software to accomplish a given task, then I’m sorry, the capability in that area doesn’t exist for them.
Where I disagree with him is his premise that we solve for the customer (accessibility) by building a Platform.
Yegge worked at Amazon before Google and drew heavily in his post from this experience. Amazon made a huge push (thanks to Jeff Bezo’s “cultural imperative” to move all development to SOA. And yet, he also jabs at Jeff’s love of his “millions of semantics-packed pixels on the landing page”, emphasizing just how difficult it is to navigate Amazon’s crowded and often confusing site. So where’s the connection between Accessibility and Platform?
I would restate Yegge’s points this way:
This to me is just another way to avoid defining your intended customer (i.e. target market customer). It’s another great example of building a solution first and then try to find the customer for it second.
- We want to sell to Everyone
- We can’t address Everyone by ourselves
- We need to build a platform that can be extended by 3rd parties to appeal to Everyone
- SOA is the best technical way to do this
And Google+’s problem, in my view is just that. After all, who is the intended customer for Google+? It appears they built it in response to the competitive threat by Facebook, or LinkedIn, or both. And while imitation is the highest form of flattery, it isn’t a path to a clear target market definition. In fact, it’s a clear path to nowhere, for by definition the target audience that you’re building for is already taken!
I’m sure many of you have received an invitation to join Google+. And like myself, you’ve accepted it and done some minimal set up and snooping around. And there certainly are some interesting twists to it, but really, are you going to move from LinkedIn, Facebook or both to Google+? Do you really need another social network?
First of all that’s a pretty rough move, akin to selling your house and moving to a foreign country in the real world. Which a few people do from time to time, but only because there’s clear value in uprooting yourself and family and making such a bold and difficult transition. I don’t personally see any compelling advantage to moving to Google+. Do you? But am I the intended customer? Are you?
Maybe it’s intended for people who haven’t joined the other social networks. Well, what is this group looking for in a social networking site? And what makes Google+ uniquely suited to this group? I currently have two myself - LinkedIn for my “professional” life and Facebook for my personal life. I’m not sure I have time, quite candidly for another virtual “life”.
According to Yegge’s post, there doesn’t seem to be any concern about any of this. Yegge is passionately advocating an internal, SOA revolution within Google. That is classic inside-out thinking that I’ve written about in this blog before.
And that is the message that I think is so important in all of this. Everything we do must be driven by a deep understanding and commitment to delivering a superior experience to our intended customer. And, if SOA does this, then great implement SOA (as painful as that may be).
Are you in the middle of a significant and costly internal improvement initiative? Is it being driven by a clear and uncompromising focus on your intended customer, or is it being driven by internal forces (e.g. cost-reduction, corporate mandates, politics, egos, etc.?)
If it’s the latter, you may want to take a step back and question whether or not it’s worth doing in the first place.
So, just to get these ambiguous acronyms straight: MFP is Maximum Flexible Product (my own invention) and the MVP is Minimum Viable Product (Eric Ries.) The two of these, in my experience, are light years apart and reflective of two different approaches to creating customer value.
First, the MFP...
Early in my software career I was introduced to the concept of “maximum flexible product.” The concept was relatively simple and straightforward - value is greatest when you give the customer as many options as possible for accomplishing any specific task.
After all, we don’t want to put the customer into a “straight jacket” where they can only do things one way. And, we also knew that every customer does things a bit differently, so in order to sell to the majority of them, we’d need to accommodate their many differences. We also aren’t completely sure which single approach will be the most common, so to hedge our bets, we need to include as many different variations as possible. Finally, and this tends to be an architectural, platform issue - it can be notoriously difficult to go back and make changes, so better to get it all in up front.
I believe this orientation comes from several customer value deficiencies. First, it comes from a lack of focus on a specific intended customer. The fuzzy focus we have on our target customer profile leads us to trying to “please all the people all the time”. Out of this uncertainty, to minimize perceived risk we emphasize product features, functionality and flexibility. Unfortunately with all this comes the unintended consequences of cost, complexity and confusion for both us and the customer. Instead of offering higher value to specific customers, we end up offer lower value to all customers. And it’s a slippery slope, because as we pursue this approach we, by necessity, have to continually add more and more flexibility, which creates more barriers to value.
There are certainly times when flexibility is required to address the customer’s needs, but it needs to be used carefully and only where it is absolutely necessary and when clearly justified by the customer’s requirements.
The MVP, by contrast seeks to build value by only adding the the minimum amount of functionality and flexibility to address the highest priority needs of a well defined customer profile. To execute an MVP well also requires an intense amount of customer understanding. Out of this customer focus and deep understanding comes an ability to hone in on the minimum but highest value needs to address, along with an appreciation of how best to address them simply and cleanly. There isn’t a need to “throw in the kitchen sink” because we know when the customer isn’t looking for a kitchen!
This approach takes an incredible amount of courage and discipline. It takes discipline to avoid drifting from our original intended customer focus. And it takes courage to say “no” to the inevitable requests for “one last” capability feature.
I mentioned that early in my software career I ran into the MFP. Well, I also ran into a great MVP as well. One of our senior product architects, in developing a new, PC-based estimating program, could have easily taken the approach of re-creating our very complex (and flexible) mini-computer estimating software. Instead, he chose to build an MVP although we didn’t call it that in those days. He took his incredible body of customer knowledge gained from developing the previous software and used it to hone the initial offering to what appeared to many of us as an overly simplistic solution.
It clearly wasn’t because he spent more time figuring out what to leave out than what to include in the initial product. Precision Estimating went on to become the industry leading construction estimating software used by thousands of contractors to this day.
I’ll leave you with this great quote from Antoine Saint-Exupery I ran across the other day that I think speaks so eloquently to the MVP approach: “Perfection is achieved, not when there is nothing more to add, but when there is nothing less to take away.”