Symptoms of a broken product culture — Part 1

9 min readSep 1, 2022

If I had a penny for every time I fucked up a management decision, I would be rich and not sitting here writing this. Jokes aside, if there is something I can extract from my — short but proficient — product leadership experience is a list of red flags that I failed to see at that time and that I’m able to see now in retrospect.

This article is, in fact, my own version of Vincent Chan’s “Transforming Product Culture at Scale”, which happened to be enlightening for me and helped me sort out all my thoughts.

Because there are way too many topics to cover, I decided to split my writing in two. In this article, I will tackle all the problems and in the following one, I’ll write about tactics to fight back against these problems.

Update: ‘Symptoms of a broken product culture — Part 2’ is here.

So, let’s get into it.

Fire-fighting syndrome

In every company, there are invariably more problems than people have the time to deal with. At best, this results in circumstances where minor issues are overlooked. At worst, ongoing firefighting depletes the resources available to an operation. Managers and engineers jump from one assignment to the next without finishing the previous one. Trying to solve problems becomes worthless patchwork. The team’s productivity plummets. Managing turns into a perpetual game of juggling which fire to put off for now while deciding where to put overworked people.

In Argentina, we call this “paddling in dulce de leche”.

If this sounds familiar to you, then your organization might be suffering from the fire-fighting syndrome. I’m sure you’ll recognize some or all of these symptoms:

There isn’t enough time to solve all the problems. There are more problems than the problem solvers — engineers, managers, or other knowledge workers — can deal with properly.
Solutions are incomplete. Many problems are patched, not solved. That is, the superficial effects are dealt with, but the underlying causes are not fixed.
Problems recur and cascade. Incomplete solutions cause old problems to reemerge or actually create new problems, sometimes elsewhere in the organization.
Urgency supersedes importance. Ongoing problem-solving efforts and long-range activities, such as developing new processes, are repeatedly interrupted or deferred because fires must be extinguished.
Many problems become crises. Problems smolder until they flare up, often just before a deadline. Then they require heroic efforts to solve.
Performance drops. So many problems are solved inadequately and so many opportunities are forgotten that overall performance plummets.

The bad news is that under pressure to combat fires, engineers are forced to come up with quick and dirty, rather than efficient, solutions. They only make an intuitive diagnosis rather than working on a problem long enough to determine its underlying cause. Then, rather than putting their speculative diagnosis to test, they make an impulsive alteration to the code. And if the short repair doesn’t fully resolve the issue (it’s typically ambiguous whether it did or not), they keep it in place and attempt a different approach. They fail to address the issue methodically, which results in their failure to find a solution. Patching not only takes longer than methodical problem solutions, but it also doesn’t solve the root causes of problems.

In general, patching is destructive. The new problems that patching has created, and the old ones that it has failed to solve, act up more and more, until a large fraction of the incoming problems is actually old ones returning. The engineer’s environment becomes increasingly chaotic, which makes it harder to run experiments and pin down problems. In some cases, the organization’s ability to solve problems collapses completely, and overall performance plummets.

Source: Stop Fighting Fires by Roger Bohn — Harvard Business Review

IT mindset

As was described by Marty Cagan, a company with an “IT mindset” — in contrast with a “Product mindset” — is a company that tries to manage its customer-facing internet software as if it were an internal-facing IT software, and this results in both bad customer experience and a troubled organization.

Why is product software so different from IT software?

A number of reasons: employees are paid to work at a company and use the software they tell them they need to use; in contrast, in product software, every user makes his own purchase decision — if they don’t want it, they won’t use it. Furthermore, in IT software a company can get away with requiring training courses, reading manuals, and specialized professional services; in contrast, in product software, if users can’t figure out how to use your software they are a click away from your competitor. For IT software, you measure the scale and simultaneous usage in the hundreds of users; in contrast, with product software, it’s in the hundreds of thousands or often millions of users. For IT software, if there is an issue with the software, they are your employees and they are forced to deal with it; for product software, an issue such as an outage disrupts revenue and immediately gets the attention of the CEO.

The truth is that most product software has a much higher bar in terms of the definition, design, implementation, testing, deployment, and support than is necessary than most IT software. It’s also true that salaries usually reflect this. Finding people with the necessary product software experience is much harder than finding IT experience.

Some of the differences between the two mindsets can be summarized as follows:

IT Mindset

Purpose: The staff exists to service the perceived technology needs of “the business.”
Passion: Product and tech are mercenaries. There is little to no product passion. They are there to build whatever.
Requirements: Requirements are “gathered” from stakeholders, prioritized in the form of roadmaps, and implemented.
Staffing: Lack of true Product Managers (especially strong PMs), lack of true interaction designers, the prevalence of old-style project management, engineers are unfamiliar with the demands of scale and performance, the existence of old-style business analysts, and heavy use of outsourcing.
Funding: Funding projects (output).
Process: Very slow, heavy, waterfall processes, even when the engineers consider themselves Agile.
Prioritization: Everything is important. The goal is to make every internal stakeholder satisfied.
Silos: People align by function, creating silos between the different areas of the business, product, user experience design, engineering, QA and site operations.
Organization: Engineering is often under a CIO or CEO. Product is not represented at C-level.
Accountability: Accountability is a farce. The people actually working on a project typically have no real say in what they are building, and sometimes even in how it’s built, and even when it’s due. In theory, the leadership team could try to hold the requesting stakeholders accountable for the results, but if they do they immediately hear complaints that they didn’t get what they actually wanted, and because of delays and costs, critical things had to get cut, and so it’s certainly not their fault.
The role of technology: Technology is viewed as a necessary evil. It is a source of fear more than a source of inspiration.
Leadership: Leadership happens in silos. Each department pushes for its own goals. Maintaining the status quo is more important than innovating.

Product Mindset

Purpose: The staff exists to service the needs of your customers, within the constraints of the business.
Passion: Product and tech are missionaries. They have joined the organization because they care about the mission and helping customers solve real problems.
Requirements: Product Managers must discover the necessary product to be built. Moreover, we know that most ideas will not work with customers the way we might hope, and we also know that those that do work will require several iterations to achieve the necessary business results.
Staffing: Strong PMs and engineers with deep knowledge of the users and customers; deep knowledge of the data; deep knowledge of the business; and deep knowledge of the industry.
Funding: Funding product teams are measured by business results (outcome).
Process: Technology-enabled product organizations simply must move much faster, and work differently, in order to deliver the necessary solutions for our customers and our business.
Prioritization: Customer needs are the only priority. “Ruthless prioritization” is exercised.
Silos: Depend on true collaboration between product, user experience design, technology, and the business units.
Organization: There’s a big difference between the engineers that support “true IT” and those that work on commercial products. True IT engineers usually report to the CIO, and the commercial product engineers report to a CTO.
Accountability: People are really accountable and measured by results. No excuses.
The role of technology: The technology enables and powers the business. It is embraced and valued. The people that create the technology are respected as the key contributors they are.
Leadership: Leadership in a commercial product company understands that it’s their job to create the culture and environment necessary to nurture continuous innovation.

Slow outcome velocity

To speak in strict Agile terms, in teams with SCRUM-ish methodologies “velocity” is an indication of the average amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team (what is usually measured with a burndown chart). It differs significantly from team to team and heavily depends on complexity. One problem with velocity is that it conflates work done with planning accuracy. In other words, a team can inflate velocity by estimating tasks more conservatively. If a team says that a task will take four hours or is worth 4 points instead of taking two hours or worth 2 points, their velocity will look better (sometimes called point inflation). This means that there is no such thing as a good velocity or a bad velocity.

Furthermore, the problem with focusing on the velocity of output and not outcome is that customers couldn’t care less. Your amazing CI/CD process is meaningless if this doesn’t affect directly the value your customers get from your product.

The challenge is that driving outcome requires both sustaining and disruptive innovation, depending on the situation, and not every organization is in the condition to face disruptive innovation at a high pace.

Chaotic planning

Another evident symptom of a broken product culture is a constantly changing direction that leads to chaotic planning. If you feel that every time the wind change also your priorities change, then is time to pay attention to your product vision.

The underlying cause could be either a complete lack of a solid product vision or maybe a product vision that is too weak to withstand the conditions of your business. This lack of vision causes multiple issues, not only chaotic planning. Other symptoms are for instance difficulties in defining the structure of the teams, the business domains, the priorities, the OKRs, and so on and so forth.

A simple way to stress test your vision is to run this simple checklist:

Is it customer-focused?
Is it stretched but not unrealistic?
Is different from competitors?
Is looking into the future?

Anyhow, lack of vision is not the only possible cause for chaotic planning. This could come also just from ineffective processes, an inefficient chain of command or a troubled company culture.

Diminished trust

As a result of all of the above, there is diminished trust in the product organization. Stakeholders see the processes, the Product Managers, the Product Designers, and everything else as something in the way of progress. The software development machine earns a bad reputation for not providing real value.

And as you might already know, trust plays a significant role in boosting efficiency in any company, as open and honest communication between parties is only possible if there is some level of trust. Inefficient communication between employees can slow workflow, reduce productivity, and increase costs.

One common red flag that indicates that this is happening is when stakeholders tend to speak directly to engineers in order to get their thing to production, skipping completely the Product Managers or any Change Request process that you could have in place.

Conclusion

The truth is I haven’t yet figured out what Product Culture is. Turns out that Product Culture is not a series of one-off team-building activities, nor is it a one-size-fits-all guide to doing things “the Product way”. It is not something to be prescribed; it’s something to be discovered. Most importantly, Product Culture is something that all of us have the power to shape.

Since I can’t tell you now what Product Culture is, I did my best to tell you what Product Culture is not.

So, if you see any of these signals in your organization: