Why you need to have strong product ownership
On having a clearly defined vision in product development.
Lens (source: Pixabay)
A software product is often thought of as a collection of features built for a particular purpose, but that is only the tip of the iceberg. Below the waterline, we find that software is only an artifact–the output of a process that connects a product designer’s vision with those who might benefit from their work.
To anyone who has not successfully designed a product before, vision is a mystical concept. It’s something that gets chalked up as a natural talent by some and as pure luck by others, but neither perspective is accurate. Vision is nothing more than a decision making framework that allows a product designer to narrow the problem space that lies between them and their goals.
Learn faster. Dig deeper. See farther.
In many projects, ideas around how decisions are made stay locked up in the head of a single designer, or at least in the tacit knowledge of the team they’re leading. This is dangerous territory, because rapid shifts in external conditions on software projects are common. When an unwritten rule changes, it’s hard to say whether the rule was ever really well defined at all.
By contrast, explicit guiding principles serve as an anchor in turbulent times, and a guide star in times of active exploration. A well-defined vision tells the designer what to say yes to and what to say no to–what can be sacrificed and what is worth sacrificing for.
Why is strong product ownership important?
When a product designer clearly communicates the heading of their internal compass, expectations are set for everyone else involved in their projects. Although this can have a polarizing effect, it’s generally better to learn up front that a particular product is not meant for you than it is to figure that out long after you’ve put some major investment into it.
These points are well understood in the world of product development, but they are a source of tension pretty much everywhere else. The typical user, customer, client, investor, executive, salesperson, marketer, help desk worker, tester, graphic designer, UX designer, and even software developer are not trained in the art and science of product ownership. It is a skill set unto itself.
As actors in the awkward dramatic play that is the software industry, we disagree… often. Each of us believes that we see things clearly from our own vantage point, but in the end, we are acting out the parable of the Blind men and an elephant. We talk past one another and often miss important details because they simply do not appear within our field of view.
Because software developers are the ones who actually implement products, they exist on the critical path that lies between a concept and its reification. If there isn’t strong alignment between a product designer’s vision and the software developers that implement it, Bad Things Will Definitely Happen.
The promise of clear communication about a designer’s goals is that it makes strong alignment possible, which in turn leads to better software.
Ruby on Rails as a case study in strong product ownership
The design of the Rails web framework is unapologetically tied to its suitability as a foundation for the development of Basecamp, the product it was extracted from in the first place. The project may have thousands of open source contributors, but in the end, it is measured first and foremost by how well it fits the needs of its founder.
This connection goes beyond raw technical concerns. Rails is also intrinsically linked to the particular tastes and sensibilities of the team that develops Basecamp, with David Heinemeier Hansson (DHH) serving a leading role in those decisions throughout the entire history of its development.
This creates an interesting dynamic for the project, because it means that if your technical problems are similar to those found in Basecamp and you have similar design tastes as the team that develops that project, you’ll find Rails to be a perfect fit for you. For everyone else, your mileage may vary.
Because many people do have problems that are a good fit for Rails, it has become a massively popular web framework. Even outside of the perfectly matched use cases, there are plenty of teams that find shoehorning Rails into their development process to be cheaper and more comfortable than the alternatives.
And then… there is everyone else. Some happily use alternative tech stacks and never bother to give Rails a second thought. But others feel outraged at how much influence Rails has had on the web development world, and will stop at nothing to point out its flaws.
This stratification is the essence of what happens in projects that are guided by strong product ownership principles. Whether that generates more heat or light depends entirely on how clearly the designer’s intent is communicated.
Learning a thing or two about product design from the Rails doctrine
In an apparent attempt to settle any questions about DHH’s vision for Rails once and for all, the project now has its own official doctrine.
Like many things around Rails, the doctrine has been met with a mixture of disdain, controversy, and delight. It is polarizing, and it is written in high-handed rhetoric fit more for an impassioned pastor’s sermon than for the leader of one of the world’s most influential technical projects.
And it’s not just the style of the Rails doctrine that many developers take issue with, it is the pillars of Rails themselves that are subject to intense scrutiny at the technical level. Most developers will find at least some of the ideas to be admirable; few if any will accept the whole set as canon no matter how much DHH preaches the gospel.
The controversy around the Rails doctrine is predictable. That said, even the most stubborn opponent of the Rails way cannot deny two fundamental truths about the framework: It has had a tremendous influence on our industry, and its core values are well defined.
Are those two things essentially tied together? Perhaps not. But it is probably safe to assume that they’re not totally coincidental, either.
If you can read between the lines, the Rails doctrine is a master class in what it means to be serious about defining a vision for a product. It tells us not just what guiding principles form the basis for the product designer’s values, but why they’ve been selected, and what motivated those decisions in the first place.
No matter what you think of DHH or Rails, the fact that the framework has a doctrine at all is worth thinking about. If you’re even remotely interested in product development, be sure to dig in and see what you can learn from it.
Editor’s note: Gregory is working on a book about the non-code aspects of software development, called Programming Beyond Practices. Follow its progress here.