Product

There is a vast wealth of literature about product management and product development. This literature can teach you how to successfully conceive of innovative products aligned to core business strategies and bring them to market quickly, mitigating risk with “fail fast” approaches, rapid prototyping and early validation. It can teach us all to create lean start-ups.

But in the world of IT, how often do we get the opportunity to create entirely new products within the enterprise? I argue: not very often. When this does occur, it is generally with the core products themselves: what the business is selling the customer. The platforms that support this business are generally not considered products, even if they have product owners. Traditionally, these are projects.

This article does not attempt to address this entire problem but rather focus on how to effectively communicate product vision without adding overhead.

Projects are not products. A project could be considered a kind of product that does not add value in and of itself*. It is a mechanism that has many moving parts, and not all of the parts actually contribute to the fabrication of the product. It has a layer of artifacts around the actual delivered value, but most of these artifacts are reactive: spreadsheets and plans that are manually updated to reflect the truth. They are not the truth, and do not provide actual business value to the customer (we can get optics on the truth, but that is a different area that merits exploration on its own).

For all the lessons one can learn from current product literature, there is not much that sheds light on how to apply product principles to projects “in flight,” the ongoing IT roadmap that has a yearly cycle of budgeting and planning. Anyone who has tried to shoehorn Agile user stories into IT maintenance tasks knows the pain of applying apple methodologies to orange problems.

The answer lies in creating flexibility around both what we conceive of as projects and products so that we can show stakeholders clear results as quickly as possible. Time to market should be re-framed as time to result to reduce emphasis on actual releases to market and focus on core value delivered with a cadence. But staying faithful to ceremonies, artefacts, concepts and roles that do not directly lead to results often creates more work around the product, not for the product. So we also must eliminate anything that does not directly contribute to results.

This means that how the work items or tasks or stories are expressed needs to first and foremost eliminate all possible ambiguity so that the person tasked with the work can execute the work autonomously, creating a perfect, functioning result. Clearly these units must exist in a prioritized backlog, but I do not care so much what the unit is, as long as it meets this requirement.

What I do need is a document that expresses the product vision so concisely that it can serve as a map for all team members when there are doubts about how to implement a task. A map is not strong enough — I want a key. I want a vision expressed with enough precision that it can be used to decrypt any task and show me the expected result. This must contain expected results as success criteria above all else.

This document is then widely socialized, most importantly with the development teams, who are usually the least social in the context of a project and most deserving of our empathy. They also have no time to spare with idle communication.

In my previous article, I sought to challenge the dependence upon the scrum master role. Here, I propose to challenge the dependence upon the product owner role in a similar fashion. The product owner’s goal is to create and actively maintain this product document. By asking that all inquiries be checked first against this document, communication no longer is filtered through a bottleneck, and emphasis is on the highest level of clarity. This forces the product owner to be extremely clear with vision and challenges teams to resolve ambiguity with autonomy.

If the “why” has to be spoon fed on a daily basis through endless conversations, something is broken. This lack of clarity grows in volume downstream and manifests as defects and churn. Managing this is normalized into routine behavior. None of this adds value to the customer. Zero.

We need a protocol to handle any questions that cannot be answered by this document, of which there will undoubtedly be many. This is when we go back to the product owner.

The most important and widely socialized artifacts in a project will be those that can reduce ambiguity at any given moment. This pierces the control layer of burndown charts and taskboards and get at the truth of the project. The project results do not depend directly upon a chart or a user story. The results ultimately depend upon how the teams work together and how they understand the problem to solve.

Finally, the team needs to understand how to solve the problems with code. That is where the architecture comes in.

*note that “project” in this context is general, not in which it may mean a specific repository of code, like a GitHub project.

This is part two of three articles related to the foundation of a result-driven software development framework: Protocol, Product and Architecture (PPA).

Lucas Hendrich is an ITIL® Foundation certified technology professional and co-founder of gitbetter.io.

Click here to join our mailing list.