Jeni — Marketplace Intelligence(Still building at the moment)

Turning fragmented marketplace signals into decisions Bravo can act on.

TL;DR

Bravo is a payments and dining rewards marketplace connecting diners with 500+ restaurant partners across Metro Vancouver. Despite years of customer, merchant, and transaction data, the team lacked a way to understand what those relationships meant—or where to act.

With no PM, predefined requirements, or predetermined solution, I defined, designed, and built Jeni end to end: an AI-powered intelligence system that turns Bravo's fragmented marketplace signals into actionable opportunities.

Role
Product Designer & Builder
Year
2026
Collaborators
CEO · 1 Backend Engineer
Built with
Claude · ChatGPT · AWS · Figma

The starting point

I wasn’t given a product to design. I was given an ambition.

Bravo’s CEO and marketing team had a recurring problem. By the time a new restaurant opened or an existing one was visibly struggling, the team was often already late to the opportunity.

The initial ask was loose: could AI help Bravo spot these signals earlier?

I turned that idea into the first version of Jeni, a market intelligence tool that monitored public signals around restaurant openings, closures, and other merchant activity.

Jeni V1 — Bringing restaurant openings, closures, and other public signals into one monitoring view.

That first version changed the scope of my role.

After seeing me turn a loosely defined AI idea into a working product, the CEO gave me a much broader mandate: expand Jeni across Bravo.

Monitoring would remain one capability within Jeni, but the larger product was undefined. There was no predefined problem, workflow, or solution. I had to determine where Jeni could actually create value inside the business.

One collector in detail — health closure orders, with unresolved merchant matches preserved for review rather than guessed.

Finding the product

The next brief was one sentence: make Jeni useful to Bravo.

After seeing V1, Bravo’s CEO asked me to take Jeni further into the business. There was no feature list, target workflow, or predefined problem to solve.

I started with the systems Bravo already used. The existing merchant portal tracked credit balances and transaction history, while customer records captured balances, rewards, referrals, and dining activity. The data was there. What was missing was a way to interpret it across the marketplace.

The ledger showed credit remaining, but not when a merchant was becoming a problem.

Bravo’s existing merchant portal exposed balances and transactions, but recognizing urgency still required someone to interpret them manually.

Understanding both sides still didn’t tell Bravo what to do.

A merchant could need help and a diner could be a strong match, but that still didn’t mean Bravo should intervene. The decision also depended on whether the expected value justified the cost.

Merchant Need

Where does the marketplace need help?

Diner Opportunity

Who could realistically respond?

Bravo Economics

Would acting create enough value?

This became the product thesis for Jeni.

Jeni would connect merchant need, diner opportunity, and Bravo’s economics to identify where intervention was actually worth considering.

Building Jeni

Turning the product thesis into a decision workflow.

The thesis gave Jeni three things to reason about. The product still had to make that reasoning useful to the people running Bravo.

I designed Jeni around a simple progression: surface what needs attention, explain why it matters, connect the relevant merchant and diner signals, and make the next decision easier to evaluate.

01 / See What Needs Attention

Start with the exceptions, not the database.

Bravo already had the data. The problem was knowing where to look first.

I designed Jeni to surface the merchants, diners, and opportunities showing meaningful change, then prioritize them by urgency and potential business value.

Instead of another dashboard to explore, Jeni opened with what Bravo could act on.

02 / Understand Why

Show the evidence behind the signal.

A flag only mattered if the team could understand what was driving it.

I designed Jeni to connect each state back to the underlying behavior, such as credit burn, transaction activity, visit patterns, and recent change, so the team could judge whether an opportunity was real before acting.

Jeni first established the network baseline: how credit was being used, where transaction volume was moving, and what normal looked like across the marketplace.

From there, the team could drill into a flagged merchant and see what was actually driving the signal.

For Happy Day Cafe Kingsway, a static credit balance became a time-sensitive signal once Jeni showed burn velocity, replenishment history, and runway.

But urgency alone wasn’t enough. Jeni also needed to understand the business behind the number.

Credit showed when attention was needed. Operational behavior helped explain what kind of opportunity it was.

Visit frequency, customer mix, daypart behavior, and spend patterns gave the financial signal operational context.

03 / Find Who Can Move It

Connect merchant need with diner opportunity.

Understanding the merchant explained the problem, but not who could change the outcome.

I designed the diner side of Jeni around behavioral signals such as inactivity, top-up activity, customer value, visit history, and merchant affinity. This helped the system identify not just an audience, but the diners most relevant to a specific merchant need.

Instead of treating diners as a list of accounts, Jeni organized them by behavioral state: who was drifting away, showing top up signal or worth retaining.

But behavioral state alone didn’t make a diner relevant.

Jeni also needed evidence that the diner and merchant actually belonged together.

Cross-merchant behavior exposed relationships that raw audience overlap would miss. I used lift rather than shared-diner count so large merchants wouldn’t automatically dominate the recommendation.

Relevance could then become a specific play.

Once diner behavior and merchant context were connected, Jeni could move from “who looks interesting?” to “who could change this outcome, and how?”

Each diner carried the signal, suggested action, and expected value forward, preserving the reasoning behind the recommendation.

04 / Make the Economics Visible

A useful intervention still had to be worth running.

Connecting the right diner to the right merchant still wasn’t enough. Every intervention had a cost to Bravo, and more activity did not necessarily mean more value.

I made the economics part of the recommendation itself, so the team could evaluate an opportunity against credit cost, expected margin, and network value before deciding to act.

The same action could look very different once Bravo’s economics entered the decision.

I surfaced expected value beside the recommended action, making the tradeoff visible before the team committed budget.

I didn’t reduce value to a single number. Direct value to Bravo and broader network value could point in different directions, so I kept them visible separately rather than hiding the tradeoff inside one score.

Economics also changed prioritization.

Once Jeni could estimate the value of individual plays, the same logic could compare opportunities across the business.

Opportunities were ranked by estimated net margin rather than activity alone, showing both the spend required and the expected return.

I deliberately showed expected upside together with the spend required to create it. The goal wasn’t to make Jeni sound confident; it was to give Bravo enough context to judge whether the recommendation was worth taking.

The decision model was now complete.

Merchant Need × Diner Opportunity × Bravo Economics → Intervention

05 / Turn the Decision Into Action

A recommendation only mattered if the team could do something with it.

By this point, Jeni could identify an opportunity, explain the evidence behind it, connect the relevant diners, and make the economics visible.

The final step was turning that reasoning into a specific next move the team could evaluate and act on.

The same framework could support different kinds of decisions, from creating demand to replenishing credit to maintaining a healthy state.

The same framework supported different decisions: create demand, replenish credit, or simply keep monitoring. Each recommendation explained why it mattered, what to do next, and what could change.

I structured each recommendation around three questions: why does this matter now, what should Bravo consider doing, and what could change if it works.

The recommendation stayed close to the evidence, with the underlying reasoning available for the team to inspect before acting.

Actionable did not mean automatic. The team still controlled whether and how to intervene.

The Outcome

From a side project to the roadmap.

Jeni started as an open-ended experiment around restaurant intelligence. It has since become a live internal product for understanding Bravo’s marketplace and identifying where the team can act.

The product is now part of the CEO’s roadmap and has been included in the investor pitch deck as part of Bravo’s evolving intelligence capabilities.

The project also changed my role.

I entered Jeni as a product designer with a loosely defined AI opportunity. I ended up defining the product strategy, designing the decision model, and building the working system myself.

More importantly, it changed how I think about product design: when the path is unclear, designing the interface is only one part of the job. Sometimes the larger responsibility is defining what should exist in the first place.