Culture cannot be changed by decree, but rather by results

7 min read3 days ago

Many leaders face the challenge of changing a company’s culture. The most common mistake is thinking that culture can be transformed by decree, with rules, speeches, or institutional presentations. The reality, however, is that culture does not change because someone tells it to — it changes when people see a new behavior generating results and start adopting it.

In other words, culture does not change with a decree but with results.

Why doesn’t culture change by decree?

When a leader announces that “from now on, we will be more collaborative,” “we will have a data-driven culture,” or “we will adopt an agile mindset,” it may sound inspiring. However, without concrete examples and results to validate this change, the new directive tends to be ignored or generate resistance.

This happens because a company’s culture is nothing more than a set of expected behaviors in certain situations. And behaviors don’t change with words — they change with experience.

If we want a team to adopt a new way of reacting, we need to demonstrate this new reaction in practice, demonstrating that it generates value.

Practical example: Lopes’ broker app

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

The discovery process lasted around 5 months!;
The discovery process focused only on discovering the problem, not on finding the solution;
The discovery process was done only internally, with a demand survey from the business areas and benchmarking with other broker apps available on the market, without any conversations with customers;
The “MVP” was defined with 58 requirements and features, and there were already 90 more requirements and features with a defined scope to be developed after the launch of the “MVP”;
The main problem to be solved was based on the hypothesis that if the brokerage received a lead, which is a potential client interested in a property, the faster it gets this lead and interacts with the client, the greater the chances of closing a deal;
Then, the team analyzed the brokerage’s journey and realized that when a lead arrives, the brokerage needs to search Lopes’ database of potential clients to check if the lead’s potential client is already in our database and, if not, register their data in our system.
Based on this analysis of the brokerage’s journey, the team then realized that if the brokerage could send some other property options to the potential client, this would increase the chances of closing a deal;
This process created the scope to be implemented, which took around 5 months of discovery plus 7 to 8 months of development to build the “MVP” application. In other words, it was taking more than 1 year to make an “MVP”. 😱

There are a few points to highlight from this process:

The problem discovery process was very long, which generated a huge list of problems for the brokerage firm to be solved;
The solution discovery phase was not executed. The team went from problem discovery directly to delivery without any opportunity to test solution hypotheses;
The massive list of problems to be solved directly impacted the product development process, making it very long as well;
If the solution discovery work had started as soon as the main problem was discovered (speed in getting the lead into the brokerage firm’s hands), the team would probably have been able to design a simpler solution that would have taken days instead of months to implement.

Regarding this last point, after some discussions, we thought of an app with just a push notification for each lead received, and the brokerage firm could continue with other tasks as it was already used to doing. To make it even simpler to test the solution hypothesis, we thought of not building an app but sending an SMS or a WhatsApp message to the brokerage firm. An A/B test can be performed to compare the closing rates of brokers who received SMS notifications with those who did not.

Even though we had made significant progress in developing the app, we decided to implement SMS notifications. It took us 10 days to implement them, and we were soon able to test the hypothesis that the faster a broker receives a lead and interacts with the client, the greater the chances of closing a deal.

This example of the Lopes broker app shows the importance of two principles of Product Culture: the need to 1) deliver quickly and frequently and 2) focus on the problem and understand it well to create and test solution hypotheses before developing the product.

This example helped me a lot at Lopes because I used it whenever the product development team received requests to implement solutions that had already been specified. When these demands arrived, we would say, “Your demand is interesting, but what problem do we want to solve? If you tell us the problem, the team can find faster and cheaper solutions. Remember the “MVP” of the broker app?”

Practical example: Demand for gym memberships at Wellhub

Another very interesting example occurred at Wellhub, which was formerly known as Gympass. When I joined Wellhub in 2018, the product development team, including engineers, designers, and product managers, was tiny, less than 5% of the company’s total employees. Typically, tech companies have 25% to 40% of their employees on this team. Because the team was small and did not practice Product Culture, this team focused on meeting the demands of other company areas.

One time, one of these areas, the gym partnerships department, came to the product development team with a demand. The partnership manager was closing a deal with a new gym, and she said that to close the partnership, the gym was demanding that we change the check-in process to include the electronic signature of a liability waiver that the gym requests from all its new members. We explained that this would be a time-consuming change and that it would be very strange for the end user to have this change in how they checked in at only one specific gym.

We asked the partnership manager if we could talk to the gym to understand the problem better. We met with the person from the gym and the person who handled the gym’s legal issues. We asked why this request was being made and whether this requested format was mandatory, to which they said no, that it was just a suggestion. At that point, we asked if there was a link to the liability waiver with a text saying “By checking in at this gym, you agree to the Liability waiver available at XPTO”. The person from the legal department said yes, this was already enough. Then we showed them this implemented text since it was an optional field that could be filled in when registering a new gym, and everyone was happy. The people at the gym for having their problem solved, the partnership manager for being able to meet a client’s demand to close the partnership, and the product development team for not having to do a new development specifically for a client.

From that day on, the partnership manager started bringing us the demands of new partnerships, saying, “Look, the gym asked for this, but I think it’s better if you talk to them to better understand the problem.” Of course, we started using this example internally to illustrate the importance of focusing on the problem, one of the principles of Product Culture.

The formula for cultural change

These examples illustrate a simple but powerful model for transforming a company’s culture:

Adopt the change first — Before demanding that everyone change, try the new approach with a smaller group.
Generate clear results — Show, with numbers and concrete examples, that the change works.
Share the learning — Give visibility to the positive impact of the change so that others feel motivated to adopt it.

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