The thing about product innovation in tech

By the virtue of having been in a few R&D and new product development gigs, I’ve collected a few observations. Conceptually, innovation work is important and it makes sense to do it, but in practical sense? I found that execution is really tricky, and making it work is not trivial.

Let’s establish a few parameters. We’re talking about a product and engineering organization where each team is working towards a mission, and where each group of teams is organized around a product domain that is only loosely coupled with others. We are also talking about an organization where majority of the teams are product teams. Those teams are supposed to be working towards a long-term strategic goal, but are free to pivot at the zoom level of months-years. Finally, we’re talking about teams who, as the time passes by, accumulate maintenance obligations that they cannot ignore or forgo without penalty that comes in form of spikes in maintenance cost or team’s workload, or perhaps dips in customer satisfaction or software quality.

Why have product innovation in the first place?

Seriously, why can’t just all product teams innovate at their will?

The thing about product teams is that they create things and, by doing that, implicitly commit to keeping these things alive until something happens that makes them write some of them off.

Majority of the software products get bigger and more complex over time. You may like it or not, but there are legitimate reasons behind that, although we won’t go deep into them. I think it’s enough to assume that, because the company you’re part of develops software and this software, at large, only gets bigger over time, there’s a fair chance that part of this software that your team owns also grows over time.

Having more and more of maintenance work on the team means there’s less and less time to create something new. But there’s more: at the org level, because the software the teams build gets more complex, it gets harder to make sense of it and harder to confidently make changes. You might have been through such experience, either as an employee of a big company (those are pretty common) or perhaps of a company that isn’t big but had made a few unlucky turns along the way when it comes to system architecture (those who truly make it unsalvageable are rare). So things get more complex, and it naturally gets harder to make changes without breaking stuff.

Compare that newly created teams dedicated to greenfield projects: nothing to maintain, can go crazy fast, nothing crashes or corrupts the data! How awesome would that be? Imagine a team where people don’t have to keep legacy running. What would such team look like?

What does a product innovation team do?

I think greenfield projects are what the companies do to make product innovation happen. Not every greenfield project leads there, for sure, but some do, and that’s amazing.

Such a team would probably be given a permission to change things within some scope of the product. It’s not practical to empower one team, or even several teams, to tear down the old product, when they are outnumbered by teams who keep it working. Or maybe develop something completely new, — that said, a new part of the existing product. It’s rare that a team would go on to create a completely independent product, because in that case it’s indistinguishable from being a separate company, and if that’s not happening, it’s probably some “in-house startup” show at 7.

Either way, the purpose of such a team is probably to make such a change (in the product) that would otherwise be unachievable by the means of “regular” product teams’ effort.

To outpace a “regular” product team, with all their maintenance debt and SLAs, an innovation team needs to make different trade-offs. And by that I mean only do things that are going to lead to achieving the goal, while dropping everything else.

What leads to the goal? Relentless focus on creating the customer value. That is, on creating functionality of the product (or, as we discussed earlier, a new product) that is going to address the needs of the customers. When either building with the support of select customers, or in a user testing phase, such team would respond to the customer feedback much faster than org average. They would then go ahead and make changes in the product fast enough to clear the customer feedback inbox faster than it comes in.

But then, what gets dropped?

What does a product innovation team not do?

The trade-offs are caused by where the team’s focus is: product. So by that logic, things like software quality, amount of rework, and operational excellence are secondary and are therefore droppable.

Just imagine: your team doesn’t have to carefully keep the test coverage in the code and make sure that each change is perfectly (and confidently) green.

In this mode, it’s okay that your team is developing a new microservice that is consistently bottom 5% performance-wise, does not follow the common code style guidelines, and is so far off the quality standards, even SonarQube doesn’t know where to start raising issues. Like, the code is really crappy, and you know it, and the team know it, but this, you know, isn’t a priority topic.

How does this even make sense?

It does, because when the work is comprised of rapid changes on the product, lots of code is being thrown away and lots of what was a bug yesterday becomes no longer relevant because it’s gone.

The pace is just too fast for the knowledge on the engineering side to build up.

Product innovation work’s impact on the team

I’ve been directly involved in four episodes of product innovation over the past couple years, and it’s always mostly different, but there’s a few things that I found following a pattern. Let’s talk about them.

Innovation work skews the sense of ownership. Especially for an engineer, who, in any “regular” product team, is expected to make high-confidence changes and high-quality choices in the code, it might be hard to adapt to the rapid pace of innovation work, and then it’s equally hard to go back to where they have to do maintenance. And especially if the innovation team is supposed to hand the results over as soon as they’re validated, but not fully production-ready, to another team. A particularly memorable example was when there were highly likely reliability issues in the code, but the feature set wasn’t fully implemented yet, so the team had to choose to focus on the latter.

Potential overlap of topics that leads to uneven workload. If the innovation team is supposed to get an idea to a handover-ready state and move on to the next thing, there might be (and, it seems, happen all the time) episodes of excessive maintenance load. In simple English, the team’s under pressure to make two things work, — and the teams (and humans in general) aren’t elastic, they just really don’t auto-scale with the load.

As a result of that,

Some important feedback missing, especially for the engineers. It’s not about coworkers saying “good job” here, — not even talking about humans in this case. Feedback comes in many forms, and in this particular case it’s about engineering metrics, such as the four golden signals of SRE or peculiar bugs related to data model, those come up months after the feature is considered released.

It’s hard to evaluate hard skills. When it’s all about the product, it’s really hard to evaluate the technical proficiency and skill, especially among the engineers. If it was about frequent iteration and making small changes, was there even an opportunity to crack a hard technical problem? In that sense,

None of them is good or bad, but if you are responsible for job satisfaction, performance evaluation, and professional development of folks on your team, you should seriously consider the trade-offs and potential consequences of sticking to a mode of work that is purposefully different from the rest of the org, definitely important and pragmatic, but challenging in different ways, giving opportunity to learn things that might simply not be applicable in other teams.

---

Knowing that, you can make a few changes in how the org operates and how the success is defined. Knowing that there’s one or several teams operating in the mode that is different from the rest of the org, in the absence of familiar signals, you might want to establish different ways to tell true success from luck. You might go further and establish a separate set of roles and adjust hiring to target more suitable profiles. Just make sure that these changes are going to last, — imagine how much it would suck to be an engineer who’s stuck on one team because their skill set doesn’t fit in other teams.