Vision – or the lack of communicated vision – is a problem I’ve been trying to tackle on multiple teams for the last several months. The specific problem is caused by Product Owners (or Customers) who do not have a vision for the system they own.

It’s not that there isn’t anyone in the organization who has a vision for the system–that’s often the Product Owner’s boss. Rather, the troubles start when the boss delegates responsibility for product ownership but doesn’t take the time to instill that same individual with his or her desires and dreams for the system.

And what is the result of this failure to delegate vision with product ownership?

  1. Teams focusing on less, and even unimportant, features such as sophisticated admin functionality that only benefits Product Owner.
  2. An undercurrent of doubt within that team that the development path is not directed toward an overarching, understood, and meaningful goal. (This undercurrent will, at best, draw away productivity and, at worst, foster team-wide infighting over the development direction.)
  3. A completed system that does not deliver business value.

In one word, it’s waste.

3 Responses to “Agile Anti-Practice: Delegating Product Ownership without the Vision”
  1. Peter,
    A mandatory document in the aerospace & defense as well as the Enterprise Content Management (through AIIM) business is the Concept of Operations (ConOps). It describes withy words and picture how the system will fulfill the mission. Say fly to the moon and return. Or consolidate all contract informaiton in a single location. It answers the Why, Who, When, Where type questions for the project.
    The ConOps is part of the project chartering process, where the deliverables and those accuntabile for the deliverables are connected in a matrix made public – a Big Visible Chart.
    When the project gets “confused” the ConOps and the Responsibility Assignment Matrix (RAM) (Accountability actually, rather than responsibility) are consulted to get t he team refocused on the mission – fly to the moon or collect enterprise documents.

  2. Hi Glen-

    Thanks for the rapid-fire comment!

    I probably should have been more specific about the context of the situation. In this case, we are an e-commerce environment that is heavy on market testing, analytics, and other things that can cause teams to turn on a dime. Our teams typically release working software on a weekly basis. While there are months-long initiatives that get sketched out and built, even the end-state of these high-profile endeavors is entirely susceptible to shifts in the business environment, feedback from the previous week’s metrics, and out-of-left-field adjustments that must be made to keep the business operational. (I apologize for intentionally withholding many of the meaty details.)

    I’d agree that your proposal could fix some of the problem. It would force the “boss” to at least initially lay out a specific vision for each new initiative. But I’d argue that a vision on paper is still not the same as a vision instilled through face-to-face conversation, white-boarding, and even trial, error and adjustment. I’d compare it to the letter of the law (requirements) versus the spirit of the law (vision). In our fast-paced context, I believe we need product owners who live and breathe the spirit of the law and have the authority to interpret the product vision so that it survives the frequent and novel twists of our complex environment.

  3. I cannot even begin to describe how perfectly this post sums up a common problem with an inordinate number of projects I’ve been involved in (as a developer and manager). Clients wonder why the finished product doesn’t meet their ‘vision’, without ever telling you what that vision is.

    I like the concept of a ConOps – it reminds me of 37Signals’ concept of a ‘story’ ( – but I’m imagining pulling it out half way through a project in response to an irrelevant change request, or the third meeting about whether thumbnails should be cropped or resized, and I can’t imagine it holding much sway with the immediate problems.

    Ultimately, I think you need a client receptive to this kind of approach for it to be effective.

    Of course, I’m only thinking about client work here, as opposed to in it’s real context, but I think it’s application could and should be broader. There’s certainly no harm in approaching client work in this way.

Leave a Reply

To prove that you're not a bot, enter this code
Anti-Spam Image