Two recent, excellent, blog posts have touched on a topic I've been wrestling with since May's OpenStack Summit: What is the role of the Product Management function, if any, in the OpenStack development process?
The first article, "Calling all 'User Landians' to lead OpenStack above the cloud," by Evan Scheessele, talks about the "real user" of OpenStack—those people that need to deliver a solution that brings some sort of value to their organization. The other article, "Who's In Charge Here Anyway?…," by Rob Hirschfeld, speaks to the dynamics of how decisions—which OpenStack features are in in or out—get made in the OpenStack ecosystem.
Like most people I've held a variety of positions in my career. And I've enjoyed virtually all of them. But product management is what I especially enjoy. I love understanding deeply what customers need. (This goes way beyond asking customers what they want, as I explain here.) I love the process of helping developers understand those requirements. I love seeing those developers come up with creative solutions I never could have dreamed of. And then I get to see customers react to these really cool solutions. I can't say I "love" deciding the cutoff line for which features are in and which are out for a given release, but I know it comes with the product management territory. Product management is at the heart of understanding market opportunities, customer requirements, seeing how technologies can solve a problem, and then seeing customers react when they see something that will improve their world. How neat is that?
Most of us have likely experienced the following: An engineer or small group of engineers have an idea for a product. They work on it and then, when it has some level of critical functionality and it looks like it's solving a real problem, other people start to take notice. Product management sees the value. Company management might start to get involved. It probably gets exposure to the sales organization and possibly even customers. The project transitions from being a lab-focused effort to becoming an official program in the company.
I think OpenStack is at this inflection point now. The developers that have been and are drawn to it are interested in developing OpenStack functionality. As a result of the effort of many people over time OpenStack now has sufficiently interesting and valuable capabilities where an additional type of person is being drawn to it: Those that need to decide on which cloud technology they're going to build and deliver their solutions. These people are interested in and need to develop applications that run on OpenStack, but they're not interested in writing OpenStack itself.
The OpenStack developers (contributors) need to have a way to thoroughly understand who these users are and what their requirements are. This is where "product management" can help. It's the discipline that can segment those users, make sure they're understood intimately, and ensure that development has information that exceptionally clearly lays out their needs—so development can be sure and focus on solving those problems.
But OpenStack is developed using an open source model. The community, not a person, decides what a given release does and does not have. Capabilities gain momentum and get accepted based on their own merit and the value they deliver. It's an environment where good ideas implemented well survive… as they should.
Would product management for OpenStack be wise or foolish? It would be both. Introducing into the OpenStack process the "decision" role of product management (i.e. the function of deciding which features are in and which features are out of a given release) would be foolish. It would be beyond foolish: It would be a disaster. As a person committed to OpenStack, open source and product management I think doing this would violate a (the?) core precept of open source: The community decides what the capabilities should be.
Enriching, however, the information and documentation about users, their personas, building cross-OpenStack-project user stories, etc. I think would be very helpful for OpenStack. The current OpenStack Persona group, which I'm in the early stages of plugging into, is adding this kind of value. I certainly hope there is interest in having that work not only continue—but to expand—so the OpenStack development community has a rich set of context available about who is ultimately the beneficiary of this exceptional development method and resulting technology. This function is in no way "management." There's no managing involved. It's simply going through the effort to thoroughly understand a population of people and then documenting and communicating it well to the people writing the code.
This article was originally published on Accelerated Insight. Republished with permission.
Comments are closed.