Our robo advisor: A lesson in skipping UX research

At the end of the day, sometimes your success simply comes down to user behavior. Your product isn’t broken. The design isn’t bad. Users simply aren’t ready to buy.

Because of this, you need to understand the type of product you’re selling. If you sell food, you expect people to buy it every day. But if you sell investments, where there’s always the fear of losing money, you can’t expect users to click “buy” immediately after signing up.

These were my exact words during a product performance review. However, it took my team building a robo advisor feature that dragged on for eight sprints (four months) to finally realize it (time we could’ve used to set up a simple behavioral/email automation flow to nudge users into investing).

You’d think that with all the tools and data we have today it’d be easy to build a feature that users would adopt. So how did we still miss the mark?

The product owner had one goal: get users to click “start investing” and actually buy a product. Users were onboarding just fine but no one touched that button. After a management meeting, the product leaders decided we needed a feature: a personality quiz that would recommend the perfect investment.

Sounds smart, right? Except they skipped the most important part: understanding the users. There was no user research and no real look at the anxieties, doubts, or behaviors of the people we were building for. The product managers rushed into user stories and acceptance criteria, and the design team only heard about the feature at the design sprint stage.

Here’s the reality: if the main goal was to get users investing, they needed to be taken on a journey. They needed reassurance, feedback loops, and a chance to tell us their concerns. At the same time, our design team was already working on an in-app feedback feature — one that would collect real-time feedback at critical moments. For example: if a user spent too long staring at a product page without buying, a gentle prompt could pop up asking, “Are you having any challenges buying your first product?”

See the difference? Instead of guessing, we could’ve been listening.

In this article, I’ll unpack our assumption-driven flop, show you how user research changed the game, and share practical lessons you can use to avoid the same mistake. By the end, you’ll see why UX research isn’t just another box to tick, it’s the foundation of building what users actually want.

The robo advisor flop: Building on assumptions

The idea for a robo advisor didn’t come from our users. It came from our manager. They had seen the feature on a competitor’s app and were fascinated by it. In one of our weekly meetings, they hinted that it could help users decide faster on which product to invest in:

Our product owner, desperate for a win because we were behind on our numbers that quarter, jumped on it immediately. A week later, the product manager rolled out a detailed PRD with user stories and acceptance criteria.

The only meeting held was with the technical team to confirm if AI could power the logic. The answer was yes: if a user provided certain responses, the system could recommend a set of products. From there, the engineers were ready, and the design team was pulled in to “make it look good.”

During the design sprint, we raised a concern. Based on continuous feedback and research, our team was already working on a very different solution: an in-app feedback feature. The idea was simple but backed by solid data:

1. Nudge users at critical steps, for example, if they linger too long on a product page, a gentle prompt would ask if they were experiencing challenges
2. Give users space to share pain points in real time, so we could identify why purchases weren’t being completed

Our recent interviews showed that most of our users weren’t Gen Z or Millennials, as we had assumed early on. Over time, the user base had shifted to Gen X people far less tech-savvy. Many struggled with processes we thought were seamless. Some admitted they didn’t understand how to buy a product. Others were confused by the tiering system.

We believed usability testing had already validated the flows, but reality was different. Users’ expectations and anxieties had changed, and we needed a way to capture those insights continuously. Instead of leaning on that research, the team built a feature based on assumptions, competitor envy, and internal pressure.

The result? Four months of development, eight sprints, and countless hours of design and engineering, only to launch a feature that less than three percent of users even tried. Of those who started the quiz, fewer than one percent actually went on to invest. Adoption was flat, conversions didn’t move, and revenue remained exactly where it was.

In-app feedback success: Driven by user insights

Six months after launching the robo advisor — and seeing zero impact — the design team was finally given the green light to build the in-app feedback feature we had been advocating for. Unlike robo advisor, this solution was born directly from user research, not assumptions.

The feature itself was simple: a contextual prompt that appeared at critical points in the journey. If a user lingered too long on a product page without buying, a gentle nudge would ask, “Are you having any challenges making your first investment?” Users could respond instantly, giving us real-time insight into their pain points:

The results were immediate. Engagement with the feedback tool was far higher than we expected as over a third of users responded within the first month. But more importantly, the verbatim feedback completely reshaped how we saw our users.

We started seeing messages like:

• “Oh, I’m just testing the app, not ready to invest yet”
• “I’m waiting for my Tier-3 upgrade to be approved before I can invest”

These weren’t technical bugs, they were real behavioral insights. One piece of feedback even revealed a hidden friction point in our internal tier upgrade process that was silently delaying investments. With that knowledge, we were able to fix the flow and speed up approvals, removing a huge blocker.

Beyond improving product decisions, the feature also had a direct impact on perception. Our app store rating jumped from 3.0 to 4.5 stars, largely because we created a clever experience: if a user gave us five stars inside the app, they were prompted to share that same rating on the Play Store.

The in-app feedback tool didn’t just collect opinions, it gave us a continuous feedback loop that drove better products, smoother processes, and happier users.

And once we understood why users were hesitating, it became clear what we needed next: a way to guide them back into the journey after they dropped off.

Automation flow for re-engaging users after drop-off

When we introduced in-app feedback, we discovered that many users were curious but not yet ready to invest. Instead of assuming disinterest, we built an automation flow to re-engage users at every critical step.

Here is the flow we designed:

1. User starts onboarding journey — A user begins exploring the app and lands on the product details page
2. Drop-off detection — If the user abandons the journey at this point (e.g., closes the app or navigates away), the system flags the drop-off and triggers automation
3. Automated email prompt — The system immediately schedules a contextual email:
   1. If they stopped on the product details page, the email reminds them of the specific product and encourages them to return
   2. If they dropped at the payment page, the email nudges them to complete their purchase with a simple call-to-action
4. Smart re-entry
   1. When the user clicks the email and re-opens the app, they aren’t taken to the home screen
   2. Instead, they’re dropped back exactly where they left off:
      1. If it was the product details page, that is where they land
      2. If it was the payment page, the app opens directly at payment so they can complete the transaction with minimal friction
5. Progressive funnel
   1. Each step has its own recovery path:
      1. Product page drop-off → Product reminder email → Return to product page
      2. Payment page drop-off → Payment completion email → Return to payment page
6. Final conversion or exit
   1. If the user completes the payment, they’re automatically moved into the post-purchase funnel, where they start receiving onboarding content, tips, and engagement prompts
   2. If they drop off again after multiple reminders, the system can move them into a “cold leads” segment for future campaigns

Side-by-side comparison: Assumption-driven vs. user-driven design

When we put the two approaches next to each other, the lesson becomes obvious:

The difference is clear: assumption-driven design burns time and resources without solving real problems, while user-driven design compounds value with every cycle. One creates a dead end; the other creates a roadmap.

The importance of UX research

Looking back, the robo advisor flop wasn’t just a wasted feature, it was a wake-up call. It forced us to rethink how we approached product development and gave us some lessons we still use today:

1. Validate ideas early
2. Involve UX from day one — Product managers, engineers, and stakeholders all bring valuable perspectives, but without early UX input, it’s easy to build for the business instead of the user
3. Balance opinions with data — Stakeholders will always have ideas (and sometimes egos). That’s fine, but ground every decision in user interviews, surveys, and actual behavior
4. Treat failure as a teacher — The robo advisor didn’t move the needle, but it reshaped how we build. Without that flop, we might never have pushed hard enough for in-app feedback, which became one of our most impactful features

This mindset shift changed our entire product strategy. Instead of asking, “What features can we ship next?” we now ask, “What problem do users actually need us to solve?” That one question alone has saved us time, money, and frustration across multiple releases.

So here’s my challenge to you: the next time your team gets excited about a shiny new feature, pause and ask: “Have we talked to users yet?”

Final thoughts

Our journey from robo advisor to in-app feedback was messy, but it taught us the most important lesson in product development: skipping UX research is always a gamble.

We spent four months building a feature that nobody wanted, only to realize that a simple research-backed tool could deliver immediate insights, fix hidden process issues, and even boost our app rating from 3.0 to 4.5.

The difference wasn’t luck, it was listening. By putting users at the center, we moved from wasted sprints to building features that actually mattered.

Today, UX is non-negotiable on our team. We start with research, validate before building, and let our users guide the journey. And the best part? They’ve noticed, their feedback keeps shaping better experiences, and their trust in our product keeps growing.

If you’ve ever had your own “robo advisor” moment, you’re not alone. Comment your experience below.

The post Our robo advisor: A lesson in skipping UX research appeared first on LogRocket Blog.

This post first appeared on Read More