There are many types of teams and cultures that exist inside of businesses which utilise groups of software engineers/developers. Over the past 10 years I have experienced many of them so today I thought I would write about what are, in my opinion, the most common 2. Then finish with why 1 of them is my favourite.
To clarify these types of teams can be found in any company which uses technology, regardless of whether the end product is software-based (SASS) or if it is targeted directly at customers or businesses (i.e. B2B or B2C).
The Feature Team 🛠
Features teams typically consist of:
- 1 project manager
- 1 designer or UX specialist
- 2-10 developers or testers
They are given a roadmap laid out by senior project leaders and they take responsiblity for building it. There is freedom in how they execute the features and projects.
Their primary focus is to delivery features and projects.
The Product Team 📊
Product teams consist of similar members but with a slight difference
- 1 product owner -> note the difference
- 1 designer or UX specialist
- 2-10 developers or testers
If the team contains many more members than this then the team begins reaching critical mass.
Product teams are given a business problem to solve, not a roadmap. These problems usually come from a "Product Strategy"
They are measured by their business results, so there is a lot of pressure to ensure their chosen features and projects help the customers and the business.
Their primary focus is to help the business grow and have a bigger impact.
What kind of problems do Product Teams solve? 🤔
We are talking about very common and high-level businesss problems, such as:
- How can we increase revenue?
- How can we decrease churn rate?
- How can we increase customer acquisition?
- How can we increase customer retention?
The team is empowered with finding the best way to solve the problem at hand. It is not unusual for the team name to be a word which relates to these questions e.g. "Acqusition Team" or "Retention Team".
Phases of a Product Team
There are typically 2 phases that a product team can be found in at any given time and they are interchangeable.
Both are essential and require the entire team to give input.
1. Discovery phase 🔍
The team are collaborating and working through one of the problems with the goal of coming up with a physical feature or project. This is where real innovation comes in.
It is worth noting this is usually quite hard to do at home and relies on very good team relationships to do remotely.
2. Delivery phase 🚀
So once a feature or project has been chosen, this is the phase dedicated to writing the code and shipping it.
Unlike the discovery phase this functions very well remotely although good team communication is still vital to an efficient delivery.
The "Product Strategy" 📜
Dictating the problems a product team should solve is usually the "product strategy" (it is not essential though which is why companies often ignore it).
The "product strategy" takes the high level goals of the business (there might be alot) and helps FOCUS them into a couple of key points. Without this focus it is hard to know exactly which goal to spend resources on this quarter. Trying to hit 2 has a higher chance of succeeding than trying to hit 7, as the below quote I came across many years ago explains.
"The key to product is what you don't do"
Each strategy item usually has an OKR to help define what the objective and target is with it.
Types of engineers: Rockstars 🤘 vs Superstars 💫
Something I thought was worth touching on is my feelings on Rockstars vs Superstars. I generally find software engineers fall into one of those titles.
Superstars are usually good at most things and they like to try new things.
Rockstars are amazing at one thing in particular and usually do not like to try new things.
I generally find that Rockstars fit well with a Feature team, whereas Superstars fit better with a Product team. Although both can do equally well in either type, it all depends on whether the engineer enjoys being involved in solving problems rather than shipping features.
Summary
I am a big fan of the Product Team. Of having ownership over a commercial business goal and having to solve problems which will help move the business forward and ultimately exist outside of the tech world. I love writing code but I want the code I ship to have the maximum impact it can because developer time is not cheap (I do not mean that in an arrogant way but from a business resource perspective).
I think the question is not "Which type of team are you in?" but "Which type of team do you want to be working in??
I hope you found this article useful. Please email or tweet me if you have any thoughts about the Product vs Feature team topic.
Thanks