Symptoms of a broken product culture — Part 2
In my previous article, Symptoms of a broken product culture — Part 1, I wrote about the red flags in product organizations and focused mainly on the problems. In this article, I’m going to cover possible tactics and strategies to solve those challenges.
In case you don’t want to go over the whole previous article, the issues that I highlight are the following:
- Fire-fighting syndrome
- IT mindset
- Slow outcome velocity
- Chaotic planning
- Diminished trust
You’ll see that this article is directed to product and software development leaders in general, but of course, the content is relevant to everyone involved in the process.
Stop fighting fires
Easy to say, hard to do. Right?
There are several ways to eliminate fire fighting, but as with any other problem, the first step is to recognize that you have it. Therefore, the first significant step towards progress is the moment the management of the company acknowledges it and decides to make it a priority. This might sound obvious, but actually, most of the fire fighting is precisely caused by management and their own obsession with urgency over importance. That is why it’s paramount that somebody speaks up either from within or from outside.
I’m going to borrow the categories and some ideas from the article ‘Stop Fighting Fires’ by Roger Bohn in HBR.
Tactical Methods:
- Put out fires with gasoline. If a part of your business or product is constantly set on fire and drawing your attention from what’s important, then set it on fire to the ground. In other words, shut down operations when a product is bringing more problems than solutions.
- Be a ruthless prioritizer and perform triage on everything. As Brandon Chu put it in his famous ‘Ruthless Prioritization’ article, there is always a way to accomplish your goal faster than you currently plan to. Even though being ruthless usually feels unnatural to teams, is the responsibility of the leaders to challenge people to be ruthless and really cut what’s not necessary.
- Ask for external help. Adding temporary problem solvers from outside of the team will allow your people to focus on what’s important, while others put out the fires. This is not only an efficient way to move forward but also will definitely help with morale. Usually, the teams don’t want to deal with problems and want to focus on what’s fun and rewarding, like creating new features.
Strategic Methods:
- Change your software development strategy. I’ve tried everything. Very long detailed roadmaps and no roadmaps at all. Estimation-based Gantt-type plans and appetite-based cycles. Very aggressive OKRs and absolute no targets. There is no recipe for product strategy, no matter what you read in a book. If your strategy doesn’t work, try something diverse. Also, different company moments might require different strategies, and it is ok to change, as long as you don’t fall into a constant pendulum swing.
- Outsource ancillary products and features. If something is not core to your business, then don’t let it draw your attention. Completely outsourcing pieces of your product will prevent your team from having to deal with the issues attached to it and the cost of maintenance.
- Solve classes of problems, not individual problems. Grouping problems in the same class will allow you to identify and — ideally — solve the root cause. This will seem more costly at the beginning, but it will prevent future fires and will definitely pay off.
Cultural Methods:
- Be cool. Just like the dog in the meme, chill. In the majority of the cases, life is not being threatened by your unsolved bugs. If leaders freak out, everyone freaks out.
- Don’t tolerate patching. This is mainly up to technical leaders, but it should be also up to Product Managers not to push for quick and dirty solutions. A patch is a credit that you’ll have to pay eventually (what is known as tech debt).
- Don’t push to meet deadlines at all costs. I know this is particularly difficult for Product Managers since is part of their main role to push for it. But what’s important to underline here is the ‘at all costs’ part. In product companies, most deadlines are self-imposed, so use your criteria and be flexible with them.
- Don’t reward fire fighting. Stop glorifying engineers that spent 4 hours on a weekend to fix a bug. Not because that’s bad behavior, but because it’s a sign of a toxic culture. Organizations should recognize and reward managers who practice long-term preventive, methodical problem solutions and don’t have many fires to put out.
Move from an IT Mindset to a Product Mindset
Is it Uber a “tech company” or a “product company”? This is a tricky question to answer. An easy answer is to say that is a “tech-driven product company”, but almost nobody says this. I know this might sound trivial, but if you ask this question in an organization, the answer of the majority is going to tell you a lot about their culture and mindset.
I don't have any numbers to support my statement, but I feel that most companies are founded by engineers and, in general, there are a lot more CTOs than CPOs. What this creates is a dominant tech-driven culture in the market, where everything is about building software, leaving customer experience in a secondary tier.
The fact is, technology shouldn’t be a “necessary evil” nor the end itself. Technology can, and it should be, part of the value proposition. Founders create companies for a plethora of reasons, being technology for the sake of technology one of them, but is supposed that every company is made to help humans progress in a way. And when the whole point is about helping people, then the technology becomes secondary by definition.
Now ask yourself: what is the background of people in my company? 99% is composed by people who studied finance, marketing, engineering, design, business administration, human resources, etc. Nobody studied “How to help people make progress in their lives”. Reduced to its core, a product company is a bunch of people who know how to build software together with a bunch of people who know how to make money in the process.
All this introduction is just to explain why I believe that the “IT Mindset” is the norm and having a real “Product Mindset” feels unnatural to teams.
This is why hiring Researchers is the most disruptive thing you can do to transition to a Product Mindset. These people is obsessed with customer experience and helping people make progress, and as a product organization you can’t afford not to have them in your team. They usually have backgrounds like psychology or communication. And even though Product Managers and Designers can, and should, do research activities, culturally speaking is not the same as having full-time Researchers.
The other symptom of this problem is when companies treat product software as IT software. To tackle this, Marty Cagan suggest a list of actions that I’m going to mix with my own recommendations:
- Draw a clear line between customer-facing software and internal software. The demands are different, the skills needed are different, and you will find you need different staff, processes and resources. (More about this topic below)
- Turn your designers into Product Designers. This is a big matter that deserves his own article. If you are interested in this, here is a nice and quick article about it: “The clear-cut difference between UX Design and Product Design, explained” by Aaron Travis.
- Make everything pass through a Product Manager. No matter what, no matter how technical it is, making everything pass through the scrutiny of a PM will help your team shape everything from the point of view of the users and not technology. It might not be the most efficient measure, but is a cultural move.
- Hire engineers that understand the demands of large-scale, highly available software, and how it is different from “enterprise software”.
- Optimize your development process for outcome instead of output. Find the way to make ‘change in people’s behaviour’ (aka outcome) part of your Definition of Done. Be sure that nothing is “done” until there is some sort of business impact.
- Make sure your Product Managers have an holistic view of the business. They need to understand and critizice everything that happens outside the product organization, including marketing, sales, human resources, operations, and everything else that affects either the product, the business or the team.
Avoid a culture obsessed with productivity
There is a great talk by Jeff Gothelf where, among other things, he speaks about what Agile is. He explains that being agile is simply responding to change over following a plan. Sadly, what’s happened in the real world is that organizations have used agile not for learning, not for agility and course correction, but for the production of software and the efficient delivery of high-quality code.
I’m sure you‘ve seen your CEO freak out because your engineers are idle. And I get it, I’m not that naive, companies need to repay salary costs. But cranking out software is not the way. The way is by producing customer value, and that might come from one single line of code, or even from removing lines of code.
One way to sort this out by design is to introduce a cool-down period in your development process. In this period engineers can focus on whatever they want, like fixing bugs, exploring new ideas, or try out new technical possibilities.
In the Shape Up process, after each six-week cycle, you should schedule two weeks for cool-down. This is a period with no scheduled work where you can breathe, meet as needed, and consider what to do next.
Secure a 20% of your time on continuous innovation
Startup product companies usually struggle to balance continuous and sustaining innovation. While innovation is desperately needed, the reality of a startup is that it needs a runway to actually run the needed experiments to drive disruptive innovation. Resources are always scarce, and keeping the machine running while innovating some times feels like running and tying your shoes at the same time.
One way to settle this pickle is to use a simple rule: dedicate 80% of your time on what brings revenue today, and secure a 20% for what will bring revenue in the future.
This is precisely the advice that Eric Schmidt, former Google CEO, took from Bill Gates. You can read more about it in the book ‘How Google Works’ by Eric Schmidt and Jonathan Rosenberg.
And as it is explained in the book, this rule can be deceptively hard to actually follow. Leadership teams often understimate how long it takes for revenue from a new product to ramp up. That shiny new stuff can be much more interesting than the boring old core business stuff, but it’s the core stuff that pays the bills, and if you make a mistake there, you probably won’t be able to recover.
What’s also really important besides paying attention to the core 80%, is to secure a 20% focus on innovation. And I don't mean the famous “20% rule” from Google, I mean a directed and strategic focus on innovation that has to come from the leadership. Failing to do this will result on new incumbents threatening your business while also making your team feel demotivated for not having the chance to innovate.
It’s worth acknowledging that established companies that stop innovating don’t usually die overnight. They can usually live off their brand for potentially several years. But it’s also important to recognize that many of the forces that today can propel good companies to very rapid growth, are the same ones that can accelerate their demise.
Draw a clear line between customer-facing software and internal software
The demands are different, the skills needed are different, and different processes and resources are needed. Both are important, but they are very different and most of your focus must be on your product software.
The differences between the two are usually very evident.
Internal software:
- Doesn’t strictly require accountability.
- Product Management is optional.
- Deadlines are self-imposed and flexible.
- Quality supersedes velocity.
- Doesn’t necessarily allow for experimentation.
Customer-facing software:
- Everything requires accountability.
- Product Management is mandatory.
- Time to market is crucial.
- Velocity supersedes quality, because “a Product shipped earlier is worth more to customers than a product shipped at a later time”.
- It is built for experimentation.
If you can outsource or buy off-the-shelf any of your true IT software (internal-facing software) you should do so, so that you can put the best people, time, and mind-share on the customer-facing software.
Timeboxing
Anyone who knows me at work, knows what my #1 weapon is: product cycles. And anyone who experienced product cycles knows what’s the secret sauce: timeboxing.
I’m not going to write about product cycles here because there are plenty of articles and literature about it, being ‘Shape Up’ by the Basecamp folks probably the most relevant to date. But let me explain why timeboxing is so important.
In “IT Mindset” or tech-driven companies exists a paradigm of development by estimation, where the company moves at the pace of the engineers and is up to them to decide how long it would take for this X feature to go live. The problem relies of course on how difficult it is to estimate software development, mainly on a company running mostly on legacy code and where engineers have to constantly discover how things work. If you are missing every single estimation and consequently missing every deadline, you should stop and think about this.
Timeboxing forces the whole organization to step up. On the one hand, leaders are forced to decide what’s the desired appetite of an initiative. And on the other hand, product folks are forced to make everything fit on a cycle. This paradigm diverts the conversation on customer value and what is really important instead of what’s the best way to build a piece of software and how long it would take.
Putting customer value and time-to-market on the center of the discussion is one of the most important aspects of transitioning into a true product organization, and you can do this by design with product cycles or any other timeboxing technique.
Empower Product Managers
Recently I had the pleasure to give a talk for the Product Heroes community here in Milan, and in the Q&A somebody asked:
“What if we don’t have time to do discovery?”
To what I answered:
“You either find the time to do discovery or find a new job.”
In retrospect, I might have been a little too harsh. But what I was trying to explain was that organizations believe or don’t believe in Product Management. And when I say “organizations” I mean basically the leadership of the company. If they don’t truly believe in the power of research, scientific experimentation and constant iteration, then there's no much to do. There is no magical process or method that can solve this problem.
It is the responsibility of the leader (CPO, VP, Head of) to fight this battle. Product Managers are usually in no position to do so.
Fake Product Managers (aka “backlog administrators”) are typically the norm, because having real Product Management requires an end-to-end commitment in the organization.
So, to fight this back I recommend having these basic rules:
- Prevent stakeholders from going around the PMs to reach out to technology.
- Avoid top-down decision-making as much as possible.
- Avoid decision-making in meetings where PMs are absent.
- Help PMs better understand the problems instead of trying to force solutions.
The easiest way to enforce these rules is by using processes, but it might not be enough. You know, rules are meant to be broken. Therefore, this is when real leadership comes into place and you as a product leader need to put PMs in the spotlight. These are some of the strategies I recommend:
- Make PMs run a regular Product Demo. It’s a great opportunity to show off and spread Product Culture at the same time.
- Make PMs show impact and business results in your company’s all-hands meeting (in case you have one). If you don’t have one, you can still share results regularly by scoring your OKRs, showing metrics through a dashboard, or whatever other method your company is used to.
- Push PMs to take the lead in decision-making. I.e. make them call for mission meetings and teach them to be in control of stakeholders.
- Force PMs to be the voice of your customers. You can do this by exposing them to raw customer feedback and making them share it to the whole company.
- Create a healthy culture by rewarding those who are really committed to creating customer value. The reward has to be tangible. This generally means salary raises, promotions, bonuses, or any other significant reward that sends a clear message to the rest.
Conclusion
There is no single way to fight this battle and definitely there is no magic recipe. What is certain is that this is mainly a cultural battle that requires serious leadership. And by ‘serious’ I mean people who is willing to speak up when something is wrong and act upon it.
Broken product cultures lead to broken businesses. Failing to achieve product-market fit is typically followed by banishment, either because you ran out of money or because you get beaten by a competitor. This shouldn’t be just in the interest of Product Managers, it should be in the interest of the whole organization.
Companies who work in silos struggle to adopt product cultures because it implies that what’s in the center is the customer, and therefore nothing else matters. Your marketing targets, your finance targets, your recruiting targets. Nothing matters. The one and only thing that matters is product-market fit.
