Translating customer requests into product innovation

There’s no such thing as a perfect product - everything has room for improvement. But how do we determine the right product innovations?

In this article, I’ll share three metrics to look out for, how to gather customer requests, and how to translate them into the right product innovations.

But before I do that, I want to say everything I'm going to share is my own personal opinion, these are my personal views.

What is product innovation?

Before I actually start getting into how to capture customer requests, and how to convert them into product innovations, I want to talk briefly about what a product innovation is.

Three classifications of product innovation

When it comes to products, there are three main areas you can classify a product innovation into.

Net new

The first one is you're creating a net new product, you're creating a product that your company does not offer today, or no one offers today. How do you build a new product based on customer requests?

A pivot

The second one is you have a product, but based on some feedback, you want to pivot from it. That's pivoting from an existing product line.

Building incrementally

The third one is you have a product, and you want to build incremental features on top of it. You want to keep making your product better and provide more features so users find it even more valuable. That's product innovation to build an incremental feature.

How to determine the right innovation: three metrics

For any product innovation, how do you determine if that is the right innovation? If that is the right product idea? The way to do that is to assess that idea on three different metrics or three different pillars.

1. Viability

The first one is viability. By viability, I mean a few things. The first is you as a product team, or your company has a mission. Does that product innovation align with the goal of your product? Does it align with your company's mission?

Viability in the business context could basically come down to is it something for which someone would pay? Because at the end of the day, you're making a product for someone to buy or someone to use so you can monetize it in a different way.

So is there someone who finds the whole idea around a product a viable business offering?

2. Feasibility

The second pillar to determine if your product innovation idea is a good idea is to determine if it is feasible. Feasibility is critical because a lot of times when we hear feedback, or we do brain-storming, we come across many ideas which sound great, but there is no technology to support those ideas.

A good example of such an idea is autonomous driving, we all want cars to drive on their own, but it is not something for which we have foolproof technology. Yes, there are many companies, big, small, and all kinds who are trying to solve the whole problem or trying to solve small components of the whole ecosystem.

The hope is that in a few years, we will have that ecosystem where cars can drive on their own. However, that does not exist today. So it's critical to see what is on the horizon of your product and whether the product you want to build is going to be feasible on that horizon. Is there going to be technology to make your product a reality?

Again, when it comes to technology, there are companies who can choose to build that technology, but if you're not in that business, and if you're relying on existing technology, then that technology has to exist to make your product idea a reality. If that is not the case, then that is not the right product innovation idea for you.

3. Desirability

The third one is desirability. We talk a lot about viability, that someone has to pay, and they should see value in it. Then it has to be feasible, there has to be technology to make it happen.

Desirability is equally if not more important. By desirability, I mean do your end-users get excited when they have to interact with your solution? Or do they feel this dooming dread,"Oh, I have to go in and start working on this product now, and I just don't want to interact with this. The user experience is so bad, and I had to do so many things manually to make it happen".

If that is the case, then your end users are not happy interacting with the product. A good product and a really successful product provides a good end-user experience. So you have to also assess your idea on how you're defining user experience and if your customers, your end users are going to like that or not.

How to gather customer requests

I'm going to move to how do we actually go about collecting or gathering customer requests? It sounds like a very simple and intuitive thing to do. You talk to your customers, and you see what their pain points are and what's on their wish lists. You collect all of them and there we go, you have exactly what you need to build a product.

But something that sounds so simple is actually not that simple to do in real life. The good thing is, that there are multiple ways we can go about collecting feedback from customers and collecting requests from customers.

Data mining

The first one is data mining. If you happen to be in a business where you have many touchpoints with your end-users, and you can collect direct feedback from them, then you are already sitting on a wealth of knowledge where you can figure out what it is your customers are struggling with.

What are they hinting at or telling you directly or indirectly that this is what they expect from you in your next product innovation?

Leverage existing data

If you have a community where people are discussing what problems they face if you have a call center where people are reaching out and explaining what kinds of problems they are struggling with if they're leaving feedback for your products about what they don't like or what they like, all of that is somewhere already sitting in your data.

So if you have access to such data, the simplest, easiest, fastest thing you can do to understand what it is that customers expect and want from you, is by mining this goldmine of data you are already sitting on.

Surveys

The second mechanism through which you can collect customer feedback is through surveys. You can conduct a survey, an online survey, which is totally randomized. If you go to let's say a website, it'll just pop up and you answer quickly one or two questions. You can get information from customers.

Surveys have purpose

The way surveys differ from data mining is data mining could be all over the place, you don't really know what you're looking for, so you have to be very smart in figuring out what you want to look for. But surveys are designed with a purpose in mind.

Let's say, for example, you're building a new tool or you want to establish if there is a market for some idea you have, you can run a quick survey and you can ask simple questions like "Would you use a tool like that?", and that gives you an idea there is a market for such a product, if there are customers or end-users who are struggling with this, they see this as a pain point, and if they're going to be using it eventually.

Surveys aren’t biased

Surveys are quick, cheap, and at the same time randomized, so they don't necessarily have any bias in them. So you get a pretty good representation of the whole population, and you get a good idea of how this product will work for the vast majority of my audience.

Again, the thing about surveys though, is it has to be focused. You have to know what it is that you want to establish or reject by conducting a survey.

So data mining and surveys are non-invasive or indirect ways of understanding what consumers and end-users want from us.

User research

The third method to collect feedback is basically to do user research. This happens a little down the line in the product lifecycle, this happens after you have already established there is a market, there is someone who's going to pay for it. Now you want to establish what exact problems you want to solve in this space.

You've established a broad product concept, a broad idea that this is what you want to do, you have a few personas in mind that these are the people who will benefit from this product. What you want to do now is research with these end-users and personas to see how their typical day is, and what kind of things they would like to do with such a solution, which today is an idea, but if it were to become reality, what kind of things would they expect?

What is it they're struggling with today in their life? And if this product were to become available, what will be their expectations from it?

Shadowing

The fourth one is one step deeper than user research. Because in research, you're mostly asking questions. Granted, there are open-ended questions like 'walk me through your day' and 'how would you go about doing something like this?' And maybe a series of 'why, why, why'. But they are still pointed questions.

Questions can be flawed

In shadowing, you're not necessarily asking questions. The reason to do this is when you ask people a question, they try to answer it to the best of their knowledge. Our brain works in such a way at times that we create things that maybe don't exist, we try to answer things that are maybe only true in our head, but not a reality today.

To eliminate all that bias, there is a fourth mechanism through which you can collect customer requests, and that is called 'shadowing'.

In shadowing, what you're doing is basically sitting next to your end-user, your persona, and just watching them.

• How do they go about carrying out their daily activities?
• Are they struggling with something?
• Are there tasks they have to do manually?

That is how you figure out, in this persona's day-to-day life, what are the areas where you can bring improvements and make their life easier? That's the concept of shadowing, and you're not really asking questions while shadowing you're just sitting there like a fly on the wall and watching what the user is doing.

Brainstorming workshop

Finally, the most interactive mechanism is a brainstorming workshop. In some ways, this is the culmination of steps one through four.

• You have established your market.
• You have also done surveys to see if people are struggling with this problem and they are looking for a solution for this.
• Maybe you have gotten some ideas through data mining.
• You have done your user research.
• You have also done your shadowing, and
• You have synthesized the result of all this into some key broad product and feature ideas.

What you want to do in brainstorming now is get together with the right set of people, this set of people are maybe someone you shadowed or someone who is going to be paying for your product, some other people who are going to be building it, or designing it.

Refine the ideas

In this multidisciplinary workshop, you're basically refining those ideas, you're voting on those ideas to see which one makes sense, and which one doesn't. Then you're refining the ideas that make sense, the ideas you want to build right now.

You're building low-fidelity prototypes, you're coming up with the high-level architecture, and what different components you need. The output of this workshop is a very low-fidelity blueprint for your product.

What next?

Finally, I want to leave a few thoughts after you collect all this information. Information is all around us, we live in the age of data, there's data around us, and to some extent, we can say there's a lot of information around us as well.

What to do with your findings

But how do you find what is the right information? And once you find that right information, where do you go from there? I want to leave you with a few key things you can do with the findings of the customer requests.

Prioritization

Let's say you've figured out a few customer requests, the first thing is you want to go through all of them, and see which ones actually make sense. Here we do prioritization.

Again, some of these ideas might be very high-level ideas, and maybe they are product ideas for things that don't exist today, or maybe they are incremental features. Nevertheless, you'll end up with at least a few ideas 5, 6, 7, maybe 10, which is a good thing.

You don't want to be in a situation where you don't have any ideas, it's good to be in a situation where you have a lot of things to do. Now the goal is to figure out which ones are the right ones to do now, and which ones are the things you would do later.

For this prioritization, you keep a couple of things in mind.

Value

The first one is how much value is going to bring to your customers? So you can get an idea while you're shadowing them, or when you're interviewing them, or when you survey them, you try to get an idea of how valuable this information or this product feature/innovation will be for my end-user.

And you rank the list of requests you've received for product features or product ideas based on how much value it's generating. If we could build everything that generates value for customers, that'd be great.

Resources

But we also work with limited resources and sometimes our technology is not there to enable all these features. So you try to apply these filters to see how much value it generates for customers. How much time will it take for me to build it, mobilize it, and make it available to customers?

Time

Thirdly, do I even have the technology to make all of this? Is it something that's available today, and then I can make it work right now? Or do I have to wait for maybe the next six months for something to become available for this feature to become a reality?

So you apply these filters, do a joint weighted average, and then figure out which ones have the highest impact, and least amount of time, and you don't have to wait for anything to become available. That's how you go about prioritization.

Add details

Once you've prioritized on a high level, you want to add details to those ideas. Because a simple thing, like let's say you're in a video streaming service, you want to build a recommendation feature, for example.

Maybe customers have told you, "once I'm done watching a show if I like that show, I want similar shows to be recommended to me". In concept this is great, it's obvious to see how it will add value to customers and end-users.

But you want to go deeper than that, when you're actually talking about building a product feature, you want to see:

• How the user will interact with this thing and how many recommendations you want to make.
• What if the user does not choose any recommendation or does not like a new recommendation?
• How will you take that feedback into your recommendation engine?

You need to define at least some level of detail as to what things you want to build as part of that recommendation engine.

After you prioritize, the next step for you is to add details to build that idea as a product requirement.

Low fidelity prototypes

Once you have added certain details, for example, in my recommendation engine, “these are the five things we could potentially do” but let's say in the first version, we only want to do numbers one and two.

For number one and number two, what you want to do now is some low-fidelity prototypes, you want to see:

• How it'll look to the user on the screen,
• How are they going to interact with this thing?
• Is it something that's on a touchscreen or they're interacting through voice? And
• What happens when they interact with it?
• How do you capture that feedback?
• How do you refresh their list?

Gather feedback

So for the things that you want to build now, you want to create low-fidelity prototypes of that so you can get immediate feedback in the workshop I was talking about. If you are doing a brainstorming workshop, you can get feedback there.

Otherwise, you can identify a set of personas and users and say "hey, these are the two or three low fidelity prototypes we have for this recommendation feature we are building", and get their feedback before you actually start building anything.

Put something very low fidelity, maybe just wireframes and mock-ups, and walk a few users through them and see how they work.

• Is it intuitive?
• Are they liking that experience?

Validate

Get their feedback so you already have something from the end-user before you start building. This also helps you validate your requirements, and your thinking around how the product feature will work with the end-user.

Again, as I was saying that desirability is a key aspect of a successful product. If end users do not like to interact with your feature, they might still do it because it's part of their job, or there is no other way around but the moment they find a product doing what your product does, but with a better experience, they will abandon your product.

It's key to providing a really good end-user experience.

The building lifecycle

Finally, once you've collected the requirements, prioritized them, built some low-fidelity prototypes, ran them by your end-users, managed their feedback, and refined what you want to build as the MVP, you build it.

Ongoing feedback

In the building cycle itself, if you have tools and the mechanism to keep getting this continuous feedback from the end-user, for example, if you're working with a couple of big enterprise companies who are very interested in your product, then you could get this feedback from them on an ongoing basis.

But if you are more on the consumer side, where it's not possible to reach out to the same set of users all the time, or any set of users all the time, you could do feedback sessions that are farther apart. You could do paid sessions where users can provide feedback on the actual working demo/working prototypes of your demo.

That's how in your build cycle, you can continuously keep getting their feedback and iterating based on their feedback.

A never-ending cycle

Once everything is ready, you test it, you launch it, and you keep an eye on your key metrics, you still keep collecting feedback. The product innovation cycle keeps going on because, in theory, it's a never-ending cycle.

There’s no such thing as perfection

There is this concept of a perfect product. It's only a concept – it doesn't exist. There is no such thing as a perfect product, there's always room to make a product better.

There's always room to make your products simpler for end-users to use, and there's always room for your products to expand the horizon of what they can do.

That's why it's a never-ending iterative process.

Thank you.