Digital Product in Travel

Digital Product

Defining clear requirements for an MVP  in the Travel Industry.

Implementing technology initiatives at hospitality organizations isn’t always as straightforward as it can be in smaller, leaner organizations.

Guest preferences and generational shifts rapidly outpace the speed at which dated legacy systems can keep up with an increasingly tech-savvy traveler.

Digital Product in Travel
Digital Product in Travel

I get it – the simple thought of defining the “Version 1” of your new travel product can leave you dreaming about a daiquiri at one of your organization’s Caribbean resorts instead.

But even though hotel and timeshare organizations are notorious for having many moving parts on the back end, you can take a few steps on the business side of the house to make defining an initial state a little less daunting.

Business Process Flows

When defining the bare-minimum functionality, an agreed-upon business process flow should be your single source of truth. This doesn’t mean that it cannot change or be updated as new information is discovered during the initial design phases.

However, the easiest way to get the business and I.T. – Digital Product – aligned is to have an understanding of what steps the end-user should be able to carry out in the first version with the technology that is available to us.

Specifically for hospitality organizations, this means having high-level conversations with our Enterprise Architecture leads about what initial features can be delivered with the existing tech stack and then mapping them out in a process flow to represent the basic steps a user should be able to perform.

The example below depicts a high-level self-service reservation modification flow; a popular initiative in today’s timeshare landscape.

Digital Product
Digital Product

Lower levels of granularity inside of each organization will reveal many more moving parts than what is shown above.

However, it is good practice to have conversations around a diagram like this early on to align expectations because any Features and User Stories you write should be directly tied to the steps in the business process flow.

System-agnostic requirements

As the business SME (Subject Matter Expert) you know literally everything about the business solutions your organization uses.

You know what information they provide, and you know exactly where a frontend application should make the API call to find a guest’s status level to show them relevant offers.

So you work with your Business Analysts or Product Owners to document the exact solution in your Acceptance Criteria.

But what happens when you spend 6 months documenting requirements for the project to get shelved due an acquisition or a change in the tools being used by the organization?

By writing requirements that specifically call out a solution, you may have lost 6 months of work because your organization is making changes that have downstream effects on the tools in your tech stack; the same tools that were documented numerous times in your Acceptance Criterias.

One way to avoid this is by always writing system-agnostic requirements.

It is the idea that you can write business requirements that can be solutioned by the technical team and delivered regardless of whether you are managing inventory with “Timeshare Inventory Inc”. or with “Best Timeshare LLC”

So rather than having an acceptance criteria that says:

“Frontend must consult Best Timeshare LLC to determine the availability of the room.”

You might say:

“Frontend must consult inventory system of record to determine the availability of the room.”

In the second version, we refrain from calling out a specific tool.

This way, if we’re writing requirements for the MVP of our self-service reservation modification application, we can write the requirement today and, when the organization finishes its acquisition of Hotel XYZ, we can use their inventory system and pick up where we left off without having to rewrite requirements.

Conclusions

With complex infrastructure being a reality for most travel organizations, developing scalable MVPs as a part of a larger reservation transformation initiative can help make decent strides in the meantime.

The key is to set aside time for meaningful conversation between the business and I.T. to get the best ROI, not only from a financial perspective but also from a perspective of time.

And having a good process map and business requirements is time well spent!

Working on reservation transformation initiatives? WillDom’s the source for you!

With 10+ years’ experience connecting enterprises with best-in-class-tech talent, WillDom offers:

  • Digital product experience rooted in the Orlando hospitality market
  • A tech talent pool of over 5000 software developers and technologists

Explore our end-to-end software development solutions, and connect with us on willdom.com, and follow us on LinkedIn and Twitter!

Share This Post

Share on linkedin
Share on facebook
Share on twitter
Share on email

More To Explore