It's so much easier to suggest solutions when you don't know much about the problem.

Why is research so important?

I was talking to a friend of mine recently who had an idea for a new app. While the idea seemed interesting. I had some questions: What problems would it solve? Who would be it's main users? Are there any similar services on the market already? For any inventor, entrepreneur or product development team these should be the questions that you ask at the very beginning of your project.

Research is not a phase in the development of products, it is the engine that drives the development and refinement of products and services.

In order to correctly apply research to every aspect of product development you need to understand why it is so important. And this needs questions, not ideas. Tomer Sharon tells us that he interviewed 200 product managers/founders during the research for his recent book Validating Product Ideas. Out of the 200 only 2 kept a notebook with a list of questions. The other 198 had notebooks full of ideas.

Understanding the Problem

Michael O Leary, CEO of Ryanair, Europe’s largest airline recently attended a conference about creativity at the US Embassy in Dublin.

Although, the point of the conference was to highlight creativity and innovation, there were signs that O’Leary didn't really understand the point of innovation. In some off the cuff remarks, he commented on cyclists in Dublin and the blight that they are on the city. What he blurted out:

That’s all we need in Dublin going forward is more bloomin’ bicycles. In a country where it rains about 250 days a year, the way forward in Dublin is: more bicycles...We should take the cyclists out and shoot them.

This would certainly solve the problem of cyclists getting in the way of the rest of the traffic but it is a perfect example of someone thinking too much about the solution and not enough about the problem.

Problem: Cyclists are a nuisance on Dublin streets
Solution: Get rid of Cyclists

While there is a simplicity of thought which makes the solution very attractive, I wonder if a little more time could have been spent on the problem before moving on to the solution.

Why are cyclists a nuisance to other road users? Because there are no cycle lanes. Why are there are no cycle lanes? Because we need more space for vehicles. Why do we need more room for vehicles? Because it is too dangerous to cycle in Dublin.

There could be other solutions to this problem, but as you can see by thinking through the problem it is more likely that we will be able to get to the root cause rather than dwelling on the symptoms.

Applying this to product development

Let us look at a specific product which also fell down when it came to research and defining the problem.

In 1975 Sony launched Betamax, the first home video recording machine. From a technical point of view it worked as well as VHS which was a later arrival to the market. JVC who launched the VHS format were solving a different problem to that being solved by Betamax.

What was the difference between the understanding of the problem? The Betamax format allowed home users to record up to one hour of television so it worked well up to a point.

JVC went further and developed a 2 hour format which they extended to 4 hours by 1977. As a result the VHS tape could also be used for movies and as a result 40 production companies signed up with JVC to use their format. Sony soldiered on for another 11 years before conceding defeat and moving over to the VHS format.

Defining the problem

If I were given one hour to save the planet, I would spend 59 minutes defining the problem and one minute resolving it.
Albert Einstein

There are some very simple reasons why people often fail to adequately define a problem. The biggest culprit is that no time is spent thinking about the problem.

High level thinking
Michael O’Leary was probably guilty of focussing too much on high level thinking in his attempt to solve the transport problem in Dublin. While, it may look good on first viewing. The details are a little bit controversial and it is pretty clear that his solution would not work.

Buzzwords

When used too liberally, marketing buzzwords become a crutch, filling silences and convincing ourselves that our actions are taking us in the right direction.

While a buzzword may begin as a genuine concept it quickly loses all meaning when overused by someone who doesn't understand what they're talking about.

Have a game of buzzword bingo with a speech from the Governor of the Bank of England and see what you think. Does he really know what he's talking about?

Getting stuck on the first level
In essence getting stuck on the first level means you are solving a symptom rather than the problem. You need to examine the problem and ask lots of questions about the it.

The 5 Whys are set around asking ‘why' to a problem, getting the answer and then asking why again and again, until you come up with the real root cause of a problem.

In any situation if you are asked why? The natural human response is to give the simple or most obvious explanation. Human instinct was not always like that. If you think about children and their incessant ‘whys’. It is not easy to answer more than one or two of the whys when a child is putting the questions.

Asking questions is the key
You need to create a time for asking questions and a time for providing answers. The latter may seem more important but that is an illusion. It is the ability to ask the right question that is the most important part of the research phase. In order to ask the right question, you need to ask a lot of questions. As with brainstorming, no question is stupid and all need to be put on a post-it, written on a whiteboard and left for later discussion.

Is research compatible with the lean methodology?

The answer to this is simple. It has to be compatible. If you are not building learning and research into your development model then who exactly are you developing your product for? Whether it's agile, waterfall or lean is meaningless unless you are constantly asking questions of your product, your users and your team.

Tomer Sharon notes in his book that the Build-Measure-Learn feedback loop can be too convergent at times to allow for flexible problem solving. But, this is only the case if the product manager/founder is too rigid in the first place. If you continue to ask difficult questions then you can decide whether it is time to pivot or persevere with your product roadmap. To quote Steve Blank:

"Build, Measure, Learn – isn’t just throwing things against the wall to see if they work."

The key to making any idea or product work is to make sure that you have fully implemented research throughout all phases of the product's development. If, for example, you omit it from the first phase you end up building a product or service that solves the wrong problem or only solves a symptom of a larger problem.