The long, slow, march of innovation

I recently had the opportunity to sit down and talk with the co-founder of Teradata: Phil Neches. During our conversation, I brought-up a session at George Gilder’s WTF back in 2004. I had come across a summary of his discussion there from Fast Company during some other reading. What struck me the most about his comments was that oftentimes, revolutionary technology really exists at the far edge of our worldview. What he said was this using the automobile’s adoption as a metaphor:

Right now we can only see “horseless carriage” applications. Everyone sees new technologies based on how it relates to or replaces existing technologies. New technology always enters the market at the margins. We still measure engine performance in horsepower. The big payoff of this technology is going to be something else.

In essence, real, revolutionary technology is actually evolutionary; it’s real use/purpose/value only revealed after we remove our own inability to see beyond our own current perspectives.

Then I saw a recent article on innovation over at a Forrester blog titled “Not All Innovation Needs to be Disruptive“. Slightly different angle since the focus was on the end result rather than technology, but the same learning applies: innovation doesn’t need to be or isn’t disruptive. Rather it moves slower, more incrementally, searching for the right application. Then BANG! Everyone notices.

Ultimately innovation is only innovation when you understand the real fit between a technology and it’s most valuable application. And often it takes a lot of trial and error. But what most people see instead of a long, painful process is an immediate, almost overnight success. While many companies try to create that same success, they often don’t recognize that the pursuit of instant success is actually counter to ultimate success: discipline to listen to the market, understand a problem, and seek a great solution.

Five Ways to Torpedo Your Product Management Career

See my article on The Pragmatic Marketer Magazine here:

http://www.pragmaticmarketing.com/publications/magazine/8/1/five-ways-to-torpedo-your-product-management-career

Pricing software

I’ve always thought that software should be sold based on how businesses want to consume it. Ok, that’s not exactly true as 1) I’ve only been on this usable mission for the last two years and 2) most people want to step-up to the business software smorgasbord and feast for nothing.

 Ok, so what do I really mean? I mean that pricing software has typically been an inside-out approach based on a cost-plus model or, even worse, a “how-much-can-you-afford?” model. Typically how this all ends-up is that customers feel frustrated over the notion that what they want and need isn’t delivered to them in a way that makes sense for them. How would you feel if you wanted a can of diet coke and were told that you had to purchase it in 64 gallon quantities and consume it on the spot? Well a lot of software is sold the same way.

So, as part of some research on existing pricing for one of my products, I see this post and it completely captures what I’ve always felt and stated but with the weight of a better-organized article.

Web 2.0 technologies adoption, open-source software, and new services-based software are all changing the way software is discovered, trialed, and eventually consumed. My quest for solutions that satisfy the B>E equation is heavily influenced by this common inbalance between software pricing/licensing and how users want to consume it. Now we’ll have to contend with solutions that not only are consumed differently but produced differently and with significantly different cost basis.

Building Useful Software Part One: Beware The Power User

Power users. Every product has ‘em. And boy are they great. They are happy to extol to others the hidden virtues in every crevice of the product. And a lot of times they can lead you to new ideas of where the product can be extended to new uses  markets(that is when they’re not bitching about things like not being able to integrate with their new XYZ product or that your product doesn’t support the latest greatest Web 2.0 gadgety feature).

So what’s to fear? These guys know your product, they love it. Why not listen to them and do what they ask? Well…it goes like this. Power users represent only a fraction of your user base. Develop for them, and you’re screwed. SCREWED!

Read the rest of this entry »

When “unintended features” come knocking

Have you ever experienced the “thrill” of releasing an exciting new version of your product only to have customers complain about a feature that is now broken?

“But, how could this happen?, you ask. “Doesn’t development have a regression test to ensure these things are caught?”, you scream to the unfortunate and convenient program manager scapegoat.

Then you find out the issue: there was never a feature specifically coded to support how your customers started to use your product. It could be anything for which a work-around (argh! I hate that phrase…) might be created. Uh-oh. What to do now?

Read the rest of this entry »

Classic Fumble: Preventing users from shooting themselves in the foot…

It’s a common phrase I’ve heard uttered by engineers of all types be they usability, systems, software and so on. “We have got to make sure that users don’t shoot themselves in the foot by <insert inane/benign/obscure user operation here>.

What this phrase is really meant to convey is the well-intended effort to prevent a poor user experience by allowing bad things to happen. Prevention is then implemented through protective measures. And while I fully support this philosophy, in fact I count it as one of my major agendas for any product I manage, it’s the implementation of that philosophy that often runs afoul of the very users it is meant to protect.

Read the rest of this entry »

It’s the little things cont…

I’ve traveled internationally for the purpose of conferences and partner meetings. But this last time, the purpose was for sales meetings and it required formal business attire. I was really excited as I’ve been working to upgrade my entire wardrobe including the purchase of tailored suits. I was looking for the perfect excuse to get some new things.

Having traveled to Europe before I remember seeing everyone wearing suits – the suit is the mandatory everyday attire for European business culture – it’s just simply expected. Casual Fridays and Dockers are the sole creation of Silicon Valley and progressive US businesses. I was so jazzed…

Read the rest of this entry »

You want fries with that?

Have you ever felt that you just don’t get good enough market feedback from the field? Is sales not providing you with details around the customer problem? Do you get basic feature requests instead of good (and relevant) descriptions of business problems? Well, you’re not alone and there’s a simple reason why.

 More...

So what type of sales folks do you have in your organization?

Do you have order takers like at McDonalds?

 

Or do you have problem solvers?

 

Read the rest of this entry »

It’s the little things…

As Vincent Vega said “it’s the little things” …

Like what’s the deal with freeze-dried coffee? In every hotel in Europe you get extensive tea choices but the only coffee you get are those little packets of coffee that look like sugar? 

 

 

C’mon! Give me some REAL COFFEE! I’m working with massive jet lag here! The irony is that most locals drink coffee more than tea – at least from what I’ve observed. So ditch the electric kettle (which is a staple in every European home and office) and get me a Senseo or something!

Foolish consistency is the hobgoblin of little minds…

So said Emerson. I have to think he was writing about bureaucracy or some other process-laden organization.

God, if I have to fill out one more form just to get one word changed…

Why is it that most processes are supposed to be more efficient yet most end-up being overly-bureaucratic nightmares of B.S paperwork, needless questions, and endless reviews? More...ANY process should always have the following qualities: 

Repeatable – if the process isn’t defined to a level that enables it to be repeatedly and EASILY followed, then throw it out.

Controllable - if you have no idea how things work or know what’s going on, it ain’t a process.

Efficient – This seems to be the big area of problems. Processes that are repeatable and controllable, but that aren’t efficient completely defeat the purpose. Here that SOX auditors and consultants? You’ve delivered a big suck-job on that one you sonsof…

Adaptable – This one is even a bigger problem. Have you ever requested something from…oh let’s say IT…and received a blank stare that screams “we don’t have a procedure for that…”? If you have created a process is soooo effin rigid that the slightest deviation causes the entire machine to grind to an ugly hault, then please remove the sign someone stapled on your back that says “asshole” – seriously, it there – just look.