Today we’re digging into @maret_kruve’s article today, Five Dangerous Half-Truths That Make Bad Product Ideas Sound Good. She argues that product teams are telling partial truths that feel safe and reasonable. Let’s call it fake confidence. Those half-truths survive because organizations reward certainty and polished stories.
Over time, stories begin to replace evidence. AI makes this harder to notice…outputs look convincing and often pass the eye test. Ideas appear finished before they are tested, and teams can fool themselves without realizing it. From my own experience, staying focused on evidence is tiring. It takes real discipline from a team.
Here are the catchphrases she highlights that weaken products as ideas harden into decisions. They all sound reasonable, but compound the problems when we don’t find the evidence to support them.
“Users want this.”
“Engineering says it’s doable.”
“Users can figure it out.”
“It will be profitable.”
“Users will find it.”
Let’s jump into the discussion
You offer a practical shift. Instead of debating stories, teams should ask for evidence across five areas in your ADEPT framework: user need, team ability, actual effectiveness, total cost, and adoption reality.
You’re not saying there is perfect certainty, but the goal is to find strong signals.
So here’s the question I want to open up. We’re constantly told storytelling is a powerful tool. I don’t think the argument is that storytelling is bad. It’s that we are leaning too far into narrative and not far enough into evidence. Why does this happen?
Let’s dig into product validation with Maret Kruve. Maret is a featured Helio author and has spent time developing her ADEPT framework. Excited to talk about all these lies we tell ourselves.
“If users really needed your feature, they’d already be desperately trying to solve the problem themselves. Real demand creates visible pain, workarounds, and user-generated solutions.”
Let’s jump into the first question. What evidence do you think is necessary before saying “users want this”? If others in the community have questions, jump in!
For me, “users want this” starts when I can see pain in their behavior, not just hear vague interest in their words. I have more confidence when problem shows up without me pitching the idea first. In practical terms, this means that users are bringing up the problem unprompted or have hacked together workarounds. These I’d say are high quality signals and theoretically I’d prefer to see a sizable amount of those, but in reality I’ve deemed just handful of those enough too
This makes sense. Focus on problems that are obvious and easy for a user to identify where to start. Some problems though require a level of coordination across a group of people, like in B2B products. Do you treat these the same way?
Great question. I treat them slightly differently in form, but not in principle. In B2B the signal isn’t always just one person developing a workaround, it’s organisations creating weird and informal rituals and processes to cope. Spreadsheets, Slack channels, excessive meetings, manual handoffs - those are all workarounds. So I still look for unprompted pain and signs of ineffective solutions, just sometimes expressed collectively not individually.
This makes sense. In our own work, I find that showing evidence across a series of events or activities in a business is challenging, especially when you need to get your team aligned to identifying whether the problems are worth solving.
The signals need storytelling to frame the problem. I think this is where it gets muddy and starts to bleed into… “Users can figure out how it works.”
In these scenarios, we’re searching for the connective tissue that makes the solution make sense. This seems to push teams into spirals, especially when builders are chomping at the bit to address the product. We WANT IT TO WORK. Recommendations here?
This makes sense. In our own work, I find that showing evidence across a series of events or activities in a business is challenging, especially when you need to get your team aligned to identifying whether the problems are worth solving.
The signals need storytelling to frame the problem. I think this is where it gets muddy and starts to bleed into… “Users can figure out how it works.”
In these scenarios, we’re searching for the connective tissue that makes the solution make sense. This seems to push teams into spirals, especially when builders are chomping at the bit to address the product. We WANT IT TO WORK. Recommendations here?
Stories are unavoidable if you want alignment. I’ve tried “selling” ideas with just evidence and with stories… and stories always win. By far. They create momentum in a way raw data unfortunately doesn’t.
I see it like that: a good story is a delivery mechanism, not a decision-maker. Evidence is what should inform confidence that we’re not fooling ourselves. So as a product leader, no matter if working on my own product or mentoring others, I think the responsibility is to look past the narrative layer and ask: “What evidence is this actually grounded in?”
So for my own work at least, I convince myself with data first, then convince others with stories.
Great. This is all fine until the CFO comes into the room and wants to know whether this is going to generate money. How do you collect evidence of profitability before the product is built?
Great. This is all fine until the CFO comes into the room and wants to know whether this is going to generate money. How do you collect evidence of profitability before the product is built?
That’s a million-dollar question, right? If there would be a sure-way how to prove profitability upfront, everyone would be only building million-dollar products.
That said, you can reduce risk by grounding the math in reality. I look for evidence that money already moves around the problem: what people are paying for today and what it costs them not to solve it. Even before building, you can validate price sensitivity, procurement friction, and sales cycles with real buyers.
This work is not about getting to 100% certainty about the payoff, more about discovering potential dealbreakers before it’s too late.
Yes, so much of this work is reducing risk, perhaps not actually having the answers. Do you have any specific patterns or techniques for helping people “remove” bad ideas?
When someone pitches me their idea (e.g in hackathons/startup programs I mentor often), I usually use ADEPT in my head first to understand how well I understand the idea. In most cases there will be things they don’t mention, eg around building costs (“practicality”) or GTM (“targetability”).
Then I ask questions to fill in my knowledge gaps. Because “why” questions come off aggressive, I try to use “how” questions instead. E.g “how do you know your solution is going to save users more time/money than X?” Or “how do you plan to find and convince your first 10 users to try it?”
Usually the discussion and conclusions flow quite naturally from there.
If needed, I give my assessment framed in terms of risks and unknowns. Something in lines of “The biggest risk I see is that while you’re solution looks quite promising, you’re building for an extremely crowded market and you might have trouble getting noticed. If I were you, I’d try to….” And list options how to reduce those risks.
At least for early stage ideas, I’ve learned that I’m not particularly good at fortune telling. So instead of telling my overall opinion, I suggest risk management options instead, so they can do the work and figure out themselves how good or bad the idea is.
@maret_kruve, I really love and align with the takes around estimation and being truthful around not really knowing how long an outcome is going to take (which is why in software dev, ranges make SO MUCH SENSE).
My Question(s):
Have there been times when you do discard truth to appease hard stakeholders?
And:
Do you know why some leaders want fake thruths over honest estimations? Is it just easier to manage for them?
This is a great way to lead someone along questioning. Brilliant. I want to thank you @maret_kruve for answering my questions. Love the ideas. We’ll keep the thread open, and I encourage others to ask questions!
Have there been times when you do discard truth to appease hard stakeholders?
I personally lack natural fear of authority (to the amusement and annoyment of my bosses), so I haven’t really tried to please my stakeholders for the sake of pleasing. But I am fiercely protective of my team. So yes - for me there have been times when I’ve felt the need to be selective with truths in order to avoid unnecessary trouble for someone else. No regrets
I think all leaders want the truth, but they just don’t have the capacity to unpack and understand all the muddy, confusing details - especially if they have only minutes to spare for each topic. Truth is usually complicated, vague and full of uncertainty. But stories are simple, short and make sense right away. That’s what they’re great tools for spreading ideas. Just bad tools for decision-making.
@maret_kruve thank you so much for this piece! For me, I notice we lean on stories because they feel true and easy to agree with. Real evidence is harder and can feel “uncomfy.” I think we see that when teams feel pressure, they often choose the version that feels good and keeps everyone aligned instead of the one that actually leads to better decisions.
Which leads me to my Q, What signal would you trust more than a strong narrative when making a hard product decision?
Anything from 2 stars and above is usually good enough to start low-cost experiments. For high-cost decisions (6+ months of building etc), I’d prefer to see 4 stars. 5 is unrealistic in real life, but included for the reference.
