Feature Owner at Swile
Introduction
At Swile, a contributor does not have only the “Engineer” cap but also the “Product Manager” one. We are expected to articulate problems, requirements, proposed solutions, and measures of success. This is what we call internally being a Feature Owner.
This is not a common practice in French Tech companies, where this is usually the Product Owner’s or the Engineering Manager’s job. Swile management has implemented this practice for all engineering teams from the beginning.
In this article, we will discuss the benefits of such a practice, its limits, and its dangers.
Definition
As a Feature Owner, we own the feature (an Epic) selected by our manager. “To own a feature” means that we are in the driver’s seat from start to end.
We start by fully understanding and challenging the stakeholders’ needs before designing with them the best minimal functional solution. We can get support from the Product Team who has the business vision and will provide all the key elements to get the job done.
We look for existing projects or documentation that can help us design and develop the solution. We initiate an execution plan and challenge our vision with our team and the other company teams (DevOps, Staff engineers, etc.). We must write down and centralize all the information we have gathered in a public document.
Then, we write the user stories with an exhaustive functional definition without diving into the technical implementation. We also set the desired end state that needs to be achieved for the work item to be considered “done”. The implementation details are up to the contributor taking the ticket. We present the Epic to our team and ensure that it’s well understood by all teammates. Feature Owners and Contributors are not solely responsible for executing the work, which is a team effort.
We help answer questions about priority order, scope change, etc. and provide updates at team syncs. We continually evaluate whether we are working towards our key results. We also guarantee that deadlines and scope are respected. We ensure proper stewardship toward the stakeholders and create follow-up issues for any known bug.
Once the Epic is completed, we present the result to the stakeholders and take their feedback. Identified quick wins will be addressed in the next sprint, and evolution ideas will lead to potential new epics.
After the stakeholders’ validation, we do a demo of the functionality to the whole company and ensure that the rollout strategy is complete.
Finally, we wait for the first Customer’s feedback to identify if the goals were achieved. In addition, we may schedule a retrospective of the Epic.
Advantages
The main advantage of being a Feature Owner is that we meet many people within the company. Indeed, to be sure that the strategy meets all needs, the different business lines of the company must be involved: Product, Security, DevOps, Customer Service, Compliance & Legal, etc.
Being a Feature Owner is being an entrepreneur in a large structure. We are autonomous and free to approach the subject as we please. We have a global vision of the project and we can touch upon all the different products and technical aspects.
As a newcomer, being a Feature Owner for the first time allows us to quickly increase our skills from both organizational and communicative points of view. Our manager acts as a safety nest, allowing us to make mistakes and learn from them.
We can be compared to a sports coach. A tacit agreement is put in place between us and the contributors so that the latter progress as efficiently as possible on their tickets and that we are always available to help them. We generate adhesion and interest toward the feature, resulting in a good team spirit.
Finally, we ensure that all contributors are familiar with the product specifications and technical architecture of the solution, acting as an enabler. If we are absent for a few weeks, contributors will be able to solve by themselves any issue. This way, we empower contributors, letting them take initiative rather than waiting for the PM in case of an unexpected edge case, therefore, the Product Manager is not a blocker.
Disadvantages
The first Feature Owner experience is always difficult, we get scattered very quickly. We may have a hard time defining the boundaries of the feature we are framing. Having regular touchpoints with the stakeholder help us keep the goals in mind. At the same time, we need to specify what will be out of the scope and be able to say “no” to our stakeholders, in order to keep the feature doable in an iteration.
It can be difficult to have a clear understanding of which responsibilities belong to the Feature Owner or to the Engineering Manager. Who should take care of communication regarding the direction? Who should manage relationships with external partners? How do we deal with exceeded deadlines? All these questions can be confusing.
In a large company with many departments, like Swile, it can be difficult to identify which teams will be impacted by the project and who to contact to get the relevant information. As a newcomer, it can be very intimidating at first.
Finally, the Feature Owning experience will vary from one to another, some will have better soft skills and project management knowledge, and others will have to step out of their comfort zone to upgrade those skills. We also need to be able to take a step back to question the path we have taken and accept that we may have gone the wrong way.
Conclusion
Although it might be difficult, especially when projects do not have well-defined goals, being a feature owner is a very rewarding experience. We become closer to the product, meet different profiles and improve our project management skills. Contributors become responsible and will improve as Feature Owners through their experiences. Be careful of course to mentor well the juniors so that this experience will not perturb them so much.
Thanks to Pierre Mary for reviewing the article.
