Give me problem solvers

Over my career, I've had the opportunity to work with countless individuals in trying to push innovation and products forward. And it's become clear to me there are two kinds of individuals (not including the "don't-give-a-damn" and "incompetent" crowd):

  • Those that figure out ways to solve problems

  • Those that see nothing but problems

It's that simple in my eyes. I am amazed that there is no grey area, people do not change, people do not switch sides on this. They either solve problems or they don't! Period. And, it's not surprising to me that in my experience those individuals that figure out ways to solve problems end up overdelivering and exceeding expectations and those that see nothing but problems work hard to triage and underdeliver.

Had a Director I worked with at Whirlpool that I had a great deal of respect describe the latter crowd as "people that love to deliver the turd!" Seeing problems is easy. Solving them is a combination of science, art, and work. And is the real measure by which we should set the talent bar.

It's not that the turd-swamis are not smart, or lazy, or incompetent, or inarticulate. In fact, my experience is that the turd-swamis are usually smarter than average and very articulate. Which, ironically, creates a problem! They tend to get the ear of upper management and are able to create churn (although usually upper management sees through that, eventually).

So, my challenge has been two-fold:

  1. How do I identify people during the interview process that are problem solvers vs. turd-deliverers?

  2. When I'm interfacing with a turd-activist, how do I tactfully find someone else to work with?

I have not solved the problem of the latter; its simply something I've acknowledged I must do if I am going to be successful in my role. If I figure out a technique that works, I will blog about it for sure :) On the interview front, I've found you can discover one's leaning by digging deep on a) their work history (pick a project they've done), and b) giving a hypothetical project and see how they attack it. Problem solvers take the latter and push it forward; turd-swamis take the latter and push back.

I love one of Vince Lombardi's quotes:

Never confuse activity with accomplishment

I think I will add to my repetoire (yes, I need to clean it up and make it more elegant):

Never confuse intelligence with problem solving


I am more and more convinced...

that successful innovation is not about ideas, or even about execution, but rather...

It's about killing bad ideas quickly

I have no data to back this, I could not write an HBR article on it. Just a hunch based on what I've witnessed relative to ideas that have proven themselves through the pipeline yet can't seem to get resources to deliver due to those resources working on the wrong things.

I'm not advocating the Innovator's Dilemma problem of examining an idea on paper and having the data to kill it due to market opportunity and sizing; however, I am advocating having the discipline to prioritize resources to ensure the biggest opportunities receive the feeding they require. The problem lies with those companies that do not have the capability to measure their highest opportunities.

I'm still a believer in fail faster... maybe I should augment with kill faster?

Connected Home Revisted...

Wow, it really it going to see the light of day! Very cool to see something I championed and played a big part of make it out the door finally. Sheesh, did it really take two years to get it out the door? Ouch.

I did a little Googling on LaundryTime tonight, and ran across a number of naysayers. Unfortunately, the public articles somewhat miss the point of the value proposition and the pilot (although goals might have changed since I was there).

LaundryTime is a perfect example of a way to test out new concepts in search of great ideas to bring to market. It began with extensive consumer research - that's when I first became aware of Communispace - that identified a problem (actually the research reinforced a known problem - buzzer solutions for end of cycle are not good solutions). Then, ideate concepts that solve the problem, and find out ways to test those concepts. LaundryTime is one such test. Whether LaundryTime is the right consumer solution is not the point; that it is being tested with real customers in a cost-effective manner is the point.

My favorite part of, and my biggest role in, LaundryTime was getting the right IHA companies together to work on this project. Just like in Mealtime (a test of solutions in the connected kitchen), the final group of companies collaborting was not the same as the initial group conceived. Several iterations occured fleshing out uninterested parties and finding companies whose goals aligned with the project. Finding companies willing to invest sweat equity into a non-revenue project is quite a challenge, and very rewarding when it happens.

As it turns out, that's where I built my skillset to work with external parties (eight years of independent consulting certainly helped). Inside Amazon, I'm often asked in amazement "how did you get them to do THAT?" when I announce a deal with a third party. It's simple! If I can get companies to work with me and invest their effort when no profit is to be had, imagine what they'll do when actual money is involved! :)

Now, if Eaton can ever get HomeHeartbeat to the market, I might actually start BUYING some connected home technology I spent so much time in...


Enabling Innovation

I'm in the camp that there is no shortage of innovative ideas, just a shortage of backbone and ability to execute on those ideas. It does leave one question... just how do you tap those ideas?

Most people will say "just brainstorm." Those that study the innovation space are ok with brainstorming as part of a more structured innovation process that tests and refines brainstormed ideas. And, if brainstorming is an effective technique, it leaves a question of

For this posts sake I am going to restrict the scope of innovate to within a product, meaning, the product has been defined at a high level and the innovation occurs within that product context.

An effective technique I just successfully oversaw was a variation of the "empowering your team to innovate" mantra. It's simple - as product manager, I kept product requirements thin. Just enough to define breadth of product, and certainl enough to define the consumer and business problems. But, not deep on the requirements side. I gave the team freedom to innovate. And I accepted the risks associated with such an approach. It was simple: we knew the goal, we knew the problems. We had a fairly large team (upwards of 10+ program managers and developers), we needed to tap those creative minds if we were going to catch up to our competitors.

To be sure, there are those that don't like that approach. Those fall into two buckets: a) those that don't like that level of empowerment given themselves, and b) those that are not comfortable watching from afar the level of empowerment granted to the entire team.

For a), the solution was straightfoward: have those invididuals engage other individuals on the team that are comfortable making decisions in this space. Those inddividuals were all too happy to provide input!

For b), only two ways to make that crowd comfortable: ensure that the accountability structure is still in place, and show them the benefits with tangible results!

How did the product turn out? As one customer said: "Wow, this puts you 10 times beyond (competitor X)!" We did missfire on a few cylinders. A couple innovations did not pass the innovation bar. However, the breadth and depth of innovation outside of that more than made up for the few misses we had. Not to mention the morale benefits of enabling a team to make product decisions. Definitely a learning experience for me. It's a strategy I will pursue on all future products.

This one is for Brian

Ok, since I indiscriminately deleted my last blog and an interesting thread that materialized, I am going to repost the gist of it and see if it sparks the same conversation.

I started with a post on a Universal Shopping Cart - the ability to add items from multiple sources and checkout in a single, streamlined process instead of checking out at each individual source.

Brian Erst augmented that concept with an even better idea - have the cart have enough intelligence to find the best deals (based on the consumer criteria, such as availability, price, and delivery) out there. In other words, invert the traditional workflow from a) find place to buy something b) add item to cart from that place. What a great concept to get fledgling retailers an opportunity to compete with the big boys by meeting an untapped consumer need.

It would not be too hard for Google Checkout to provide the bare bones of this service. Between Google Checkout and Froogle (or even Google Base) they have the foundation tools to do this from a pricing and availability angle. The catch is that they would have to get other retailers to use Google Checkout when consumers are away from google.com, and consumers would need to become familiar with a new universal cart paradigm - not always easy, as witnessed by the number of paper checks still written today at retail stores (don't get me started on that one).

I would like to advance this a step further. Such a universal cart as Brian paints becomes even more useful to me if it integrates seamlessly with local shopping experiences. More and more, I find the need for items that I need sooner than online retailers can provide - yes, things I need now. But, where to find them locally? Which big box retailer carries said product? Are there businesses closer that carry it? What if I am in my car, on my way home from work? Integrate that into the workflow, and I'm a happy customer. And retailers collect higher margins from me, as I am willing to pay more to get something now vs. waiting for it.



Ok, starting up my professional blog again. I love the URL for it... pioneerit. I don't know why, but I was reading the umpteenth article/book that overused the term innovation, and I started to contemplate alternatives to this buzzword. After a while, and discarding some words, I settled in on pioneer. That's it. That nails it for ME. Pioneer. Blaze new trails. Be there first. Don't know the outcome. Have confidence. Have the capability to take on all unknown challenges that will arise.


I just finished my first week in my new role as Product/Program Manager for Amazon Web Services Order Pipeline Services. If that name is a little vague, and doesn't appear on the AWS site, it's not supposed to. While I do own AWS Gift Certificates and our AWS Order Pipeline, there are some ideas floating around that.

As part of the first week, I of course sat down with my new boss. As much as I dislike the idea of having a boss - all things being equal I'd much rather hang my own shingle as I once did - I do like the diversity and growth opportunity offered by working for a company. As we reviewed my priorities and short term goals, I was absolutely energized by one of my boss' sentence fragments:

...and any other products and ideas you might come up with...

This was in the context of talking about my overall ownership and responsibilities. We were covering the products I own and the input/expertise he expects from me, and said the above in a way where he expects me to incubate, develop, and launch new ideas. How refreshing, how energizing. This, in an operations group. (Aaron if you are reading this we have some work to do)

Already love my new job, stay tuned for the details.