In the previous chapter, we saw the difference between a team that solves problems and a team that implements solutions. While a problem-solving team needs to have a deep understanding of each problem it will solve, the people who are affected by it, the context in which it occurs, and the motivation people have to have this problem solved, the solution implementing team focus on implementing what is asked, no matter if what is implemented will bring any results.
The measurement of result delivery for these two types of teams is often quite different. Through the way a team reports its results, we clearly know what kind of team it is. Something like:
Tell me about the results you deliver and I’ll tell you what kind of team you are on!
While the solution implementing team usually measures its delivery of results based on the number of features delivered, the problem-solving team measures its delivery of results based on how well the problems have been solved.
Solution implementing teams are those “feature factories” that we already mentioned in the previous chapter, that is, whose main metric is the quantity and speed of feature delivery. As this is its main metric, this team is now measured by its deliveries. The team said it was going to deliver that functionality that day, so that’s what the organization expects and that’s what the organization will ask the team.
This situation is not as unusual as you might think. At Locaweb, before implementing OKRs, the product development team was primarily measured by its planning assertiveness. If the team said it was going to deliver X on day Y, that was what was expected of the team, with no concern whether X was the right thing to do and whether it was actually going to bring results for the company or customers. By implementing OKRs, we managed to make the team increasingly focused on understanding and solving problems.
When I joined Lopes, I found something very similar. A portal team, a CRM team, and an app team, all of them with predefined deliveries planned up to 6 months ahead, because that was what was agreed with the company’s management. Lopes had even hired two consulting companies that, when presenting their results report, showed the number of features delivered as their main result, because that was what was demanded of them, delivery of features.
It is important to note that a situation like this does not happen solely because of the product development team. It is also the responsibility of the people who are making the demands. While the product development team must always ask what problem they are trying to solve with that demand, the people who make the demands must always contextualize these demands bringing the problem that motivated the demand.
After my first 30 days at Lopes, I started working with the team to define the OKRs for the next quarter, which even motivated HR to also make its planning based on OKRs. These OKRs were then presented to the entire leadership of the company. It was the way I found to bring about a change in culture and mentality both in the product development team and in the entire company.
Most of the OKRs we defined were focused on business results. Increase in sales, increase in the conversion rate, and so on. That’s what matters to the business. Features are a means to get to an end, they are not an end in themselves, even in 100% digital companies, such as Conta Azul and Locaweb, digital products are a means to the end. Locaweb even makes this very explicit in its mission to “make businesses born and prosper through technology”, while Conta Azul wants to “boost the success of small entrepreneurs by giving small businesses more organization, control and time through technology.” Note that in both companies the technology and, consequently, the digital product is a means to an end. Both achieve their mission “through technology”.
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 almost 30 years of experience in creating and managing digital products:
In the next chapter, we’ll look at the value of ecosystem mentality.