This really resonated with me. In my experience, most product teams don't struggle because they don't value customer discovery; they struggle because discovery is operationally expensive. Recruiting participants, finding time on everyone's calendar, dealing with no-shows, consolidating notes... all of that competes with delivery commitments and day-to-day priorities.
What I found particularly interesting is the gap between the people who feel the pain and the people who approve the budget. Product Managers, Designers, and Researchers experience the consequences of limited customer access every day, but leadership often sees only the investment, not the friction behind it. The connection between operational efficiency and strategic outcomes was very well articulated here. When you reduce the cost of learning, you don't just save time—you improve decision-making, reduce rework, and increase confidence that the team is solving the right problem. Great insight and a very clever way to validate the hypothesis.
Thank you, Tiago. You put it better than I did: leadership sees the investment, not the friction behind it. That gap is the whole problem. The people who could authorize the fix never feel the daily cost, so it never looks urgent from where they sit.
And you named the part that matters most. When the cost of learning drops, the gain is not only time. It is better decisions, less rework, more confidence that we are solving the right problem. The time saved is just the part that is easy to measure. The rest is where the real value lives.
Congrats on the launch and on the way you used ReveLumi to test your own market hypothesis. That is a strong signal in itself.
I also like the product. ReveLumi clearly has a place in the research toolbox, especially when the real blocker is not willingness, but the operational drag of recruiting, scheduling, interviewing, and synthesis.
The part that made me think most is the late-stage research pattern in some of the answers.
Teams do not only avoid customer conversations because they are hard to organize. Sometimes that argument feels more like an excuse, or a luxury problem, used to justify premature investment into solutions. In many cases, teams simply start too late, after serious investment has already gone into the solution.
At that point, research easily stops being learning and becomes approval-seeking.
Solutionism with a research layer on top.
I guess if a company does not see the value and ROI of early research insights, it will pay for it later through expensive pivots, rework, or products nobody really needed.
Yetvart, thank you, and you pulled the most important thread. I agree: the operational friction is sometimes the excuse, not the cause. Researching late looks exactly like that, research stops being learning and becomes approval-seeking for a decision already made. Solutionism with a research layer on top, as you put it, is a sharp description.
What I see is that the two feed each other. When talking to customers is operationally expensive, the temptation is to leave it for later, and later is almost always too late, once the team has already fallen in love with the solution. Removing the friction does not guarantee research happens early, but it removes the most common excuse to postpone it. The question that stays with me is cultural: even with the operational barrier gone, how many teams will choose to listen before building, instead of after? This goes beyond tool adoption, it's a mindset change.
Joca, yes. I agree that there is a cultural layer.
But I would add one point: if the people responsible for the project do not have the competence to do early research, they should either train it or bring it in early. Otherwise, they are not just “moving fast.” They are extending the life of a potentially weak project.
In medicine, a late and letal diagnosis is expensive. In business, it is too.
And early research does not always need to be a large scientific study. This is where I think companies overcomplicate the argument. A team can run 8 to 10 good exploratory interviews within a week, using existing networks, customers, prospects, or social platforms. Or your tool.
Even with two people working five days, at a day rate of $1,000, that is roughly $10,000.
For that, you can already learn whether the problem assumption is real, whether users care, what alternatives they use today, what switching would cost them, what they currently spend or lose, and what doing nothing means.
That is not perfect scientific evidence. But it is enough to create a staged gate: dig deeper, pivot, or stop.
Compared with the cash burn of building prototypes, aligning stakeholders, creating business cases, and keeping a weak project alive, early research is not expensive. Late research is.
Yetvart, the medical analogy lands. A late diagnosis is expensive precisely because the cost compounds while you do nothing about it. Same in product.
And I like that you put a number on it. Your 10K for a staged gate is the cost of doing the research. The number worth putting next to it is the cost of not doing it. A squad of six costs around 80K dollars a month. So the comparison is roughly 10K once, against 80K a month for a team heading in the wrong direction, plus the prototypes, the stakeholder alignment, the business cases. Framed that way, early research is not a cost. It is the cheapest insurance on the table.
That framing, research as a gate rather than a study, is what most teams miss. They treat it as a big formal event, so they postpone it, and postponing is what makes it useless. One thing your estimate shows well: most of that 10K is still operational, two people for five days. Compress that load and the gate gets cheap enough that there is no excuse to skip it. Though your competence point stays. A cheap gate only helps a team that knows what to ask.
🫣 When teams are built only around formally trained solution-finders, every user and their struggles start to look like a nail, when the hammer is the only tool in their toolbox.
That is the perfect way to put it. Diverse teams ask better questions because not everyone is holding a hammer. Thanks for the conversation, Yetvart, this thread added more than the post itself. Boa noite!
Congrats on ReveLumi launch!
This really resonated with me. In my experience, most product teams don't struggle because they don't value customer discovery; they struggle because discovery is operationally expensive. Recruiting participants, finding time on everyone's calendar, dealing with no-shows, consolidating notes... all of that competes with delivery commitments and day-to-day priorities.
What I found particularly interesting is the gap between the people who feel the pain and the people who approve the budget. Product Managers, Designers, and Researchers experience the consequences of limited customer access every day, but leadership often sees only the investment, not the friction behind it. The connection between operational efficiency and strategic outcomes was very well articulated here. When you reduce the cost of learning, you don't just save time—you improve decision-making, reduce rework, and increase confidence that the team is solving the right problem. Great insight and a very clever way to validate the hypothesis.
Thank you, Tiago. You put it better than I did: leadership sees the investment, not the friction behind it. That gap is the whole problem. The people who could authorize the fix never feel the daily cost, so it never looks urgent from where they sit.
And you named the part that matters most. When the cost of learning drops, the gain is not only time. It is better decisions, less rework, more confidence that we are solving the right problem. The time saved is just the part that is easy to measure. The rest is where the real value lives.
Congrats on the launch and on the way you used ReveLumi to test your own market hypothesis. That is a strong signal in itself.
I also like the product. ReveLumi clearly has a place in the research toolbox, especially when the real blocker is not willingness, but the operational drag of recruiting, scheduling, interviewing, and synthesis.
The part that made me think most is the late-stage research pattern in some of the answers.
Teams do not only avoid customer conversations because they are hard to organize. Sometimes that argument feels more like an excuse, or a luxury problem, used to justify premature investment into solutions. In many cases, teams simply start too late, after serious investment has already gone into the solution.
At that point, research easily stops being learning and becomes approval-seeking.
Solutionism with a research layer on top.
I guess if a company does not see the value and ROI of early research insights, it will pay for it later through expensive pivots, rework, or products nobody really needed.
Thank you for bringing it up
Yetvart, thank you, and you pulled the most important thread. I agree: the operational friction is sometimes the excuse, not the cause. Researching late looks exactly like that, research stops being learning and becomes approval-seeking for a decision already made. Solutionism with a research layer on top, as you put it, is a sharp description.
What I see is that the two feed each other. When talking to customers is operationally expensive, the temptation is to leave it for later, and later is almost always too late, once the team has already fallen in love with the solution. Removing the friction does not guarantee research happens early, but it removes the most common excuse to postpone it. The question that stays with me is cultural: even with the operational barrier gone, how many teams will choose to listen before building, instead of after? This goes beyond tool adoption, it's a mindset change.
Joca, yes. I agree that there is a cultural layer.
But I would add one point: if the people responsible for the project do not have the competence to do early research, they should either train it or bring it in early. Otherwise, they are not just “moving fast.” They are extending the life of a potentially weak project.
In medicine, a late and letal diagnosis is expensive. In business, it is too.
And early research does not always need to be a large scientific study. This is where I think companies overcomplicate the argument. A team can run 8 to 10 good exploratory interviews within a week, using existing networks, customers, prospects, or social platforms. Or your tool.
Even with two people working five days, at a day rate of $1,000, that is roughly $10,000.
For that, you can already learn whether the problem assumption is real, whether users care, what alternatives they use today, what switching would cost them, what they currently spend or lose, and what doing nothing means.
That is not perfect scientific evidence. But it is enough to create a staged gate: dig deeper, pivot, or stop.
Compared with the cash burn of building prototypes, aligning stakeholders, creating business cases, and keeping a weak project alive, early research is not expensive. Late research is.
Yetvart, the medical analogy lands. A late diagnosis is expensive precisely because the cost compounds while you do nothing about it. Same in product.
And I like that you put a number on it. Your 10K for a staged gate is the cost of doing the research. The number worth putting next to it is the cost of not doing it. A squad of six costs around 80K dollars a month. So the comparison is roughly 10K once, against 80K a month for a team heading in the wrong direction, plus the prototypes, the stakeholder alignment, the business cases. Framed that way, early research is not a cost. It is the cheapest insurance on the table.
That framing, research as a gate rather than a study, is what most teams miss. They treat it as a big formal event, so they postpone it, and postponing is what makes it useless. One thing your estimate shows well: most of that 10K is still operational, two people for five days. Compress that load and the gate gets cheap enough that there is no excuse to skip it. Though your competence point stays. A cheap gate only helps a team that knows what to ask.
🫣 When teams are built only around formally trained solution-finders, every user and their struggles start to look like a nail, when the hammer is the only tool in their toolbox.
Tenha uma ótima noite.
That is the perfect way to put it. Diverse teams ask better questions because not everyone is holding a hammer. Thanks for the conversation, Yetvart, this thread added more than the post itself. Boa noite!