The fall of our product manager
Our process has evolved over the years as we’ve tried a bunch of different things and constantly improved how we work together.
At the beginning of our product, we had a dedicated product manager. After they left, this role was filled by either the company leads or a new product manager who joined the company. Unfortunately, this never worked out because the product manager always knew less than the development team that built the product. So, in the end, this responsibility fell to the company leaders until they also left and only the development team remained. Everyone started pitching in and helping out with tasks that were previously handled by the product manager.
During one of our retrospectives, we came up with the idea of a temporary product manager role. This role is designed so that anyone who feels ready can become a feature owner in addition to their regular role.
The complexity of product development
Over time, we added some other temporary roles, like the technical coordinator or the release commander. Each of these roles has specific responsibilities that depend on the phase of the feature. Our process is still being improved, but the basis of it is now very stable. Not everyone enjoys taking on these roles, as they can sometimes be outside of a developer or designer’s comfort zone. However, it provides everyone with the opportunity to at least try it out with a strong support system behind them.
Feature Owner as a Visionary
A feature owner’s main responsibility is to come up with a vision for a feature. The details should be worked out by the experts who will be working on it. The feature owner doesn’t decide on the design or the technical implementation plan. They are there to create a guide for the different development teams so that everyone is working towards the same goal.
A feature owner needs to talk to all the stakeholders to gather all the information they need to create a concept that fits with the overall product vision, which is set by the product leads. This sounds easy, but it can be difficult for a developer to not base their decisions on an implementation idea or for a designer to not base their decisions on a design idea.
A vision shouldn’t be restricted too much in the beginning. You need to figure out what is actually wanted first, and then you can reduce it based on factors like limitations of the existing product, technical feasibility, or development time. But if the original vision is clear, it gives the team the opportunity to maybe get closer to it at a later point.
Once the vision is established and the concept is finalized, it’s time to get everyone on the same page. The concept document is our core place in which the feature puts the concept and its vision into words. The document itself has a fixed structure to enable everyone to find the information that they need faster. Our concept documents are always accessible to the whole team, and many of them help the feature owner improve the concept and the description of it. When development starts, it’s important to make sure that everyone has the same idea in their heads, not just that they’ve read the document. This is where the technical coordinator comes in.
Technical Coordinators provide grounding
The technical coordinator is the opposite of the feature owner. While the feature owner is trying to do the best for the outside perspective of the product, the technical coordinator focuses on the inside, keeping things simple and stable. So even though the feature owner is sometimes a developer and could also be the technical coordinator, we make sure that the same person never has both roles for the same feature.
The role of the feature owner ends in the release phase, because the analysis of the feature itself is handled by our product analysts. We tried to make the feature owner the driver behind the analysis for a while, but the problem was always time. Analysis tends to happen quite a while after the release, and by that point the feature owner is already focused on something else.
As the team matures, our process will continue to evolve. We invite you to share your questions and comments with us at welovedevelopers@platogo.com.
by Dominik Go
