MARTYHAUGHT

In the early years of my software career, I worked in larger organizations where we had different groups of developers along with non-technical teams working collectively inside formal processes. Imagine some form of waterfall process where you had an architect group backed by business analysts, multiple teams of software engineers, and a quality assurance team all watched over by a group of project managers. It was slow and inefficient at delivering the software that business needed. During the late 90s and early 2000s, it was all I knew.

Fast forward a decade later and now I exclusively work in small, cross-functional teams that are fully self-contained. We ship software lightning fast, can react to change requirements overnight and are incredibly efficient.

However, one weakness that I’ve observed lately is when the client doesn’t own the traditional product owner role fully. It seems odd that this would happen but on two recent projects I noticed a trend where the client wasn’t interested in completely steering product development and/or user experience. It could be that they felt comfortable with how our team at Haught Codeworks was handling both pieces. Or maybe past experience with traditional web consultancies led to bad patterns of interaction.

When the client doesn’t fully own the three areas of product development, UX and QA it leaves a vacuum. It’s rare that software engineers will think of these aspects on behalf of a client. If a client asks for feature A, we assume they know what they’re asking for and will verify after we ship the feature that it meets their needs. When a client doesn’t take product ownership, features sometimes get built in a way that isn’t ideal for the user experience. With no one thinking of the bigger picture features are built with a lack of context and assumptions go unchecked. Who’s to blame in those cases? Ultimately both sides are and given that a software consultancy should be the expert on shipping quality software, it’s become clear to me that we need to guard against this. The product needs an advocate, even if it requires the team to adopt that role.

The trick is, who owns this piece on a small team? In a perfect world everyone on the team would own product development. In practice it’s not realistic to spread this responsibility across the team. Product development is very time consuming when done properly and it’s not something I want to leave for the team to ‘sort of’ provide in an ad-hoc manner.

My thoughts lately have shifted. What if I had one person own these three roles? First, product development would focus on representing the user and making sure the client understood how best to build the software to meet the user’s needs. This person could dig a bit deeper than clients might on their own and really get the product moving in the right direction, long before any code has been written. UX could be properly handled up front with usability having a dedicated champion as features are planned out and tested. Finally, they could do the last check of finished features to make sure they match the intentions of the product owner and provide a good experience for the users. It’s hard for engineers to reliably verify their own work, so this also functions as a second set of eyes to test a feature before the client ever gets to see it.

I haven’t heard of anyone mixing there three facets of product ownership into a single person’s set of responsibilities. Is it too much of a stretch? Any other gotchas? I am curious what others have experienced in this space and if they are starting to see value in this sort of thing for smaller teams. Finally, I’d like to add someone to the Haught Codeworks team in this capacity. If you or someone you know might be interested, reach out.

blog comments powered by Disqus