Back to resources

When to Build New Features

Mission / Vision / Charter
Collaboration
Cross-Functional Collaboration
Prioritization

19 August, 2021

Florian Marin
Florian Marin

Software Engineering Manager at Teads.tv

Florian Marin, Senior Software Engineer at Teads.tv, shares how new features can be added to the roadmap and what works best for the end-users.

Problem

I ran a team that was delivering top-notch features pretty fast. The problem arose when we realized that our customers were not using those features. Naturally, it led to team frustration; they worked on a feature for about 2 - 3 months; that is great, but not everyone uses it. The worst part? We don't even know why. I focused on these aspects to transfer my team from a delivery team to a product team. It was essential to make features that were not only used by our customers but also solved their problems.

To break down more about the team frustration, some of the team members were tech-oriented and wanted to deliver high-quality technical features that were scalable. It is unfavourable to work on something and then move on to something else, and a year later, coming back to work on the first thing. In the meantime, some leave the team because they don't feel recognized, whereas it has nothing to do with what they ship.

Actions taken

My first take on this situation was building a flawless relationship with the PM and UX designer. I must admit that my business knowledge was not perfect, for which I could not convince my PM as to why I think a specific feature was necessary and why it was not significant. I wanted to improve the business through the edge and slowly explain the problems we tried to solve to my team members. Hence, I had grown a strong relationship with the PM.

I conducted weekly meetings to discuss the technical aspects we were working on. Also, I prepared discussions on what we were going to work on next; even if it meant solving a problem 一 not a technical issue or a feature 一 we would find a structured approach to work towards it.

After everything, we defined a vision. It would help us figure out what was the problem, and where we wanted to go with the problem. Once we had all of those, we would present that in front of the team to find a solution. We needed to work with hypotheses and not on strong beliefs.

When we released a feature, we wanted to know the number of people using those features, why they were using them, etc. This would be our way to measure everything. Besides, it would provide us with some qualitative and quantitative feedback, further helping us to know if we should spend more time on the feature. If the answer was yes, we had to figure out the following steps, and if no, we should not waste our time on it anymore.

Measuring everything from the technical and product perspective would reduce complications for the future. Google Analytics and some other external tools were of great help when it came to this. We could finally figure out that 10 people clicked or viewed our feature. Something more specific that we implemented on our website was a data pipeline, which collected information and stored it in a database that we used as a tool to visualize it.

On top of that, we wanted to keep things agile and work by iteration. If one of the priorities changed, we could switch easily by releasing a small iteration and have less frustration among team members. The agile process was essential to keep the processes straightforward; test, learn and fail fast.

Last but not least, I stopped building a roadmap for the longer term. Previously, I used to create a well-defined roadmap for 2 quarters, but I didn't do it anymore as soon as I learned my lesson. I realized that it was not feasible to create a roadmap for such a long term in our industry because something changes every day. We had a vision roadmap for a quarter, but I did not put too much detail into it. I would only have a general outline, and later the team would decide which subjects were necessary and how to define them.

Lessons learned

  • Make sure that the team understands the goals. That would help them perceive their responsibilities and know what others (or the rest of the group) are working on alongside them. No one should feel burdened by a team's objectives.
  • In a fast-paced company environment, create a shorter yet strategic roadmap. It should include the major milestones and steps needed to reach a goal, but nothing too comprehensive. It should work as a document to help articulate strategic thinking.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Managing Different Time Zones: Inclusive Collaboration Methods

19 May

Jonathan Belcher, Engineering Manager at Curative, shares an unknown side of synchronous communication tools and advises managers on how to handle a team that’s spread across the globe.

Remote
Internal Communication
Collaboration
Cross-Functional Collaboration
Jonathan Belcher

Jonathan Belcher

Engineering Manager - Patient Experience at Curative

Creating a Company Culture That Balances Helpfulness and Productivity

16 May

Alexis Philippe, Vice President, Product & Engineering at Amilla, describes his one simple rule for creating a culture of helpfulness that doesn't disrupt productivity.

Mission / Vision / Charter
Company Culture
Collaboration
Cross-Functional Collaboration
Alexis Philippe

Alexis Philippe

Vice President, Product & Engineering at Amilla

Streamlining Product Processes After a Reorganization

16 May

Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.

Acquisition / Integration
Product Team
Product
Building A Team
Leadership
Internal Communication
Collaboration
Reorganization
Strategy
Team Processes
Cross-Functional Collaboration
Snehal Shaha

Snehal Shaha

Senior EPM/TPM at Apple Inc.

How Less Viable Solutions Solve Common Architectural Challenges

13 May

Tom Hill, Engineering Manager at Globality, Inc., describes his decision-making practices when making architectural decisions.

Architecture
Different Skillsets
Conflict Solving
Collaboration
Tom Hill

Tom Hill

Engineering Manager at Torii

Navigating Disagreements When It Comes to Priorities

9 May

Pavel Safarik, Head of Product at ROI Hunter, shares his insights on how to deal with disagreements about prioritization when building a product.

Innovation / Experiment
Product Team
Product
Dev Processes
Conflict Solving
Internal Communication
Collaboration
Convincing
Strategy
Prioritization
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.