Photo by Matt Seppings on Flickr used under Creative Commons
This is a question I’ve been asking myself a lot lately.
When a product reaches maturity, meaning it works as designed (mostly), the ugly bugs are resolved and you’ve got a good number of users, inevitably, as a product team, you begin planning for new features.
Most of the time, your initial release doesn’t include everything you wanted, so that list probably has a number of “Phase 2” items that are important but somehow didn’t make the first release. You’ve also probably got a list of strategic features you want to build, and a list of truly innovative features that you know will benefit your users.
The (good) problem is that you have more people using the product now, and they’re providing you with lots of useful feedback. If you’re lucky, the feedback matches up nicely with your lists, and having user feedback validates your strategy.
If you’re not, you’ll have to scramble and reprioritize the lists to account for user demand.
Go through a couple releases, and you’re likely to have one or two really innovative features that you want to build, but that keep slipping due to incremental enhancements and bug fixing.
As a product team, you’re responsible for the product and those using it. You oversee the strategic direction of the product, and you know what your users want and need. Unfortunately, wants and needs don’t always correspond.
So, how do you make the decision to do something innovative?
Connect, now in its fourth release, has this (good) problem. It’s mature and has several thousand people using it each day, and I have a short list of incremental enhancements that we should get around to building because people keep asking for them, most notably email integration and OraTweet group integration.
While both these features would benefit users and drive further adoption, we’re supposedly an innovation shop, and neither feature is terribly innovative.
Let’s be honest, social isn’t innovative anymore; it’s mainstream. Maybe it was when we debuted the IdeaFactory a couple years ago, but even then, you could correctly say we were following Digg, Facebook and any number of other consumer apps.
So, we yearn to push the envelope and experiment with new technologies, but all our users really want is incremental improvement. For instance, today I had a call with a guy to chat about future integration with email and OraTweet; at the end of the conversation, I tried to drop a nugget about some plans we’re cooking up to do something really cool.
He didn’t seem all that interested.
Once users find value in a product and come to rely on it, they want it to be better in controlled ways that don’t disrupt operations. If you need an example, look no further than Facebook, and the backlash over their redesigns.
The challenge for product teams is finding a balance between keeping users happy with incremental updates and cajoling them into accepting truly innovative features. Another argument for “the future is good enough”.
What do you think? Should product teams push the boundaries of technology, or should they put more value on incremental improvement? Maybe there’s an easy way to balance these that I’m missing.
Find the comments.
Perhaps my vision is skewed, but I suspect that users search for a solution, and once they find a solution and fall in love with it, they're more inclined to keep what they have. This is especially true if the users exerted great effort to find the solution that they have – after going through all of that effort, why go through effort again to learn a new release, new features, new ways of doing things?
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.
Exactly right. Users want to *use* the product (surprise), and they understand that changing it could break it or force them to retrain themselves.
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.
Would it be possible to just hand Connect over somewhere (like I believe you did with Mix) and move on to new projects? Are there other “real” product teams who would take care of your baby?
The best home for Connect would be with an IT team, since it's production. No product team would take on the operational side. However, I doubt any IT team would be interested. Ruby isn't a common skill 🙂
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.
Ah, my bad, operational team of course. But yes, I can see the problem of trying to sell that sort of an oddity inside this particular company 🙂
Well, the uptick in use for daily business operations by more people and teams certainly helps make a case for keeping it running and for some operational oversight, if it leaves our control.
For now, it's the only real concrete thing we can point to as ours, which is kind of important.
Hi Jake, seems to me that maybe the core issue you are lamenting is not really about the users, but about how to balance the distinct motivations of an “innovation incubator” and “mainline product development”?
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;-)
My point applies (or should) to mainline product development too. Not sure you meant it, but it sounds like you're saying innovation doesn't solve real, identified problems 🙂
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 🙂
>> sounds like you're saying innovation doesn't solve real, identified problems
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).
OK, I didn't think you meant that, but it sounded that way.
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.
This is a pretty good description of the complaints about using flash in metalink. Some people reject it explicitly saying they consider flash a marketeering device (not to mention a difficult IT hurdle) and want fast access to technical information to be more important than whiz-bang graphics. And the team implementing it comes back and says it's faster because it reduces network roundtrips and has a very high accept rate among users. Which both highly conflict with my personal anecdotal evidence.
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.
You also seem to advocate balance and judgement in new feature introduction too 🙂
Seems like we're absolutely on the same page then Jake – sorry, I didn't get that sense from your original post. But the discussion is good, and I think it is important to have that sense of balance a main player in the conversation. Portfolio management!
I don't always like to lead with a strong opinion. If there's discussion, I'll add my thoughts in comments. This is a real problem with product, i.e. balancing strategic innovation with incremental enhancements. The tendency I've seen is to err on the side of incremental enhancement, which is great for customers (usually), but leaves the product in stasis for too long.
It's not an easy problem to solve.
Seems like we're absolutely on the same page then Jake – sorry, I didn't get that sense from your original post. But the discussion is good, and I think it is important to have that sense of balance a main player in the conversation. Portfolio management!
I don't always like to lead with a strong opinion. If there's discussion, I'll add my thoughts in comments. This is a real problem with product, i.e. balancing strategic innovation with incremental enhancements. The tendency I've seen is to err on the side of incremental enhancement, which is great for customers (usually), but leaves the product in stasis for too long.
It's not an easy problem to solve.