Research In, Data Out: How I Keep Product Decisions Honest

Research before you fall in love with the solution

The most expensive mistake in product is building the right solution to the wrong problem. Before I scope anything, I go to primary market research, talking to the actual owners, tenants, or account holders the product is for. Not to validate the idea I already have, but to find the problem worth solving.

It is uncomfortable, because research often kills the feature you were excited about. That is the point. Better to lose a feature in a research session than after three months of engineering.

Define the smallest thing worth shipping

Once the problem is clear, I force the scope down to an MVP, the smallest version that genuinely tests whether the problem is real and our solution works. Defining the MVP is mostly an exercise in saying no: stripping away everything that is nice-to-have until only the load-bearing assumption is left.

A tight MVP is not a smaller product. It is a faster way to learn whether the product should exist at all.

User testing closes the gap between intent and reality

There is always a gap between how I imagine a flow and how a real user moves through it. User testing is how I close it before launch instead of after. Watching someone hesitate, tap the wrong thing, or abandon a step tells me more than any internal review ever could, especially in financial flows, where a moment of confusion costs trust.

Let the analytics tell you what to build next

After launch, the work shifts to listening. I lean on Mixpanel, Adjust, and Power BI to see what users actually do, where they drop off, what they repeat, what they never touch. The first action is easy to drive; the second is where real value shows up, so I watch retention and repeat behaviour, not just sign-ups.

Research tells you what to build. Analytics tell you whether you were right. Keeping both in the loop is how I make sure the next decision is a little less of a guess than the last one.