The 3-month experiment turned into how things roll around here. And these have been the happiest, most productive two years of my professional career. Even with the fact that I've now also become the reluctant manager trying to understand why managers were ever needed and how that could become untrue again.
The first impacts of No Product Owner were evident and easy to see:
- Developer motivation through ownership. Feeling you don't need permission to do what you know is right did wonders to what we got done.
- Emergence of monitoring. We refused to rely on feedback from those upset or active, and wanted to see the feedback in scale, even when the users were not pushing through all the obstacles to get the message to us.
- Owning up to all things maintenance. We opened our ears to hear what they said about us. We weren't picky on the per-process channel, but focused on hearing and understanding, and dealing with it as soon as we could.
- Frequent software delivery. Making a release was our choice. We paid attention to the costs of it. We released more frequently, collecting less stuff on the shelf.
- Unfiltered developer - end-user and 3rd party communication. Solving hard to solve problems in debugging calls, getting other 3rd party devs to understand the right details, and not needing to remove the damage filtering can do on understanding end user needs.
- Implementing beyond own "box". We'd use the internal open source model to implement things truly end to end so that "done" became something that was in the hands of our real end users.
- End-user documentation turned part of product. We started writing end user documentation, targeting our release notes as useful communication and working with marketing to highlight themes that had been bubbling over a longer time.
- Discovering features never requested (measured useful). We would listen to problems not just as bugs to fix but as opportunities of designing better features.
At two years, I'm starting to look at the places where the No Product Owner approach is breaking for us. I currently model this as three levels of signals, where some we are able to work with and others need something we don't naturally have.
- Loud signals. Hearing what people say is not that difficult. It even works that they say it to any of us, and any of us deliver the message further in the team. If someone has a clear idea of a feature and they ask for it, this comes through loud and clear. If someone has a problem with out product and they figure out that it indeed is a problem and contact us, it comes through loud and clear.
- Medium signals. These are signals that already require some amplifying for them to turn into action. Like a badly written bug report from end users. Or need to create a monitoring view that shows a trend. We've improved in dealing with this a lot over the two years, and it looks to be an area that will grow.
- Low signals. This requires so much work, that we may need to bring back a product owner role just to work on this. It is easy to miss relevant things that we should be acting on, because work required to make the information actionable requires significant amounts of work. Be it the "this feature isn't really very good" and making that into ideas of how it isn't good and what we could do to make it better, or seeing and innovating technologies that would change how we see the playing field.
It just might be that that is what we'll ask the product owner to be, or that is what I find my role growing into. Time will tell.