Preface

Many of us who are software engineers or product managers spend our time developing and promoting a product. Most likely, we have called our team, which consists of software engineers, product managers, designers, testers, etc., as the product team. But in many cases we are not the product team, we are the feature team. What is the difference between these two? How do we know which one we are?

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. 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.

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 to be built are handed down by executives.

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. 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.

It’s all about solving problems, not implementing features. (Marty Cagan – Inspired)

Product Team’s key characteristics

The Product Team has 3 core characteristics:

• Firstly, the Product Manager gives the team a problem to solve.

• Secondly, the Product Manager and the company empower the team to solve this problem in the way they want.

• Thirdly, as a consequence, the team is accountable for the result.

In a nutshell, there is a switch of mindset in a Product Team: the team thinks like owners, not like employees, so they take the responsibility for the outcome, rather than just the output by delivering feature.

What Does a Product Manager Do In a Features Team?

In this setting, a product manager/product 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 figures out how those hands can do the work without tearing their hair out.

Mercenaries build whatever they’re told to build. Missionaries are true believers in the vision and are committed to solving problems for their customers. (Marty Cagan – Inspired)

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.

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 need truly cross functional and powerful product teams.

Visit Marty’s article for more information.

photo by Austin Distel