After reading my last article on the differences between a feature team and a product team, one may realize how valuable a product team is and may ask herself what we need to do to turn a feature team into a product team. Well, that’s the topic of this article! \o/

Not all feature teams are ready or willing to turn into a product team

A product team is given a problem to solve and an outcome to achieve. The team has complete autonomy to decide how to solve the problem and achieve the outcome and is incentivized to do so as fast as possible. Ideally, the team has also the autonomy to define what problem to solve and what outcome to achieve.

Product teams have to achieve outcomes, not only deliver products and features. The products and features they deliver are means to generate results for the company that owns the product and to solve a problem or to address a need of the customer. This result for the company can be more revenue, lower costs, increase customer engagement, etc.

Some teams and people are not willing to be concerned about business results. They prefer to be told what to deliver and to work on delivering what was asked. In this case, they should look for places to work where being told what to do is the common practice. However, my understanding is that the number of places working this way is diminishing and soon it will be quite hard to find these places, the same way that today is very difficult to find places where Waterfall is the preferred software development process.

Some teams and people may be willing to be concerned about business results, but they are not equipped with the knowledge needed to understand the business in order to deliver business results. These people need to be educated on how the business works so they can devise ways to impact the business through technology.

The feature team is ready to turn into a product team

Ok, so you believe the feature team is ready to turn into a product team, i.e., the feature team is both willing to turn into a product team and has the necessary business understanding in order to impact it with technology, then it’s time to work on transitioning the feature team into a product team.

This transition should be considered under two perspectives:

• business people: whenever business people bring new requests to a product team, the business people need to bring these requests in the format of problems to be solved and outcomes to be achieved. They should refrain from bringing solutions or, if bringing a solution, making it clear that it is a solution hypothesis, not a solution implementation request, and the product team has complete autonomy to come up with other solution hypotheses to be tested. It’s ok for people from business to participate in the solution discovery, but the contribution should come in the form of collaboration not mandate.

• product team: the product team needs to be proactive in impacting the business. Whenever the team is asked to implement a certain solution, the team should ask what is the problem we are trying to solve with this requested solution and what are the outcomes expected. If the person who’s asking (business person, manager, C-level, founder) is not willing to answer, explain to her that if the product teams knows the problem to be solved and the outcome to be achieved, the team may be able to figure out solutions that may be faster to implement.

What if business people say that the team should only implement what was asked?

In some cases, it may happen that the business people are not willing to disclose the problem to be solved and the outcome to be achieved. They may simply say that they know what they are asking and the team must implement it. In this case, my strong recommendation is that the people from the product team look for another place to work unless they are willing to work as a feature team.

A product team is always given problems to solve and outcomes to achieve. The team has complete autonomy to figure out ways to solve the problem and to achieve the outcome as fast as possible. This autonomy is necessary because the product team has the necessary knowledge and experience in technology and digital product development to come up with the best solutions.

Ideally, the product team has also the autonomy to define what problem to solve and what outcome to achieve. That’s the ultimate stage of maturity of a product team. In this stage, the team understands a lot about the business in order to define with some input from business people what problems to focus on and what outcomes to achieve.

Summing up

• Not all feature teams are ready or willing to turn into product teams. If not ready, we need to educate them on the business so they can devise ways to impact the business through technology. If not willing, probably we need to change the team to have people that want to deliver results to the business.
• To make the transition, both business people and people in the product team have to collaborate. People from business should refrain from bringing solutions to be implemented and should instead bring problems to be solved and outcomes to be achieved. People from the product team should always ask what’s the problem to be solved and the outcome to be achieved whenever they are asked to implement something.
• In some cases, it may happen that the business people are not willing to disclose the problem to be solved and the outcome to be achieved. They may simply say that they know what they are asking and the team must implement it. In this case, my strong recommendation is that the people from the product team look for another place to work unless they are willing to work as a feature team.
• Ideally, the product team has also the autonomy to define what problem to solve and what outcome to achieve. That’s the ultimate stage of maturity of a product team. In this stage, the team understands a lot about the business in order to define with some input from business people what problems to focus on and what outcomes to achieve.
• This autonomy is necessary because the product team has the necessary knowledge and experience in technology and digital product development to come up with the best solutions.

Digital product education, coaching, and advisory

I’ve been helping companies bridge the gap between business and technology through education, coaching, and advisory services on digital product development and management. Check here how I can help you and your company.

Newsletter

I write regularly about product management, product development, digital product leadership, and digital transformation. You can receive a notification whenever I publish a new article, without depending on any social network algorithms to notify you! Just subscribe to my newsletter.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

• Startup Guide: How startups and established companies can create profitable digital products
• Product Management: How to increase the chances of success of your digital product
• Leading Product Development: The art and science of managing product teams

You can also acquire the books individually, by clicking on their titles above.