How a Non-Technical PM Used Emergent to Build an Enterprise Product Tool from Scratch

In hospitality, the margin for error is thin. A broken booking flow at peak season does not just create a support ticket. It costs reservations, damages guest trust, and shows up in reviews that live on the internet forever. For a US-based hospitality company with nearly 4,800 employees, the pressure to ship reliable, guest-facing product features quickly and without gaps was constant.

Their product team was not keeping up. Not because of talent, but because of tooling.

Use Case Overview

The company's product team is responsible for building and maintaining the digital experiences that guests interact with directly, from booking flows and account dashboards to loyalty program features and post-stay communication tools. With over 100 people across design, frontend, backend, and QA shipping features that affect guest experience at scale, the cost of misalignment was not abstract. It showed up in broken releases, missed seasonal windows, and bugs that reached guests before anyone on the team knew they existed.

Using Emergent's vibe coding platform, the company’s product manager built do.it, a fully custom, initiative-driven work tracking system built around how their team actually operates. It replaced Jira and a tangle of disconnected tools with a single structured system, and it was live within days, built entirely without writing a single line of code.

Challenges

1. Standups Were Exposing a Deeper Problem

Sprint standups were regularly running past 40 minutes. Engineers blocked on QA sign-offs that had never been logged. Work completed but never linked to the initiative it belonged to. Bugs raised one week, live in production the next. In an industry where a guest encountering a broken checkout page or a malfunctioning loyalty account portal will simply book elsewhere, that kind of operational noise had a direct cost. The tools were supposed to bring clarity. Instead, the team was spending more time managing them than shipping features.

2. Jira Was Built for Everyone, Which Meant It Was Built for No One

The company had been on Jira for years. At their scale, the annual spend on Jira and the surrounding tool stack ran well into five figures. But cost was only part of the frustration. The deeper problem was that Jira's flexibility required constant configuration, heavy admin overhead, and a learning curve steep enough to make onboarding new team members a persistent drain.

"It became a tool we managed instead of a tool that helped us," the product manager recalled. "Half the team had their own workarounds. The other half just stopped using it properly."

For a hospitality company where product releases are timed around peak travel seasons, a summer booking surge or a holiday loyalty promotion window does not wait for a team to untangle a misconfigured workflow. Delays had real revenue implications.

3. No Visibility Into What Was Actually Guest-Ready

Design, frontend, backend, and QA teams each tracked work in their own way. Bugs raised against guest-facing features were not reliably linked to the tasks that caused them. Release planning lived in one place, QA test cases in another. Leadership had no reliable way to confirm whether a feature touching guest accounts or booking flows was genuinely ready to go live, or whether it was about to create a problem for thousands of guests simultaneously.

4. Work Disconnected from Guest Outcomes

Individual tasks floated without clear connection to the business goals driving them. An engineer could close ten tickets in a sprint and still have no clear sense of whether the guest experience had actually improved. For a hospitality company where every product decision ultimately lands in front of a guest, that disconnect between daily execution and real-world outcomes was quietly eroding both quality and team morale.

Solution

The product manager had a precise vision of what the team needed. A system where every piece of work, no matter how small, connected upward to a guest-facing goal. Where a bug raised against a loyalty account feature was always tied to the task that introduced it. Where QA sign-off was part of the workflow, not an afterthought.

What was missing was a way to build it without pulling engineers off guest-facing product work or waiting months for an internal development cycle to begin.

After discovering Emergent, the product manager spent a few focused days building do.it entirely through natural language prompts, with no code written at any point. The experience was, in their words, "the first time I felt like I could just build what I was imagining without having to convince anyone or wait for anyone."

1. A Hierarchy Built Around Guest-Facing Outcomes

do.it is structured around three issue types that reflect how hospitality product teams think about delivery. Initiatives represent the "why," a new booking flow, a loyalty program enhancement, a guest account feature tied to a seasonal campaign. Tasks are the "what," automatically generated for Design, Frontend, Backend, and QA the moment an initiative is created. Bugs are always linked to the task that caused them, so when something breaks in a guest-facing feature, the team knows exactly where it came from.

Nothing in do.it is an orphan. Every piece of work connects upward to a guest outcome.

2. A Workflow Designed for Seasonal Delivery Pressure

The platform tracks issues through ten workflow states, from Todo through In Dev, In Review, In QA, QA Approved, Live Canary, and all the way to Live Production. Teams can drag and drop cards on dedicated Kanban boards for each function, or use the Filter Board for advanced cross-project queries. A unified Dashboard gives leadership a real-time view of initiative progress across the entire team, critical when a summer booking feature or a holiday loyalty rollout has a hard launch date that cannot move.

3. QA That Protects the Guest Experience

QA test cases, test suites, and test runs are managed centrally within do.it and linked directly to QA tasks. For a hospitality product team, this matters enormously. A bug in a booking flow or a guest account portal is not just a technical issue. It is a guest experience failure that can result in a lost reservation, a negative review, or a support call at midnight. With test case management living inside the same system as the work itself, nothing gets marked ready for release without a clear, traceable QA record behind it.

4. Collaboration Tied to the Work, Not Lost in Chat

Slack integration delivers targeted notifications covering @mentions, status changes, and assignment updates directly to the relevant team member. Activity feeds and comment threads keep discussions anchored to the specific feature or bug being worked on, not buried in a channel that scrolls away before anyone acts on it.

Outcomes

1. Standups Cut from 40 Minutes to Under 15

With every initiative, task, and bug visible in one place and automatically connected to the right context, the company's daily standups transformed almost immediately. Managers stopped spending the first half of every meeting re-establishing shared context. Real-time dashboards replaced the pre-meeting scramble. What used to take 40 minutes now rarely exceeds 15, freeing the team to spend that time actually shipping.

2. Fewer Bugs Reaching Guests

By requiring every bug to be linked to the task that caused it and integrating test case management directly into the QA workflow, teams gained end-to-end traceability across every release cycle. Guest-facing issues that previously slipped through to production are now caught earlier in the pipeline, before they affect bookings, loyalty accounts, or guest trust.

3. Releases Timed to Seasonal Windows, Not Tool Limitations

The structured workflow from Todo to Production, combined with Canary and Production deployment stages, gave teams a consistent, repeatable path to release. With clearer ownership at every stage and QA fully embedded in the flow, the team can now confidently hit the seasonal launch windows that matter most in hospitality, summer booking peaks, holiday promotions, loyalty program refreshes, without the last-minute scramble that previously defined every major release.

4. 100+ Team Members Onboarded in Days, Not Weeks

Despite the scale of the company's product organization, adoption was immediate. The system's opinionated structure, with everything in its place and roles clearly defined by team function, meant there was almost nothing to configure and very little to explain. Engineers, designers, and QA testers understood the workflow from day one. No lengthy training sessions. No admin overhead. No workarounds invented by people who gave up on the official process.

5. Built in Days for a Fraction of the Cost

A custom internal tool of this complexity, built through traditional development, would have taken months and cost upward of $42,000. The company's product manager built the same thing on Emergent in a matter of days, at a fraction of that cost, without writing a single line of code and without pulling a single engineer away from guest-facing product work.

The build did not just save money. It proved something more important: that the people closest to a problem are now capable of solving it themselves.

Conclusion

This is not a scrappy startup experimenting with new tools. It is a nearly 5,000-person hospitality company where product quality is inseparable from guest experience, and where a bug in the wrong place at the wrong time of year can have consequences far beyond a support ticket.

The fact that a product manager there was able to independently design, build, and deploy an enterprise-grade work tracking system used by over 100 people, in days, on Emergent, says something significant about what is now possible for teams that cannot afford to wait.

They did not compromise. They did not wait. They did not hand the problem to someone else and hope for the best. They built exactly what they needed, and they were using it before the week was out.

If you are still asking whether Emergent is the right call, this company's answer is already built, already running, and already making sure the right features reach guests on time.