> ## Content Index
> Fetch the complete content index at: https://christingeorge.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Asking Is Cheap
- URL: https://christingeorge.com/asking-is-cheap/
- Published: 2026-10-07T05:20:49.000Z
- Updated: 2026-10-07T05:20:49.000Z
- Description: How I ask opinionated product managers to test their ideas with customers before arguing for them, and how interviews became part of judging a release.
- Author: Christin Emmanuel George
- Tags: Product, Customer Research, Product Leadership, The Workshop

The hardest thing I ask of strong product managers is to come back with evidence for an opinion they already hold. Good product managers are opinionated, and I do not want to remove that, since having an opinion is what made them strong in the first place. What I ask is that the opinion goes to customers before it goes into a roadmap.

The line I have used with every team I have led is that asking is cheap. A customer conversation costs an hour, and a clickable prototype costs a designer a few days. Building the wrong product costs a quarter of engineering time, and then more time to take it back out.

The line has a second half. Customers will ask for the moon, and the useful question is whether they will pay for the transport. What someone would give up budget, time or an existing workflow to get is the question a product has to be built on.

### Why belief is not enough

A motto from my years running MindHelix was "build, break, innovate". Break is the word most teams skip, because you cannot break your own work when you already believe in it. Someone outside has to do it for you.

On my teams that someone was the customer. Before we built, we put a clickable prototype in front of customers and asked them to say out loud what they were thinking as they moved through it. People are polite about an idea when you describe it to them. They are far more useful when they are lost on the second screen and saying so.

These conversations changed large decisions. One led me to scrap a product the organisation had already approved. Another time we had an approved feature planned that built on a part of the product everyone, including me, assumed customers used. In one conversation a customer mentioned, almost in passing, that they did not use it. We checked, found that most customers did not use it either, and dropped the feature to rebuild the part underneath it. Both calls were unpopular when I made them, and both cost far less than shipping and finding out afterwards.

### How we judged a release

I did not run all of these interviews myself. I set the practice up for the team and made it part of how we judged whether a release had succeeded. I took the sessions personally when the customer was large or the participant was senior.

After a release we could see usage, so we split customers into heavy adopters, mild adopters and those who had not adopted, and we interviewed each group. The outline was the same for all of them: what the older workflow was, what was helpful about it, how the new one compared, and what would make their working day easier. I started from the old workflow because that is what a new feature is competing with.

Non-adopters were the group I learned the most from. A few of them started using the product after I walked them through it. For those customers the gap had been in understanding the product. A usage chart would have counted them as a failed release.

Once an interview was finished, I used the last few minutes to test what I was considering for the next quarter. By then the person had spent the whole conversation in concrete detail about their own work, so their reaction to a new idea was grounded in that detail. A reaction given cold, at the start of a call, is worth much less.

Building software gets easier every year, which moves the hard part of the job to knowing what should be built. I still want the opinion. Validate it, run the experiment, and then argue for it as hard as you like.