In my “Cutter Predicts…” post for 2013, I briefly made the point that a picture/image of an asset is merely one form of representing a physical asset. With services like Instagram, The Fancy and Wisemarkit drawing our attention these days, it is natural to think in terms of photos and/or photo streams. However, I contended:
The nature of the phenomenon we are examining here is not restricted to photos/images. Rather, it is generic. Regardless of the nature of your company’s assets, any information about them that flows through the “pipes” of your company is potentially a productive asset. It can be utilized (once an API is exposed) through an app store that mines the information for its flow, currency, accuracy, relevance, etc.
Implementation-wise, enterprise app store applications of the nature discussed above require three steps. First, an API which gives access to some aspect of the representation of your assets needs to be exposed. Second[i], an idea is conceived how to utilize the API in a commercially promising manner. Third, some folks – in-house, partner’s or external – need to develop the application that implements the idea that utilizes the exposed API. Once the first step is taken, the second and the third steps can largely be accomplished through one form or another of crowd-sourcing. For example, you might opt for expert-sourcing.
The importance of crowd-sourcing in the context described here is the fact that we are living in the era of applications. Fewer companies can afford the resources required nowadays to develop and test the myriad of applications that emanate from needing more applications on more platforms, on more devices, for more channels. Moreover, conceiving brilliant applications is not necessarily something your company’s experts will do better than the wisdom of crowds. I would actually submit that a vibrant crowd (call it “developer community” if you prefer) might be better suited to come up with ideas than your own staff. Your staff members are largely confined to your company’s context, whereas crowds could/would connect the dots for your company in unpredictable contexts.
If you accept this premise, the role of the Product Owner changes in a most intriguing manner. He/she might still be “managing the flow of work into the team,” but in the context described above the Development Team itself morphed big time. The winning application for your API could be developed by a few bright students in some dormitory that conceived an opportunity your staff members did not. There is no way the product owner could “manage the flow of work into the team[ii].” Rather, the product owner manages the incentive for the flow of work to be independently generated by the way he/she exposed the API.
Judging by the rapid growth in the number of enterprise app stores, the product owner role becomes largely indirect. It is not the grooming of the backlog that matters so much. Rather, it is the setting of the incentives through the definition of the business design of the API that enables “drawing out the most valuable possible product by the desired date[iii].” In so doing, the product owner becomes more of player in the construction of a shaping platform than a custodian of the product backlog.
[i] This second step, of course, could precede the first step. The specific order discussed in this post is meant to highlight the power of independent ideation.