Not all teams are created equal. When a company is building tech products, there are three types of product teams it might have:
- Product teams
- Feature teams
- Delivery teams
At a superficial level, they might seem the same. After all, they all deliver products, right?
But there are distinct differences in the way the teams are set up and empowered to make decisions that will ultimately determine whether the product succeeds or fails.
To explain how important they are, let’s first take a closer look at the types of team:
Delivery Teams: The most common teams are not really product teams at all, they are delivery teams, aka “dev teams”, “scrum teams” or “engineering teams”. A delivery team comprises a backlog administrator (product owner) and developers who are focused on delivering output. Requirements which are often well-defined upfront are handed over to the team and the focus is on delivering those requirements on time and on budget. There’s no real drive to push true, consistent innovation for customers.
Feature Teams: Feature teams are all about output. They are instructed which deliverables (typically features) are expected, and will generally do minimum product discovery work. Deliverables are usually provided to the team by executives across the business in the form of a prioritised list, aka “roadmap”. This means feature teams have a low sense of ownership over the outcome, and can’t be adequately held responsible for the results. If your team is really just managing a backlog of requests, it’s probably a feature team.
Empowered Product Teams: Product teams are focused on and measured by outcomes, rather than output. Rather than being given exact deliverables, the team is asked to solve problems and has strategic context. This means they are empowered to figure out the best way to solve the problems, and are accountable for the results. Empowered product teams include a product manager who provides the much-needed context for team members. That context forms the basis for thousands of micro-decisions made by a diverse mix of team members as they work to deliver product-market fit.
The most important difference between product, feature and delivery teams
Building products that achieve product-market fit is tough. If the team building the product is not set up to solve problems, innovate and address the risks, the product is more likely to fail.
One of the differences between the three types of teams comes down to how they manage risks. What do we mean when we talk about risks?
Consider the four key elements that make a successful product:
- Valuable: Will people buy it or choose to use it?
- Usable: Will people be able to work out how to use it?
- Feasible: Can the product be built with the time, skills and technology you have?
- Business viability: Will the solution work for the business? What is the ethics risk – should you build it?
In any team, different people have responsibility for ensuring each of these factors does not become a risk.
In a feature team, it is the designer’s role to ensure usability, while engineers are responsible for ensuring feasibility. The person called a product manager is typically just herding the cats and providing a backlog. Importantly, in a feature team there is nobody in the team explicitly taking responsibility for value and business viability. That comes down to the executive who requested the feature on the roadmap. If the executive says they need the team to build a feature, it’s because they believe that feature will deliver value and is viable for the business. However, this can cause problems down the track if they do not take responsibility when the feature hits the market and doesn’t deliver product-market fit.
In a product team, value and viability are the responsibility of the product manager.
That’s how empowered product teams reduce your risk of failure. An empowered team will make hundreds of decisions each day as they build the product and every single decision is reducing the risks of failure – they are not blindly following instructions and delivering what was asked in letter, but not in spirit.
By contrast, delivery teams rarely have control over any of the risks. Often, the design and key technical decisions lie with external design and architecture teams. Their goal is to focus on delivery in the allocated time.
Example: Empowered Product Team vs Feature Team
One of Propel’s early projects was to develop an employee payroll app to allow employees to add their hours to a timesheet. The executive gave the team instructions to “create this pre-designed specific workflow which lets me, as an employee, punch in and record my hours”
So that’s exactly what the team did.
They designed and developed the workflow to achieve what the executive asked, and the executive considered it to be a job done. However there were a bunch of use cases which were not considered in the request from the executive which unnecessarily narrowed the audience for the feature.
How would an empowered product team do things differently?
An empowered product team would have been given broader context which would enable them to include a broader range of important requirements that an executive is likely to miss.
For example, they could ensure the design worked well for a broader range of employee use cases, such as where only part days were worked or where people worked past midnight and the dates when the employee started and stopped work are different, and when the user is visually impaired.
If the team is able to take the initiative to identify and incorporate these considerations early, they can build them into the design to cater for the needs of the variety of users, sometimes without any additional cost and avoiding rework.
Recap: Why you really need empowered product teams
Empowered product teams are given problems to solve. Engineers and designers are asked to step up and not just design and code, but actually come up with the right solution. A team that is entrusted with the product is highly motivated to achieve both business and customer outcomes and will provide a better solution and enjoy their experience at work more.
How to accelerate your development and innovation with Propel product teams
When accelerating with a development partner, are you asking your partner to operate as a feature team or a product team?
Remember, one of the major differences between a feature team and an empowered product team is whether they are tasked with the delivery of specific features or being tasked with the context of a problem to solve.
Often when businesses decide to accelerate development, they tend to augment their existing teams with feature teams or development teams. These teams build what they are asked, focusing on outputs without context or agency to drive the outcomes that are needed to achieve product success. Whilst the feature may be delivered as requested, this often leads to suboptimal outcomes or, worse, product failure.
A better way is to find a strategic product development partner like Propel that has the skills and capabilities to add empowered product teams. These teams have the product, design and technical leadership required to ensure the right product is delivered – even if that ends up being a little different to what you initially expected or asked for.
