When to Build New Features
19 August, 2021
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.
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.
- 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.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
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.
Engineering Manager - Patient Experience at Curative
Alexis Philippe, Vice President, Product & Engineering at Amilla, describes his one simple rule for creating a culture of helpfulness that doesn't disrupt productivity.
Vice President, Product & Engineering at Amilla
Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.
Senior EPM/TPM at Apple Inc.
Tom Hill, Engineering Manager at Globality, Inc., describes his decision-making practices when making architectural decisions.
Engineering Manager at Torii
Pavel Safarik, Head of Product at ROI Hunter, shares his insights on how to deal with disagreements about prioritization when building a product.
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.