Nancy Wang is Senior Vice President, Product Operations at Hilton Grand Vacations (HGV), a market leader in the vacation ownership industry. She spent the last decade of her career working at Alert Logic, a comprehensive cybersecurity portfolio now owned by Fortra, beginning as a lead system engineer. Nancy worked her way up to principal engineer before taking on product management responsibilities and, ultimately, becoming Vice President of Technical Product Management. In her tenure, Nancy led the Alert Logic MDR product’s scale from 0 to 80 million MRR within two years.
In our chat, Nancy shares how she’s spearheaded a “cultural mind shift” away from an IT plan-build-run organization to a product-centric one. She talks about the biggest mindset shift of this process — how to tackle a problem and decide its priority — and the process of taking a fully running team and moving it to another working model. Nancy also discusses her experience frontloading the planning phase and creating an action plan ahead of an M&A.
In the non-tech companies I’ve worked for, the technology team was often referred to as “IT.” Because of that, the technology team ran more like an IT plan-build-run organization. IT is largely integrated with various functional business teams, and in that type of setup, the majority of customer needs are rendered from our functional business team.
Customer requests would come into the IT organization, and the process the team used to take was to note the ask. Because most of the time, internal team members are using the existing technology stack, they’ll say, “Hey, I don’t like this,” or “I want a new button here,” or “This doesn’t give me X functionality.” Business functional teams prescribe almost exactly what they’re looking to change in the systems. The request gets documented as a feature, and then the feature gets sized and architected for that unit of effort by itself. The process probably is not new to a traditional IT organization.
Within this whole initiation phase of the effort, it doesn’t have the steps or process to help decide, “Does this fit our overall technology roadmap? Does it make sense to add this button?” So, when you’re about to launch that feature, only at that time the cross-application implications become realized by the team.
The cultural mind shift was to change from the plan-build-run model to something that I’m very familiar with — a product-centric mindset. When you get a problem from the customer, you would take that in and ask some more questions. You’re asking me to change my application this way — why? What are you looking to do within our product that you can’t do today? What is the problem you are trying to solve? That was the biggest shift from a mindset perspective, from executing what the users are asking for directly to really understanding what problem the customer is trying to solve, then solution for the real problem.
It’s both, but it’s heavily tilted to the employees. In my experience, software companies versus non-software companies operate very differently. If you imagine you’re a hospitality company, you have all these different properties the company manages. You have employees who are doing contracting and sales. They’re using the application to deliver a service to the customer or have some interaction with the customers through the technology stack.
There’s the application for the sales teams, which is the beautiful kiosk and other touchscreen or VR applications. By the time the customer signs a contract, a hospitality company may use a contract generation application. There’s also an application to run the loan processing. All of that is another ecosystem. Further, resorts need to run on something, so some system needs to be run at the front desk to check guests in. It’s linked to a reservation system in the backend. This company may have a few different subsets of ecosystems that employees are using.
Of course, a hospitality company may also have a whole technology stack that is directly customer-facing — like a member website and mobile app, which are directly interacting with the customer. In those cases, the company can receive feedback directly from the customers. But in a lot of cases, the internal teams may rely on a technology stack to provide good customer experience from sales to reservation to managing resorts. And those systems are more internal-facing versus customer-facing.
How do you take a running team and move them to another working model?
First, you need to have the right team structure in place. In an IT plan-build-run organization, there’s a team that does business relationships and documents the problems, and then a team that does analysis and writes the stories and requirements down. We didn’t have a team or a process within the overall flow to say, “Let’s ask them more questions. What problem are you trying to solve? We’ll maintain and innovate a technology roadmap for the whole organization to work off of.”
In my experience, when I’ve joined a company with this model, I’d first form a dedicated product management team within the technology organization. We arranged the team with both existing employees as well as new hires from other industries who had deep experience in product management. We established, holistically, what the product management function actually means and what it means to the organization.
The second key step is to standardize so the team is operating in a unified fashion from a process and tooling perspective. After a product management team was formed, the company could deploy programmatic product management training courses across the various teams within the product management group, which I’d done in my previous job. It was focused on general product management workflow, processes, and tooling. Without those things, the team can’t know what’s an overall priority for the various efforts in flight that way. Aligning on an overall strategic priority and a unified roadmap that’s well understood with the right tooling is really important.
Lastly, it is crucial to lead by example. I’m a believer in leading in the middle, so I do like to get into the various product workstreams and understand them, especially for the higher priority efforts. I give the team a bit of a push to get them started on the new process and mindset. I see success with that.
I helped my last company through a successful acquisition. My last company was a SaaS-based cybersecurity company called Alert Logic, which specializes in managed detection and response. We were acquired by a larger company called Fortra, which was on a streak of buying cybersecurity providers to complete its portfolio. When an acquisition like this happens, the acquiring company does not always decide to integrate the companies together and merge the portfolio. Rather, they focus more on operating cost synergy.
At some places I’ve worked, we’ve gone through acquisitions of other companies. In those scenarios, it’s important to bring employees from the acquired company along in the integration journey and have them focus on more of an integration roadmap early on. One, for their expertise, and two, because it will give everyone a common goal to go after. It’s beneficial for both the company and those individuals because they’re now working on a more long-term, strategic roadmap.
Normally, prior to an acquisition, the existing team would be working on the existing roadmap to keep current customers and employees satisfied. With that, it’s important to not jeopardize how the team spends their day-to-day. When you integrate teams, there’s a whole new bucket of strategic work to prioritize across the company. It’s good practice to have representatives from both the parent company and the acquired company work together on the integration efforts. That way,employees from both sides can bring their expertise and work together on system integration.
On top of that, it can be helpful to employ some consulting firms. Right after an acquisition, companies may need a boost of resources to plan the overall integration effort and perform system discovery. The planning piece is quite key from a technology perspective, and a lot of the other teams’ integration depends on that technology integration. The pressure goes on the technology team to figure out things like overall timing and cost. The company as a whole needs to be able to forecast and plan alongside other milestones accordingly. So it’s a couple of different teams working together and frontloading the planning phase to create an action plan. Then you can decide how to staff it, etc.
Normally, I have a group of customers who are selected to represent the needs of different customer groups and profiles. Companies often host events and customer advisor boards to review upcoming roadmaps and features with customers. This is a great way to gather feedback to help shape the upcoming release and experiences. We do this currently as well, and during some of these events, our product managers and UX staff attended to show customers the next version of our member website and collect feedback from them in person. We also get feedback from sales executives in the sales centers. As we build our future roadmap and product backlog, we take the customer and team members’ input into account.
The four key KPIs or guiding principles are to deliver against our established or committed roadmap on time, in scope, in full, and within budget. Easier said than done, right? As a product person, a lot of times, you either need to sacrifice either time or scope. It is not easy. Because we’re now standardized on the product management tool, we have readily available dashboards and charts that we can look at.
When I was pulling a year-end readout, I saw a clear growth in the number of features released throughout the year. Even though features can be big or small, that shows that the team is steadily growing in terms of the velocity. That’s another KPI I look at.
We look at customer success metrics as well. We are now starting to establish those within the product, as well as the outside of the product from a more human engagement perspective. That will give us guidance around both ratings and feedback from the customer.
For the internal system, we use NPS, but we do have a customer-facing part of our application, the member website, and mobile app. We also have quite an active Facebook user group. We get feedback from our selected members by sending out surveys, and, within the UI, we build in analytics. We look at analytics to see what members use the most on our sites. We also have a UX team reviewing that to figure out how we can improve the overall flow of the website.
I think it’s twofold. First, with anything, communication is key — especially for a large organization like ours. Everybody is busy, and there are a lot of functional teams to communicate with. Within those teams, you also have different leadership levels that you need to communicate with. Establishing a steering committee and communication cadence that makes sense to each team is important to ensure you have those different levels of conversation.
For example, product managers will have broad stakeholder meetings with the working team. You also want to make sure senior executive leadership is kept up-to-speed about the overall status, as well as about the decisions the team is making.
Second, it’s key to reduce the “silo conversation” as much as possible. That’s also a culture shift. Because when you’re launching a software release or a new product, it doesn’t matter what level the audience that you’re targeting is on. It doesn’t matter what team they’re on. They will be affected. They’re going to receive the software launch in a pretty unified fashion, so establish the stakeholder cadence to say, “Hey, you need to join this meeting to understand what’s going on.” And make it effective as well. Establish that launch readiness cadence so people know that this is an important meeting, or this is a stakeholder training demo I should probably pay attention to. Have that plan well laid out and standardized.
Have a unified launch readiness plan so people know the documentation repository they should go to for the latest tutorials and videos if they want to catch up.
I am very excited about what AI can bring to the industry and our economy as a whole. From a company operation perspective, we can use more and more AI-based technologies to ramp up efficiency in our daily communication. For example, AI can help send an email with pre-compiled action items or help us process information faster. One common use case is providing AI reports and we can ask it to summarize the information and draw conclusions from the data. That saves a ton of time and it’s pretty easy to do.
I am also excited about what AI can do to the broader industry as a whole. A lot of companies are now starting to adopt AI and chatbots in a lot of broad use cases. For the companies who have customer data, AI opens up the potential to build more personalized experiences for customers. And the boom in native support for various software vendors is going to also boost the innovation for companies in many different industries as well. This is just the beginning — I am super excited for what AI can do for our future innovation and technology stack.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Want to get sent new PM Leadership Spotlights when they come out?
Hypergrowth happens when a company experiences an exceptionally rapid rate of expansion, typically more than 40 percent annual growth.
Detractors have long-term effects like negative brand perception, reduced customer loyalty, and a decrease in sales.
To proactively address liability concerns, you can create an internal product recall team for dealing with risks and ensuring quality.
Our Galileo AI Fall ’24 release makes Highlights available to all Pro and Enterprise customers. We’re also debuting Ask Galileo, which enables you to directly ask questions about what you see in session replays.
Learn more →
