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

Myth Busting

10 December

Supporting principles on why being data led (not driven) helps with the story telling.

Alignment
Managing Expectations
Building A Team
Leadership
Collaboration
Productivity
Feedback
Psychological Safety
Stakeholders
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

DevSecOps: Why, Benefits and Culture Shift

29 November

Why DevSecOps matter and what's really in it for you, the team and the organisation?

Innovation / Experiment
Building A Team
Leadership
Ownership
Stakeholders
Cross-Functional Collaboration
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

The Growth Mindset in Modern Product Engineering

28 November

The impact you can have with a Growth Mindset' and the factors involved in driving orchestrated change.

Building A Team
Leadership
Collaboration
Feedback
Ownership
Stakeholders
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

How to measure Engineering Productivity?

30 November

When you grow fast, its normal to focus on Value delivery aka "Feature Releases". Too many releases too soon will inevitably lead to piling tech debts and before you know, inefficiencies creep in, performances goes down, and ultimately any new release takes too long. Sounds familiar? Then read on..

Productivity
Prioritization
Performance
Ramkumar Sundarakalatharan

Ramkumar Sundarakalatharan

VP - Engineering at ITILITE Technologies

How to improve engagement and retention in remote engineering teams?

25 October

Mrunal Kapade, an Engineering leader, based in Silicon Valley, shares tips that helped reduce attrition in the remote engineering teams while leading multiple teams from startups to Fortune 500 companies.

Remote
Company Culture
Collaboration
Motivation
Team Processes
Mrunal Kapade

Mrunal Kapade

Director of Engineering at Inspire Energy