— Work I

An MVP, Shipped in a Single Quarter

Product Discovery & MVP Strategyfinding the one feature worth shipping

Read the case ↓
Project record — F. Reich
Timeframe
Q1 2019
Context
EventMobi — Event App
Role
Lead Product Designer
Constraints
Legacy codebase · <3 months to market · thin engineering capacity
Outcomes
  • Shipped to market inside the quarter, on a ten-year-old codebase
  • Gave Sales a brand-new revenue line, per the executive goal
  • One coordinated handoff across three functional surfaces — event app, web, and CMS
the brief

Ship something Sales can sell — by end of quarter.

The executive team set the goal plainly: enable Sales to generate new product revenue in Q1. The product team's job was to find the feature worth building — and deliver it against three hard constraints: less than three months to market, thin engineering capacity, and a decade of accumulated technical debt.

EventMobi's event app augments conferences with digital engagement — networking, live polls, gamification. What it would become next wasn't handed to us as a spec. It had to be discovered, justified, designed, and shipped, in one quarter. In my experience, this is the harder, truer version of product design: not the greenfield concept, but designing within the realities of an existing product that needs UX, UI, and technical overhauls — while the business clock runs.

Snapshot of the product team's process and output for the initiative
Fig. 1The full arc of the initiative — from business goal to shipped MVP.
research

Finding the product in the support data.

While our PM sized business opportunities, I led the mining of our own field data: every client request and complaint captured by Support in the trailing two to three years. (Older than that and you're studying problems the market has already solved.) The capture tool couldn't do analysis, so I exported everything into Sheets where we could actually manipulate and visualize it.

Clusters of customer feedback exported from Aha! and visualized
Fig. 2Two to three years of Support tickets, clustered. Two patterns kept surfacing.

Two clusters kept re-appearing: clients purchasing the event app specifically for networking, and clients asking for a way to book time with vendors, exhibitors, and each other. Event planners running networking-driven events were explicit — some said they would pay for a solution. Picture a conference floor with a hundred-plus exhibitor booths: attendees don't want to wander and hope, they want a systematic way to reserve a conversation.

With a pattern in hand, the discipline was to define the thing as sharply by what it was not as by what it was: a 1:1 attendee-to-attendee appointment booking tool for buyer–supplier meetings — not a lead-generation tool for exhibitors, not a topic-meetup planner. And an honest competitive read: CVENT and DoubleDutch already had this. We weren't differentiating; we were catching up. That honesty shaped every scope decision after it.

the problem

Interrogating the ask before drawing a single screen.

Once the executive team escalated appointment booking as the Q1 release, we needed to understand it well enough to ship something genuinely valuable — fast. With no time to recruit external participants, we got resourceful: our own staff included people who had been event planners, the exact persona we were building for. We interviewed internally, then pressure-tested what we heard against the support data.

Problem-analysis document logging internal interviews — meeting inputs, notes, and extracted use cases side by side
Fig. 3Interview synthesis with internal staff who matched our personas — external recruiting wasn't an option on the timeline or budget.
Second page of the same problem-analysis document — the possible use cases under consideration, with those ruled out of scope for the Q1 MVP listed separately
Fig. 4Scoping the use cases: pre-event booking between buyers and suppliers in, the rest deferred past Q1 and beyond MVP.

The decisive finding: the most important use case was pre-event booking between suppliers and potential buyers — booking during the event itself was far less common. That let us cut ruthlessly. The MVP would target the conference format, attendee-to-attendee (buyer ↔ supplier), primarily pre-event, on an assumed 50:50 split of mobile and web.

Event planner persona
Fig. 5The Planner — buys networking outcomes for their event.
Supplier attendee persona
Fig. 6The Supplier — wants qualified conversations, scheduled in advance.
Buyer attendee persona
Fig. 7The Buyer — reciprocal value; time is the scarce resource.
design

Designing inside the walls of a ten-year-old app.

The event app carried real structural constraints: two menus (a main menu, plus a secondary one holding the user's personal items), visual patterns nearly a decade old, and an engineering reality where the 'right' answer — a familiar calendar UI like Google's or Apple's — was flatly out of technical reach for Q1. Pre-filled location dropdowns? Out of scope. The design problem became: introduce a new, sellable capability without disrupting the app's existing UX, within what engineering could actually build in the timeline.

The existing EventMobi event app
Fig. 8The starting point: the event app as it stood.
Agenda list and calendar views in the existing app
Fig. 9Existing agenda patterns the new feature had to live beside.

To get breadth fast, I proposed and facilitated a Crazy 8s session with the VP of Product, both PMs, and both product designers — quantity of ideas first, judgment second. Pie-in-the-sky welcome: one of mine was booking an appointment entirely through a chatbot. The point is to turn the wheels before converging.

Crazy 8s lo-fi sketches for appointment booking
Fig. 10Crazy 8s output — divergence on a deadline.
delivery

One feature, three surfaces, one handoff.

The feature touched all three functional groups in the platform. I structured the handoff so each engineering group received exactly the screens and flows relevant to them — event app, web, and the experience manager — with continuous design critique running in Confluence throughout, so we never over-invested in a wrong direction.

Design feedback rounds in Confluence
Fig. 11Continuous critique, in writing, in the open.
Handoff organized by functional group
Fig. 12Handoff mapped to the three functional groups.

It shipped. Below, two attendees at an event finding each other and booking a meeting — the loop that turned support-ticket noise into a product Sales could put a price on.

Motion studyThe shipped MVP: two attendees discover each other and book a 1:1 appointment.