It's not an easy problem to solve.

It's not an easy problem to solve.

You're right, as a user of a support system (or any mission-critical software, especially like the go and stop controls on a car), I don't want innovation, I want dependability.

I'm asserting that users don't want innovation. The only people who deny that assertion are marketers

I'm also asserting that product teams (mainline or otherwise) need to balance the incremental and the innovative because they know the product and are its shepherds. The product team should understand its domain and adjust strategy accordingly, combining the innovative with the incremental. Balance is the issue.

No Jake, I said innovation applies everywhere: ” users … want their problems, pains or aspirations addressed. And 'innovation' is just a characterisation of the solutions we put out there to achieve this” but in mainline product management, these are more likely to be of the “minor innovation” variety.

You're asserting that it is self-evident that any product will benefit from (implied: major?) innovation. I would say actually, no, that's not a universal truth.

I guess the key point I was making is that the problem is an obsession with “innovation” in the first place.

In mainline product management, that shouldn't be the point – you should be focused on serving your markets and customers and users. If that requires some technological innovation, well and good. But innovation is not it's own end. Whereas the innovation incubator/20%-er is expressly chartered to solve problems that _require_ innovation (not necessarily technological).

Obviously, I disagree.

Not sure how you define a mature product (age, bugs), but any product at any state of maturity will benefit from both incremental enhancements and innovative features. It's the product team's responsibility to ensure this.

I don't think that every product team does this in the right mix b/c it's tough. Eventually, they bow to pressures from users and internal management to do more of one and less of the other.

Oh, and refactoring is always done for its own sake

I think the distinction is quite a subtle but important one.

First I think its true to say that user's don't want innovation per se, they want their problems, pains or aspirations addressed. And “innovation” is just a characterisation of the solutions we put out there to achieve this.

But when it comes to “mainline product development”, the imperative for solving real, identified problems and delivering predictable, manageable value is paramount. The more mature your product, the more likely these are to be incremental “minor innovations” (in fact, pushing a “major innovation” is probably a warning sign that you've actually moved into another problem space altogether, or are actually futzing and refactoring for the sake if it).

However, an innovation incubator cannot be constrained by such mundane practicalities if it is to be successful (which I presume is measured on some scale of delivering major breakthroughs: opening new markets, or completely new approaches to an established problem domain). So while I still believe innovation incubators _must_ be focused squarely on real utility and value to customer as the ultimate goal, the real distinction is the latitude they are given to explore new technologies and combinations. In other words, like any true research project, they are expected to operate with a much higher level of risk (where proving something doesn't work is almost as valuable as proving something does).

So the fundamental question is probably: can you do both at the same time?

I'd say yes, and in fact it is an established practice in product development/R&D – the concept of managing a portfolio of activities across a range of risk profiles (from low risk maintenance of existing products to high risk exploratory work). Google's “20%” programme is probably a good example of this in action…

Good luck with your search for balance in your life;-)

For now, it's the only real concrete thing we can point to as ours, which is kind of important.

Ideally, we can find the time to do both new features and incremental enhancements. It's tough to balance, but using 80/20 time has worked pretty well.

I've come to think that to do innovative work, your top requirement must be impact on production users. This is what we're trying to do now, adding stuff we think is fun and innovative that doesn't affect the Connect codebase.

Still, the problem is resources. Users want incremental enhancements to Connect, without any downtime or bugs, natch, and we want to build something new. It's a tough equation to solve, especially with two developers.

From that perspective, a new strategic feature introduces the possibility of breaking stuff that was just fine, thank you.

In that case, the best way to get a strategic feature into the product is to try to convince the customer to clamor for it. It sounds like this is what you were trying to do, but this particular customer wasn't interested.