I’ve been using the term “Product Engineering” to describe software production, even though it is still separated into two different departments in most companies. That’s because these cannot stand without the other. Like a two-headed mythological creature, both succeed or fail together. Yes, as a tech executive, your partnership with your product counterpart is the most important in the company. And there’s no denying that engineers are often too eager to point a blaming finger at product managers without regarding their own responsibility. Nevertheless, there’s no denying that sometimes your company’s product department is not up to par. What do you do then?

That’s a concrete problem that is becoming easier to spot recently. The rise of mindsets such as empowered product teams and product-led growth is terrific, and I’ve seen it dramatically help startups get to value quicker. However, these rely heavily on strong product chops, and when you try implementing these methodologies without a solid product team, it will become apparent very quickly. As hard as it is to hire senior engineers, I believe it’s much more complicated to find reliable and experienced product leaders. When that happens, it’s time to start doing something.

First, you have to accept that sitting down and sulking is not an option. Some of you reading this article are inevitably going through something similar right now and have been waiting too long without taking any action. Realize that you’ve got agency and power as an executive, and you can make things better. The concept of such extreme ownership can seem foreign to some people. Still, most CEOs I work with dream about their executives taking the initiative in such a way.

Second, you have to ensure alignment at the executive team level. The ideal scenario, as I’ve recently seen at one client, is where your peer VP/CPO is aware of the lack of expertise on the product managers’ part and openly discusses that problem with you. While what we’ll describe below will help circumvent obstacles in the short term, mitigating the problem for real would require them to change things up. In some scenarios, the product leader is the problematic link. In those cases, I would like to believe that you can talk about that openly with your boss. Either way, let them take responsibility for finding a long-term and sustainable solution (they and you can find suggestions and approaches by joining the free closed community for executives in tech that I’m launching this month. Subscribe here to get access to the first cohorts).

Thinking Time

Now, if you’ve been following me for a while, you probably have noticed that my recommended toolbox has a lot of best practices that touch on the relationship between R&D and product. The first tactic is to start making more room to think. That’s especially relevant if your team keeps complaining that the work they’re getting isn’t specced enough or not well thought out. Many times, giving the product team more time to process things is helpful.

Introducing intermissions is a great way to achieve that and enjoy many other benefits. These are weeks where your team focuses on innovation and tech capital, as opposed to churning out new features (the full chapter of my book which covers this topic is available for free if you sign up at the bottom of this article). For the product team, the immediate benefit is having a week where they are not in the regular rush of having to “feed the beast” with specced features. We’re often locking down the next sprint without having seen this one’s features in production for a minute. This method of operation means we often commit to tweaks without seeing a real need for them or miss opportunities to leverage what works since we’ve already moved on to something else.

Realize Value

Sometimes, even when you provide the time to think, product teams lack the skills or the capabilities to assess the situation. Engineers with fingers calloused from many debugging sessions possess excellent critical thinking skills and can approach many questions with the Socratic method (often without realizing it). Less technical product leaders who are not data-driven could benefit from working with the engineers to review past work using such methodologies.

For example, I recommend companies hold meta-retrospectives (some of my clients call these “impact retrospectives”) every couple of months. In these meetings, we don’t focus on the straightforward delivery of the software (that’s what your regular retrospectives are for) but on the results of these completed features in the real world after they’ve had some time to be used. Looking at new changes performed since the previous meta-retrospective, which of the new features seem to be helping, and which are dead in the water?

Sometimes, such thinking is not performed well because the data is not easily accessible to the product team. Whereas an engineer might whip up a report after mashing together data from logs, the database, and some analytics tools, product’s hands are tied to some dashboard that hasn’t been updated in a year. By the way, sometimes working together on collecting this data can help the product managers learn how to accomplish some by themselves or, even better, introduce new tech capital opportunities for making this data easily accessible and transparent in the next intermission.

Product Mastery

Lastly, I’ve yet to see a high-impact team that doesn’t have a high level of product mastery: The engineers understand the customers, the market, the competition, and your product. They don’t simply perform tasks because “that’s what the ticket said.” They make sure to understand the task and what it is meant to achieve. That means that your team has to rely less on perfectly specced features to make all the micro-decisions that software engineering requires.

Taking it even further, they should also feel free to speak up whenever they think the tasks do not make sense. Sometimes it is simply a matter of pointing out a different approach to achieve a similar result or suggesting some edge cases be left out for the time being as opposed to “doing as they’re told.”

Taking it even further, with a good bit of chutzpah and a healthy relationship with their product peers, they can express doubt that a particular task makes sense and hear more about it. I’m not saying product management should be led by team consensus, but that healthy inquiry can help spot misconceptions and misunderstandings before the feature work is completed.

Yes, a lot of this is about your engineers partaking in some level of “product work.” So what? As I stated initially, these tactics are used to mitigate your company’s current needs. Would you rather be “right” and have nothing of value produced at the end of the quarter? I’d much rather have a successful team. Further, this makes all your engineers better at their jobs, even when you have a fantastic product team. With time, you can dial down some of the efforts, but all of them are worthwhile regardless.