Not all product teams are created equal.
The reality is, when a company is building tech products, there are three types of product teams it might have: product teams, feature teams and 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.
We recently hosted a Q&A Breakfast with Marty Cagan, author of “EMPOWERED: Ordinary People, Extraordinary Products”, a partner at the Silicon Valley Product Group and a former product leader at eBay, Netscape and HP.
He explained the thinking behind one very simple truth:
To explain how important they are, let’s first take a look at the different types of team you can have:
The most common teams are not really product teams at all, they are delivery teams, aka “dev teams” or “scrum teams” or “engineering teams”.
A delivery team comprises a backlog administrator (product owner) and developers who are focused on delivering output.
There’s no real drive to push true, consistent innovation for customers.
Feature teams are all about output. They are told which deliverables (typically features) are expected, and will generally do minimum product discovery work.
The 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 outputs, 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.
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 should be held accountable for the results.
Importantly, 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.
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.
The biggest difference between the three types of teams comes down to how they manage risks.
A successful product is valuable, usable and feasible. Will people buy it or choose to use it? Will people be able to work out how to use it? And can the product be built with the time, skills and technology you have?
There’s also a fourth key risk: business viability. Will the solution work for the business?
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. However, there is nobody in the team explicitly looking after 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.
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 they considered it to be a job done.
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 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.
When accelerating with a development partner, are you asking the 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 deliverables to output or problems to solve.
Often when businesses decide to accelerate development, they tend to augment their existing teams with development teams. These teams build what they are asked, focusing on outputs without the context or agency to drive the outcomes that constitute product success. 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.