I have been working for some time in companies undergoing digital transformation or with individuals, including C-level executives, unfamiliar with digital product development methods.

One of the biggest challenges for these companies is transitioning from a mindset of “business demands and technology implements” to a mindset of “business brings problems/needs, and technology works on understanding these problems/needs with the user, testing solution hypotheses, and implementing a validated solution hypothesis.”

Typically, business people think and say things like, “I am the business person, so I am the one who understands our business problems/needs the most and how to solve them. You just have to implement what I say.” This business person thinks of the technology team as implementers of solutions, not a problem-solving team.

Solution implementation teams are teams that work on implementing a solution conceived by someone else. This other person is usually someone from the so-called “business area,” which could be someone from sales, marketing, customer success, customer support, finance, operations, or even a director, vice president, or founder. In these teams, the product manager mainly manages the backlog and helps the team deliver the requested solution, the product designer focuses mainly on designing a pleasant interface, and the engineers have to code and deploy the requested solution.

Solution implementation teams do what was requested, with little or no commitment to the quality of the solution or even whether it really solves the problem. These teams can also be called a “feature factory,” “feature team,” or “delivery team.” Their performance is measured by the quantity of features the team produces.

On the other hand, problem-solving teams are teams that work to deeply understand the causes of the problem, the context, and the motivation people have to solve it. By doing this, they can test different solution possibilities and implement the best solution for the problem at hand. This type of team is known as a “product team” or “empowered product team.”

So why does the “business demand => IT implements“ doesn’t work?

Instead of giving just one reason, I’ll list six reasons:

1. The “business demands => IT implements” model is unlikely to produce innovative products that customers love. This is because business people don’t know what is possible. Knowing what is possible and testing solution hypotheses is one of the main responsibilities of a product development team.

2. Successful technology companies like Apple, Amazon, Google, and Netflix do not use the “business demands => technology implements” model to build their successful products. They prefer the product development model of “business brings problems/needs => technology works on understanding these problems/needs with the user, testing solution hypotheses, and implementing a validated solution hypothesis” because they know this model brings the best results.

3. The “business demands => technology implements” model creates an adversarial position between business and technology teams. Consequently, the technology team’s commitment and engagement decrease, leading to high turnover and increased frustration for business people, resulting in a vicious circle.

4. People in technology do not feel responsible for the outcome of what they build because the business area has already defined what to do.

5. The business area may demand developments that are good for the individual interests of each business area but not necessarily good for the company.

6. The business area may ask for complex things that will cause long development cycles. The longer these cycles, the higher the frustration generated and the greater the chances that the delivery will not meet needs and generate expected results.

Does the other model really generate better results?

The fact that the “business demands => technology implements” work model has many problems does not necessarily mean that the other model actually generates better results. To answer this question, if the work model where “business brings problems/needs → technology works on understanding these problems/needs with the user, testing solution hypotheses, and implementing a validated solution hypothesis” delivers better results, I will share an interesting case.

When I joined Lopes, the team was working on an “MVP” for an app for its brokers. I put “MVP” in quotes because it had been in development for 7 months and still lacked 2 or 3 months to be delivered. When I delved deeper into the process and why it was taking so long, I learned a few things:

• The discovery took around five months!
• The discovery focused only on the discovery of the problem, not the discovery of the solution.
• The discovery was done internally, with demand gathering from business areas and benchmarking with other apps for brokers available in the market, without any conversations with clients.
• The “MVP” was defined with 58 requirements and features, and 90 more were scoped to be developed after the “MVP” launch.
• The main problem to be solved was based on the hypothesis that if the broker received a lead, which is a potential customer interested in a property, the faster she received that lead and interacted with the client, the higher the chances of closing a deal.
• Then, the team analyzed the broker’s journey and realized that when a lead arrives, the broker needs to search Lopes’ potential customer database to check if the lead’s potential customer is already in our database and, if not, enter their data into our system.
• From this analysis of the broker’s journey, the team realized that sending some other property options to the potential client would increase the chances of closing a deal.
• This process created the scope to be implemented, which took around five months of discovery plus 7 to 8 months of development to build the “MVP.

Some points to highlight from this process:

• The problem discovery process was very long, resulting in a huge list of broker problems to be solved.
• The solution discovery phase was not executed. The team went from discovering the problem directly to delivery without any opportunity to test solution hypotheses.
• The huge list of problems to be solved directly impacted the product development process, making it too long as well.
• If the solution discovery work had started as soon as the main problem was discovered (speed in handing the lead to the broker), the team could probably have conceived a simpler solution that would take days, and not months, to implement.

Regarding this last point, after some discussions, we thought about an app with just one push notification for each received lead, and the broker could continue with other tasks as usual. And to make it even simpler to test the solution hypothesis, we thought about not even building an app but sending an SMS or a WhatsApp message to the broker. An A/B test could be done to compare the business deal rates of brokers who received an SMS notification with the business deal rates of brokers who did not receive it.

Even though we had progressed a lot in the app’s development, we decided to implement the SMS notification. It took us ten days to implement it, and soon after, we tested the hypothesis that the faster a broker receives a lead and interacts with the client, the higher the chances of closing a deal.

This example of the Lopes’ app for brokers shows the importance of the two principles we have just seen: 1) the need to deliver quickly and frequently, and 2) to focus on the problem and understand it well to create and test solution hypotheses before developing the product.

How do you transform a feature team into a product team?

A product team receives a problem to solve and a result to achieve. The team has complete autonomy to decide how to solve the problem and achieve the result and is encouraged to do so as quickly as possible. Ideally, the team also has autonomy to define which problem to solve and which result to achieve.

Product teams need to achieve results, not just deliver products and features. The products and features delivered are means to generate results for the company that owns the product and address a problem or meet a customer’s need. This result for the company may mean more revenue, cost reduction, increased customer engagement, and so on.

Some teams and individuals are not willing to be concerned about business results. They prefer to be told what to deliver and work to deliver what was requested. In this case, they should seek companies where receiving instructions on what to do is common practice. However, I have noticed that the number of places working this way is decreasing, and soon it will be challenging to find such companies, much like it is difficult today to find places where the waterfall model is the preferred software development process.

On the other hand, some teams and individuals may be willing to care about business results but are not equipped with the necessary knowledge to understand the business. These people need to be educated on how the business operates so that they can create ways to make an impact through technology.

The feature team is ready to transform into a product team

Okay, so you believe the feature team is ready to become a product team? Is the feature team willing to become a product team and has the necessary business understanding to impact it with technology? So, it’s time to work on transitioning the features team into a product team.

This transition should be considered from two perspectives:

1. Business People: Whenever business people bring new requests to a product team, they must present these requests in the format of problems to be solved and results to be achieved. They should refrain from providing solutions or, if they propose a solution, make it clear that it is a solution hypothesis, not a request to implement a solution. The product team has full autonomy to explore other solution hypotheses to be tested. It is normal for people in the company to participate in the discovery of the solution, but their contribution should always come in the form of collaboration, not imposition.

2. Product Team: The product team needs to proactively impact the business. Whenever the team is asked to implement a specific solution, they should inquire about the problem we are trying to solve with that requested solution and the expected results. If the person asking (business person, manager, C-level, founder) is unwilling to answer, explain to them that if the product team knows the problem to be solved and the result to be achieved, they can discover solutions that may be faster to implement.

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

In some cases, business people may not be willing to disclose the problem to be solved and the result to be achieved. They may simply state that they know what they are asking for, and the team should focus on implementing what has been requested. In such a case, my recommendation for the product team members is to look for another place to work unless they are willing to function as a features team.

A product team always receives problems to solve and results to achieve. The team should have complete autonomy to figure out ways to solve the problem and reach the result as quickly as possible. This autonomy is necessary because the product team possesses the knowledge and experience in technology and digital product development required to arrive at the best solutions. Ideally, the product team also has the autonomy to define which problem to solve and which result to achieve. This represents the highest stage of maturity for a product team. At this stage, the team has a deep understanding of the business to collaboratively decide on which problems to focus on and which results to achieve, incorporating input from the business people.

Digital transformation and product culture

This article is another excerpt from my newest book “Digital transformation and product culture: How to put technology at the center of your company’s strategy“, which I will also make available here on the blog. So far, I have already published here:

• About the book
• Part 1: Concepts
  • Chapter 1: The so-called digital transformation – Project and Product
  • Chapter 2: Uncertainty and digital transformation
  • Chapter 3: Types of company
  • Chapter 4: Type of company vs digital maturity
  • Chapter 5: Business models
  • Chapter 6: Agile, digital and product culture
• Part 2: Principles
  • Chapter 7: Deliver early and often – Measuring and managing the productivity – Case study: Dasa Group – Case study: Itaú Unibanco
  • Chapter 8: Focus on the problem – The Famous Product Discovery

Workshops, coaching, and advisory services

I’ve been helping companies and their leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) bridge the gap between business and technology through workshops, coaching, and advisory services on product management and digital transformation.

Digital Product Management Books

Do you work with digital products? Do you want to know more about managing 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 books, where I share what I learned during my 30+ years of experience in creating and managing digital products:

• Digital transformation and product culture: How to put technology at the center of your company’s strategy
• Leading Product Development: The art and science of managing product teams
• Product Management: How to increase the chances of success of your digital product
• Startup Guide: How startups and established companies can create profitable digital products