Chalk X

Summary:

• Brilliant ideas from senior leaders can be dangerous due to cognitive bias.
• There are only 2 predictors to a successful product, 1. It doesn’t get canceled 2. Users proactively choose to use it. 
• Knowing who your users are and what they will use is the most important thing to figure out.
• In internal company products, IT software/systems, users are sometimes hard to find but the effort is worth it.
• Stakeholders of all types need to be managed/influenced but winning them over won’t yield a profit.

A Parable:

In the early 2010s Jeff Bezos had a brilliant idea. His idea: Amazon needed to be in the smartphone business, and it needed to be a cheap smartphone that used 3D technology. By all accounts Bezos got deeply invested in his brilliant idea and moved forward with designing a phone he thought was really cool. Ultimately no one wanted the product and the phones eventually sold at less than a dollar just to get rid of the inventory.  This netted 170+ Million dollar loss for the company.

The Danger of Brilliance 

In product development there is a saying, “There is nothing more dangerous than a senior leader with a ‘brilliant idea’”. This is usually because there is no opportunity to validate the assumptions around the idea being brilliant or not. Most of the leaders we think of as brilliant have had their fair share of flops as well. Steve Jobs had the Apple Newton, a personal assistant device that cost $2,500 dollars at launch vs. the existing Palm Pilot which cost $299 at the same time. Microsoft had the Zune, a pocket music player that had no exclusive music vs Apple’s iTunes. Google+ trying to take Facebook’s market but with no unique differentiator. 

In each of these scenarios the leaders of these companies ran into a common product design fallacy: 

1. Copy what the other guy is doing. 
2. I have a brilliant idea on how to do that. 

Why does this happen? Unfortunately success comes with cognitive biases. The more we become successful the more confident we are in our success. This is sometimes called a hot-hand fallacy, if we won before we should win again regardless of the differences in environment, context, or expertise. Add to that the overconfidence effect, where we overestimate our abilities, especially if we have been successful in the past.

As complexity in a problem grows it inherently gets harder and harder to solve the problem, but because of our natural bias we don’t recognize the gap.

I first became aware of this in my first day of studying business strategy at WP Carey School of Business at Arizona State. The Dean of the school started us with a test. “You’ll do fine. You all were smart enough to get in to the school.”, he said. It was a single sheet of statements, “The highest cause of deaths for men over the age of 40 is cancer.” and do you agree or disagree followed by a confidence rating 0-100% confident. Basically we were wrong and overconfident. “In all the years I’ve done this it never fails, everyone of you is overconfident in things you know nothing about.”

This can be seen in every day life. The next time you are at a cocktail party and someone is telling you how they have the idea that would fix the economy, ask them if they would fix your broken toaster. Likely they wouldn’t know how. Which is more complex, the economy or the toaster?

There is a better way:

What is successful in the market is a terrible indicator of the success of a future product. There has been research on this and there are only 2 predictors of a return on investment of a product. 

In product design we have 2 goals, reducing the risk of our project getting canceled (a story for another day) and finding out what our users will proactively use. 

In my previous article I introduced the product development lifecycle. The second step is validate with everyone. There are lots of people to validate with, but users are the ones that matter most. Sorry brilliant CEOs. 

Users: 

Since the best predictor for success is “will users proactively use it”, then that has to be our top priority. But who is using our product? Sounds simple but it isn’t always straight forward. 

When you go and buy something at the store, you are the customer, user, and typically the only stakeholder. Inside a company these roles are frequently held by different groups, and sometimes those groups have representatives.

The easiest way to see the differences is with an example. Let’s consider a fire truck as our product: 

If your product is a Fire Truck then the user is a firefighter, customers are city councils since they provide the money, and one key stakeholder are property owners who don’t want their houses burning down in a fire. Each group has different demands and interests. Even among firefighters there are various groups like drivers vs. nozzle firefighters.

All these folks matter, as they all need to be invested in wanting your product. There are probably more types of stakeholders than anyone else. They can greatly influence a purchase, block usage, prevent the project from being built, etc. For stakeholder management I highly recommend Charles Lambdin’s series on influence mapping.  

How to Validate if a user will use it:

Hopefully you have identified the users and their problems in the discovery process. Without this we don’t know demand and you probably should go forward. Assume we know the demand then within the product development cycle there are at least 3 check points with users before implementation. 

Validation – Here we validate what we found in our discovery process. There are three main things to make sure we validate: can it be built, can we/users afford it, and will users want it. They all should be validated but the first one is will users want it. After all, if they don’t, who cares what it costs. Here we may ask more users than those in the discovery process if they too would want to use it. 

Mockup – Mockups can be for users, customers, or stakeholders. Again we prioritize users to show them possible implementations and get their feedback. A mockup is a picture, drawn quickly. Maybe a post-it interface where options can be swapped out. This really is testing workflows, solutions, and understanding. Fast, cheap, simple.

Prototypes – Build a pseudo working product. This maybe a website without a backend, a 3D printed example, wireframing tools (UXPin, proto.io, etc) , or anything a user can interact with that will mimic the product and give your team feedback. 

There is a distinct increase in effort at phase. Our goal is to test assumptions as cheaply and quickly as possible. Since cancelation is a risk to our success, we don’t want to spend too much time, effort, and money before we know the customer desires. Ideally we can identify what they MOST need. This will allow us to implement something we know has demand.

Usage:

• If someone comes to you with a great idea, always take it through a validation process. Make them a co-traveler if possible. Follow up questions are always helpful like “That sounds interesting, how did you realize that?”. “Which users do we want to focus on first?. “Let’s see if we can’t get a mockup in front of our users to see how they would use it.” Some great ideas may be great but they need to be tested, before that they are just a hypothesis.
• Find your users, as many as you can. A user representative is nice but they are a stakeholder not a user. There are different user needs even within a demographic of users. One size does not fit all.
• See what they do, not what they say. Only their proactive use not lip service will get you a return on your investment. Seeing how a customer uses something has more information than a conversion or survey.
• If you have lots of influences on the product design other than users, we all do, try some influence mapping.  It is a great technique to keep moving forward with your product.