Would you use product X?

Do you like product X?

What do you enjoy most about the user experience?

These questions all elicit feedback. However, these questions are broad. If you want more specific feedback that you can transform into changes to your product, you will want to ask questions that elicit more details.

If this insight seems obvious, why do we - as builders, designers, and coders - all too often ask for product feedback that leaves us no better off than we were before asking?

I believe - and will provide examples to support in the article that follows - that by asking probing questions, we can collect actionable feedback that leads us to make worthwhile product improvements.

But only by asking the right questions, at the right time and in the right way, can this value be unlocked. If you need help learning to ask the right questions (and follow-up questions), this article is for you.

I have learned how to ask questions through a mixture of patience, practice, coaching, and building.

First, some relevant stories from my past missteps.

How my firsthand experiences building led me to ask different types of questions

When I started a FinTech company to help kids and parents learn about financial education at home, I asked parents if they thought financial education was important to the well being of their children.

What do you think these parents said? As a matter of fact, nearly 100% said that “yes” such education was important.

Guess how many of these parents went on to use the product I built? Only a fraction.

This short example illustrates the importance of asking the right questions. I asked the wrong one. Perhaps I should have asked the following:

  • What tools do you use today to teach your children about financial education?
  • Why do you value teaching your children about money?
  • How are you planning to educate your children about money?

All three of these questions probe the same assumption as the first question: namely, that parents will want to teach their children about financial literacy.

But these questions are fundamentally better because they probe deeper and give the user room to explain their logic and rationale.

This qualitative feedback - where we can go deeper beyond assumptions and platitudes - is where insights exist to shape better product experiences. And that is a central goal for builders.

A second aim of builders is to not only build products that people use, but to build products that people find uniquely valuable.

When I was starting my career I had aspirations of being a Product Manager. A friend, who was a successful Senior Product Manager at Google, challenged me with a simple assignment: build a product that 10,000 people use.

I thought deeply about the challenge and looked into tools to help with student loans and Mapping APIs. Ultimately I decided that I would build a tool that helped solve various problems in my own life. I sat down and thought through these questions:

  • What is a problem I currently have that technology can help address?
  • Can I build a solution?
  • Do I know how to build the technology?
  • If I build a product, can others benefit from it too?
If you build it they may come...but you need to ask what your users want and need first.

I decided to build a Chrome extension that enabled users to quickly switch between tabs. After roughly 6 months on the Chrome store the free extension passed 10,000 active users.

I sat down with friends and started asking them how they used the tool and what they needed the tool to do to add more value in their lives.

I honed in by asking very specific questions:

  • How many times do you use the tool (and I would cross reference this with internal data)?
  • What does the tool not help you do that you need it to do?
  • Can I join you at your workstation or desk and observe you using the tool?

These questions led to new insights.

Ultimately I decided that the improvements users wanted were beyond my technical capacity.

So I let the tool sustain itself without further coding improvements.

What did I learn from this experience?

Firstly, building is rewarding. Solving your own problems with small tools and hacks can be great fun and also educational.

Secondly, when you build something that has utility, and others start to use it, you have a unique opportunity to learn from users to make improvements.

These improvements, in turn, can yield even better product features, designs, and outcomes. These enhancements can better satisfy and align with the needs of your users.

Hence a small flywheel can be set in motion.

And lastly, it’s ok to build and push the limits without committing to further releases and development work. It’s ok to say “no” and allocate your time and technical resources elsewhere.

By asking the right questions you can unlock real value.

But this value does not need to be applied just to development cycles. It can also make you realize you are headed down a path you don’t want to be on.

And you can use insights from users - and gleaned from the questions that you ask - to make better informed decisions.

I had a product manager who once noted: “if the feedback is not a strong yes, then it's a no.” I think about this belief system a lot because I am always looking for perspectives that can help shape, inspire, and influence the products I design and build.

I would challenge that product manager - and you - to amend that quote: “If the feedback is not a strong yes, ask why not. If you can’t glean insights from users, then it’s a no.”

The art of intentional product feedback starts with you - the builder - and an open mind.

But tied closely to an open mindset is the ability to ask the right questions. It is healthy to say “in the spirit of open-mindedness, I’m striving to learn and I am learning by asking questions.”

There are many educational tools, online schools, engineering communities with online coding tests, and communities like freeCodeCamp to help you learn to engineer, design, wireframe, and deploy products.

But how many of these tools teach you how to ask questions, think critically about the replies, and then circle back with relevant follow up questions?

When building anything for others - a tool, a website, an app, or highly specialized software (like a QR Code Generator) - you need to know what people want, need, and most strongly value.

Only by asking questions can you learn these things. Only by asking questions can you produce a product that gets your users to a “strong yes.”