Giving hotels a clearer view of their distribution.
A hotel-facing foundation for distribution, seller visibility, and eligible inventory controls, backed by the shared capabilities the wider business needs.
My role
VP of Product · Platform & Acquisition
Platform leadership
2024–Present
Audience
Hotels & internal teams
Work covered
Strategy, requirements & platform planning
The brief
Create a hotel-facing platform that brings reach, visibility, and eligible controls together, while establishing a shared foundation for the travel ecosystem.
My role
I lead product strategy, roadmap priorities, requirements, and execution across platform and acquisition initiatives. I defined the centralized platform direction and led integration planning, source-of-truth decisions, and buy-versus-build analysis.
Working across the business
I partner with engineering, finance, operations, supply, commercial, analytics, and executive teams. Product direction and requirements are my remit; engineering implementation and the operational service depend on work across those disciplines.
Product direction & scoped availability. Release status is confirmed for the relevant capability, market, property or partner, and connection. Most capabilities in v2.1 are awaiting status confirmation; Platform PMS is marked Planned.
The problem starts with the hotel.
The Platform proposition begins with three questions: who is selling a hotel’s rooms, what prices are guests seeing, and how much work does another distribution channel create? Hotels need useful information and controls around those decisions, rather than another disconnected interface.
Distribution visibility
Participating sellers and guest-facing rates need to be understandable together. Visibility is only as complete as the connected partners and available data.
Operational effort
New routes can add connections, agreements, and management tasks. The product direction is one hotel onboarding foundation with routes activated for an agreed scope.
Pricing context
A hotel’s own rate is more useful when compared with relevant local conditions. That comparison needs meaningful filters and privacy for other properties.
My platform remit connects these hotel needs to pricing, inventory, content, bookings, supplier management, and internal tools. A hotel-facing capability has to be supported by consistent data and clear ownership behind the interface.
A hotel foundation within a wider ecosystem.
Platform and Exchange solve related problems for different audiences. Platform is the hotel-side foundation; Exchange is a route to distribution partners. HafH and Omakastay remain distinct distribution opportunities in the product proposition.
Hotel foundation
Participating hotels
Rooms, rates & availability
KabuK Platform
Onboarding, eligible controls & visibility
Additional hotel-side routes
HafHOmakastay
Global supply
Inventory alongside the Asia-first focus
→
The exchange
KabuK Exchange
Resolve supplier records to a hotel
Select an eligible source
Apply partner commercial terms
→
Distribution
Partner platforms
OTAs
Travel agencies
Wholesalers
Travel platforms
The hotel perspective
Platform is the participating hotel’s foundation for onboarding, visibility, and eligible controls. HafH and Omakastay are separate potential routes; they are not shown as downstream of Exchange.
Conceptual product model adapted from the v2.1 decks. Routes depend on eligibility, connection readiness, and agreed terms. This is not a production architecture diagram.
Visibility should support a decision.
The visibility concept brings participating sellers and the prices charged to guests into one view. An important product constraint is freshness: the visibility concept uses daily updates. Coverage depends on partner connections and the data available.
The control scope includes hotel rates, availability and allotments, and enabling or disabling individual partners or channels through Platform. Some changes may require approval. That distinction belongs in the requirements and the experience, so a hotel can understand what it can change and what happens next.
View largerKabuK Platform v2.1, slide 5. Illustrative concept, not a product screenshot. The deck specifies daily updates and partner-dependent coverage.
The product question
Can the hotel understand who is distributing its inventory, see the information’s freshness and coverage, and act within the controls it actually has?
Useful market context, without identifying competitors.
The compset concept compares a hotel with masked, grouped properties rather than identifying individual competitors. The comparison can be configured around stay dates, room conditions, cancellation terms, and the area considered comparable.
This is a different product problem from simply displaying a lower price. A comparison must be like-for-like to be useful in a rate discussion. Coverage for this concept is limited to markets where KabuK has properties.
View largerKabuK Platform v2.1, slide 7. Illustrative concept; other properties are masked and grouped. Coverage is limited to markets where KabuK has properties.
The decisions behind the platform.
My work includes defining platform scope and requirements, planning integrations, and evaluating investment choices. These are the decision areas behind the hotel-facing proposition.
Shared capabilities and clear service boundaries
The decision area
I established the platform product direction across pricing, inventory, content, bookings, supplier management, and internal tools.
Why it matters
A hotel control or distribution route depends on several domains working together. Clear boundaries make it possible to discuss which capability owns a change and which teams depend on it.
The trade-off
A broad platform vision needs boundaries that keep delivery understandable. Centralization is useful only when ownership and interfaces stay clear.
Data consistency and a source of truth
The decision area
I led integration planning that covered normalization, consistency, and source-of-truth decisions across fragmented systems.
Why it matters
The same hotel, rate, inventory item, or booking can appear in different systems. Requirements need a consistent meaning for the information passed between them.
The trade-off
A shared model has to support common behavior without discarding meaningful supplier differences or hiding the limits of the available data.
Buy versus build
The decision area
I evaluate travel technology capabilities and third-party providers against speed, cost, control, and long-term flexibility.
Why it matters
The fastest way to add a capability may introduce a dependency that affects later pricing, operations, or distribution choices.
The trade-off
Implementation speed is considered alongside ongoing cost, ownership, and how easily the capability can change.
Distribution and product-specific scope
The decision area
The Platform direction supports internal operations and external integrations, with future B2B and B2B2B distribution in scope.
Why it matters
HafH, Omakastay, and Exchange serve different purposes. A shared foundation should not turn those routes into indistinguishable products.
The trade-off
Reuse needs to coexist with route eligibility, market differences, partner permissions, and separately confirmed readiness.
Turning platform direction into business priorities.
I lead strategy, roadmap, requirements gathering, and execution across the platform and acquisition remit. That means aligning engineering feasibility with the needs of finance, operations, supply, commercial, analytics, and company leadership.
The business work is closely connected to the technical planning: what information needs to be consistent, which capability should be prioritized, what a third-party dependency means for future options, and how the investment supports reporting and decisions.
Progress, scope, and what comes next.
Work established
Platform vision and product direction, an operating model across the core domains, integration planning, and investment analysis.
Capability readiness
At the v2.1 review point, availability for distribution routes, visibility, inventory controls, compset intelligence, and white-label offerings requires confirmation. PMS is marked Planned.
White-label offerings extend the direction toward a hotel’s own booking engine, website, and loyalty program. Those offerings retain their product-specific scope and commercial terms. Activation depends on the property, connection readiness, and the scope agreed for that product.
The aim is a platform that supports new product lines while giving hotel partners clearer information and eligible controls. Adoption, operational efficiency, and the quality of decisions are the outcomes that matter beyond the interface.