I want EBO to work.
That is exactly why I should not trust myself too easily while researching it.
I have spent time imagining the product, questioning its features, and becoming attached to the problem behind it. When someone likes the idea, I naturally want to treat their reaction as evidence that I am moving in the right direction.
When someone criticises it, I want to explain what they misunderstood.
Those instincts are understandable.
They are also dangerous.
If I only accept information that protects EBO, then I am not researching the product. I am defending it.
Enthusiasm is not evidence
There are many ways to receive encouraging feedback without learning anything useful.
I can describe EBO passionately, explain every future possibility, and then ask:
Would you use this?
The person may say yes.
They may genuinely mean it at that moment. The idea might sound interesting, the presentation might be convincing, or they may simply want to support me.
But saying that you would use something is very different from changing your behaviour when that thing actually exists.
People regularly download productivity applications they never open again. They make schedules they do not follow, buy resources they do not complete, and feel excited about routines that disappear a few days later.
I do versions of this too.
That means hypothetical enthusiasm is weak evidence.
A compliment can be emotionally valuable without being useful for a product decision.
Behaviour is more informative than opinions
Instead of asking people to predict an imaginary future, I need to understand what they have already done.
What did their last real week of studying look like?
When did they intend to study but fail to begin?
What interrupted them?
What happened after they missed a day?
Which tools did they try?
Which ones did they stop using?
What did they return to repeatedly?
The purpose is not to interrogate someone or judge their discipline. It is to replace general claims with actual behaviour.
Someone might say they are “usually consistent,” then describe repeatedly losing momentum after a few days. Another person might say they need more motivation while their real difficulty is not knowing what to begin.
The words people use to describe a problem and the behaviour surrounding that problem are not always identical.
Both matter, but they tell me different things.
The problem and the solution are separate
One of the most important lessons EBO has taught me is that a real problem does not validate my solution.
Suppose I find strong evidence that students struggle to begin studying consistently.
That supports the existence of the problem.
It does not prove that EBO’s current design will help.
The same is true if students feel isolated, abandon productivity tools, or struggle to recover after breaking a routine. Those experiences may be genuine while every solution I have imagined remains wrong.
Problem validation asks:
Is this difficulty real, important, and repeated?
Solution validation asks:
Does this particular response improve it?
I used to blend those questions together. If someone recognised the problem, I interpreted that recognition as support for the product.
Now I try to keep them separate.
EBO has to earn both.
I should not rescue the idea from criticism
When someone criticises a feature, it is tempting to explain the better version that exists in my imagination.
Perhaps the current description was incomplete. Perhaps the unfinished interface made the idea confusing. Perhaps I already planned to solve the exact issue they noticed.
Those things may be true.
But immediately defending the product prevents me from seeing the experience they actually had.
If someone misunderstands a privacy control, the problem is not automatically that they failed to pay attention. The design may have communicated poorly.
If they cannot understand why a feature exists, a longer explanation does not prove the feature belongs.
If they want to remove something I consider important, that disagreement deserves investigation.
Research becomes meaningless when every criticism receives an excuse.
I need to observe confusion before correcting it, listen to rejection before debating it, and allow people to react to what exists rather than what I promise it will eventually become.
Prototypes should fail before the product does
Building is satisfying, especially when AI makes it possible for me to implement ideas beyond my current programming ability.
That creates another danger: I can produce something before I have earned enough evidence to justify producing it.
A working feature feels more legitimate than a sketch. Once it exists, deleting it becomes emotionally harder because time and effort are attached to it.
Testing smaller representations first can reveal problems before they become expensive commitments.
Can someone understand the experience without a detailed explanation?
Where do they hesitate?
Which words confuse them?
What do they assume is visible to other people?
Which part would they remove?
A prototype does not need to prove that the entire product works. It needs to expose where my thinking does not match the user’s experience.
Failure is much cheaper while an idea is still easy to change.
Bias can hide inside good intentions
I care about the problem EBO is trying to understand.
But caring does not make me objective.
I may ask questions in a way that suggests the answer I want. I may remember enthusiastic reactions more clearly than doubtful ones. I may speak mostly to people who think similarly to me.
I may also exaggerate the meaning of small amounts of evidence because I want to keep moving.
Avoiding bias does not mean pretending I have no opinion. It means creating a process that does not depend entirely on my opinion winning.
Criticism should be recorded, not softened.
Uncertainty should remain uncertainty.
If I do not yet have meaningful numbers, I should say that instead of presenting ambition as traction.
If nobody has paid for the product, I should not use language that implies they have.
Honest evidence may make the project look less impressive temporarily.
It also makes every later claim more credible.
Research must be respectful
EBO concerns students, and some of those students may be minors.
That makes the way I research the problem as important as what I learn.
I do not need deeply personal information to understand study behaviour. I should avoid collecting details that are unnecessary, protect anything identifiable, and ensure that participation is genuinely voluntary.
A useful insight is not worth obtaining through pressure or carelessness.
Research should not make students feel that they are being evaluated. The purpose is to understand the product problem, not measure their worth or discipline.
If someone describes inconsistency, distraction, or an abandoned routine, that is not an admission of failure.
It is evidence about ordinary human behaviour.
Evidence must be allowed to change the plan
Research is only meaningful if different results can produce different decisions.
If every possible response leads me to build the same product, then the process is theatre.
Evidence might suggest continuing with changes. It might reveal that the problem is narrower than I assumed. It might show that a particular idea creates more confusion than value.
It could indicate that EBO needs to be repositioned.
It could eventually tell me to stop.
I do not like that final possibility, but excluding it in advance would make every other decision less honest.
The objective is not to prove that my original idea was correct.
The objective is to discover what deserves to exist.
I am learning to ask better questions
My earliest approach to EBO was to imagine something, build it, and then add more.
Now I am trying to create a slower loop:
Listen.
Identify what actually happened.
Separate the problem from the proposed solution.
Test the experience.
Notice confusion and rejection.
Build only what earns stronger support.
This process is less visually exciting than launching features. It produces fewer impressive screenshots and more uncomfortable notes.
But those notes may matter more than another screen.
I still want EBO to succeed.
I am simply learning that success cannot mean protecting the idea from reality.
It has to mean allowing reality to shape the idea.