The Danger of Building Feature Teams, Not Product Teams
Don't be a feature factory
Happy Friday, Product People! Carlos here, here to talk with you about what it means to lead a ‘feature team.’ It’s not pretty, and it’s not Product Management. Let’s dive in to how to avoid it.
With so many new and promising technologies, it's easy to present idyllic view of the tech landscape. In this Dream Product World, every single company out there has invested in a good Product Management Team, is paying attention to customer needs, and everyone is working cross collaboratively.
While the needle is moving in the right direction in terms of companies adopting more modern software development practices, and Product Management is more in-demand than ever, it’s not entirely a bed of roses.
One trend that happens far more frequently than we’d like, is that companies find themselves building feature teams, not Product Teams. This happens when executives only half-invest in new Product methodologies, and give teams only half of the power they need to build customer-focused products.
Product Teams vs Feature Teams
Let’s understand the main differences between the concept of a Product Team and a features team.
The Product Team we should all be striving to build is one that works cross-functionally, with all disciplines working together to help reach short term goals that fit into long term plans. Product designers, engineers, and marketers work together and are empowered to make their own decisions and suggestions.
You might also be interested in: Empowering Your Offshore Team is a Part of a Diversity-by-Default Approach
In this type of team, the Product Manager plays a critical role in acting as a diplomat and translator between these disciplines and C-Suite.
Of course, every Product Team looks a little different across different companies. This might be in terms of methodologies used, the ratio of engineers to designers, the number of Product Managers, etc. There are many ways to structure a Product Team. But at their core, Product Teams should be working cohesively and autonomously towards a shared product vision, guided by Product Management.
At least, that’s the idea.
Sometimes the teams that actually end up being built are what Marty Cagan refers to as ‘feature teams.’ Instead of figuring out how best to solve customer problems through thorough research and cross-collaboration, features are handed down by executives and teams are expected to build them.
This means that the features team doesn’t actually come up with the solutions to the customer problems. Rather, they exist to build what executives tell them to do. This makes them more focused on outputs over outcomes, working just to get tasks ticked off the roadmap, without having the creative freedom to discover potentially better solutions.
What Does a Product Manager Do In a Features Team?
In this setting, a Product Manager/Owner finds themselves working more as a Project Manager.
Where they’d usually be valued for their understanding of the customer and their ability to make important product decisions, in a features team, their skill set is used a little differently. They help other team members to meet executives expectations by managing the workflow, and acting mainly as a diplomat between execs and teams.
Essentially, leadership handles the big picture thinking and the teams (scrum teams, dev teams, whatever they’re called in a particular Product Organization) are simply the hands that do. And so a Product Manager works in more of a Project Management function, and focuses on using their hands to work instead of to tear their hair out.
Why Does This Happen?
It’s hard to say exactly why this happens, because every company will have its own reasons for going off the rails like this. But here are some educated guesses:
The shift to feature teams instead of ‘true’ Product Teams is symptomatic of a lack of trust in employees. You might have hired a designer, but you don’t think they’ll understand your customers enough to know what to build, despite user research being a core component of any designer’s toolkit. Your Product Manager might have years of experience in feature discovery, but you’ve already decided what to build, and you don’t want to be told otherwise.
It could be something that you’re not conscious of. It’s possible to believe you have full faith in your teams, but if you examine your communications and the flow of work, you find you’ve been more dictatorial than you’d intended.
Another root cause of the problem is your stakeholder/shareholder relationships. If you have a tough time saying ‘no’ to those at the top, that’s going to filter down into needing to make unreasonable requests of your team on the ground.
What Are The Consequences?
Not building the right thing
Your designers know how to design, and your engineers know how to build, and your Product Managers know how to guide development. You need to let them decide how they should work, otherwise they won’t be building the right thing, for the right people.
Usually, in a ‘true’ Product Team, the teams will be able to tell you the why behind everything. The engineer will tell you that this information architecture works for XYZ reasons. The designer will tell you that this button looks a certain way because they tested several versions and this is the one that converts.
You’ll often find that in feature teams, if you ask them why anything is happening, the answer will be ‘because that’s what management wants.’ That’s no way to build the right thing.
Losing out on talent
In this environment, you won’t be able to retain the talent you hire. Product Managers who are hired to work as Project Managers don’t tend to stick around for long. The same goes for your designers, who won’t feel much more empowered than interns if you’re there directing them to design things the way you want them done.
The same goes for pretty much anyone in your team. They’re professionals who were hired to do a job that you’re only letting them do 50% of. Not only are you wasting their talents (and therefore your money) but you’re also wasting their time. Companies waste a lot of resources when they’ve got a revolving door of employees coming and going.
You might also be interested in: Why Do Product Managers Quit?
Teams have all of the responsibility, and none of the power
This is a very common joke in Product Management, as PMs shoulder a lot of responsibility for the success of a product, without the formal authority of telling people what to do. But they do play an important role in directing and owning the Product Strategy.
What happens with feature teams is that they have no say in what gets built, but the blame lands fully on them when it doesn’t live up to the executive’s expectations. If it can’t be built on time, blame is placed on the engineers, even if they warned you it wouldn’t be possible. If the users echo your designers sentiments, that the design is confusing, somehow the designer still usually shoulders the blame.
You don’t want to sow those kinds of seeds in your team.
What’s The Solution?
The solution is twofold. Training, and trust. What comes first is very much a chicken and egg situation. You need to trust your teams to be worth the investment of training, and training helps build trust in teams, and so on.
Trust starts with your hiring practices, by making sure that you’ve brought the right people on board. Training starts when you decide that to move forward, you'll build truly cross functional and powerful Product Teams.
Don’t forget to check out some of the previous issues!