Start something

Archive for the ‘Collaboration’ Category

While spending some time recently in NYC, having gotten through all the reading I brought with me more quickly than expected, I decided to do a quick re-read of The Innovator’s Solution. It is the first place I can recall seeing “value networks” used in place of “value chains,” and so I began reflecting on the notion of value networks further.

“Value networks” suggests new complexity to creating what Geoffrey Moore calls a whole offering. Value isn’t created sequentially, in a chain similar to the assembly lines of the factory system. Value comes from multiple partners working in parallel value chains that assemble together into a larger network of value for customers. Think about the value of the iPhone that is derived from the phone itself, the infrastructure provided by mobile carriers, and the population of app developers.

Companies need to be comfortable operating in these sorts of large and complex value networks. They need to know where they sit within a given value network, and understand the relative position of their competitors and partners in theirs and other value networks.

Partner network development and management has become a business critical capability, enabling companies to take advantage of both open innovation and outsourcing and alerting companies to emergent opportunities and threats in adjacent markets.

It occurred to me that relative to its importance, little is available to aid firms in developing this competency. Managers and executives need tools and frameworks to help design strategically advantageous partner relationships and actively manage partner networks. While originally intended to help companies craft an open innovation strategy, the strategic openness matrix I started working on a few weeks back could help solve this problem.

Replacing research areas with capabilities, managers and executives could use the matrix to determine the capabilities most important to differentiation and competitive advantage (the so-called core) and those that are necessary but undifferentiated (sometimes referred to as context or periphery). Core would be targeted for internal investment while context might be outsourced to a more capable partner. Should the focal firm already be a leader in a “context” capability, offering that capability as a service to others may present an opportunity to launch and grow a new business (e.g. think Amazon Web Services).

What about selecting partners and designing (yes, willfully designing) the dynamics between partners? For that I have drawn inspiration from Osterwalder’s business model canvas and customer value map. I created what I’m calling (for now) the partner relationship map (referred to as “the map” for the remainder of this post). As with the strategic openness matrix, I am making this early version available under a creative commons license so that others might build off of and improve what I started.

The map is separated into three sections. On either side of the map are the sections representing the focal firm and the partner firm (which side is which is an arbitrary decision really). Each firm/partner is endowed with a unique set of resources and capabilities that it employs in the service of specific customers and according to identifiable business imperatives, all of which is reflected in the map.

The middle section represents the interface between the two firms. The interface is characterized by the level of interdependence and integration between the two firms. Two firms might be highly interdependent with a customized interface that approaches vertical integration. Of course, tight integration does not require mutual dependence (is Apple really dependent on any one developer for its iOS platform?), and such asymmetries create business risk that must be recognized and actively managed.

The inverse of a tightly integrated interface would be a modular interface, characterized by a high level of standardization that allows firms to easily swap out one partner for another (or be swapped out). Returning to the example of iOS, its noteworthy that from the perspective of the app developer, the app it is creating will only run on iOS and must be modified for Android, implying tight integration between the app and the platform. From the perspective of Apple, the interface is standardized so that any app developer can plug into the iOS platform. At the interface, perspective and directionality matters. To understand how, it helps next to consider the arrows going in either direction labeled value proposition.

Firms present a value proposition not just to customers but also to partners. In a partner relationship, there is an exchange of value, as reflected by the reciprocal value propositions in the map. The partner uses its resources and capabilities to offer some value in service to the focal firm’s business imperatives or in service of its customer segments. In return, the firm offers the same, perhaps most commonly in the form of a payment that serves the partners imperative to grow revenues and make a profit.

The value proposition of the firm may be appealing to lots of partners of the same sort (e.g. SFDC, Wal-Mart, and Amazon all offer valuable platforms to their partners) or only a few. The value proposition of the partner may, too, be appealing to lots of firms (think of outsourcers all the companies they serve) or only a few.

Let’s consider another case of a focal firm that has created a valuable platform which its partners can leverage to reach their customers. Facebook is one such case, with its partner Zynga. From Facebook’s perspective, it has created a modular interface, accessible to all sorts of partners, Zynga included. Facebook offers access to a large population of users who frequent the site. From Zynga’s perspective, the interface is highly customized; offerings have to be built or adapted in some way to plug into the Facebook platform specifically. Zynga enriches the Facebook user experience with fun games, but lots of other companies could offer a similar value proposition.

The partner relationship map can be used to identify these sorts of power asymmetries. They can also be used to come up with win-win partnerships that balance out the power and value propositions on both sides. I’d invite anyone who has gotten to the end of this post to try out the map; draw out one of your partner relationships or the partner relationships of an example company and reply in the comments with your thoughts on how useful the map is and how it might be improved.

The (unpleasant) experience of going through our performance review process at work this summer, primed by Dan Ariely’s book The Upside of Irrationality (even better than Predictably Irrational), left questioning a lot about how we management talent. In particular, I began to wonder whether coupling performance feedback with compensation and promotion decisions really makes the most sense.

If we got back to first principles, would the two still be coupled? Does the performance review actually better inform compensation or does compensation distract from providing and receiving valuable feedback? Do raises and bonuses reinforce the feedback loop of performance reviews or frustrate intrinsic motivations? Do the business needs to award raises on a fiscal calendar compromise the timeliness and relevance of the associated performance feedback?

The hypotheses I came up with to answer these questions all went into the system of mastery feedback loops described below and the performance support groups I suggested as a near term way of realizing some of the benefits.

The name “Mastery Feedback Loops” is derived from Daniel Pinks’ Drive. In it, he identifies three intrinsic motivations in the workplace: purpose, autonomy and mastery (to which I would also add identity, to account for the social nature of the human animal, but that’s another discussion). The practice formerly known as performance management needs to be better aligned with these intrinsic motivations. For that reason, mastery feedback loops would differ in three important ways:

The focus would be on mastery of capabilities – Instead of obsessing on backward looking metrics, the goal would be to constantly improve and make appropriate investments in a firm’s talent (even when that means “reallocating resources” away from underperforming talent). Coaches, rather than managers, would help individuals identify the capabilities that are important to the success of the business (collective, purpose-driven goals) as well as the individuals ongoing professional development (autonomous goals). Metrics would then be set to monitor progress toward the ideal mastery of those capabilities.

The process would be decoupled from compensation and promotions – Tying feedback to promotions and raises only increases the stress and negative emotion from both receiving and giving constructive criticism. Taking that out of the equation returns the focus to where it should be – continuous improvement, kaizen for the individual. Concerns about that next bump up create a distraction and can poison the employee/manager relationship. Money may also not be the best way to motivate the desired behaviors.

Feedback would be social and continuous – Freed from the strictures of the fiscal calendar, feedback could be delivered with more frequency so individuals can monitor their progress on an ongoing basis, helping to set the stage for flow in the workplace. Brining in a greater variety of perspectives will improve the quality of feedback and incentives for improving, helping individuals understand how they are perceived by all parts of the organization (social esteem being important to human happiness).

An interesting area for further investigation might also be how to align performance management better to the intrinsic motivations of groups as well as individuals. As the social behavior of hives and swarms suggest, it cannot just be assumed that the same intrinsic motivations will dominate in a group.

Organize into groups of 7-13 individuals, ideally around specific capabilities or competencies that the constituents are looking to develop or that are important to their roles at the company

Meet regularly (weekly if possible) for an hour or so over coffee (or other refreshments) in something like a performance support group (hmmm, maybe that’s what we should call this hack)

Working together without any nominated leader, set mastery goals for each person in the group; maybe assign some at home individual pre-work so the process moves quickly while meeting

Help “coffee chat” members set specific metrics to monitor their progress toward mastery and figure out how to take the necessary measurements

Each week (two weeks or month), discuss where each person is at and provide advice on how to improve

Use an online tool (e.g. wiki, Google Site, etc.) to post metrics of progress and to solicit and provide feedback asynchronously

At the end of the year and start of the formal performance review, prepare documentation on each group member, signed collectively by the group, recording how that person’s performance has changed over the course of the year; this document can be brought into conversations with management as an additional data point in the review/evaluation/appraisal and help make the case for promotions and raises where appropriate

Like this:

When Google Wave appeared in my Gmail I was thrilled. I got excited envisioning the paradigm shift to a new communication platform that would disrupt email. I must have been just like all the developers working on Wave in private alpha. So why did Google Wave fail and what can we learn? (Don’t actually expect me to have the definitive answers here.)

Wave was and is a technology in search of an application. Google tried to suggest applications to users with its YouTube videos and pre-built Wave templates, but adoption never followed. Which begs the question, who was Google building this for anyway? To me it seems pretty clear. Google didn’t have a customer in mind; it was building Wave for itself, Field of Dreams style. Don’t be fooled by Apple’s example, even when they design for themselves, they are designing with a customer in mind because they all use Macs, iPods, iPhones and iPad in their personal life too.

I’m not faulting Google for its experimentation. I praise it. But I also think this is the kind of result you can expect from free. Requiring your customers to pay even a small amount introduces some discipline and rigor and forces you to develop something that is truly value adding. You’ll know if it is not because, well, they won’t pay. This is central to the Customer Development process I learned from Steve Blank (disclaimer: learn <> master).

Doubtless Google learned a lot from this experience, and that’s what makes failures great. The code lives on, much of it open source, which is encouraging. Google developers may not have figured out just how to unlock the value in their really neat idea, but someone else still might. Innovation in the collaboration market is going to be frothy for months and years to come.