The Hidden Architecture of Decision-Making: Why Your Dashboard Is Not a Product

In this conversation, Anekha Sokhal, CEO of Moshi, maps the shift from passive data collection to active, recommendation-driven workflows in commodity trading. Her core argument is that the dashboard model of software fails because it overloads users with information without providing the connective tissue of second-order insights. By focusing on building tools, engineers often create UI problems rather than solving business ones. This analysis helps technical leaders who face pressure to build complex systems by providing a framework for prioritizing recommendation engines over static displays to create products that users actually integrate into their work.

The Trap of the Do-It-Yourself Dashboard

Engineers often assume that more data equals more value. They build complex, real-time dashboards that surface every available metric, assuming the user will derive the necessary insights. Sokhal’s experience suggests the opposite: when you provide a dashboard, you are not solving a problem; you are creating a UI challenge.

The system responds to this by being ignored. If a user does not intuitively understand how the data relates to their specific portfolio, they will not use it. The immediate benefit of a custom-built dashboard is that it feels productive to the engineer, but the downstream effect is a product that sits unused.

> "If everyone is building software, how do you get it to actually beat software that people will use? It is a bit of a chicken and egg."
>
> -- Anekha Sokhal

Why the Obvious Fix Makes Things Worse

Conventional wisdom in AI engineering suggests that more data or more agents will solve the problem of market complexity. However, Sokhal argues that simply processing more information is insufficient. The real value lies in the recommendation system, or the ability to connect seemingly unrelated events.

For an oil trader, knowing the price of oil is trivial. Knowing that an energy equities company is making a move that will indirectly impact oil supply in three weeks is the competitive advantage. This requires a recommendation system that maps second and third order derivatives. Most teams fail here because they treat recommendation systems as a secondary feature rather than the core engine of the product.

> "If you are a trader and you are looking at one thing, you actually care about the second and third order derivatives right now, which you would not immediately know."
>
> -- Anekha Sokhal

The 18-Month Payoff: Building for Workflow, Not Just Output

There is a disconnect between what engineers build and how users operate. When an engineer builds a system that requires the user to manually connect dots, they are forcing the user to do the hard work. A durable product, by contrast, pushes insights to the user that are already filtered for relevance.

This creates a high-signal environment. The discomfort for the engineer is that this requires building a complex, n-dimensional graph of data, an investment that pays off in 12 to 18 months as the system becomes more accurate and indispensable. The immediate pain of building this infrastructure is the barrier to entry that creates a long-term competitive moat.

Key Action Items

• Audit your Dashboard output (Immediate): Stop asking what data should I show and start asking what decision does this data trigger? If the user has to perform more than one cognitive step to act, the system is failing.
• Prioritize Recommendation over Retrieval (Next Quarter): Shift engineering resources from building better search or retrieval interfaces toward building a recommendation system that predicts what the user needs to see next.
• Implement Confidence Scoring (Next Quarter): When dealing with noisy alternative data like social media or disparate news sources, do not present raw feeds. Build a confidence layer to filter out noise; this creates immediate trust.
• Adopt the 5-on-1 Meeting Model (Immediate): For customer discovery, stop doing 1-on-1s. Use round-table, multi-client sessions to aggregate feedback and force users to discuss their actual pain points in a group setting.
• Build for Integration, Not Ownership (6-12 Months): Instead of building standalone software that requires users to switch contexts, focus on building systems that ingest the user's private, messy data like PDFs or internal logs to provide insights within their existing workflow.
• Filter the Hiring Noise (Next Quarter): If you are receiving thousands of applicants, stop treating hiring as a volume game. Implement a high-signal filter that prioritizes candidates who understand the specific domain, such as finance or commodities, rather than just general AI capability.