Every successful software development project I’ve ever worked on has had a Product Owner. They may not have been called by that exact title, but that was essentially their job. They were responsible for defining the product, prioritizing features, and answering the myriad of questions developers had as they built those features.
The Product Owner isn’t necessarily a technical role. In fact, in some ways it’s better if it’s not done by a technical person because it’s important to see the product from the user’s perspective. I know from my own experience that sometime my technical skills can get in the way of that. But even though the Product Owner isn’t a technical role, it is a critical and vital role.
One of the benefits of having a champion for the product with a clear vision of what the product is and how it should behave is that the team can then rely far less on written requirements.
Traditional requirements can consume up to half of developers’ efforts on a project. It takes a lot of time and energy to gather requirements, write up a document that describes them, and then have developers read, interpret, and act on those requirements. As you might imagine, this is also the largest source of bugs in any part of the software development process.
When we use traditional requirements we’re really setting ourselves up to fail because we’re defining a very complex system but our definitions really have no basis in reality—they come from our heads. And if you ask craftsmen in any other field,they’ll tell you that the process of construction teaches them how to make the right choices. When we develop code in a traditional way, where there are requirements that can’t be executed, we’re depriving ourselves of this vast source of knowledge and feedback.
There are certainly times when written requirements are appropriate, and there are certainly some kinds of software projects where, on a Waterfall approach, it’s the right choice. I’m really not an absolutist though sometimes I appear that way in writing.
In most situations, on most projects—and especially projects that are particulalry complex—it really pays to have a Product Owner or a product champion to streamline the development process, cutting out 30% to 50% of the effort upfront and removing at least that many bugs on the backend from misunderstandings in interpreting requirements.
Sometimes managers say to me that they can’t afford to have a dedicated person act as a Product Owner for the development team and I say you can’t afford not to. Development is insanely expensive. Most companies don’t realize that they spend a fortune on software development. Their salaries, office space, insurance, and a myriad of other things—let alone opportunity costs—all add up.
So when development is delayed or is inefficient, it profoundly affects a company’s bottom line and very often the managers on the front lines don’t recognize this is happening. It’s a classic example of penny wise and pound foolish and I’ve see it almost universally in the industry.
We are, after all, knowledge workers, and we can leverage our knowledge to be more effective and efficient. If you assume your skills or your team skills are stagnate then they will be. But if you recognize the power of the gray matter between your ears—and everyone else’s—then you can do extraordinary things. As managers it’s really our job to do this for our team, and not just because it’s better for the company but because it’s more fulfilling for the individuals, too, and if you can address fulfillment for the individuals in your team then you are a great manager.
The main job of the Product Owner, aside from defining the product and prioritizing the features, is to help the developers any way they can by removing impediments, answering questions promptly, working with other teams to coordinate dependencies, and supporting the team to do the right thing.
Scrum defines the two roles of ScrumMaster and Product Owner to almost be complementary to each other. The ScrumMaster is concerned about the health of the team and their sustainability. The Product Owner is concerned with the product. But a wise Product Owner is also concerned with the health of the team because that’s the engine that drives the creation of the product.
They’re also concerned with the quality of the whole product, not just features, because they recognize that the product must give value not just today but well into the future. And so they encourage the team to write good code that is supportable even if it takes a little extra time up front.
But the Product Owner is also where the buck stops. They carry the major responsibility for the definition of the product so if the team builds a wrong thing or builds the thing in the wrong order, it’s the Product Owner who often takes the heat for this because that’s their responsibility.
So the Product Owner has two aspects. On one hand, they’re the superstar, the champion for the product, and they drive the team to build the right thing. On the other hand, they are the single wringable neck, the person management blames if they get the product definition wrong.
If you’re a Product Owner then you probably don’t want to figure out your job all by yourself. There are standards and practices you should be aware of. It’s an important role and it’s fundamentally different than traditional product managers. All their skills on building complex spreadsheets and charts won’t really help you very much, but there is a wealth of information online on how to be a good Product Owner. It’s vital in Agile development and it can also be very useful even in traditional Waterfall development, even with requirements documents. It’s extremely helpful to have someone who truly understands what the product should be and can answer the many questions that come up during development that are never in requirements.
Scrum says that the ScrumMaster and the Product Owner should be different people and usually that makes a lot of sense, but I have worked on projects where the ScrumMaster and Product Owner was the same person and it worked out very successfully but I consider those individuals to be particularly enlightened. They cared about their teams and they cared about their products. There is a middle ground where both can be kept in balance, and this is an ideal place for the Product Owner to be.
Previous Post: « Smaller Tasks Have Big Benefits
Next Post: Assert Behaviors Through Acceptance Tests »